Hoy obtuve un VPS con 2 direcciones IP.
La IP encendida eth0funciona cuando lo hago, ping -I eth0 www.google.comobtuve una pérdida de paquetes del 0%, pero cuando lo hago, ping -I eth1 www.goole.comobtuve una pérdida de paquetes del 100%.
Esta es la ifconfigsalida:
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 es la salida 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
Y este es el resultado 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
Intenté reiniciar el sistema pero nada funciona.
Respuesta1
"DEFROUTE=yes" en ambas configuraciones de interfaz no hace lo que crees.
Reinicie (para borrar cualquier modificación que haya realizado) y ejecute "ip route".
Deberías 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
Cuando emite "ping -I eth1 8.8.8.8", debido a que el sistema no está configurado con una puerta de enlace predeterminada accesible desde eth1, las solicitudes ARP se envían a todas las interfaces para encontrar 8.8.8.8 en la red 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, el servidor DNS de Google no está en la misma subred que su VPS).
Continúe e intente agregar la segunda ruta predeterminada:
# ip route add default via 185.8.49.1 dev eth1
RTNETLINK answers: File exists
Parece que el sistema no acepta fácilmente múltiples rutas predeterminadas.
Y eso tiene cierto sentido: ¿de qué otra manera sabría el dispositivo a través de cuál de sus múltiples puertas de enlace enviar un paquete? ¿Enviaría una copia por puerta de enlace... y luego manejaría múltiples paquetes de devolución? ¿O enviaría paquetes de forma arbitraria, de forma no determinista (una pesadilla para solucionar el problema)?
Presumiblemente podría equilibrar la carga, así que intentémoslo:
#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
...
¿Pero 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!
Ahora depende de usted decidir si el equilibrio de carga es algo querealmente necesitoy estamos dispuestos a apoyar.