Por qué las consultas de dnsmasq escapan de la VPN tras una redirección DNS

El cliente de la LAN llega correctamente a su VPN y, aun así, sus consultas DNS aparecen por el enlace ascendente equivocado. No es una fuga en el sentido habitual; es lo que ocurre cuando el router deja de reenviar una consulta y la responde él mismo. La interceptación reescribe el destino hacia un socket local, y luego el resolutor abre una segunda conversación, no relacionada, con su propia dirección de origen y su propia decisión de enrutamiento. Las marcas aplicadas al flujo del cliente describen la primera conversación y absolutamente nada sobre la segunda.

La marca no viaja con la consulta

Las marcas de paquete viven en una entrada de conntrack y en el paquete en vuelo. Una regla REDIRECT termina con ese vuelo: la carga se entrega a un socket local y la entrada original ya ha hecho su trabajo. Lo que sale del router después es un socket nuevo creado por el proceso del resolutor, con la dirección del propio router como origen.

Por eso una ruta de política basada en la dirección del cliente de la LAN nunca coincide con la consulta ascendente. El socket nuevo pertenece a dnsmasq y no al cliente, y el núcleo evalúa la ruta para el tráfico del propio router. Las reglas de origen, las reglas de interfaz y las reglas de marca ven una tupla distinta. Suponer que la marca se propaga es el error más común en esta configuración y resulta invisible en una captura del lado del cliente.

Las dos conversaciones sí comparten un nombre y un momento, y eso es lo que las hace parecer un solo flujo cuando hojeas una captura.

Dónde el reenvío se convierte en resolución local

Empiece por averiguar si el puerto 53 se redirige, se traduce a otro host o se deja intacto, porque los tres casos se comportan de forma distinta. Una redirección a un puerto local termina con el reenvío, mientras que una traducción a otra máquina mantiene el paquete en movimiento y mantiene significativa la tupla del cliente.

Mire ambos protocolos. Un resolutor accesible por UDP y TCP se probará por los dos, y un conjunto de reglas que solo cubre UDP deja un hueco silencioso para las respuestas grandes. Las reglas que genera el propio gestor de configuración del router también cuentan, y editar un archivo generado suele perder contra la siguiente recarga.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Esas salidas responden tres preguntas en orden: qué reescribe la consulta, qué la recibe y qué proceso posee el socket que escucha. Una vez conocido el dueño, la política ascendente tiene dónde vivir.

Dele al resolutor su propia política de salida

Un upstream específico de dominio es la herramienta más limpia cuando solo algunos nombres necesitan el túnel. dnsmasq acepta una línea server acotada a un dominio, con una interfaz o dirección de origen opcional que dirige la consulta fuera de un dispositivo elegido. Ese direccionamiento es lo que hace que la segunda conversación siga a la VPN.

server=/corp.example/10.30.0.53@tun_work
log-queries

El dominio, la dirección y la interfaz de arriba son marcadores de posición para sus propios valores. La selección de dominio y el control de salida siguen siendo decisiones separadas: la ruta debe existir, el resolutor ascendente debe permitir la dirección de origen y el cortafuegos debe permitir la respuesta. El direccionamiento solo por interfaz no es fail-closed, porque un túnel que desaparece puede dejar al resolutor cayendo a otra ruta. Mantenga cualquier alternativa pública lejos de un espacio de nombres que deba permanecer privado.

Ponga la línea en el propietario de configuración que el router admite, no en un archivo generado, o la siguiente recarga borra la corrección.

Qué no puede conservar una caché compartida

Un solo reenviador con una sola caché sirve a cada cliente de la LAN, y eso derriba una distinción que algunas redes necesitan. Si dos clientes deben resolver el mismo nombre de forma distinta, el socket compartido no tiene manera de recuperar qué cliente preguntó. La política por cliente tiene que vivir en instancias de resolutor separadas o en una función de reenvío que conserve la identidad.

Una respuesta en caché tampoco es evidencia sobre la ruta nueva. La respuesta puede llegar de la memoria mientras la ruta ascendente sigue rota.

Las reglas de puerto 53 no dicen nada sobre las aplicaciones que hablan DNS por HTTPS o por TLS. Esas consultas nunca llegan a la redirección, así que una política construida solo sobre el puerto 53 describe un subconjunto del tráfico y debería documentarse como un subconjunto.

Verifique la segunda conversación, no la primera

Pruebe con un nombre que usted controle y observe ambos lados. Una captura del lado del cliente demuestra que la consulta salió de la LAN; solo el lado del router demuestra a dónde fue después.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Vacíe la caché antes de cada intento, porque una respuesta caliente oculta un upstream roto. Repita por TCP y luego repita con el túnel caído para ver qué hace el resolutor cuando su ruta preferida ya no está. Ese último comportamiento decide si el diseño es fail-closed o solo afortunado.