DNS lost net op as de VPN-killswitch poarte 53 blokkearret
In killswitch kin DNS bewust blokkearje. Ferlykje it oplossen allinnich yn de tunnel mei in útsûndering foar in lokale resolver, en bepale dan hokker laach echt mislearre.
As de killswitch de tunnel falle lit, nimt er it DNS-paad mei, en de resolver dy't efterbliuwt is selden dejinge dy't jo ferwachtsje. Twa ûntwerpen behannelje dat momint hiel oars: elk DNS-pakket blokkearje dat net yn de tunnel sit, ofien resolver as útsûndering oerein litte. Beide binne te ferdigenjen. Fanôf in browser-tab sjogge de symptomen hast itselde, dus de earste taak is útfine hokker ûntwerp jo eins útrôle hawwe.
Ik hâld dy ûnderskieding foar eagen, want de ferbettering is yn elk gefal tsjinoersteld. It iene ûntwerp hat in bredere útsûndering nedich, it oare in smelliere. Rieden kostet jo of privacy of in middei.
Twa DNS-ûntwerpen foar deselde steuring
Ûntwerp A behannelet de resolver as in tsjinst lykas oare efter de tunnel. Brânmuerregels tastean UDP en TCP 53 allinnich op de tunnel-ynterface, en it adres dat de klant krijt is in resolver binnen de tunnel. As de tunnel falt, stopje de sykopdrachten, en dat is it bedoelde resultaat, gjin fout.
Ûntwerp B hâldt in resolver berikber op it lokale netwurk, meastentiids de router op 192.168.1.1 of de bestjoerssysteem-stub op 127.0.0.53, mei't namme-oplossing net mei de tunnel stjerre moat. It is handich op in thús-LAN dêr't de router foar it hiele hûs oplost. Op hotel- of lofthaven-Wi-Fi wiist deselde útsûndering nei immen oars syn server, en elke namme dy't jo yntype wurdt iepenbier, sels as jo webtraffik blokkearre bliuwt.
De grins is wa't de resolver besit. Fertrouwe jo de lokale, dan is in útsûndering in lyts, earlik gat. Dogge jo dat net, dan is it ûntwerp allinnich-tunnel it iennige dat hâldt, en de priis is dat in fallen tunnel alle nammen meinaamt.
Wêrom't de eigen sykopdracht fan de VPN-klant noch wurket
De klant moat de hostnamme fan de gateway oplosse foardat der in tunnel is, dus in strikte blokkade mei it bootstrap-paad fan de klant net dekke. De measte klanten cacheje it einpuntadres of leverje in dokumintearre bootstrap-útsûndering foar dy iene host. As jo regelset dy sykopdracht blokkearret, komt de tunnel nea werom en de lochboeken litte in klant sjen dy't syn eigen server net berikke kin, wat in beliedsdefekt is en gjin DNS-defekt.
Split-DNS is it oare plak dêr't dit opkomt. De klant skoot in ynterne sône nei in privee resolver en lit al it oare by de systeemresolver. Nei in fal kinne iepenbiere nammen noch oplosse wylst ynterne ferrinne, om't de privee sône gjin rûte mear hat. Foar de brûker is dat "de VPN hat it ynternet stikken makke"; foar it resolver-loch is it in fraach dy't nea oankaam.
Under systemd-resolved kinne jo de splitsing direkt sjen.resolvectl statuslistet de DNS-servers per keppeling en de routingdomeinen, en nei't de tunnel delgien is bliuwt it ynterne domein wizen nei in server op in keppeling dy't net mear bestiet. De stub op 127.0.0.53 akseptearret de fraach noch, wachtet dan op in upstream dy't net antwurdzje sil, en dêrom duorret de flater sekonden ynstee fan daliks werom te kommen.
Fersifere DNS giet net om in pakketfilter hinne
DNS over HTTPS en DNS over TLS reizgje oer 443 en 853, dus in regel dy't poarte 53 blokkearret hat neat oer harren sein. "DNS" op poarte blokkearje is belied oer in poarte, net oer namme-oplossing. As jo killswitch alle traffik bûten de tunnel blokkearret, is DoH by ûngelok dekt. As jo in útsûndering makke hawwe foar in captive portal of in iepenbiere resolver, is it dat net.
Klant-side bediening is de goedkeapere hefbeam. Firefox lit syn DoH-resolver farre as de kanariefûgelnammeuse-application-dns.netnet oplost, en dêrom publisearje behearderde netwurken dat domein as NXDOMAIN; ûndernimmingsbelied kin it ek fêst útskeakelje. Android Private DNS en Chrome syn befeilige DNS hawwe har eigen skakelaars en har eigen standertwearden. Dy útskeakelje is betrouberder as it efternei rinnen fan resolver-adressen, want de adreslist feroaret en jo regelset net.
Der is in ferzje hjirfan dy't hielendal net oer lekken giet. In applikaasje mei in fêste resolver hat noch altyd in netwurkpaad nedich om der te kommen. Fersifering feroaret wa't de fraach lêze kin, net oft it pakket de masine ferlitte kin, dus in blokkade foar it hiele apparaat ferslacht de ynstelling sûnder dy oan te reitsjen.
Koppelje it symptoom oan de laach
De measte rapporten komme as ien sin, en dy sin neamt meastal al de laach. De tabel hjirûnder is wat ik trochsykje foardat ik in regel oanreitsje; it punt is te besluten oft de fraach blokkearre, ferkeard rjochte of nea ferstjoerd waard.
| 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 earste twa rigen binne dy't minsken ferkeard diagnostisearje. In stil falle en in wegering lykje beide as "DNS is stikkene" yn in browser, mar mar ien fan beide betsjut dat jo killswitch syn wurk docht. In wegering betsjut dat eat antwurde, dus de blokkade is net dêr't jo tinke.
Stel it resolver-belied werom en bewis it dan
Ferbetterje it ûntwerp, net it symptoom. Foar oplossing allinnich yn de tunnel, tastean 53 op de tunnel-ynterface, skoot de ynterne resolver mei de tunnelkonfiguraasje mei en lit de fysike keppeling sûnder elke DNS-tastimming. By wg-quick is de rigelDNS =dejinge dy't de resolver yn de ynterfacekonfiguraasje skriuwt, dus in tunnel dy't dy weilitten lit de âlde resolver stean en elke fraach op it ferkearde paad.wg-quick-hânliedingdokumintearret dat gedrach per platfoarm.
Kontrolearje dan yn dizze folchoarder. Op Linux litresolvectl statusde aktive keppeling sjen,dig +short example.comtestet in iepenbiere namme,dig @10.8.0.1 internal.example.comtestet de privee, ensudo tcpdump -ni any port 53lit sjen hokker ynterface de pakketten brûke wylst jo beide draaie. Op Windows jouweGet-DnsClientServerAddress -AddressFamily IPv4enResolve-DnsName example.comdeselde twa feiten: wa't konfigurearre is en wa't antwurdet.
Einigje mei de negative test. Keppelje de tunnel los, befestigje dat in farske iepenbiere namme mislearret, befestigje dat de privee namme mislearret, enbefestigje dat gjin poarte 53-pakket de fysike adapter ferlitten hat. In blokkade dy't allinnich foar cache-antwurden hâldt, hâldt hielendal net.
Kontrollist foardat jo it ticket slute:
- De resolver dy't by de steuring brûkt waard is dejinge dy't it belied bedoelt.
- De eigen einpunt-sykopdracht fan de klant is noch tastien, fia cache of útsûndering.
- DoH en DoT wurde of troch de blokkade dekt of binne útskeakele troch belied.
- Privee sônes mislearje sletten, net iepen, sadree't de tunnel fuort is.