Enrutamiento por origen para dos grupos VPN: qué se le escapa a su regla
Una regla de la forma from coincide con la dirección del cliente antes de que SNAT la reescriba, y una prueba desde la puerta de enlace no coincide con ninguna de las dos. Ejecute la consulta por grupo y lea las prioridades en su lugar.
Dos grupos de clientes, una puerta de enlace y el plan parece trivial: una regla envía el primer grupo por el enlace rápido, otra envía el segundo grupo por un túnel de socio. Luego las reglas están puestas y el segundo grupo sigue saliendo por la ruta por defecto. La regla no está rota. El origen del paquete no es lo que el autor esperaba en el momento de la consulta, porque la traducción y la consulta ocurren en puntos distintos del recorrido del mismo paquete, y el orden es el contrario del diagrama mental que dibuja la mayoría.
La consulta ocurre antes de que se reescriba el origen
Para un paquete reenviado desde un cliente VPN, el núcleo ejecuta una secuencia fija. Llega a la interfaz del túnel, pasa por prerouting, donde viven conntrack y DNAT, después se toma la decisión de enrutamiento, después el reenvío, después postrouting, donde SNAT se aplica al final. Una regla de la forma from se consulta durante esa decisión de enrutamiento, lo que significa que ve la dirección original del cliente, no la traducida.
Así que añadir una regla de masquerade no cambia qué política coincide con el flujo saliente. Lo que cambia es lo que ve el extremo remoto y, por tanto, qué camino de vuelta existe. Son dos consecuencias distintas, y las revisiones de cambios las confunden constantemente. Sepárelas y el diseño suele quedar claro en un minuto.
Es en la dirección de respuesta donde la dirección traducida aparece en las reglas. Un paquete que vuelve a la puerta de enlace va dirigido a la dirección traducida, y si tiene reglas de política basadas en el destino o en la interfaz por la que llegó, ese es el valor que va a comparar. La misma conexión, una fuente de verdad distinta en cada dirección.
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
Dos grupos con orígenes distintos sí necesitan tablas distintas, y el diseño es sólido. Lo que la tabla anterior descarta es el atajo de depurar mirando qué recibió el sitio remoto y deducir la regla a partir de eso.
Una prueba desde la puerta de enlace no es una prueba del grupo
El tráfico que genera la propia puerta de enlace nunca pasa por prerouting, porque no llegó por ninguna interfaz. Se enruta en la ruta de salida, con la dirección de la propia puerta de enlace como origen, y una regla from basada en un rango de clientes no coincidirá. Cada ticket de este ámbito que dice que funciona desde la máquina pero no desde el cliente es ese mismo hecho repetido.
Simule el cliente en lugar de aproximarlo. La consulta de enrutamiento puede preguntarse directamente, con un origen y una interfaz de entrada:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201
Ejecútelo una vez por grupo. Si los dos comandos devuelven la misma interfaz, las reglas no separan los grupos, y el motivo es o una regla que falta o una regla de mayor prioridad que coincide con ambos. Si devuelven interfaces distintas pero el cliente sigue fallando, el fallo está después de la consulta y puede dejar de mirar las reglas.
Prioridad, no posición en el archivo
Las reglas se evalúan en orden ascendente de prioridad, y el número es lo que importa, no el orden en que las escribió. La tabla local está en la prioridad 0, la tabla main en 32766 y la regla por defecto en 32767, por eso una regla añadida con la prioridad por defecto cae cerca del final de la lista y pierde contra casi todo.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201
Una prioridad explícita hace visible el orden pretendido en el archivo y en la revisión. También evita que una adición posterior se adelante en silencio a una regla existente, que es la causa más habitual de que una política que funciona deje de funcionar tras un cambio no relacionado.
Una regla coincidente que apunta a una tabla incompleta es la otra trampa. Si la tabla 201 contiene una ruta por defecto pero ninguna ruta al destino, el paquete se descarta o se envía al lugar equivocado, y la regla parece perfectamente correcta de forma aislada. Lea la tabla, no solo la regla. Una regla es un puntero, y una tabla vacía es un puntero a la nada.
El camino de vuelta tiene que existir igualmente
La política de origen elige una salida. No crea un camino de vuelta. Si el segundo grupo sale por un túnel de socio, el socio tiene que saber cómo llegar a 172.31.8.0/24, ya sea con una ruta de vuelta a la puerta de enlace o recibiendo direcciones traducidas que ya conoce.
Elegir entre eso es una decisión de diseño con consecuencias visibles. Enrutar el rango de clientes de vuelta conserva la identidad de cada cliente en el socio y exige que acepte su prefijo. La traducción esconde el grupo detrás de una dirección y exige que el socio acepte solo esa dirección, a costa de que sus registros y los suyos ya no coincidan sobre quién se conectó.
Elija lo que elija, escríbalo junto a la definición del grupo. Una ruta de vuelta que solo existe en la memoria de alguien es justo el tipo de cosa que sobrevive hasta que el socio cambia un cortafuegos, y luego cuesta un día reconstruirla.
No atrape el túnel propio de la puerta de enlace en la política
Las reglas que escribe para clientes también se aplican al tráfico que genera la puerta de enlace, salvo que lo excluya. Una regla amplia basada en una marca o en la interfaz de salida puede capturar la conexión propia de la puerta de enlace con el socio, y entonces el túnel que transporta la política es enrutado por la política. Eso produce un bucle o una caída que parece un fallo del proveedor.
Limite cada regla tanto como permita el diseño: prefijo de origen, interfaz de entrada y, donde se admita, una marca que solo lleven los paquetes de clientes. Después pruebe la conectividad propia de la puerta de enlace tras cada cambio de reglas, porque el fallo es autorreferente y no aparece en una prueba desde el cliente.
La página de manual de ip-rule documenta la semántica del selector y de la prioridad. Combínela con una prueba de consulta por grupo y el diseño se vuelve comprobable, que es la diferencia entre un enrutamiento por política que aguanta un año y uno que todos temen tocar.