Hvorfor dnsmasq-spørringer slipper ut av VPN-en etter en DNS-omdirigering

LAN-klienten når VPN-en sin riktig, og likevel dukker DNS-spørringene opp på feil oppstrømslenke. Det er ikke en lekkasje i vanlig forstand; det er det som skjer når ruteren slutter å videresende en spørring og svarer på den selv. Avskjæringen skriver om målet til en lokal socket, og deretter åpner resolversen en ny, urelatert samtale med sin egen kildeadresse og sitt eget rutingsvalg. Merkene som er satt på klientflyten, beskriver den første samtalen og absolutt ingenting om den andre.

Merket reiser ikke med spørringen

Pakkemerker lever på en conntrack-oppføring og på pakken underveis. En REDIRECT-regel avslutter den ferden: nyttelasten overleveres til en lokal socket, og den opprinnelige oppføringen har gjort jobben sin. Det som deretter forlater ruteren, er en fersk socket laget av resolverprosessen, med ruterens egen adresse som kilde.

Derfor treffer en policy-rute knyttet til LAN-klientens adresse aldri upstream-spørringen. Den nye socketen tilhører dnsmasq og ikke klienten, og kjernen vurderer ruten for ruterens egen trafikk. Kilderegler, grensesnittregler og markeregler ser alle en annen tuppel. Å anta at merket forplanter seg er den vanligste feilen i denne oppsetningen, og den er usynlig i et opptak på klientsiden.

De to samtalene deler faktisk et navn og en timing, og det er det som får dem til å se ut som én flyt når du skummer gjennom et opptak.

Hvor videresending blir lokal oppslagning

Begynn med å finne ut om port 53 omdirigeres, oversettes til en annen vert eller får være i fred, fordi de tre tilfellene oppfører seg ulikt. En omdirigering til en lokal port avslutter videresendingen, mens en oversettelse til en annen maskin holder pakken i bevegelse og holder klientens tuppel meningsfull.

Se på begge protokollene. En resolver som er tilgjengelig over UDP og TCP, vil bli testet over begge, og et regelsett som bare dekker UDP, etterlater et stille hull for store svar. Regler som genereres av ruterens egen konfigurasjonsbehandler, teller også, og å redigere en generert fil taper vanligvis mot neste innlasting.

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 utdataene svarer på tre spørsmål i rekkefølge: hva som skriver om spørringen, hva som mottar den, og hvilken prosess som eier den lyttende socketen. Når eieren er kjent, har upstream-policyen et sted å bo.

Gi resolversen sin egen utgangspolicy

En domenespesifikk upstream er det reneste verktøyet når bare noen navn trenger tunnelen. dnsmasq godtar en server-linje begrenset til et domene, med et valgfritt grensesnitt eller kildeadresse som styrer spørringen ut av en valgt enhet. Det er denne styringen som får den andre samtalen til å følge VPN-en.

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

Domenet, adressen og grensesnittet ovenfor er plassholdere for dine egne verdier. Domevalg og utgangskontroll forblir separate beslutninger: ruten må finnes, kildeadressen må være tillatt av upstream-resolversen, og brannmuren må tillate svaret. Bare grensesnittstyring er ikke fail-closed, fordi en tunnel som forsvinner kan la resolversen falle tilbake på en annen vei. Hold enhver offentlig reserveløsning langt unna et navnerom som må forbli privat.

Sett linjen hos konfigurasjonseieren ruteren støtter i stedet for i en generert fil, ellers sletter neste innlasting rettelsen.

Hva en delt hurtigbuffer ikke kan bevare

Én videresender med én hurtigbuffer betjener hver LAN-klient, og det kollapser en forskjell som noen nettverk trenger. Hvis to klienter må slå opp det samme navnet ulikt, har den delte socketen ingen måte å gjenopprette hvilken klient som spurte. Policy per klient må leve i separate resolverinstanser eller i en videresendingsfunksjon som beholder identiteten.

Et bufret svar er heller ikke bevis om den nye veien. Svaret kan komme fra minnet mens upstream-ruten forblir brutt.

Regler for port 53 sier ingenting om applikasjoner som snakker DNS over HTTPS eller over TLS. Disse spørringene når aldri omdirigeringen, så en policy bygget bare på port 53 beskriver en delmengde av trafikken og bør dokumenteres som en delmengde.

Verifiser den andre samtalen, ikke den første

Test med ett navn du kontrollerer, og se på begge sider. Et opptak på klientsiden beviser at spørringen forlot LAN-et; bare rutersiden beviser hvor den gikk videre.

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 hurtigbufferen før hvert forsøk, fordi et varmt svar skjuler en brutt upstream. Gjenta over TCP, og gjenta deretter med tunnelen nede for å se hva resolversen gjør når dens foretrukne vei er borte. Den siste oppførselen avgjør om designet er fail-closed eller bare heldig.