DNS ei lahenda enam, kui VPN-i kill switch blokeerib pordi 53
Kill switch võib DNS-i meelega blokeerida. Võrrelge lahendamist ainult tunnelis lahendiga kohaliku resolveri erandiga ja tehke seejärel kindlaks, milline kiht tegelikult ebaõnnestus.
Kui kill switch tunneli maha võtab, võtab see kaasa ka DNS-i tee, ja alles jääv resolver on harva see, mida ootate. Kaks lahendust käsitlevad seda hetke väga erinevalt: blokeerida iga DNS-pakett, mis ei ole tunnelis, võijätta üks resolver erandina püsti. Mõlemad on kaitstavad. Brauseri vahekaardilt näevad sümptomid peaaegu identsed välja, seega esimene ülesanne on välja selgitada, millise lahenduse te tegelikult juurutasite.
Hoian selle erinevuse silme ees, sest parandus on mõlemal juhul vastupidine. Üks lahendus vajab laiemat erandit, teine kitsamat. Oletamine maksab teile kas privaatsuse või ühe pärastlõuna.
Kaks DNS-i lahendust sama rikke jaoks
Lahendus A kohtleb resolverit kui üht teenust tunneli taga. Tulemüüri reeglid lubavad UDP ja TCP 53 ainult tunneli liidesel, ja kliendile antav aadress on resolver tunnelis sees. Kui tunnel ära kukub, otsingud lakkavad, ja see on kavatsetud tulemus, mitte viga.
Lahendus B hoiab resolveri kohalikus võrgus kättesaadavana, tavaliselt ruuter aadressil 192.168.1.1 või operatsioonisüsteemi stub aadressil 127.0.0.53, põhjendusega, et nimelahendus ei tohiks tunneliga surra. See on mugav koduses LAN-is, kus ruuter lahendab kogu maja eest. Hotelli või lennujaama Wi-Fi-s osutab sama erand kellegi teise serverile ja iga nimi, mille sisestate, paljastatakse, kuigi teie veebiliiklus jääb blokeerituks.
Piir on selles, kellele resolver kuulub. Kui usaldate kohalikku, on erand väike ja aus auk. Kui ei, siis ainult tunneli lahendus on ainus, mis peab, ja hinnaks on see, et maha kukkunud tunnel võtab kaasa kõik nimed.
Miks VPN-kliendi enda otsing ikka töötab
Klient peab lüüsi hostinime lahendama enne, kui tunnel olemas on, seega range blokeering ei tohi katta kliendi alglaadimise teed. Enamik kliente kas salvestab lõpp-punkti aadressi vahemällu või pakub dokumenteeritud alglaadimise erandi just selle ühe hosti jaoks. Kui teie reeglistik selle otsingu blokeerib, ei tule tunnel kunagi tagasi ja logid näitavad klienti, mis ei saa oma serverini jõuda — see on poliitika, mitte DNS-i defekt.
Jagatud DNS on teine koht, kus see ilmneb. Klient lükkab sisemise tsooni privaatsesse resolverisse ja jätab kõik muu süsteemi resolverile. Pärast kukkumist võivad avalikud nimed ikka lahenduda, samal ajal kui sisemised aeguvad, sest privaatsel tsoonil ei ole enam ühtegi marsruuti. Kasutaja jaoks on see "VPN rikkus interneti"; resolveri logi jaoks on see päring, mis kunagi kohale ei jõudnud.
systemd-resolvedi all näete jagunemist otse.resolvectl statusloetleb DNS-serverid lingi kohta ja marsruutimisdomeenid, ja pärast tunneli kukkumist osutab sisemine domeen endiselt serverile lingil, mida enam ei ole. Stub aadressil 127.0.0.53 võtab päringu ikka vastu, ootab seejärel ülemvoolu, mis ei vasta, ja seetõttu võtab rike sekundeid, selle asemel et kohe tagasi pöörduda.
Krüpteeritud DNS ei lähe paketifiltrist mööda
DNS over HTTPS ja DNS over TLS sõidavad portidel 443 ja 853, seega reegel, mis blokeerib pordi 53, ei ole nende kohta midagi öelnud. "DNS-i" pordi järgi blokeerimine on poliitika pordi, mitte nimelahenduse kohta. Kui teie kill switch blokeerib kogu liikluse väljaspool tunnelit, on DoH juhuslikult kaetud. Kui eraldasite loa captive portali või avaliku resolveri jaoks, siis ei ole.
Kliendipoolsed juhtimisvahendid on odavam hoob. Firefox loobub oma DoH-resolverist, kui kanarilinnu nimiuse-application-dns.netei lahendu, mistõttu haljatud võrgud avaldavad selle domeeni NXDOMAIN-ina; ettevõtte poliitika võib selle ka väljalülitatult kinnitada. Android Private DNS ja Chrome'i turvaline DNS on oma lülitite ja oma vaikeväärtustega. Nende väljalülitamine on usaldusväärsem kui resolveri aadresside tagaajamine, sest aadresside loend muutub ja teie reeglistik ei muutu.
Sellest on versioon, mis ei räägi üldse leketest. Kinnitatud resolveriga rakendus vajab selle juurde jõudmiseks ikkagi võrguteed. Krüpteerimine muudab seda, kes saab päringut lugeda, mitte seda, kas pakett saab masinast väljuda, seega kogu seadme blokeering võidab seade ilma seda puutumata.
Sovitage sümptom kihiga
Enamik raporteid jõuab ühe lausena ja see lause nimetab tavaliselt juba kihi. Allolev tabel on see, mille ma läbi käin enne reegli puutumist; mõte on otsustada, kas päring blokeeriti, suunati valesti või jäi üldse saatmata.
| 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 |
Kaks esimest rida on need, mida inimesed valesti diagnoosivad. Vaikne kukkumine ja keeldumine näevad brauseris mõlemad välja nagu "DNS on katki", kuid ainult üks neist tähendab, et teie kill switch teeb oma tööd. Keeldumine tähendab, et miski vastas, seega ei ole blokeering seal, kus arvate.
Taastage resolveri poliitika ja tõestage see
Parandage lahendust, mitte sümptomit. Ainult tunnelis lahendamiseks lubage 53 tunneli liidesel, lükake sisemine resolver tunneli konfiguratsiooniga kaasa ja jätke füüsiline link ilma igasuguse DNS-i loata. wg-quicki puhul kirjutab resolveri liidese konfiguratsiooni ridaDNS =, seega tunnel, mis selle välja jätab, jätab vana resolveri paigale ja iga päring läheb valele teele.wg-quicki käsiraamatdokumenteerib selle käitumise platvormi kaupa.
Seejärel kontrollige selles järjekorras. Linuxis näitabresolvectl statusaktiivset linki,dig +short example.comtestib avalikku nime,dig @10.8.0.1 internal.example.comtestib privaatset, jasudo tcpdump -ni any port 53näitab, millist liidest paketid kasutavad, kui käitate mõlemat. Windowsis annavadGet-DnsClientServerAddress -AddressFamily IPv4jaResolve-DnsName example.comsamad kaks fakti: kes on konfigureeritud ja kes vastab.
Lõpetage negatiivse testiga. Ühendage tunnel lahti, kinnitage, et värske avalik nimi ebaõnnestub, kinnitage, et privaatne nimi ebaõnnestub, jakinnitage, et ükski pordi 53 pakett ei lahkunud füüsilisest adapterist. Blokeering, mis peab ainult vahemällu salvestatud vastuste puhul, ei pea üldse.
Kontrollnimekiri enne pileti sulgemist:
- Rikke ajal kasutatud resolver on see, mida poliitika ette näeb.
- Kliendi enda lõpp-punkti otsing on endiselt lubatud, vahemälu või erandi kaudu.
- DoH ja DoT on kas blokeeringuga kaetud või poliitikaga välja lülitatud.
- Privaatsed tsoonid ebaõnnestuvad suletult, mitte avatult, kui tunnel on kadunud.