DNS sa nevyrieši, keď kill switch VPN zablokuje port 53

Keď kill switch zhodí tunel, zoberie so sebou aj cestu DNS, a resolver, ktorý zostane, je málokedy ten, ktorý očakávate. Dva návrhy zvládajú ten okamih veľmi odlišne: blokovať každý DNS paket, ktorý nie je v tuneli, alebo nechať jeden resolver stáť ako výnimku. Oboje je obhájiteľné. Z karty prehliadača vyzerajú príznaky takmer rovnako, takže prvou úlohou je zistiť, ktorý návrh ste vlastne nasadili.

Držím si ten rozdiel pred očami, pretože oprava je v každom prípade opačná. Jeden návrh potrebuje širšiu výnimku, druhý užšiu. Hádanie vás stojí buď súkromie, alebo popoludnie.

Dva návrhy DNS pre ten istý výpadok

Návrh A berie resolver ako ďalšiu službu za tunelom. Pravidlá firewallu povoľujú UDP a TCP 53 len na rozhraní tunela a adresa odovzdaná klientovi je resolver vnútri tunela. Keď tunel padne, vyhľadávanie sa zastaví, a to je zamýšľaný výsledok, nie porucha.

Návrh B drží resolver dostupný v miestnej sieti, zvyčajne router na 192.168.1.1 alebo systémová stub adresa 127.0.0.53, s odôvodnením, že preklad mien by nemal umierať spolu s tunelom. Je to pohodlné v domácej LAN, kde router prekladá pre celú domácnosť. Na Wi-Fi v hoteli alebo na letisku tá istá výnimka mieri na cudzí server a každé meno, ktoré napíšete, sa prezradí, aj keď váš webový provoz zostáva zablokovaný.

Hranica je v tom, kto resolver vlastní. Ak dôverujete miestnemu, výnimka je malá a poctivá diera. Ak nie, návrh len s tunelom je jediný, ktorý drží, a cenou je, že spadnutý tunel zoberie so sebou všetky mená.

Prečo vlastné vyhľadávanie klienta VPN stále funguje

Klient musí preložiť meno hostiteľa brány skôr, než tunel existuje, takže striktný blok nesmie pokrývať cestu na zavedenie klienta. Väčšina klientov buď ukladá adresu koncového bodu do cache, alebo dodáva dokumentovanú výnimku pre tento jediný hostiteľ. Ak vaša sada pravidiel blokuje toto vyhľadávanie, tunel sa nikdy nevráti a záznamy ukážu klienta, ktorý sa nedostane na vlastný server; to je chyba politiky, nie DNS.

Rozdelený DNS je druhé miesto, kde sa to prejaví. Klient tlačí internú zónu na súkromný resolver a všetko ostatné necháva systémovému resolveru. Po páde sa verejné mená môžu ešte prekladať, zatiaľ čo interné vypršia, pretože súkromná zóna už nemá trasu. Pre používateľa je to "VPN pokazila internet"; pre záznam resolvera je to dopyt, ktorý nikdy nedorazil.

Pod systemd-resolved vidíte rozdelenie priamo. resolvectl status vypíše DNS servery po spojení a domény smerovania a po páde tunela interná doména naďalej ukazuje na server na spojení, ktoré už neexistuje. Stub na 127.0.0.53 dopyt ešte prijme, potom čaká na nadradený server, ktorý neodpovie, a preto zlyhanie trvá sekundy namiesto okamžitého návratu.

Šifrovaný DNS neobíde filter paketov

DNS over HTTPS a DNS over TLS chodia po 443 a 853, takže pravidlo, ktoré blokuje port 53, o nich nič nepovedalo. Blokovať "DNS" podľa portu je politika o porte, nie o preklade mien. Ak váš kill switch blokuje všetku prevádzku mimo tunela, DoH je pokryté náhodou. Ak ste vyčlenili povolenie pre captive portal alebo verejný resolver, nie je.

Ovládacie prvky na strane klienta sú lacnejšia páka. Firefox opúšťa svoj DoH resolver, keď sa kanárie meno use-application-dns.net nepreloží, a preto spravované siete publikujú tú doménu ako NXDOMAIN; podniková politika ju môže aj pripnúť vypnutú. Android Private DNS a zabezpečené DNS v Chrome majú vlastné prepínače a vlastné predvolené hodnoty. Vypnúť ich je spoľahlivejšie ako naháňať adresy resolverov, pretože zoznam adries sa mení a vaša sada pravidiel nie.

Existuje verzia tohto, ktorá vôbec nie je o únikoch. Aplikácia s pripnutým resolverom napriek tomu potrebuje sieťovú cestu, aby sa k nemu dostala. Šifrovanie mení, kto môže dopyt čítať, nie to, či paket môže opustiť stroj, takže blok celého zariadenia nastavenie porazí bez toho, aby sa ho dotkol.

Spojte príznak s vrstvou

Väčšina hlásení prichádza ako jedna veta a tá veta zvyčajne už pomenúva vrstvu. Tabuľka nižšie je to, čo prejdem, kým sa dotknem pravidla; ide o to rozhodnúť, či bol dopyt zablokovaný, zle nasmerovaný alebo nikdy odoslaný.

Prvé dva riadky sú tie, ktoré ľudia diagnostikujú nesprávne. Tiché zhodenie aj odmietnutie vyzerajú v prehliadači rovnako ako "DNS sa pokazil", ale len jedno z nich znamená, že váš kill switch robí svoju prácu. Odmietnutie znamená, že niečo odpovedalo, takže blok nie je tam, kde si myslíte.

Obnovte politiku resolvera a potom ju dokážte

Opravte návrh, nie príznak. Pre preklad len v tuneli povoľte 53 na rozhraní tunela, pretlačte interný resolver s konfiguráciou tunela a nechajte fyzické spojenie bez akéhokoľvek povolenia DNS. Pri wg-quick je to riadok DNS =, ktorý zapisuje resolver do konfigurácie rozhrania, takže tunel, ktorý ho vynechá, nechá starý resolver na mieste a každý dopyt na nesprávnej ceste. manuál wg-quick dokumentuje toto správanie pre každú platformu.

Potom overte v tomto poradí. V Linuxe resolvectl status zobrazuje aktívne spojenie, dig +short example.com testuje verejné meno, dig @10.8.0.1 internal.example.com testuje súkromné a sudo tcpdump -ni any port 53 ukazuje, ktoré rozhranie pakiety používajú, keď spúšťate oboje. Vo Windows Get-DnsClientServerAddress -AddressFamily IPv4 a Resolve-DnsName example.com dávajú tie isté dva fakty: kto je nakonfigurovaný a kto odpovedá.

Skončite negatívnym testom. Odpojte tunel, potvrďte, že čerstvé verejné meno zlyhá, potvrďte, že súkromné meno zlyhá, a potvrďte, že žiadny paket na port 53 neopustil fyzický adaptér. Blok, ktorý drží len pre cachované odpovede, nedrží vôbec.

Kontrolný zoznam pred uzavretím tiketu:

• Resolver používaný počas výpadku je ten, ktorý politika zamýšľa.
• Vlastné vyhľadanie koncového bodu klienta je stále povolené, cez cache alebo výnimku.
• DoH a DoT sú buď pokryté blokom, alebo vypnuté politikou.
• Súkromné zóny zlyhávajú zavreté, nie otvorené, len čo tunel zmizne.