Hvorfor dnsmasq-forespørgsler slipper ud af VPN’en efter en DNS-omdirigering

LAN-klienten når korrekt sin VPN, og alligevel dukker dens DNS-forespørgsler op på den forkerte uplink. Det er ikke en lækage i sædvanlig forstand; det er hvad der sker, når routeren holder op med at videresende en forespørgsel og selv besvarer den. Aflytningen omskriver destinationen til en lokal socket, og derefter åbner resolveren en anden, ubeslægtet samtale med sin egen kildeadresse og sin egen routingbeslutning. Mærker påført klientens flow beskriver den første samtale og absolut intet om den anden.

Mærket rejser ikke med forespørgslen

Pakkemærker lever på en conntrack-post og på pakken undervejs. En REDIRECT-regel afslutter den rejse: nyttelasten overdrages til en lokal socket, og den oprindelige post har gjort sit arbejde. Det, der derefter forlader routeren, er en frisk socket oprettet af resolverprocessen med routerens egen adresse som kilde.

Derfor matcher en policy-rute bundet til LAN-klientens adresse aldrig upstream-forespørgslen. Den nye socket tilhører dnsmasq snarere end klienten, og kernen vurderer ruten for routerens egen trafik. Kilderegler, interfaceregler og mærkeregler ser alle en anden tuple. At antage at mærket forplanter sig er den mest almindelige fejl i denne opsætning, og den er usynlig i en optagelse på klientsiden.

De to samtaler deler faktisk et navn og en timing, og det er hvad der får dem til at ligne én flow, når du skimter en optagelse.

Hvor videresendelse bliver lokal opløsning

Begynd med at finde ud af, om port 53 omdirigeres, oversættes til en anden vært eller lades i fred, fordi de tre tilfælde opfører sig forskelligt. En omdirigering til en lokal port afslutter videresendelsen, mens en oversættelse til en anden maskine holder pakken i bevægelse og holder klientens tuple meningsfuld.

Se på begge protokoller. En resolver, der kan nås over UDP og TCP, vil blive testet over begge, og et regelsæt, der kun dækker UDP, efterlader et stille hul til store svar. Regler genereret af routerens egen konfigurationshåndtering tæller også, og redigering af en genereret fil taber normalt til den næste genindlæsning.

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'

Disse output besvarer tre spørgsmål i rækkefølge: hvad omskriver forespørgslen, hvad modtager den, og hvilken proces ejer den lyttende socket. Når ejeren er kendt, har upstream-politikken et sted at bo.

Giv resolveren sin egen udgangspolitik

En domænespecifik upstream er det reneste værktøj, når kun nogle navne har brug for tunnelen. dnsmasq accepterer en server-linje afgrænset til et domæne, med et valgfrit interface eller kildeadresse, der styrer forespørgslen ud af en valgt enhed. Den styring er hvad der får den anden samtale til at følge VPN’en.

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

Domænet, adressen og interfacet ovenfor er pladsholdere for dine egne værdier. Domænevalg og udgangskontrol forbliver separate beslutninger: ruten skal findes, kildeadressen skal være tilladt af upstream-resolveren, og firewalling skal tillade svaret. Interface-styring alene er ikke fail-closed, fordi en forsvundet tunnel kan efterlade resolveren faldende tilbage til en anden vej. Hold enhver offentlig fallback væk fra et navnerum, der skal forblive privat.

Sæt linjen i den konfigurationsejer, routeren understøtter, i stedet for i en genereret fil, ellers sletter den næste genindlæsning rettelsen.

Hvad en delt cache ikke kan bevare

Én videresender med én cache betjener hver LAN-klient, og det kollapser en forskel, som nogle netværk har brug for. Hvis to klienter skal opløse det samme navn forskelligt, har den delte socket ingen måde at gendanne, hvilken klient der spurgte. Politik pr. klient skal leve i separate resolver-instanser eller i en videresendelsesfunktion, der bevarer identiteten.

Et cachet svar er heller ikke bevis om den nye vej. Svaret kan komme fra hukommelsen, mens upstream-ruten forbliver brudt.

Port-53-regler siger intet om applikationer, der taler DNS over HTTPS eller over TLS. De forespørgsler når aldrig omdirigeringen, så en politik bygget kun på port 53 beskriver en delmængde af trafikken og bør dokumenteres som en delmængde.

Verificér den anden samtale, ikke den første

Test med et navn, du kontrollerer, og se begge sider. En optagelse på klientsiden beviser, at forespørgslen forlod LAN’et; kun routersiden beviser, hvor den gik hen næste gang.

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

Tøm cachen før hvert forsøg, fordi et varmt svar skjuler en brudt upstream. Gentag over TCP, og gentag derefter med tunnelen nede for at se, hvad resolveren gør, når dens foretrukne vej er væk. Den sidste opførsel afgør, om designet er fail-closed eller blot heldigt.