Per què les consultes de dnsmasq s’escapen de la VPN després d’una redirecció DNS

El client de la LAN arriba correctament a la seua VPN i, tot i això, les seues consultes DNS apareixen per l’enllaç ascendent equivocat. No és una fuita en el sentit habitual; és el que passa quan el router deixa de reenviar una consulta i la respon ell mateix. La intercepció reescriu la destinació cap a un sòcol local, i aleshores el resolutor obre una segona conversa, no relacionada, amb la seua pròpia adreça d’origen i la seua pròpia decisió d’encaminament. Les marques aplicades al flux del client descriuen la primera conversa i absolutament res sobre la segona.

La marca no viatja amb la consulta

Les marques de paquet viuen en una entrada de conntrack i en el paquet en vol. Una regla REDIRECT acaba amb aquest vol: la càrrega es lliura a un sòcol local i l’entrada original ja ha fet la seua faena. El que surt del router després és un sòcol nou creat pel procés del resolutor, amb l’adreça del mateix router com a origen.

Per això una ruta de política basada en l’adreça del client de la LAN no coincideix mai amb la consulta ascendent. El sòcol nou pertany a dnsmasq i no al client, i el nucli avalua la ruta per al trànsit del mateix router. Les regles d’origen, les regles d’interfície i les regles de marca veuen una tupla diferent. Suposar que la marca es propaga és l’error més comú en aquesta configuració i és invisible en una captura feta al costat del client.

Les dues converses sí que comparteixen un nom i un moment, i això és el que les fa semblar un sol flux quan fulleges una captura.

On el reenviament es converteix en resolució local

Comenceu per esbrinar si el port 53 es redirigeix, es tradueix a un altre host o es deixa intacte, perquè els tres casos es comporten de manera diferent. Una redirecció a un port local acaba amb el reenviament, mentre que una traducció a una altra màquina manté el paquet en moviment i manté la tupla del client amb sentit.

Mireu els dos protocols. Un resolutor accessible per UDP i TCP es provarà per tots dos, i un conjunt de regles que només cobreix UDP deixa un forat silenciós per a les respostes grans. Les regles generades pel gestor de configuració del mateix router també compten, i editar un fitxer generat normalment perd contra la propera recàrrega.

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'

Eixes eixides responen tres preguntes per ordre: què reescriu la consulta, què la rep i quin procés posseeix el sòcol que escolta. Un cop es coneix el propietari, la política ascendent té on viure.

Doneu al resolutor la seua pròpia política d’eixida

Un uplink específic de domini és l’eina més neta quan només alguns noms necessiten el túnel. dnsmasq accepta una línia server limitada a un domini, amb una interfície o adreça d’origen opcional que porta la consulta fora d’un dispositiu triat. Eixe guiatge és el que fa que la segona conversa seguisca la VPN.

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

El domini, l’adreça i la interfície de dalt són marcadors de posició per als vostres valors. La selecció de domini i el control d’eixida continuen sent decisions separades: la ruta ha d’existir, l’adreça d’origen ha de ser permesa pel resolutor ascendent i el tallafoc ha de permetre la resposta. El guiatge per interfície sol no és fail-closed, perquè un túnel que desapareix pot deixar el resolutor caient cap a una altra ruta. Mantingueu qualsevol alternativa pública lluny d’un espai de noms que ha de romandre privat.

Poseu la línia al propietari de configuració que el router admet, no en un fitxer generat, o la propera recàrrega esborra la correcció.

Què no pot conservar una memòria cau compartida

Un sol reenviador amb una sola memòria cau serveix cada client de la LAN, i això enfonsa una distinció que algunes xarxes necessiten. Si dos clients han de resoldre el mateix nom de manera diferent, el sòcol compartit no té manera de recuperar quin client ho ha preguntat. La política per client ha de viure en instàncies de resolutor separades o en una funció de reenviament que conserva la identitat.

Una resposta emmagatzemada tampoc no és evidència sobre la ruta nova. La resposta pot arribar de la memòria mentre la ruta ascendent continua trencada.

Les regles de port 53 no diuen res sobre les aplicacions que parlen DNS per HTTPS o per TLS. Eixes consultes no arriben mai a la redirecció, així que una política basada només en el port 53 descriu un subconjunt del trànsit i s’hauria de documentar com a subconjunt.

Verifiqueu la segona conversa, no la primera

Proveu amb un nom que controleu i observeu les dues bandes. Una captura al costat del client demostra que la consulta ha eixit de la LAN; només el costat del router demostra on ha anat després.

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

Buideu la memòria cau abans de cada intent, perquè una resposta calenta amaga un uplink trencat. Repetiu per TCP i després repetiu amb el túnel caigut per veure què fa el resolutor quan la seua ruta preferida ha desaparegut. Eixe darrer comportament decideix si el disseny és fail-closed o només té sort.