Tengo PCa y PCb.
CaP:
$> ip addr && ip route
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:13:3b:0f:24:fc brd ff:ff:ff:ff:ff:ff
inet 192.168.3.150/24 brd 192.168.3.255 scope global eth6
valid_lft forever preferred_lft forever
inet6 fe80::213:3bff:fe0f:24fc/64 scope link
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether f8:b1:56:ba:ae:ee brd ff:ff:ff:ff:ff:ff
inet 192.168.10.150/24 brd 192.168.10.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.1.150/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
inet 172.18.0.150/24 scope global eth0
valid_lft forever preferred_lft forever
inet6 2a00:801:19:1:288f:db46:14ef:cca8/64 scope global temporary dynamic
valid_lft 546270sec preferred_lft 27270sec
inet6 2a00:801:19:1:50c3:7b14:61bc:1bc0/64 scope global temporary deprecated dynamic
valid_lft 460473sec preferred_lft 0sec
inet6 2a00:801:19:1:fab1:56ff:feba:aeee/64 scope global dynamic
valid_lft 2591993sec preferred_lft 604793sec
inet6 fe80::fab1:56ff:feba:aeee/64 scope link
valid_lft forever preferred_lft forever
5: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default
link/gre 10.110.2.204 brd 10.110.0.115
6: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
7: netgw@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1256 qdisc noqueue state UNKNOWN group default
link/gre 10.110.1.222 peer 10.110.0.115
inet 192.168.4.1/24 scope global netgw
valid_lft forever preferred_lft forever
default via 172.18.0.1 dev eth0
169.254.0.0/16 dev eth6 scope link metric 1000
172.18.0.0/24 dev eth0 proto kernel scope link src 172.18.0.150
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.150
192.168.3.0/24 dev eth6 proto kernel scope link src 192.168.3.150
192.168.5.0/24 dev netgw scope link
192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.150
Tarjeta de circuito impreso:
bash# ip addr && ip route
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:05:68:02:68:dd brd ff:ff:ff:ff:ff:ff
inet 192.168.3.1/24 brd 192.168.3.255 scope global eth0
3: tunl0: <NOARP> mtu 1480 qdisc noop
link/ipip 0.0.0.0 brd 0.0.0.0
4: gre0: <NOARP> mtu 1476 qdisc noop
link/gre 0.0.0.0 brd 0.0.0.0
5: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:05:68:03:68:dd brd ff:ff:ff:ff:ff:ff
inet 192.168.3.2/24 brd 192.168.3.255 scope global eth1
7: netpc@NONE: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue
link/gre 10.110.0.115 peer 10.110.1.222
inet 192.168.5.1/24 scope global netpc
19: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1280 qdisc pfifo_fast qlen 3
link/ppp
inet 10.110.1.16 peer 192.168.111.111/32 scope global ppp0
192.168.111.111 dev ppp0 proto kernel scope link src 10.110.1.16
10.99.196.40 dev ppp0 scope link
8.8.8.8 dev ppp0 scope link
192.168.4.0/24 dev netpc scope link
192.168.3.0/24 dev eth0 proto kernel scope link src 192.168.3.1
172.18.0.0/24 dev eth0 scope link
224.0.0.0/4 dev eth0 scope link
PCa, eth6 está conectado a PCb, eth0 mediante un cable Ethernet.
Ahora,ping 172.18.0.150 en PCbda:
bash# ping 172.18.0.150
PING 172.18.0.150 (172.18.0.150) 56(84) bytes of data.
64 bytes from 172.18.0.150: icmp_seq=1 ttl=64 time=4.31 ms
64 bytes from 172.18.0.150: icmp_seq=2 ttl=64 time=0.848 ms
Entonces el ping se apagaeth0 en PCSupongo y entroeth6 en PCa. La cosa es que eseth0 en PCaque tiene el172.18.0.150Dirección IP. ¿Cómo es que recibo una respuesta deeth0 en PCa, cuandoeth0 en PCestá realmente conectado coneth6 en PCa?
¿No está la IP únicamente vinculada a la propia interfaz? Es este el comportamiento esperado? No importa los túneles y esas cosas...
Respuesta1
Sí, es el comportamiento esperado. La respuesta de ping es un paquete IP por derecho propio y no está de alguna manera especialmente conectada al paquete al que responde. Los paquetes IP no forman "circuitos" para las siguientes respuestas, cada paquete se enruta de forma independiente.
El enrutamiento asimétrico es muy común en Internet. Por ejemplo, con el tráfico que cruza un país, la red de destino suele realizar el transporte de larga distancia. Entonces, si hago ping a un servidor en el otro lado del país, su proveedor lleva la consulta a todo el país, pero mi proveedor lleva la respuesta a todo el país. Entonces las dos rutas son muy, muy diferentes. No hay ninguna razón especial por la que un camino deba parecerse al otro.
Respuesta2
Creo que esto tiene más que ver con la puerta de enlace predeterminada si usas Linux. Como todas las interfaces están en el mismo host, cualquier tráfico saliente se realizará a través de la puerta de enlace predeterminada y su interfaz asociada.
Entonces, lo que eso significa es que, aunque se hizo ping a una dirección IP particular, la respuesta llegó a través de la puerta de enlace predeterminada, lo que significa que vino de la interfaz asociada con la puerta de enlace predeterminada.
Pruebe lo siguiente para ver la ruta predeterminada y las interfaces utilizadas para una dirección IP determinada.
ip route
Ejecute como root o usando sudo
.
Respuesta3
¿Tiene esto algo que ver con scobe global/scope link, etc.?
Probablemente tenga que ver con tablas de enrutamiento y métricas. Intentar
netstat -nr
en un símbolo del sistema en PCb
Espero que PCb esté convencido de que su interfaz Eth2 está "más cerca" que Eth1 de PCa.
La métrica que se muestra en el resultado de netstat
es una medida de la conveniencia de una ruta. Solía ser un recuento de saltos, pero es mejor considerarlo como un valor de prioridad, ya que los diferentes protocolos de enrutamiento miden el costo de las rutas de diferentes maneras.
Puede manipular temporalmente las tablas de enrutamiento usando el route
comando (ver route /?
)