VPN převzal DNS a rozbil místní názvy: opravte seznam

Tunel se zvedne, intranet se načte a název tiskárny přestane být resolvován. Nebo naopak: místní názvy stále fungují, zatímco všechno uvnitř podnikové sítě vyprší. Oba příznaky pocházejí ze stejného místa, ze seznamu resolverů, který klient VPN při připojení přepsal.

Opravte seznam záměrně a potom se samostatně věnujte mechanismu push. Trasy jsou třetí téma a ne to, co se zde opravuje.

Který seznam aplikace skutečně používají

Windows resolvuje přes nastavení na úrovni rozhraní, ne přes to, co ukazuje nějaký dialog, takže začněte efektivními seznamy pro každé rozhraní. Alias je důležitější než zobrazovaný název, protože každý příkaz níže oslovuje rozhraní. Spletete-li alias, oprava přistane na špatném adaptéru. Bude to vypadat, že funguje, až do dalšího připojení, kdy se vrátí vlastní záznam tunelu.

Otázkou je, které servery se dostaly dopředu a zda přišly jako statické záznamy, nebo jako DHCP lease. Obě skutečnosti rozhodují, která oprava je vám k dispozici.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Přečtěte výstup pro adaptér tunelu a pro fyzický adaptér a poznamenejte každou adresu na každém z nich. Statický záznam lze odstranit zásadou nebo skriptem; záznam z DHCP je vázán na lease a vrátí se, což mění opravu, kterou byste měli zvolit. Názvy ve vzdálené síti resolvuje inzerovaný resolver, názvy v místní LAN fyzický adaptér a dotaz jde na seznam, který se prohlíží první.

Odstraňte protlačené servery nebo je zařaďte níž

Smažte protlačené servery, když je nic uvnitř tunelu nepotřebuje, protože vlastní resolvery fyzického adaptéru znovu převezmou. Ponechte je jen tehdy, pokud vzdálená síť vlastní zóny, na které umějí odpovědět pouze její servery, a v tom případě postavte před ně místní resolver. Dva příkazy níže pokrývají obě volby, takže vyberte ten, který odpovídá situaci, místo abyste spouštěli oba.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Index 1 se prohlíží první, takže protlačené adresy zůstávají dostupné, ale přestávají být výchozí odpovědí na každý dotaz. Přepínač validate=no přeskakuje test dostupnosti, který často selhává, dokud se tunel ještě usazuje, takže výsledek potvrďte příkazem show, místo abyste věřili návratovému kódu.

Před tím, než se na to spolehnete, stojí za to znát dvě omezení. Windows nesmaže servery, které přišly přes DHCP prostřednictvím netsh, a tyto hodnoty přetrvávají jako DhcpNameServer pod klíčem registru rozhraní, takže úprava registru je poslední možnost, kterou je třeba po dalším lease znovu zkontrolovat. Pořadí vázání adaptérů také není spolehlivý mechanismus řazení, protože klient VPN může vložit svůj záznam na začátek seznamu.

Kde lze push filtrovat

Lepší oprava odstraní volbu dřív, než se použije. Klient Community OpenVPN umí filtrovat protlačenou direktivu podle názvu, což ponechá konfiguraci serveru nedotčenou.

pull-filter ignore "dhcp-option DNS "

Koncová mezera patří ke shodě a filtr pojmenovává volbu, ne adresu serveru. Pokud profil obsahuje také direktivu block-outside-dns, její odstranění mění ochranu proti úniku, ne resolvování názvů, takže to rozhodněte samostatně, místo abyste obě úpravy spojovali.

Pro jedno zarputilé jméno hostitele je jeden řádek v souboru hosts Windows stabilnější než přehazování resolverů pro celý stroj. Je také neviditelný pro dalšího člověka, takže ho zaznamenejte tam, kde se dokumentuje konfigurace stroje.

Zařiďte, aby oprava přežila opětovné připojení

Resolvování je třeba otestovat dvakrát, jednou proti zvolenému serveru a jednou ve formě, kterou používá aplikace. Tato dvojice odděluje problém pořadí resolverů od serveru, který vůbec neodpovídá. Přeskočení prvního testu nechá obě příčiny propletené.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Znovu připojte tunel a zopakujte oba příkazy. Cokoli jste změnili ručně, vydrží jen do dalšího připojení, protože klient při zvedání adaptéru znovu sestaví stav resolverů. Vložte řádky netsh do podporovaného skriptu pro připojení vašeho klienta, nechte skript úspěšně skončit a přidejte krátké čekání, než se spustí. Klient, který aplikuje DNS po skriptu, výsledek tak jako tak přepíše.

Pokud se veřejné názvy resolvují a vnitřní po opravě stále selhávají, seznam resolverů už není podezřelý. Dotaz se pravděpodobně vůbec nedostane na server, což ukazuje na směrování nebo pravidlo firewallu, ne na další nastavení DNS. Poznamenejte alias rozhraní a adresy, na kterých jste se zastavili, protože obojí se mezi stroji liší a ani jedno nepřežije přestavbu samo o sobě.