Por que as consultas de dnsmasq escapan da VPN tras unha redirección DNS

O cliente da LAN chega correctamente á súa VPN e, aínda así, as súas consultas DNS aparecen polo enlace ascendente equivocado. Non é unha fuga no sentido habitual; é o que ocorre cando o router deixa de reenviar unha consulta e respóndea el mesmo. A interceptación reescribe o destino cara a un socket local, e despois o resolutor abre unha segunda conversa, sen relación, coa súa propia dirección de orixe e a súa propia decisión de encamiñamento. As marcas aplicadas ao fluxo do cliente describen a primeira conversa e absolutamente nada sobre a segunda.

A marca non viaxa coa consulta

As marcas de paquete viven nunha entrada de conntrack e no paquete en voo. Unha regra REDIRECT remata con ese voo: a carga entrégase a un socket local e a entrada orixinal xa fixo o seu traballo. O que sae do router despois é un socket novo creado polo proceso do resolutor, coa dirección do propio router como orixe.

Por iso unha ruta de política baseada na dirección do cliente da LAN nunca coincide coa consulta ascendente. O socket novo pertence a dnsmasq e non ao cliente, e o núcleo avalía a ruta para o tráfico do propio router. As regras de orixe, as regras de interface e as regras de marca ven unha tupla distinta. Supoñer que a marca se propaga é o erro máis común nesta configuración e resulta invisible nunha captura do lado do cliente.

As dúas conversas si comparten un nome e un momento, e iso é o que as fai parecer un só fluxo cando follexas unha captura.

Onde o reenvío se converte en resolución local

Comeza por averiguar se o porto 53 se redirixe, se traduce a outro host ou se deixa intacto, porque os tres casos compórtanse de forma distinta. Unha redirección a un porto local remata co reenvío, mentres que unha tradución a outra máquina mantén o paquete en movemento e mantén significativa a tupla do cliente.

Mira ambos os protocolos. Un resolutor accesible por UDP e TCP probarase polos dous, e un conxunto de regras que só cobre UDP deixa un oco silencioso para as respostas grandes. As regras que xera o propio xestor de configuración do router tamén contan, e editar un ficheiro xerado adoita perder contra a seguinte 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 saídas responden tres preguntas por orde: que reescribe a consulta, que a recibe e que proceso posúe o socket que escoita. Unha vez coñecido o dono, a política ascendente ten onde vivir.

Dálle ao resolutor a súa propia política de saída

Un upstream específico de dominio é a ferramenta máis limpa cando só algúns nomes precisan o túnel. dnsmasq acepta unha liña server limitada a un dominio, cunha interface ou dirección de orixe opcional que dirixe a consulta fóra dun dispositivo escollido. Ese direccionamento é o que fai que a segunda conversa siga a VPN.

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

O dominio, a dirección e a interface de arriba son marcadores de posición para os teus propios valores. A selección de dominio e o control de saída seguen sendo decisións separadas: a ruta debe existir, o resolutor ascendente debe permitir a dirección de orixe e a devasa debe permitir a resposta. O direccionamento só por interface non é fail-closed, porque un túnel que desaparece pode deixar o resolutor caendo a outra ruta. Mantén calquera alternativa pública lonxe dun espazo de nomes que deba permanecer privado.

Pon a liña no propietario de configuración que o router admite, non nun ficheiro xerado, ou a seguinte recarga borra a corrección.

Que non pode conservar unha caché compartida

Un só reenviador cunha soa caché serve cada cliente da LAN, e iso derruba unha distinción que algunhas redes necesitan. Se dous clientes deben resolver o mesmo nome de forma distinta, o socket compartido non ten maneira de recuperar que cliente preguntou. A política por cliente ten que vivir en instancias de resolutor separadas ou nunha función de reenvío que conserve a identidade.

Unha resposta en caché tampouco é evidencia sobre a ruta nova. A resposta pode chegar da memoria mentres a ruta ascendente segue rota.

As regras de porto 53 non din nada sobre as aplicacións que falan DNS por HTTPS ou por TLS. Esas consultas nunca chegan á redirección, así que unha política construída só sobre o porto 53 describe un subconxunto do tráfico e debería documentarse como un subconxunto.

Verifica a segunda conversa, non a primeira

Proba cun nome que controles e observa ambos os lados. Unha captura do lado do cliente demostra que a consulta saíu da LAN; só o lado do router demostra a onde foi despois.

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

Baleira a caché antes de cada intento, porque unha resposta quente agocha un upstream roto. Repite por TCP e despois repite co túnel caído para ver que fai o resolutor cando a súa ruta preferida xa non está. Ese último comportamento decide se o deseño é fail-closed ou só afortunado.