☰

¿Por qué esta configuración de enrutamiento no funciona?

tag-icon • tag-icon linux routing linux-networking
¿Por qué esta configuración de enrutamiento no funciona?

Tengo dos interfaces en la máquina servidor. La salida de ip routees la siguiente:

default via 192.168.100.1 dev enp1s0 proto static metric 100
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.1
192.168.100.0/24 dev enp1s0 proto kernel scope link src 192.168.100.201 metric 100

y ip addresses el siguiente (los MAC están ocultos):

...
1: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.201/24 brd 192.168.100.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::1409:66c6:eb0d:22a1/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/ether **:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tap0
       valid_lft forever preferred_lft forever
    inet6 fe80::85:5fff:fe98:6cb7/64 scope link
       valid_lft forever preferred_lft forever

El /proc/sys/net/ipv4/ip_forwardvalor es 1; El cortafuegos está desactivado.

Lo que quiero es acceder192.168.100.1de10.8.0.100. Acceder al servidor web (que escucha todos los puertos de esta máquina) curl --interface 10.8.0.100 http://10.8.0.1funciona bien. Pero curl --interface 10.8.0.100 http://192.168.100.201la producción es Network unreachable.

Curl inicia un protocolo de enlace TCP y envía un paquete a10.8.0.100interfaz. Luego, el paquete llega a la máquina servidora en10.8.0.1. El servidor mira el destino del paquete y ve que está192.168.100.201. Luego mira la tabla de enrutamiento y ve que192.168.100.201es local. Ahora la respuesta va hacia atrás. El remitente fue10.8.0.100. Al observar la tabla de enrutamiento, podemos encontrar que se puede acceder a ella a través de tap0, que es local. Entonces ahora ingresa tap0y llega a 10.8.0.100.

Pero en realidad -no lo es. ¿Es esto porque mi línea de pensamiento está equivocada? Pensé que la información proporcionada por la tabla descrita es suficiente para determinar cómo reenviar paquetes. ¿Está esto realmente incompleto?

Respuesta1

En primer lugar, proporcionar la dirección IP y la interfaz con el parámetro -I pingno son sinónimos. Primero dice cuál source IPelegir. Lo enrutará según el flujo neto, incluidas las direcciones locales y las tablas de enrutamiento. El segundo le indica que elija directamente la interfaz a la que enviar el paquete (y elegirá la primera IP asignada como fuente).

A continuación, lo que estás haciendo no tiene nada que ver con el reenvío de paquetes. Reenviar significa que el paquete tiene que llegar realmente desde "exterior". Como está generando un paquete desde este host, no hay ningún reenvío involucrado. Es un paquete generado localmente. Como su IP de destino es una de las direcciones asignadas localmente, cuando no fuerza el ping para enviar paquetes a una interfaz específica "externa" (con -I interfaceopción), el kernel procesará este flujo de paquetes internamente. Simplemente no intentará enviarlo a una interfaz real ya que su destino "ya está aquí". Entonces esto es lo que sucede y por qué funciona en un caso y no en otro.

PD: consulte también la -ropción de la pingherramienta en caso de que sepa que lo está haciendo y ambas interfaces están conectadas al mismo dominio de transmisión (lo dudo con la interfaz TAP).

Respuesta2

El problema fue la falta de comprensión de la diferencia entre --interface IPy --interface dev. El primero usa la tabla de enrutamiento:

con --interface 10.8.0.100el paquete no se reenviará a tap0la interfaz (a la que pertenece esta ip). En cambio, de acuerdo con la tabla de enrutamiento, se reenviará a 192.168.100.58(la interfaz LAN). Entonces la ruta es 10.8.0.100 -> 192.168.100.58 -> 192.168.100.201. Incluso el hecho de que se entregó SYN, el servidor extrañamente no responderá con SYN-ACK; esa es la razón por la que curl falla.

Usando --interface tap0, es decir, la dirección de la capa de enlace, funcionará según lo previsto: 10.8.0.100 -> 10.8.0.1 -> 192.168.100.201. El SYN-ACK se devolverá utilizando la misma ruta.

información relacionada