Prečo DNS po pripojení OpenVPN v systéme Windows prestane fungovať

Port 53 nikam nevedie, no resolver stále odpovedá na ping. Skontrolujte, či filtruje block-outside-dns, a potom zabezpečte resolver, na ktorý tunel dosiahne.

Ping na kancelársky resolver po pripojení "OpenVPN" stále dostáva odpoveď, a napriek tomu každé hľadanie názvu zlyhá. Adresa je dostupná, port však nie, čo dáva zmysel, keď viete, že Windows dokáže filtrovať DNS podľa adaptéra. Ak je v profile block-outside-dns, ten filter je prvý podozrivý a smerovacia tabuľka je nesprávne miesto, kde hľadať. Dva testy nižšie oddelia vrstvy za sekundy.

Dostupná adresa, mŕtvy port

Úspešný ping dokazuje, že hostiteľ beží a že cesta existuje. Nič nehovorí o povolení dostať sa na port 53, pretože dotyčný filter pracuje v inej vrstve a viaže sa na adaptér. Preto ten istý stroj môže odpovedať na ICMP a odmietnuť každú požiadavku odoslanú na tú istú adresu. Spustite oba testy v tej istej relácii, kým zmeníte akúkoľvek konfiguráciu.

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

Táto dvojica je diagnóza. Bežná prevádzka do podsiete pokračuje, kým preklad názvov umiera, a ľudia usúdia, že server je pokazený alebo že DNS sa nikdy neposlal. Obe vysvetlenia sú drahé na sledovanie a dôkazy ukazujú na niečo užšie. Potvrďte dvojicu, kým sa dotknete nastavenia.

Táto voľba je pravidlo filtračnej platformy

Referenčná dokumentácia OpenVPN opisuje block-outside-dns ako obmedzenie Windows Filtering Platform, ktoré aplikáciám bráni dosiahnuť DNS na adaptéroch mimo tunela. Pokrýva TCP a UDP port 53. Keďže filter žije vo WFP a nie v bežnom zozname pravidiel brány firewall, pridanie povoľovacieho pravidla inde nemusí zmeniť výsledok. Preto bežná rada povoliť DNS stále zlyháva.

Nastavenie môže prísť z importovaného profilu alebo zo servera a súbor, ktorý ste naposledy upravovali, "nie je dôkazom toho, čo klient načítal". Čítajte efektívnu konfiguráciu a protokol pripojenia spolu. Voľba je tiež špecifická pre Windows a jej považovanie za prenosnú vytvára rady, ktoré neplatia.

Hľadajte klientsky komponent, ktorý obmedzenie vlastní, namiesto pridávania ďalších pravidiel. Vlastník je to, čo ho skutočne dokáže odstrániť.

Filter nie je resolver

Blokovanie prevádzky mimo tunela nenainštaluje v ňom funkčný resolver. Voľba odstraňuje cestu a necháva DNS konfiguráciu tunela na tom, kto profil nastavil. Profil, ktorý nikdy neposlal resolver, teraz nemá žiadny.

Prejdite tri kontroly v poradí. Po prvé, ktorý resolver zlyhávajúca aplikácia skutočne používa. Po druhé, či klient použil nastavenia DNS pre VPN. Po tretie, ktoré rozhranie nesie prevádzku k tomuto resolveru.

  1. Používaný resolver: porovnajte Resolve-DnsName -Server <resolver-ip> <name> s DNS servermi, ktoré vypisuje ipconfig /all.
  2. DNS pre VPN použité: pozrite si DNS záznamy tunelového adaptéra v tom istom výstupe ipconfig /all.
  3. Použité rozhranie: Find-NetRoute -RemoteIPAddress <resolver-ip> určuje odchádzajúce rozhranie pre tento cieľ.

LAN resolver sa podľa návrhu stane nedostupným pri tejto politike, aj keď iná prevádzka v LAN funguje. To je voľba, ktorá robí svoju prácu. Ak návrh potrebuje DNS cez VPN, opravte registráciu resolvera a cestu tunela; ak je potrebný split DNS s lokálnymi výnimkami, vlastník konfigurácie musí tieto výnimky vyjadriť podporovaným spôsobom.

Čo voľba nepokrýva

Port 53 nie je celý preklad názvov. DNS over HTTPS a DNS over TLS používajú iný transport a niektoré aplikácie spúšťajú vlastnú logiku resolvera bez ohľadu na systémové nastavenia. Prehliadač preto môže prekladať názvy, kým príkazový riadok nie.

Berte tento rozdiel ako diagnostiku, nie ako rozpor. Porovnajte oboje, kým usúdite, že systémový resolver je pokazený.

Pri písaní držte záver úzky. Táto voľba obmedzuje jeden transport na jednej platforme a zvyšok cesty prekladu je samostatná otázka návrhu s vlastným vlastníkom.

Skontrolujte stav pred odpojením a po ňom

Spustite rovnaké hľadanie počas pripojenia a znova po tom, čo sa vlastnícky klient odpojí. Prvé by malo pri vonkajšom resolveri zlyhať, kým je tunel hore, a druhé by malo uspieť po odstránení filtra. Ak po odpojení stále zlyháva, filter nebol vyčistený.

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

Reštart klientskej služby alebo stroja zvyčajne vyčistí starý filter. Potvrdzuje to diagnózu bez dôkazu trvalej opravy. Zapíšte, čo ste videli, pretože filter, ktorý prežije odpojenie, to urobí znova, a práve záznam odôvodňuje hlásenie chyby.

Až po týchto kontrolách má zmysel vymeniť resolver alebo prestavať politiku brány firewall. Oboje sú väčšie zmeny, než dôkazy podporujú.

Súvisiace články