¿Afecta la selección de la interfaz de salida en o después de la cadena POSTROUTING?

¿Afecta la selección de la interfaz de salida en o después de la cadena POSTROUTING?

Tengo un sistema que aloja varias instancias KVM. Todos estos están conectados a un único puente (digamos, brvirt), al que también está conectado eth1. Este entorno de capa 2 está en una red privada que utiliza 172.16.10.0/24 para un cambio de dirección. Hay otras dos interfaces en el sistema a las que llamaremos eth0(10.10.10.10) y eth2(10.10.20.20).

En general, la conectividad externa se proporciona a través SNATde la dirección de eth0(y la puerta de enlace predeterminada de los hosts también está fuera de esta interfaz). Paraalgunos sistemas, Quiero una SNATregla 1-1 explícita en la red 10.10.20.0/24, que está adjunta a eth2.

Esto es un problema porque cuando llegamos a la POSTROUTINGcadena para realizar la SNATselección de la interfaz de salida ya se ha realizado. El kernel ya ha seleccionado la ruta predeterminada (asumiendo una conexión a algo que no sea una red conectada directamente), lo que significa que cuando la SNATregla modifica la dirección IP de origen, la infraestructura de enrutamiento local descarta el paquete porque se origina en la capa 2 incorrecta. red.

¿Hay alguna manera de evitar esto? Lo que yoen realidadLo que quiero hacer es tomar decisiones de enrutamiento basadas en la dirección de origen del paquete al final de la POSTROUTINGcadena... pero se llama POSTROUTINGpor una buena razón.

Respuesta1

Esto se puede hacer con un enrutamiento simple basado en políticas.

Necesitará un conjunto de reglas y rutas con el esquema:

ip rule add from 172.16.10.X iif brvirt lookup 200
ip route add default via 1.2.3.4 src 4.3.2.1 dev ethY table 200

Variables:

172.16.10.X = KVM's IP
200         = Example value for routing_table, has to be unique for each KVM
ethY        = either eth0 or eth2
1.2.3.4     = Example Gateway on iface ethY
4.3.2.1     = Example Source-IP for each KVM

Esto enrutará cualquier cosa que provenga 172.16.10.Xdel iface especificado ethYcon la dirección de origen de4.3.2.1

También puedes hacerlo más complejo, fwmarkspero no creo que sea necesario en este caso.

Puedes verificar las rutas con: ip route get iif brvirt from 172.16.10.X 8.8.8.8. Esto mostrará la ruta y el dispositivo de salida que el kernel usaría para una conexión desde 172.16.10.Xa 8.8.8.8.

Espero que responda a tu pregunta,

f0o

información relacionada