Enrutamiento de políticas en OpenWrt: la cadena que atrapa el DNS local

Los clientes de la LAN resuelven a través del túnel y las consultas del propio router, en silencio, no lo hacen. Las actualizaciones de paquetes, la sincronización horaria y el DNS dinámico salen por el enlace ordinario mientras que cada consulta reenviada toma la VPN, y nada en la interfaz sugiere que existan dos rutas distintas. La explicación no es un fallo de la política sino una cuestión de qué gancho ve el paquete. Dos flujos, una dirección de resolutor, y solo uno de ellos cruza el router. Separarlos es toda la solución.

Dos flujos, una dirección de resolutor

El primer flujo es el que la gente imagina. Un cliente pregunta al resolutor del router, el resolutor reenvía hacia arriba, y ese paquete reenviado pasa por el router de salida. Ese paquete es visible para cualquier cosa que observe el tráfico reenviado.

El segundo flujo nunca llega de ningún sitio. Lo crea el router, así que no hay paquete entrante ni paso de reenvío que coincida.

Ambos pueden apuntar a la misma dirección de resolutor, y por eso mismo la diferencia pasa fácilmente desapercibida. Mismo destino, distinto origen, distinta cadena. En cuanto ves el origen, el resto del diagnóstico sigue.

Los paquetes reenviados y los generados localmente entran de forma distinta

El tráfico reenviado se evalúa cuando llega de otra interfaz. Los paquetes de enrutamiento de políticas lo exponen como una cadena de prerouting, y una regla colocada allí ve cada paquete que cruza el router. Por eso las consultas de los clientes se comportan exactamente como describe la política, y por eso el router la ignora. La regla no está mal, simplemente está unida a un gancho que el router nunca alcanza. Muévela y la misma coincidencia empieza a funcionar.

El tráfico generado localmente lo crea un proceso del router y entra en la ruta de salida. Lo enruta la decisión del propio router y solo encuentra la política si la política cubre esa cadena. No hay interfaz de entrada que coincida ni decisión de reenvío que observar.

Es una propiedad de dónde nacen los paquetes, no de ningún paquete concreto. Una regla escrita para una cadena simplemente no tiene opinión sobre la otra. Ninguna cantidad de ajuste de reglas lo cambia.

Elige la cadena de salida y luego estrecha la coincidencia

La solución es unir la misma intención también a la cadena de salida, o trasladar allí la regla cuando lo que te importa son las consultas del propio router. En una instalación de OpenWrt basada en un paquete de enrutamiento de políticas, eso significa elegir output en lugar de prerouting en el ajuste de cadena de la regla. Mantén las dos reglas si ambas poblaciones necesitan cobertura.

Luego estrecha qué coincide con la regla. Las direcciones de resolutor de destino en el puerto que el resolutor usa realmente son una decisión mucho más pequeña que mandar al túnel todo lo que origina el router.

Mantén las dos reglas explícitas en lugar de intentar escribir una que cubra ambas cadenas. Las reglas separadas son más fáciles de leer, y te permiten desactivar la ruta del router sin molestar al tráfico de los clientes mientras depuras. También hacen que los contadores tengan sentido de uno en uno.

Mantén el transporte propio del túnel fuera de la regla

La conexión exterior del túnel también la crea el router. Una regla que envíe todo el tráfico generado localmente al túnel enrutará el túnel a través de sí mismo, y no levantará en absoluto.

El acceso de gestión es la segunda víctima. Las sesiones administrativas originadas en el router, o las respuestas a ellas, pueden ser arrastradas al túnel por una regla local demasiado amplia y volverse inaccesibles desde la LAN.

Excluye el extremo del túnel de la coincidencia y mantén la regla limitada a las direcciones de resolutor. Eso basta para el requisito de DNS y es lo bastante pequeño para razonar sobre él.

Prueba ambas poblaciones, no una

Observa al router hacer su propia consulta y anota qué interfaz la llevó. Repite la consulta desde un host de la LAN y anota la ruta que tomó. Los contadores de las reglas de política hacen visibles ambas respuestas sin adivinar.

Trata los resultados como dos hallazgos. Un cliente que resuelve a través del túnel no dice nada sobre el router, y un router que resuelve correctamente no dice nada sobre un cliente en otro escucha. Escríbelos como líneas separadas en el registro de cambios.

Comprueba también el puerto: una regla que coincide con el puerto de destino 53 se pierde un resolutor alcanzado por DNS over TLS en el 853 o por un extremo HTTPS. Haz coincidir el transporte que el upstream configurado usa realmente, y la fuga se cierra por el motivo correcto.