DNS léist net méi op, wann de VPN-Kill-Switch de Port 53 blockéiert
E Kill-Switch kann DNS bewosst blockéieren. Vergläicht d'Opëlse just am Tunnel mat enger Ausnam fir en lokale Resolver, a fannt dann eraus, wéi eng Schicht wierklech versot huet.
Wann de Kill-Switch den Tunnel fale léisst, hëlt en den DNS-Wee mat, an de Resolver, deen hannerbleift, ass selten deen, deen Dir erwaart. Zwee Konzepter ginn domat ganz ënnerschiddlech ëm: all DNS-Paket blockéieren, dat net am Tunnel ass, odereen Resolver als Ausnam stoen loossen. Béides ass verdeedegbar. Vum Browser-Tab aus gesinn d'Symptomer bal d'selwecht aus, dofir ass déi éischt Aufgab erauszefannen, wéi ee Konzept Dir tatsächlech agesat hutt.
Ech halen dee Ënnerscheed virun Aen, well d'Korrektur an all Fall entgéintgesat ass. Dat eent Konzept brauch eng méi breet Ausnam, dat anert eng méi enk. Rode kascht Iech entweder d'Privatsphär oder en Nomëtteg.
Zwee DNS-Konzepter fir dee selwechte Stéierung
Konzept A behandelt de Resolver wéi all aneren Déngscht hannert dem Tunnel. D'Firewall-Regele erlaben UDP an TCP 53 nëmmen um Tunnel-Interface, an d'Adress, déi de Client kritt, ass e Resolver am Tunnel. Wann den Tunnel fält, halen d'Ufroen op, an dat ass dat gewollt Resultat, keen Defekt.
Konzept B hält e Resolver am lokalen Netz erreechbar, meeschtens de Router op 192.168.1.1 oder de System-Stub op 127.0.0.53, mat der Begrënnung, datt d'Nimmopfëssung net mam Tunnel stierwe soll. Et ass praktesch an engem Heem-LAN, wou de Router fir dat ganzt Haus opléist. Am Wi-Fi vun engem Hotel oder Fluchhafen weist déi selwecht Ausnam op en anere Server, an all Numm, deen Dir tippt, gëtt verroden, obwuel Ären Web-Traffic blockéiert bleift.
D'Grenz ass, wiem de Resolver gehéiert. Wann Dir dem lokalen traut, ass eng Ausnam e klengt, éierlecht Lach. Wann net, ass de Konzept nëmmen-Tunnel deen eenzegen, deen hält, an de Präis ass, datt en ofgebrach Tunnel all Nimm mat sech hëlt.
Firwat dem VPN-Client seng eegen Ufro nach ëmmer funktionéiert
De Client muss den Hostnumm vum Gateway opléisen, ier en Tunnel existéiert, dofir däerf eng strikt Blockad de Bootstrap-Wee vum Client net ofdecken. Déi meescht Cliente cache den Endpunkt-Adress oder liwweren eng dokumentéiert Bootstrap-Ausnam fir deen eenzegen Host. Wann Äre Reegelsaz déi Ufro blockéiert, kënnt den Tunnel ni zréck an d'Loge weisen e Client, deen säin eegene Server net erreecht; dat ass e Politiksdefekt an net en DNS-Defekt.
Gespléckten DNS ass déi aner Plaz, wou dat opkënnt. De Client dréckt eng intern Zon op en private Resolver an lässt alles anescht beim Systemresolver. No engem Fale kënnen ëffentlech Nimm nach opléisen, während déi intern an den Timeout lafen, well d'privat Zon kee Wee méi huet. Fir de Benotzer ass dat "de VPN huet d'Internet futti gemaach"; fir d'Resolver-Log ass et eng Ufro, déi ni ukomm ass.
Ënner systemd-resolved gesitt Dir d'Spléckung direkt.resolvectl statuslëscht d'DNS-Server pro Link an d'Routing-Domänen op, an nodeems den Tunnel erofgaangen ass, weist d'intern Domän weider op e Server op engem Link, deen et net méi gëtt. De Stub op 127.0.0.53 hëlt d'Ufro nach un a waart dann op en Upstream, deen net äntweren, an dofir dauert de Feeler Sekonnen, amplaz direkt zréckzekommen.
Verschlësselten DNS geet net ëm e Paketfilter
DNS over HTTPS an DNS over TLS reesen iwwer 443 an 853, dofir huet eng Reegel, déi de Port 53 blockéiert, näischt iwwer si gesot. "DNS" no Port blockéieren ass eng Politik iwwer e Port, net iwwer d'Nimmopfëssung. Wann Äre Kill-Switch all Traffic baussen dem Tunnel blockéiert, ass DoH zoufälleg ofgedeckt. Wann Dir eng Ausnam fir e Captive Portal oder e ëffentleche Resolver gemaach hutt, dann net.
D'Kontrollen op der Client-Säit sinn den décke Wee. Firefox gëtt säi DoH-Resolver op, wann den Kanarievull-Nummuse-application-dns.netnet opléist, an dofir publizéieren geréiert Netzwierker déi Domän als NXDOMAIN; Eng Firmenpolitik kann en och ausgeschalt festhalen. Android Private DNS an Chrome säi sécheren DNS hueneen eegen Schalter an eegen Default-Wäerter. Si auszeschalten ass zouverlässeger wéi Resolver-Adressen nozelafen, well d'Adresslëscht sech ännert an Äre Reegelsaz net.
Et gëtt eng Versioun dovun, déi guer net ëm Lecks geet. Eng Applikatioun mat engem fixéierte Resolver brauch nach ëmmer e Netzwee dohinner. Verschlësselung ännert, wien d'Ufro liese kann, net ob de Paket d'Maschinn verloosse kann, dofir besiegt eng Blockad fir dat ganzt Gerät d'Astellung, ouni se unzeréieren.
Passt d'Symptom op d'Schicht
Déi meescht Meldungen komme als ee Saz, an dee Saz nennt meeschtens schon d'Schicht. D'Tabell hei drënner ass dat, wat ech duerchginn, ier ech eng Reegel ufässen; den Zweck ass ze entscheeden, ob d'Ufro blockéiert, falsch geleet oder ni geschéckt gouf.
| 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 |
Déi éischt zwou Zeile sinn déi, déi d'Leit falsch diagnostizéieren. En typesche Fale an eng Oflehnung gesinn am Browser béid wéi "DNS ass futti" aus, awer nëmmen eng dovun heescht, datt Äre Kill-Switch seng Aarbecht mécht. Eng Oflehnung heescht, datt eppes geäntwert huet, dofir ass d'Blockad net do, wou Dir mengt.
Stellt d'Resolver-Politik erëm hier a bewist se dann
Verbessert de Konzept, net d'Symptom. Fir d'Opëlse just am Tunnel erlaabt 53 um Tunnel-Interface, dréckt den internen Resolver mat der Tunnel-Konfiguratioun eraus, a loosst de physesche Link ouni all DNS-Erlaabnes. Bei wg-quick ass d'LinnDNS =déi, déi de Resolver an d'Interface-Konfiguratioun schreift, dofir léisst en Tunnel, deen se ewechléisst, den ale Resolver op der Plaz an all Ufro op deem falsche Wee.wg-quick-Handbuchdokumentéiert dat Verhalen pro Plattform.
Iwwerpréift duerno an dëser Reiefolleg. Op Linux weistresolvectl statusden aktive Link,dig +short example.comtestt en ëffentlechen Numm,dig @10.8.0.1 internal.example.comtestt de privaten, ansudo tcpdump -ni any port 53weist, wéi en Interface d'Paketen benotzen, während Dir béides lafe loosst. Op Windows ginnGet-DnsClientServerAddress -AddressFamily IPv4anResolve-DnsName example.comdéiselwecht zwou Tatsaachen: wien konfiguréiert ass a wien äntwert.
Schléisst mam negativen Test of. Trennt den Tunnel, bestätegt, datt en neien ëffentlechen Numm feelt, bestätegt, datt den privaten Numm feelt, anbestätegt, datt kee Paket vum Port 53 den physeschen Adapter verlooss huet. Eng Blockad, déi nëmme fir gecachte Äntwerten hält, hält guer net.
Checklëscht, ier Dir den Ticket zoumaacht:
- De Resolver, deen während der Stéierung benotzt gouf, ass deen, deen d'Politik virgesäit.
- Dem Client seng eege Endpunkt-Ufro ass nach ëmmer erlaabt, iwwer Cache oder Ausnam.
- DoH an DoT si vun der Blockad ofgedeckt oder duerch Politik ausgeschalt.
- Privat Zone versoe geschloss, net oppen, soubal den Tunnel fort ass.