Hacer ping a la dirección IP en otra interfaz que no sea la que recibe la señal

Hacer ping a la dirección IP en otra interfaz que no sea la que recibe la señal

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 netstates 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 routecomando (ver route /?)

información relacionada