Hoje consegui um VPS com 2 endereços IP.
O IP ativado eth0está funcionando quando eu ping -I eth0 www.google.comtenho 0% de perda de pacotes, mas quando isso acontece, ping -I eth1 www.goole.comtenho 100% de perda de pacotes.
Esta é a ifconfigsaída:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 185.8.49.12 netmask 255.255.255.0 broadcast 185.8.49.255
inet6 fe80::250:56ff:fe84:5ed6 prefixlen 64 scopeid 0x20<link>
ether 00:50:56:84:5e:d6 txqueuelen 1000 (Ethernet)
RX packets 5716 bytes 398892 (389.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 933 bytes 294738 (287.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 185.8.49.157 netmask 255.255.255.0 broadcast 185.8.49.255
ether 00:50:56:84:5e:d7 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 56 bytes 8896 (8.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 56 bytes 8896 (8.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Esta é a saída de ifcfg-eth0:
DEVICE=eth0
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"
BOOTPROTO=none
IPADDR=185.8.49.12
NETMASK=255.255.255.0
GATEWAY=185.8.49.1
DNS1=62.149.128.4
DNS2=62.149.132.4
E esta é a saída de ifcfg-eth1:
DEVICE=eth1
NM_CONTROLLED=no
ONBOOT=yes
TYPE=Ethernet
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth1"
BOOTPROTO=none
IPADDR=185.8.49.157
NETMASK=255.255.255.0
GATEWAY=185.8.49.1
Tentei reiniciar o sistema, mas nada funciona.
Responder1
"DEFROUTE=yes" em ambas as configurações de interface não faz o que você pensa.
Reinicie (para limpar qualquer alteração que você tenha feito) e execute "ip route".
Você deverá 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 da eth1, as solicitações ARP são enviadas a 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 do 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 aceitará prontamente várias rotas padrão.
E isso faz algum sentido – de que outra forma o dispositivo saberia através de qual dos seus múltiplos gateways enviar um pacote? Ele enviaria uma cópia por gateway... e então lidaria com vários pacotes de retorno? Ou enviaria pacotes arbitrariamente, de forma não determinística (um pesadelo para solucionar problemas)?
Presumivelmente, poderia carregar o equilíbrio, 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 precisoe estão dispostos a apoiar.