Kdo na Windows skutečně aplikuje DNS nastavení OpenConnect?
Windows drží stav resolveru na třech místech. Najděte pomocníka, který vlastní připojení, než začnete ručně upravovat DNS adaptéru nebo přidávat pravidlo jmenného prostoru.
Zvednout tunel není totéž jako nainstalovat jeho DNS hodnoty. OpenConnect vyjednává a pomocník na straně Windows je aplikuje. Mezera mezi těmito dvěma kroky vysvětluje většinu selhání privátních jmen u tohoto klienta a pomocník téměř nikdy není stránka nastavení VPN ve Windows.
Oddělte, co nabídla brána, od toho, co Windows nainstaloval
Klient předává údaje o připojení skriptovacímu rozhraní a varianty pro Unix a Windows jsou samostatné programy. Ve Windows je implementací obvykle pomocník v JavaScriptu, který čte proměnné jako interní DNS server a interní doména, než se dotkne jakéhokoli adaptéru. Nic v samotném tunelu nezapisuje stav resolveru.
Toto rozdělení je důležité, protože hodnota může existovat ve vyjednávání a nikdy se nedostat k adaptéru. Pomocník, který chybí, selže v polovině nebo je starší kopií zabalenou do GUI obalu, nechá Windows přesně tak, jak byly. Relace vypadá připojená, privátní jméno se stále překládá přes místního poskytovatele a nic v okně klienta na rozdíl neupozorňuje. Čtení vlastního výstupu pomocníka je jediný spolehlivý způsob, jak zjistit, která fáze se rozbila.
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
GUI obal může dodávat vlastní kopii klienta i pomocníka, takže druhý openconnect.exe jinde na disku nic nedokazuje. Najděte spustitelný soubor, který relaci zahájil, než posoudíte jeho konfiguraci.
Přečtěte stav resolveru, aniž byste ho měnili
Tři dotazy jen pro čtení pokrývají obvyklý zmatek a každý odpovídá na jinou otázku:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effective
Server na úrovni adaptéru je to, co většina lidí myslí VPN DNS. Sufix specifický pro připojení rozhoduje, zda se krátké jméno vůbec rozšíří. Seznam zásad jmenného prostoru se vztahuje na odpovídající jména bez ohledu na pořadí adaptérů a prázdný výsledek tam není závadou, když pomocník nikdy neměl v úmyslu nějaký vytvořit. Přečíst všechny tři před úpravou je to, co zabrání opravě, která jen přesune příznak jinam.
Začněte plně kvalifikovaným jménem. Pokud se FQDN přeloží a krátké jméno ne, je mezerou sufix nebo seznam hledání, ne adresa serveru.
Jako druhý krok se ptejte přímo zamýšleného serveru, jakýmkoli již nainstalovaným nástrojem resolveru. Přímá odpověď dokazuje, že server je dostupný a autoritativní pro zónu. Nedokazuje nic o tom, který server aplikace standardně oslovuje.
Pojmenujte komponentu, která vlastní připojení
Běžná jsou dvě uspořádání. Klient spuštěný z terminálu předává cestu ke svému skriptu explicitně, takže vlastník je vidět v příkazu, který se spustil. Zabalená aplikace spouští klienta za vás a drží pomocníka ve vlastním adresáři, což znamená, že dodavatel rozhoduje, kdy se změní.
Porovnejte verze pomocníka mezi instalacemi, než cokoli vyměníte. Spuštění pomocníka staženého ze zrcadla se zvýšenými právy jen proto, že název souboru vypadá povědomě, promění mezeru v DNS v bezpečnostní incident.
Jakmile je vlastník znám, cíl opravy je zřejmý: podporovaná cesta ke skriptu ve spouštěči, aktualizace balíčku nebo opravený profil na bráně. Nic z toho nevyžaduje ruční úpravu vlastností adaptéru.
Opravte vlastníka, ne adaptér
Ručně nastavený DNS adaptéru často přežije odpojení, proto se zdá, že funguje, a pak způsobí potíže v další síti. Veřejný resolver přišroubovaný ke každému rozhraní skrývá problém privátního jmenného prostoru, místo aby ho řešil. Když pomocník nikdy nedostal DNS hodnotu, hledejte v profilu brány. Když ji dostal a adaptér stále ukazuje starý server, pomocník při připojení selhal a klientský log to obvykle zaznamená poblíž řádků nastavení tunelu.
Obnovte stav podporovanou cestou a poté ověřte celý cyklus: připojte se, přeložte privátní FQDN, otevřete službu, odpojte se a potvrďte, že se adaptér vrátil s předchozími servery.
Zkontrolujte aplikaci, která skutečně selhává
Prohlížeč s vlastním nastavením šifrovaného DNS ignoruje vše výše a dál odpovídá z veřejného resolveru. Aplikace, která drží uloženou negativní odpověď z doby před zvednutím tunelu, se chová stejně. Porovnejte ji s obyčejným systémovým dotazem na stejném počítači, než znovu změníte adresy resolveru.
Pokud je systémový dotaz správný a aplikace ne, zbývající závada je v DNS konfiguraci této aplikace, ne v cestě VPN.