☰

Paquete de respuesta en la misma interfaz que el entrante en LAN

tag-icon • tag-icon linux networking linux-networking iproute2 policy-routing
Paquete de respuesta en la misma interfaz que el entrante en LAN

Actualmente, estoy luchando con el siguiente escenario:

  • Tengo un servidor con 2 interfaces en 2 subredes LAN separadas. SI1, SI2
  • Tengo una computadora portátil que tiene una dirección IP de la primera subred.
  • Cuando intento conectarme desde esta computadora portátil en particular a la segunda dirección IP del servidor, no obtengo ninguna respuesta.

Por ejemplo, cuando intento hacer ping a 172.31.196.185 desde la computadora portátil con IP 172.31.190.129, puedo ver solicitudes entrantes en tcpdump en la interfaz ens224, pero no hay ninguna solicitud de respuesta en ninguna otra interfaz después de eso.

Aquí está mi diagrama de red:

       +-------------------------+
       |                         |
       |  Laptop 172.31.190.129  +---------+
       |                         |         |
       +-------------------------+         |
                                           |                 +-------------------------+
                                           |                 |                         |
                               +-----------+---------+       |       Linux Server      |
                          +----+                     |       |                         |
                          |    | LAN 172.31.190.0/23 +-------+ IF1  -  default gw      |
                   +------+--+ |                     |       | 172.31.190.63           |
    +----------+   |         | +---------------------+       |                         |
    | Internet +---+ Gateway |                               |                         |
    +----------+   |         | +---------------------+       |                         |
                   +------+--+ |                     |       |                         |
                          |    | LAN 172.31.196.0/23 +-------+ IF2                     |
                          +----+                     |       | 172.31.196.185          |
                               +---------------------+       |                         |
                                                             |                         |
                                                             |                         |
                                                             +-------------------------+

Además, tengo este script:

IF1=ens160
IF2=ens224

P1_NET=172.31.190.0/23
P2_NET=172.31.196.0/23

IP1=172.31.190.63
IP2=172.31.196.185

P1=172.31.190.1
P2=172.31.196.1

ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2

ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2

ip rule add from $P1_NET dev $IF1 table T1
ip rule add from $P2_NET dev $IF2 table T2

Que está escrito de acuerdo con este enlace:https://lartc.org/howto/lartc.rpdb.multiple-links.html

En mi caso, probé muchas formas diferentes de realizar un enrutamiento basado en políticas, pero ninguna tuvo éxito...

Respuesta1

TL;DR

No hay necesidad deiptables, marcas, ni para relajarseReenvío/filtro de ruta inversa. En lugar del ip rulecorreo electrónico que usó, que no coincide con los paquetes salientes, use los comandos como se describe en laDocumentación de LARTCenlace que proporcionaste:

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

entonces todo funcionará bien.

Versión larga

Incluso si siempre es posible permitir que las cosas funcionen relajándoseReenvío/filtro de ruta inversausando por ejemplosysctl -w net.ipv4.conf.all.rp_filter=2etc., permitiendo así el enrutamiento asimétrico, siempre se debe evitar el enrutamiento asimétrico. Especialmente considerando que elPuerta(si actúa como firewall con estado estricto) o elComputadora portátilEs posible que tampoco lo permita por razones similares. Usandoiptablesy las marcas para corregir un comportamiento incorrecto ciertamente no ayudarán a comprender cómo se comportará la ya compleja configuración de enrutamiento.

Si bien la documentación vinculada utiliza la IP del servidor como fuente (por $IF2/ens224: 172.31.196.185)sin interfazpara la regla ip, está especificando la interfaz entrante en la regla ( devsignifica iifaquí). Ésa es la cuestión: esto no tiene el efecto que uno espera que suceda. Ver la descripción de iifenip rule:

siNOMBRE

seleccione el dispositivo entrante que coincida.Si la interfaz es de bucle invertido, la regla solo coincide con los paquetes que se originan en este host. Esto significa que puede crear tablas de enrutamiento separadas para paquetes locales y reenviados y, por lo tanto, segregarlos por completo.

Si bien no está escrito claramente, ocurre lo contrario: paquetesoriginariode este host solo coincidirán con la interfaz loopback: no coincidirán con iif ens160ni iif ens224, sino solo iif lo(sí iifsignificaentranteinterfaz y iif locoincidencias generadas localmenteextrovertidopaquetes, considere que esto se traduce como "entrante desde el sistema local [hacia donde las reglas de enrutamiento lo indiquen]"). Esto sí importa.

Qué pasa entonces:

  1. Computadora portátilintenta llegar a $IP2 (no sabe ni debería saber que se podría llegar a $IP2 a través de $IF1 y $IP1 del servidor en la misma LAN), envía el paquete a través dePuerta,

  2. Puertaenruta el paquete al $IP2 del servidor que pertenece a $P2_NET, a su interfaz $IF2,

  3. Servidorrecibe un paquete que pertenece a $P1_NET (de 172.31.190.129) en la interfaz $IF2,

  4. ServidorEl estricto camino inversorp_filter=1comprueba la ruta inversa,

  5. Como se ve arriba, ruta inversano coincideCualquiera iifdiferente a iif lo: las dos nuevas reglas no coinciden, por lo que la única regla coincidente restante es la regla para la tabla de enrutamiento principal: a través de $IF1, como se verifica con:

     # ip route get 172.31.190.129 from 172.31.196.185
 172.31.190.129 from 172.31.196.185 dev ens160 uid 0 
     cache

  6. La ruta inversa no utiliza la interfaz desde la que llegó el paquete: el paquete se descarta.

Por las mismas razones, esta configuración actual no permitirá un correcto acceso a Internet desdeServidoral usar $IP2: nuevamente no coincidirá con las nuevas reglas e intentará usar $IF1 para esto:

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.190.1 dev ens160 uid 0 
    cache

Entonces, una vez que las dos reglas se eliminan y cambian, como se documenta en LARTC, a:

ip rule add from $IP1 table T1
ip rule add from $IP2 table T2

Eso es:

# ip rule add from 172.31.190.63 table T1
# ip rule add from 172.31.196.185 table T2

Todo funcionará correctamente, como lo indicará una búsqueda de ruta (ahora usando table T2):

# ip route get 172.31.190.129 from 172.31.196.185
172.31.190.129 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache 

# ip route get 8.8.8.8 from 172.31.196.185
8.8.8.8 from 172.31.196.185 via 172.31.196.1 dev ens224 table T2 uid 0 
    cache

Esas 3 variantes también podrían haber funcionado (simplemente colocando la regla en la tabla T2 para mayor brevedad):

ip rule add from 172.31.196.0/23 table T2
ip rule add from 172.31.196.185 iif lo table T2
ip rule add from 172.31.196.0/23 iif lo table T2

Tenga en cuenta que, como se documenta en la página de manual, iif loalterará el comportamiento siServidortambién está enrutando otros sistemas detrás de él (nuevamente, las reglas no coincidirán con esos sistemas): mejor no usarlo a menos que sea necesario.

No hay necesidad deiptablesy notas por esto. El uso de marcas para cambiar la interfaz puede causar problemas adicionales con el enrutamiento, las solicitudes ARP y el filtrado de ruta inversa (el uso de marcas generalmente requiere relajarse).filtro_rp), así que mejor no usarlos si se puede evitar.

información relacionada