"DEFROUTE = yes" em ambas as configurações de interface não faz o que você acha que faz.
Reinicialize (para limpar qualquer ajuste que você tenha feito) e execute "ip route".
Você deveria ver algo como:
# ip route
default via 185.8.49.1 dev eth0
185.8.49.0/24 dev eth0 proto kernel scope link src 185.8.49.12
185.8.49.0/24 dev eth1 proto kernel scope link src 185.8.49.157
Quando você emite "ping -I eth1 8.8.8.8", porque o sistema não está configurado com um gateway padrão acessível fora de eth1, as solicitações ARP são enviadas para todas as interfaces para localizar 8.8.8.8 na rede local:
# ping -I eth1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 185.8.49.157 eth1: 56(84) bytes of data.
From 185.8.49.157 icmp_seq=1 Destination Host Unreachable
From 185.8.49.157 icmp_seq=2 Destination Host Unreachable
From 185.8.49.157 icmp_seq=3 Destination Host Unreachable
From 185.8.49.157 icmp_seq=4 Destination Host Unreachable
# tcpdump -ni eth0 'arp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
05:07:42.821526 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 46
05:07:43.821185 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 46
05:07:44.823000 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 46
# tcpdump -ni eth1 'arp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
05:07:42.820834 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 28
05:07:43.820864 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 28
05:07:44.822841 ARP, Request who-has 8.8.8.8 tell 185.8.49.157, length 28
(Obviamente, o servidor DNS do Google não está na mesma sub-rede que o seu VPS.)
Vá em frente e tente adicionar a segunda rota padrão:
# ip route add default via 185.8.49.1 dev eth1
RTNETLINK answers: File exists
Parece que o sistema não aceita prontamente várias rotas padrão.
E isso faz algum sentido - de que outra forma o dispositivo saberia através de quais de seus múltiplos gateways enviar um pacote?
Ele enviaria uma cópia por gateway ... então lidaria com vários pacotes de retorno? Ou enviaria pacotes arbitrariamente, de maneira não determinista (um pesadelo para solucionar problemas)?
Presumivelmente, poderia balancear a carga, então vamos tentar isso:
#ip route delete default
#ip route add default scope global nexthop via 185.8.49.1 dev eth0 weight 1 nexthop via 185.8.49.1 dev eth1 weight 1
#ip ro
default
nexthop via 185.8.49.1 dev eth0 weight 1
nexthop via 185.8.49.1 dev eth1 weight 1
...
Mas isso funciona?
# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=17.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=18.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=17.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=15.3 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 15.337/17.227/18.762/1.241 ms
# tcpdump -ni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
05:46:31.837933 IP 185.8.49.12 > 8.8.8.8: ICMP echo request, id 2382, seq 1, length 64
05:46:31.855566 IP 8.8.8.8 > 185.8.49.12: ICMP echo reply, id 2382, seq 1, length 64
05:46:33.842373 IP 185.8.49.12 > 8.8.8.8: ICMP echo request, id 2382, seq 3, length 64
05:46:33.859469 IP 8.8.8.8 > 185.8.49.12: ICMP echo reply, id 2382, seq 3, length 64
# tcpdump -ni eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
05:46:32.840535 IP 185.8.49.157 > 8.8.8.8: ICMP echo request, id 2382, seq 2, length 64
05:46:32.859029 IP 8.8.8.8 > 185.8.49.157: ICMP echo reply, id 2382, seq 2, length 64
05:46:34.843725 IP 185.8.49.157 > 8.8.8.8: ICMP echo request, id 2382, seq 4, length 64
05:46:34.859020 IP 8.8.8.8 > 185.8.49.157: ICMP echo reply, id 2382, seq 4, length 64
TA-DA!
Agora cabe a você decidir se o balanceamento de carga é algo que você realmente precisa e está disposto a dar suporte.