DNS slår ikke op, når VPN-killswitchen blokerer port 53
En killswitch kan blokere DNS med vilje. Sammenlign opslag kun i tunnelen med en undtagelse for en lokal resolver, og find derefter ud af, hvilket lag der faktisk fejlede.
Når killswitchen dropper tunnelen, tager den DNS-stien med sig, og den resolver, der bliver tilbage, er sjældent den, du forventer. To design håndterer det øjeblik meget forskelligt: bloker hver DNS-pakke, der ikke er inde i tunnelen, ellerlad én resolver stå som undtagelse. Begge er forsvarlige. Fra en browservane ser symptomerne næsten identiske ud, så den første opgave er at finde ud af, hvilket design du faktisk har udrullet.
Jeg holder den forskel for øje, fordi rettelsen er modsat i hvert tilfælde. Det ene design kræver en bredere undtagelse, det andet en snævrere. Gætteri koster dig enten privatliv eller en eftermiddag.
To DNS-design til samme udfald
Design A behandler resolveren som endnu en tjeneste bag tunnelen. Firewallregler tillader UDP og TCP 53 kun på tunnelegrænsefladen, og den adresse, klienten får, er en resolver inde i tunnelen. Når tunnelen falder, stopper opslag, og det er det tilsigtede resultat, ikke en fejl.
Design B holder en resolver tilgængelig på det lokale netværk, normalt routeren på 192.168.1.1 eller operativsystemets stub på 127.0.0.53, ud fra den begrundelse, at navneopslag ikke bør dø med tunnelen. Det er bekvemt på et hjemme-LAN, hvor routeren slår op for hele huset. På Wi-Fi på et hotel eller i en lufthavn peger den samme undtagelse på en fremmed server, og hvert navn, du skriver, afsløres, selv om din webtrafik forbliver blokeret.
Grænsen går ved, hvem der ejer resolveren. Hvis du stoler på den lokale, er en undtagelse et lille, ærligt hul. Hvis ikke, er kun-tunnel-designet det eneste, der holder, og prisen er, at en droppet tunnel tager alle navne med sig.
Hvorfor VPN-klientens eget opslag stadig virker
Klienten skal slå gatewayens værtsnavn op, før der findes en tunnel, så en streng blokering må ikke dække klientens bootstrap-sti. De fleste klienter cacher enten endpoint-adressen eller leverer en dokumenteret bootstrap-undtagelse for netop den vært. Blokerer dit regelsæt det opslag, kommer tunnelen aldrig tilbage, og loggene viser en klient, der ikke kan nå sin egen server, hvilket er en politikfejl og ikke en DNS-fejl.
Opdelt DNS er det andet sted, hvor det viser sig. Klienten skubber en intern zone til en privat resolver og lader alt andet ligge hos systemresolveren. Efter et udfald kan offentlige navne måske stadig slås op, mens interne navne timer ud, fordi den private zone ikke har nogen rute tilbage. For brugeren er det "VPN'en ødelagde internettet"; for resolverloggen er det en forespørgsel, der aldrig nåede frem.
Under systemd-resolved kan du se opdelingen direkte.resolvectl statusviser DNS-serverne pr. link og routingdomænerne, og efter tunnelen går ned, bliver det interne domæne ved med at pege på en server på et link, der ikke findes længere. Stubben på 127.0.0.53 accepterer stadig forespørgslen, venter derefter på et upstream, der ikke vil svare, og derfor tager fejlen sekunder i stedet for at vende tilbage med det samme.
Krypteret DNS kommer ikke uden om et pakkefilter
DNS over HTTPS og DNS over TLS kører på 443 og 853, så en regel, der blokerer port 53, har ikke sagt noget om dem. At blokere "DNS" efter port er en politik om en port, ikke om navneopslag. Hvis din killswitch blokerer al trafik uden for tunnelen, er DoH dækket ved et tilfælde. Hvis du har udskilt en tilladelse til en captive portal eller en offentlig resolver, er den ikke.
Styringer på klientsiden er den billigere løftestang. Firefox opgiver sin DoH-resolver, når kanariefuglenavnetuse-application-dns.netikke slår op, og derfor udgiver administrerede netværk det domæne som NXDOMAIN; virksomhedspolitik kan også fastlåse det slukket. Android Private DNS og Chromes sikre DNS har deres egne kontakter og deres egne standarder. At slukke for dem er mere pålideligt end at jage resolveradresser, fordi adresselisten ændrer sig, og dit regelsæt gør ikke.
Der findes en version af dette, der slet ikke handler om lækager. Et program med en fastlåst resolver har stadig brug for en netværkssti for at nå den. Kryptering ændrer, hvem der kan læse forespørgslen, ikke om pakken kan forlade maskinen, så en blokering for hele enheden besejrer indstillingen uden at røre den.
Pas symptomet til laget
De fleste rapporter kommer som én sætning, og den sætning nævner som regel allerede laget. Tabellen nedenfor er det, jeg gennemgår, før jeg rører en regel; pointen er at afgøre, om forespørgslen blev blokeret, fejlrettet eller aldrig sendt.
| 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 |
De to første rækker er dem, folk fejldiagnosticerer. Et tavst drop og en afvisning ser begge ud som "DNS er i stykker" i en browser, men kun det ene betyder, at din killswitch gør sit arbejde. En afvisning betyder, at noget svarede, så blokeringen er ikke der, hvor du tror.
Genopret resolverpolitikken, og bevis den så
Ret designet, ikke symptomet. Til kun-tunnel-opslag skal du tillade 53 på tunnelegrænsefladen, skubbe den interne resolver ud med tunnelkonfigurationen og lade det fysiske link være uden nogen DNS-tilladelse. Med wg-quick er linjenDNS =den, der skriver resolveren ind i grænsefladens konfiguration, så en tunnel, der udelader den, efterlader den gamle resolver på plads og hver forespørgsel på den forkerte sti.wg-quick-manualendokumenterer den adfærd pr. platform.
Kontrollér derefter i denne rækkefølge. På Linux viserresolvectl statusdet aktive link,dig +short example.comtester et offentligt navn,dig @10.8.0.1 internal.example.comtester det private, ogsudo tcpdump -ni any port 53viser, hvilken grænseflade pakkerne bruger, mens du kører begge. På Windows giverGet-DnsClientServerAddress -AddressFamily IPv4ogResolve-DnsName example.comde samme to kendsgerninger: hvem der er konfigureret, og hvem der svarer.
Slut af med den negative test. Afbryd tunnelen, bekræft, at et frisk offentligt navn fejler, bekræft, at det private navn fejler, ogbekræft, at ingen port 53-pakke forlod den fysiske adapter. En blokering, der kun holder for cachelagrede svar, holder slet ikke.
Tjekliste, før du lukker sagen:
- Den resolver, der blev brugt under udfaldet, er den, politikken tilsigter.
- Klientens eget endpoint-opslag er stadig tilladt, via cache eller undtagelse.
- DoH og DoT er enten dækket af blokeringen eller slået fra via politik.
- Private zoner fejler lukket, ikke åbent, når tunnelen er væk.