DNS se neresolvuje, když kill switch VPN zablokuje port 53

Když kill switch shodí tunel, vezme s sebou i cestu DNS a resolver, který zůstane, je málokdy ten, který čekáte. Dva návrhy zvládají ten okamžik velmi odlišně: blokovat každý DNS paket, který není v tunelu, nebonechat jeden resolver stát jako výjimku. Obojí je obhajitelné. Z karty prohlížeče vypadají příznaky téměř stejně, takže prvním úkolem je zjistit, který návrh jste vlastně nasadili.

Držím si ten rozdíl před očima, protože oprava je v každém případě opačná. Jeden návrh potřebuje širší výjimku, druhý užší. Hádání vás stojí buď soukromí, nebo odpoledne.

Dva návrhy DNS pro stejný výpadek

Návrh A bere resolver jako další službu za tunelem. Pravidla firewallu povolují UDP a TCP 53 jen na rozhraní tunelu a adresa předaná klientovi je resolver uvnitř tunelu. Když tunel spadne, vyhledávání se zastaví, a to je zamýšlený výsledek, ne závada.

Návrh B drží resolver dostupný v místní síti, obvykle router na 192.168.1.1 nebo systémová stub adresa 127.0.0.53, s odůvodněním, že překlad jmen by neměl umírat spolu s tunelem. Je to pohodlné v domácí LAN, kde router překládá pro celou domácnost. Na Wi-Fi v hotelu nebo na letišti stejná výjimka míří na cizí server a každé jméno, které napíšete, se vyzradí, i když váš webový provoz zůstává blokovaný.

Hranice je v tom, kdo resolver vlastní. Pokud tomu místnímu věříte, výjimka je malá a poctivá díra. Pokud ne, návrh jen s tunelem je jediný, který drží, a cenou je, že spadlý tunel vezme s sebou všechna jména.

Proč vlastní vyhledávání klienta VPN stále funguje

Klient musí přeložit jméno hostitele brány dřív, než tunel existuje, takže striktní blok nesmí krýt cestu pro bootstrap klienta. Většina klientů buď kešuje adresu koncového bodu, nebo dodává dokumentovanou výjimku pro tento jediný hostitel. Pokud vaše sada pravidel toto vyhledávání blokuje, tunel se nikdy nevrátí a v logech je klient, který nedosáhne na vlastní server, což je vada politiky, ne DNS.

Rozdělený DNS je druhé místo, kde se to objeví. Klient tlačí interní zónu na soukromý resolver a všechno ostatní nechává systémovému resolveru. Po pádu se veřejná jména mohou stále překládat, zatímco interní vyprší, protože soukromá zóna už nemá žádnou trasu. Pro uživatele je to "VPN rozbila internet"; pro log resolveru je to dotaz, který nikdy nedorazil.

Pod systemd-resolved můžete rozdělení vidět přímo.resolvectl statusvypíše DNS servery po spojení a domény směrování a po pádu tunelu interní doména dál ukazuje na server na spoji, který už neexistuje. Stub na 127.0.0.53 dotaz stále přijme, pak čeká na nadřazený server, který neodpoví, a proto selhání trvá sekundy, místo aby se vrátilo hned.

Šifrovaný DNS neobejde filtr paketů

DNS over HTTPS a DNS over TLS jezdí na 443 a 853, takže pravidlo, které blokuje port 53, o nich neřeklo nic. Blokovat "DNS" podle portu je politika o portu, ne o překladu jmen. Pokud váš kill switch blokuje veškerý provoz mimo tunel, DoH je pokryto náhodou. Pokud jste vyčlenili povolení pro captive portal nebo veřejný resolver, není.

Ovládací prvky na straně klienta jsou levnější páka. Firefox opouští svůj DoH resolver, když se kanárčí jménouse-application-dns.netnepřeloží, proto spravované sítě publikují tuto doménu jako NXDOMAIN; podniková politika ji také může připnout vypnutou. Android Private DNS a zabezpečené DNS v Chrome mají vlastní přepínače a vlastní výchozí hodnoty. Vypnout je je spolehlivější než honit adresy resolverů, protože seznam adres se mění a vaše sada pravidel ne.

Existuje verze tohoto, která vůbec není o únicích. Aplikace s připnutým resolverem přesto potřebuje síťovou cestu, aby se k němu dostala. Šifrování mění, kdo může dotaz číst, ne jestli paket může opustit stroj, takže blok celého zařízení nastavení porazí, aniž by se ho dotkl.

Spojte příznak s vrstvou

Většina hlášení přijde jako jedna věta a ta věta obvykle už vrstvu pojmenuje. Tabulka níže je to, co projdu, než se dotknu pravidla; cílem je rozhodnout, zda byl dotaz zablokován, špatně nasměrován, nebo nikdy odeslán.

První dva řádky lidé diagnostikují špatně. Tiché shození i odmítnutí vypadají v prohlížeči stejně jako "DNS je rozbité", ale jen jedno z nich znamená, že váš kill switch dělá svou práci. Odmítnutí znamená, že něco odpovědělo, takže blok není tam, kde si myslíte.

Obnovte politiku resolveru a pak ji dokažte

Opravte návrh, ne příznak. Pro překlad jen v tunelu povolte 53 na rozhraní tunelu, protlačte interní resolver s konfigurací tunelu a nechte fyzické spojení bez jakéhokoli povolení DNS. U wg-quick zapisuje resolver do konfigurace rozhraní řádekDNS =, takže tunel, který ho vynechá, nechá starý resolver na místě a každý dotaz na špatné cestě.manuál wg-quicktoto chování dokumentuje pro každou platformu.

Pak ověřte v tomto pořadí. V Linuxuresolvectl statusukazuje aktivní spoj,dig +short example.comtestuje veřejné jméno,dig @10.8.0.1 internal.example.comtestuje soukromé asudo tcpdump -ni any port 53ukazuje, které rozhraní pakety používají, když spouštíte obojí. Ve WindowsGet-DnsClientServerAddress -AddressFamily IPv4aResolve-DnsName example.comdávají stejná dvě fakta: kdo je nakonfigurován a kdo odpovídá.

Skončete negativním testem. Odpojte tunel, potvrďte, že čerstvé veřejné jméno selže, potvrďte, že soukromé jméno selže, apotvrďte, že žádný paket na port 53 neopustil fyzický adaptér. Blok, který drží jen pro kešované odpovědi, nedrží vůbec.

Kontrolní seznam před uzavřením tiketu:

• Resolver používaný během výpadku je ten, který politika zamýšlí.
• Vlastní vyhledání koncového bodu klienta je stále povoleno, přes keš nebo výjimku.
• DoH a DoT jsou buď pokryté blokem, nebo vypnuté politikou.
• Soukromé zóny selhávají zavřeně, ne otevřeně, jakmile tunel zmizí.