Nastavte DNS na VPN adaptéru Windows v PowerShellu a ověřte to

Windows připojuje DNS tunelu k adaptéru, ne k profilu VPN. Nastavte ho po připojení v PowerShellu a pak otestujte, zda ho opětovné připojení udrží.

Připojení VPN ve Windows neukládá DNS servery do profilu, který upravujete v Nastavení. Když tunel naběhne, klient vyjedná konfiguraci IP s bránou, brána odešle seznam resolverů a Windows jej použije na adaptér tunelu. Tento adaptér je samostatné rozhraní od vaší Wi-Fi nebo Ethernetu a seznam patří rozhraní, ne profilu. Jakmile víte, který objekt hodnotu vlastní, přepsat ji v PowerShellu je jeden příkaz; zajistit, aby přepis přežil opětovné připojení, je část, která vyžaduje rozhodnutí.

Který objekt adresu vlastní

RAS vytvoří adaptér tunelu, když připojení uspěje, a odstraní jej, když připojení spadne. DNS servery, které vidíte v ipconfig /all přicházejí během této výměny konfigurace, vedle adres IPv4 a IPv6 a tras. Protože je hodnota připojena k rozhraní, Set-DnsClientServerAddress zapisuje do něčeho, co existuje jen po dobu, kdy existuje připojení.

Tento jediný fakt vysvětluje většinu zmatku kolem DNS u VPN. Profil lze prohlédnout i odpojený, ale není na co ukázat rozhraním, takže přihlašovací skript, který volá příkaz proti aliasu VPN, selže dřív, než se kdokoli připojil. Vysvětluje i změnu, která vypadá, že se vrací: nic se nevrátilo, rozhraní bylo zničeno a znovu postaveno s hodnotami, které brána odeslala.

Najděte alias, než se dotknete DNS

Název profilu a alias rozhraní jsou obvykle stejný řetězec, ale nejsou to stejné objekty. Get-VpnConnection vypisuje profily; Get-NetAdapter vypisuje rozhraní, která Windows skutečně má. DNS příkazy chtějí druhé a obě se rozcházejí častěji, než lidé čekají, zvlášť když klient k názvu adaptéru přidá popisovač jako "(RAS)".

Pokud profil neexistuje, PowerShell může vytvořit nativní záznam. Typ tunelu a ověřování musí odpovídat tomu, co brána nabízí, protože nesoulad se projeví při připojení, ne při vytvoření:

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

Připojte se jednou, pak přečtěte skutečný alias, než napíšete jakýkoli DNS příkaz:

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

Použijte přepis ve správném pořadí

Pořadí je důležitější než syntaxe. Adaptér musí být nahoru, alias se musí přeložit a účet musí smět měnit nastavení rozhraní. Připojení pro jednoho uživatele obvykle přijme změnu od přihlášeného uživatele; připojení pro všechny uživatele vytvořené s -AllUserConnection obvykle potřebuje zvýšený shell.

Samotný příkaz je jeden řádek, zdokumentovaný v referenci Set-DnsClientServerAddress:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

Dva režimy selhání stojí za to rozpoznat na první pohled. Špatný alias vyvolá chybu příkazu, což je dobrý výsledek, protože ticho by bylo horší. Správný příkaz bez viditelného účinku obvykle znamená, že se díváte na špatný adaptér: zbytkový adaptér tunelu z jiného klienta, fyzickou NIC s podobným popisem nebo druhý virtuální adaptér vytvořený nástrojem pro izolovanou síť.

Proč může opětovné připojení změnu zrušit

Přepis patří jedné instanci rozhraní. Když klient adaptér rozmontuje a při dalším připojení znovu postaví, odeslané hodnoty se znovu použijí a váš seznam je pryč. Někteří klienti rozhraní znovu vytvářejí při každém připojení; jiní je znovu používají po celou dobu relace. Porovnejte index rozhraní v Get-NetAdapter mezi dvěma připojeními a budete vědět, jaké chování máte.

Existují tři trvalé odpovědi a jejich vrstvení vytváří vlastní chyby. DNS suffix specifický pro připojení plus pravidlo NRPT posílá jen interní jmenný prostor internímu resolveru a veřejná jména nechává na pokoji. Nastavení Group Policy nebo MDM použité na připojení VPN nastaví DNS při připojení bez jakéhokoli skriptu. Naplánovaná úloha, která reaguje na událost připojení a znovu spustí příkaz, je hrubá varianta, ale funguje a zanechá log. Vyberte jednoho vlastníka DNS a zapište, který to je.

Interní názvy s jedním štítkem také potřebují seznam pro vyhledávání suffixů. Set-DnsClientGlobalSetting -SuffixSearchList platí pro celý počítač, takže mění překlad pro každý adaptér na stroji, včetně Ethernetu. Otestujte to na laboratorním stroji, než se dostane do image.

Ověřte překlad, ne jen nastavení

Resolver uvedený na adaptéru dokazuje jen to, že byla zapsána hodnota. Zeptejte se zamýšleného serveru přímo, pak se zeptejte normální cestou:

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

Rozdíl vám řekne, kde je závada. Přímý dotaz odpovídá a běžný dotaz selhává: nastavení adaptéru nebo seznam suffixů neplatí. Oba selhávají: resolver je tunelem nedostupný, takže se podívejte na trasy a pravidla firewallu, než se znovu dotknete DNS. Přímý dotaz selhává, zatímco běžný dotaz odpovídá odjinud: split DNS je špatně nakonfigurovaný a na interní jméno odpovídá veřejný resolver, což je problém politiky dřív než problém konektivity.

Spusťte test dvakrát, jednou hned po připojení a jednou po odpojení a opětovném připojení, a porovnejte Get-DnsClientServerAddress výstup obou běhů. Pokud se odeslaná hodnota vrátí při druhém připojení, přepis žil a zemřel s adaptérem a udrží se jen trasa NRPT nebo politiky z předchozí části. Uchovejte oba přepisy a časové značky připojení; vyřeší otázku, zda to vydrží, rychleji než další kolo úprav.

Související články