«DEFROUTE = yes» в обоих интерфейсах не делает того, что вы думаете.
Перезагрузитесь (чтобы очистить все, что вы сделали) и запустите "ip route".
Вы должны увидеть что-то вроде:
# 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
Когда вы запускаете команду «ping -I eth1 8.8.8.8», поскольку система не настроена на использование шлюза по умолчанию, доступного через eth1, запросы ARP отправляются всем интерфейсам для поиска 8.8.8.8 в локальной сети:
# 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
(Очевидно, что DNS-сервер Google не находится в той же подсети, что и ваш VPS.)
Продолжайте и попробуйте добавить второй маршрут по умолчанию:
# ip route add default via 185.8.49.1 dev eth1
RTNETLINK answers: File exists
Похоже, система не с готовностью примет несколько маршрутов по умолчанию.
И в этом есть какой-то смысл - как еще устройство узнает, через какой из его нескольких шлюзов отправлять пакет?
Будет ли отправлять копию на шлюз ... а затем иметь дело с несколькими возвращаемыми пакетами? Или он будет отправлять пакеты произвольно, недетерминированным образом (кошмар для устранения неполадок)?
Предположительно, он может балансировать нагрузку, поэтому давайте попробуем это:
#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
...
Но работает ли это?
# 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
ТА-ДА!
Теперь вы сами решаете, действительно ли балансировка нагрузки - это то, что вам действительно нужно и вы готовы поддержать.
