Proč DNS po připojení OpenVPN ve Windows přestane fungovat

Resolver stále odpovídá na ping, zatímco port 53 nikam nevede. Zkontrolujte, zda filtruje block-outside-dns, a pak zajistěte resolver, na který tunel dosáhne.

Ping na kancelářský resolver po připojení "OpenVPN" stále dostává odpověď, a přesto každé hledání názvu selže. Adresa je dostupná, port však ne, což dává smysl ve chvíli, kdy víte, že Windows umí filtrovat DNS podle adaptéru. Je-li v profilu block-outside-dns, je tento filtr první podezřelý a směrovací tabulka je špatné místo, kde hledat. Dva testy níže oddělí vrstvy během sekund.

Dostupná adresa, mrtvý port

Úspěšný ping dokazuje, že hostitel běží a že cesta existuje. Nic neříká o povolení k portu 53, protože dotyčný filtr pracuje v jiné vrstvě a váže se na adaptér. Proto stejný stroj může odpovědět na ICMP a odmítnout každý dotaz poslaný na stejnou adresu. Spusťte oba testy ve stejné relaci, než změníte jakoukoli konfiguraci.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Dvojice je diagnóza. Běžný provoz do podsítě dál funguje, zatímco překlad jmen umírá, a lidé usoudí, že server je rozbitý nebo že DNS nebylo nikdy předáno. Obě vysvětlení jsou drahá na sledování a důkazy ukazují na něco užšího. Potvrďte dvojici, než se dotknete jakéhokoli nastavení.

Volba je pravidlo filtrační platformy

Referenční dokumentace OpenVPN popisuje block-outside-dns jako omezení Windows Filtering Platform, které aplikacím brání dosáhnout na DNS na adaptérech mimo tunel. Pokrývá TCP a UDP port 53. Protože filtr žije ve WFP, a ne v běžném seznamu pravidel brány firewall, přidání povolovacího pravidla jinde nutně nezmění výsledek. Proto běžná rada povolit DNS stále selhává.

Nastavení může přijít z importovaného profilu nebo ze serveru, a soubor, který jste naposledy upravovali, "není důkazem toho, co klient načetl". Čtěte efektivní konfiguraci a protokol připojení společně. Volba je také specifická pro Windows a její považování za přenosnou vytváří rady, které neplatí.

Hledejte klientskou komponentu, která omezení vlastní, místo abyste přidávali další pravidla. Vlastník je to, co ho skutečně dokáže odstranit.

Filtr není resolver

Blokování provozu mimo tunel nenainstaluje uvnitř něj funkční resolver. Volba odstraňuje cestu a nechává DNS konfiguraci tunelu na tom, kdo profil nastavil. Profil, který nikdy resolver nepředal, teď nemá žádný.

Projděte tři kontroly v pořadí. Za prvé, který resolver selhávající aplikace skutečně používá. Za druhé, zda klient použil nastavení VPN DNS. Za třetí, které rozhraní nese provoz k tomuto resolveru.

  1. Používaný resolver: porovnejte Resolve-DnsName -Server <resolver-ip> <name> s DNS servery, které vypisuje ipconfig /all.
  2. VPN DNS použito: prohlédněte DNS záznamy tunelového adaptéru ve stejném výstupu ipconfig /all.
  3. Použité rozhraní: Find-NetRoute -RemoteIPAddress <resolver-ip> určuje odchozí rozhraní pro tento cíl.

LAN resolver se podle návrhu stane nedostupným při této politice, i když jiný provoz v LAN funguje. To je volba, která dělá svou práci. Pokud návrh potřebuje VPN DNS, opravte registraci resolveru a cestu tunelem; pokud je potřeba split DNS s lokálními výjimkami, musí vlastník konfigurace tyto výjimky vyjádřit podporovaným způsobem.

Co volba nepokrývá

Port 53 není celý překlad jmen. DNS over HTTPS a DNS over TLS používají jiné transporty a některé aplikace spouštějí vlastní logiku resolveru bez ohledu na systémová nastavení. Prohlížeč proto může překládat jména, zatímco příkazový řádek ne.

Berte tento rozdíl jako diagnostiku, nikoli jako rozpor. Porovnejte obojí, než usoudíte, že systémový resolver je rozbitý.

Při sepisování držte závěr úzký. Tato volba omezuje jeden transport na jedné platformě a zbytek cesty překladu je samostatná otázka návrhu s vlastním vlastníkem.

Zkontrolujte stav před odpojením a po něm

Spusťte stejné hledání během připojení a znovu poté, co se vlastnící klient odpojí. První by mělo u vnějšího resolveru selhat, dokud je tunel nahoře, a druhé by mělo uspět, jakmile je filtr odstraněn. Pokud po odpojení stále selhává, filtr nebyl uklizen.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Restart klientské služby nebo stroje obvykle starý filtr uklidí. To diagnózu potvrzuje, aniž by dokazovalo trvalou opravu. Zapište, co jste viděli, protože filtr, který přežije odpojení, to udělá znovu, a právě záznam opodstatňuje hlášení chyby.

Teprve po těchto kontrolách má smysl vyměnit resolver nebo přestavět politiku brány firewall. Obojí jsou větší změny, než důkazy podporují.

Související články