DNS se ne razreši, ko kill switch VPN blokira vrata 53

Ko kill switch podre tunel, s seboj vzame tudi pot DNS, in resolver, ki ostane, redko je tisti, ki ga pričakujete. Dva dizajna se tega trenutka lotevata zelo različno: blokirati vsak paket DNS, ki ni v tunelu, ali pustiti en resolver stati kot izjemo. Oboje je zagovorljivo. Z zavihka brskalnika so simptomi videti skoraj enaki, zato je prva naloga ugotoviti, kateri dizajn ste dejansko uvedli.

To razliko držim pred očmi, ker je popravek v vsakem primeru nasproten. En dizajn potrebuje širšo izjemo, drugi ožjo. Ugibanje vas stane bodisi zasebnosti bodisi popoldneva.

Dva dizajna DNS za isto odpoved

Dizajn A obravnava resolver kot še eno storitev za tunelom. Pravila požarnega zidu dovoljujejo UDP in TCP 53 samo na vmesniku tunela, naslov, ki ga dobi odjemalec, pa je resolver znotraj tunela. Ko tunel pade, se iskanja ustavijo, in to je predvideni rezultat, ne okvara.

Dizajn B ohranja resolver dosegljiv v lokalnem omrežju, običajno usmerjevalnik na 192.168.1.1 ali sistemski stub na 127.0.0.53, z obrazložitvijo, da razreševanje imen ne bi smelo umreti s tunelom. To je priročno v domačem LAN-u, kjer usmerjevalnik razrešuje za vso hišo. V Wi-Fi-ju hotela ali letališča ista izjema kaže na tuj strežnik in vsako ime, ki ga vtipkate, je razkrito, čeprav vaš spletni promet ostane blokiran.

Meja je, kdo ima resolver v lasti. Če zaupate lokalnemu, je izjema majhna in poštena luknja. Če ne, je dizajn samo-s-tunelom edini, ki zdrži, cena pa je, da podrt tunel s seboj vzame vsa imena.

Zakaj lastno iskanje odjemalca VPN še deluje

Odjemalec mora razrešiti ime gostitelja prehoda, preden tunel obstaja, zato stroga blokada ne sme pokriti zagonske poti odjemalca. Večina odjemalcev bodisi predpomni naslov končne točke bodisi priloži dokumentirano zagonsko izjemo za tega enega gostitelja. Če vaš nabor pravil blokira to iskanje, se tunel nikoli ne vrne in dnevniki pokažejo odjemalca, ki ne doseže lastnega strežnika; to je napaka politike, ne DNS.

Razdeljeni DNS je drugi kraj, kjer se to pokaže. Odjemalec potisne notranjo cono k zasebnemu resolverju in vse ostalo pusti sistemskemu resolverju. Po padcu se javna imena morda še razrešujejo, notranja pa potečejo, ker zasebna cona nima več poti. Za uporabnika je to "VPN je pokvaril internet"; za dnevnik resolverja je to poizvedba, ki ni nikoli prispela.

Pod systemd-resolved delitev vidite neposredno. resolvectl status navede strežnike DNS po povezavi in domene usmerjanja, po padcu tunela pa notranja domena še naprej kaže na strežnik na povezavi, ki je ni več. Stub na 127.0.0.53 poizvedbo še sprejme, nato čaka na nadrejeni strežnik, ki ne bo odgovoril, in zato okvara traja sekunde, namesto da bi se takoj vrnila.

Šifriran DNS ne obide filtra paketov

DNS over HTTPS in DNS over TLS potujeta po 443 in 853, zato pravilo, ki blokira vrata 53, o njima ni povedalo ničesar. Blokirati "DNS" po vratih je politika o vratih, ne o razreševanju imen. Če vaš kill switch blokira ves promet zunaj tunela, je DoH pokrit po naključju. Če ste izločili dovoljenje za captive portal ali javni resolver, ni.

Upravljanje na strani odjemalca je cenejši vzvod. Firefox opusti svoj resolver DoH, ko se kanarčje ime use-application-dns.net ne razreši, zato upravljana omrežja to domeno objavijo kot NXDOMAIN; poslovna politika jo lahko tudi pripne izklopljeno. Android Private DNS in varni DNS Chroma imata svoja stikala in svoje privzete vrednosti. Izklopiti jih je zanesljivejše kot loviti naslove resolverjev, ker se seznam naslovov spreminja, vaš nabor pravil pa ne.

Obstaja različica tega, ki sploh ne govori o uhajanju. Aplikacija s pripetim resolverjem še vedno potrebuje omrežno pot, da ga doseže. Šifriranje spremeni, kdo lahko prebere poizvedbo, ne pa tega, ali paket lahko zapusti stroj, zato blokada za celotno napravo premaga nastavitev, ne da bi se je dotaknila.

Ujemite simptom s plastjo

Večina poročil prispe kot en stavek in ta stavek običajno že poimenuje plast. Tabela spodaj je tisto, kar preidem, preden se dotaknem pravila; cilj je odločiti, ali je bila poizvedba blokirana, napačno usmerjena ali nikoli poslana.

Prvi dve vrstici sta tisti, ki ju ljudje napačno diagnosticirajo. Tiho podrtje in zavrnitev sta v brskalniku videti enako kot "DNS se je pokvaril", a le eno od tega pomeni, da vaš kill switch opravlja svoje delo. Zavrnitev pomeni, da je nekaj odgovorilo, zato blokada ni tam, kjer mislite.

Obnovite politiko resolverja in jo nato dokažite

Popravite dizajn, ne simptoma. Za razreševanje samo v tunelu dovolite 53 na vmesniku tunela, potisnite notranji resolver skupaj s konfiguracijo tunela in pustite fizično povezavo brez kakršnega koli dovoljenja DNS. Pri wg-quick je vrstica DNS = tista, ki zapiše resolver v konfiguracijo vmesnika, zato tunel, ki jo izpusti, pusti stari resolver na mestu in vsaka poizvedba gre po napačni poti. priročnik wg-quick dokumentira to vedenje za vsako platformo.

Nato preverite v tem vrstnem redu. V Linuxu resolvectl status pokaže aktivno povezavo, dig +short example.com preizkusi javno ime, dig @10.8.0.1 internal.example.com preizkusi zasebno, in sudo tcpdump -ni any port 53 pokaže, kateri vmesnik uporabljajo paketi, medtem ko izvajate oba. V Windows Get-DnsClientServerAddress -AddressFamily IPv4 in Resolve-DnsName example.com dasta isti dve dejstvi: kdo je konfiguriran in kdo odgovarja.

Končajte z negativnim testom. Odklopite tunel, potrdite, da sveže javno ime odpove, potrdite, da zasebno ime odpove, in potrdite, da noben paket na vratih 53 ni zapustil fizičnega adapterja. Blokada, ki zdrži le za predpomnjene odgovore, ne zdrži prav nič.

Kontrolni seznam pred zaprtjem zahtevka:

• Resolver, uporabljen med odpovedjo, je tisti, ki ga predvideva politika.
• Lastno iskanje končne točke odjemalca je še vedno dovoljeno, prek predpomnilnika ali izjeme.
• DoH in DoT sta bodisi zajeta z blokado bodisi onemogočena s politiko.
• Zasebne cone odpovejo zaprto, ne odprto, ko tunela ni več.