DNS løyser ikkje opp når VPN-killbrytaren stenger port 53
Ein killbrytar kan stengje DNS med vilje. Samanlikn oppslag berre i tunnelen med eit unntak for ein lokal resolver, og finn så ut kva lag som faktisk svikta.
Når killbrytaren slepp tunnelen, tek han DNS-stien med seg, og resolvaren som blir att er sjeldan den du ventar. To design handsamar det augeblikket svært ulikt: stengje kvar DNS-pakke som ikkje er inne i tunnelen, ellerla ein resolver stå som unntak. Begge er forsvarlege. Frå ei nettlesarfane ser symptoma nesten identiske ut, så den første oppgåva er å finne ut kva design du faktisk har teke i bruk.
Eg held den skilnaden framfor augo fordi rettinga er motsett i kvart tilfelle. Det eine designet treng eit breiare unntak, det andre eit smalare. Gjetting kostar deg anten personvern eller ein ettermiddag.
To DNS-design for same utfall
Design A handsamar resolvaren som endå ei teneste bak tunnelen. Brannmurreglar tillèt UDP og TCP 53 berre på tunnegrensesnittet, og adressa klienten får er ein resolver inne i tunnelen. Når tunnelen fell, stoppar oppslaga, og det er det tilsikta resultatet, ikkje ein feil.
Design B held ein resolver tilgjengeleg på det lokale nettet, vanlegvis rutaren på 192.168.1.1 eller stuben til operativsystemet på 127.0.0.53, ut frå at namneoppslag ikkje bør døy med tunnelen. Det er praktisk på eit heimenett der rutaren slår opp for heile huset. På Wi-Fi på hotell eller flyplass peikar det same unntaket på serveren til nokon andre, og kvart namn du skriv blir avdekt, sjølv om nettraffikken din blir verande stengd.
Grensa går ved kven som eig resolvaren. Stolar du på den lokale, er eit unntak eit lite, ærleg hol. Gjer du det ikkje, er berre-tunnel-designet det einaste som held, og prisen er at ein fallen tunnel tek alle namn med seg.
Kvifor oppslaget til VPN-klienten sjølv enno verkar
Klienten må slå opp vertsnamnet til gatewayen før det finst ein tunnel, så ei streng stenging må ikkje dekkje oppstartsstien til klienten. Dei fleste klientar bufrer endepunktsadressa eller leverer eit dokumentert oppstartsunntak for nettopp den eine verten. Stenger regelsettet ditt det oppslaget, kjem tunnelen aldri attende, og loggane viser ein klient som ikkje når sin eigen server; det er ein politikkfeil og ikkje ein DNS-feil.
Delt DNS er den andre staden der dette dukkar opp. Klienten skuvar ei intern sone til ein privat resolver og lèt alt anna liggje hos systemresolvaren. Etter eit utfall kan offentlege namn enno slåast opp medan interne namn går ut på tid, fordi den private sona ikkje har noka rute att. For brukaren er det "VPN-en øydela internett"; for resolverloggen er det ei førespurnad som aldri kom fram.
Under systemd-resolved kan du sjå delinga direkte.resolvectl statusviser DNS-tenarane per lenkje og rutingsdomena, og etter at tunnelen går ned, peikar det interne domenet enno på ein tenar på ei lenkje som ikkje finst lenger. Stubben på 127.0.0.53 tek enno imot førespurnaden, og ventar deretter på eit oppstraums som ikkje vil svare, og difor tek feilen sekund i staden for å kome attende med ein gong.
Kryptert DNS kjem ikkje rundt eit pakkefilter
DNS over HTTPS og DNS over TLS går over 443 og 853, så ein regel som stenger port 53 har ikkje sagt noko om dei. Å stengje "DNS" etter port er ein politikk om ein port, ikkje om namneoppslag. Viss killbrytaren stenger all trafikk utanfor tunnelen, er DoH dekt ved eit uhell. Viss du har laga eit unntak for ein captive portal eller ein offentleg resolver, er han ikkje det.
Styring på klientsida er den billegare spaken. Firefox gjev opp DoH-resolvaren sin når kanarifuglnamnetuse-application-dns.netikkje slår opp, og difor publiserer styrte nett det domenet som NXDOMAIN; ein verksemdspolitikk kan òg låse det av. Android Private DNS og den sikre DNS-en til Chrome har eigne brytarar og eigne standardverdiar. Å slå dei av er meir påliteleg enn å jage resolveradresser, fordi adresselista endrar seg og regelsettet ditt gjer det ikkje.
Det finst ein versjon av dette som ikkje handlar om lekkasjar i det heile. Eit program med ein fastlåst resolver treng enno ein nettverkssti for å nå han. Kryptering endrar kven som kan lese førespurnaden, ikkje om pakka kan forlate maskina, så ei stenging for heile eininga slår innstillinga utan å røre henne.
Kople symptomet til laget
Dei fleste rapportar kjem som éi setning, og den setninga nemner vanlegvis laget allereie. Tabellen nedanfor er det eg går gjennom før eg rører ein regel; poenget er å avgjere om førespurnaden vart stengd, feilruta eller aldri send.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Dei to første radene er dei folk feildiagnostiserer. Eit stille fall og ei avvising ser båe ut som "DNS er øydelagd" i ein nettlesar, men berre éi av dei tyder at killbrytaren gjer jobben sin. Ei avvising tyder at noko svara, så stenginga er ikkje der du trur.
Få attende resolverpolitikken, og prov han
Ret på designet, ikkje symptomet. For oppslag berre i tunnelen, tillat 53 på tunnegrensesnittet, skuv den interne resolvaren ut med tunnelkonfigurasjonen og lat den fysiske lenkja stå utan noka DNS-løyve. Med wg-quick er linjaDNS =den som skriv resolvaren inn i grensesnittkonfigurasjonen, så ein tunnel som hoppar over henne, lèt den gamle resolvaren stå og kvar førespurnad går på feil sti.wg-quick-handbokadokumenterer den åtferda per plattform.
Kontroller deretter i denne rekkjefølgja. På Linux viserresolvectl statusden aktive lenkja,dig +short example.comtestar eit offentleg namn,dig @10.8.0.1 internal.example.comtestar det private, ogsudo tcpdump -ni any port 53viser kva grensesnitt pakkane brukar medan du køyrer båe. På Windows gjevGet-DnsClientServerAddress -AddressFamily IPv4ogResolve-DnsName example.comdei same to fakta: kven som er konfigurert, og kven som svarar.
Avslutt med den negative testen. Kople frå tunnelen, stadfest at eit ferskt offentleg namn feilar, stadfest at det private namnet feilar, ogstadfest at inga port 53-pakke forlét den fysiske adapteren. Ei stenging som berre held for bufra svar, held ikkje i det heile.
Sjekkliste før du lukkar saka:
- Resolvaren som vart brukt under utfallet, er den politikken meiner.
- Oppslaget til klienten på eigen endepunkt er enno tillate, via buffer eller unntak.
- DoH og DoT er anten dekte av stenginga eller slått av etter politikk.
- Private soner feilar lukka, ikkje ope, når tunnelen er borte.