Nastavenie DNS na adaptéri VPN v systéme Windows pomocou PowerShellu a následné overenie
Windows priraďuje DNS tunela k adaptéru, nie k profilu VPN. Nastavte ho po pripojení v PowerShelli a potom otestujte, či ho opätovné pripojenie zachová.
Pripojenie VPN v systéme Windows neukladá servery DNS do profilu, ktorý upravujete v Nastaveniach. Keď sa tunel zdvihne, klient vyjedná konfiguráciu IP s bránou, brána pošle zoznam prekladačov a Windows ho použije na adaptér tunela. Ten adaptér je samostatné rozhranie od vášho Wi-Fi alebo Ethernetu a zoznam patrí rozhraniu, nie profilu. Keď raz viete, ktorý objekt vlastní hodnotu, prepísanie v PowerShelli je jediný príkaz; dosiahnuť, aby prepísanie prežilo opätovné pripojenie, je tá časť, ktorá si vyžaduje rozhodnutie.
Ktorý objekt vlastní adresu
RAS vytvorí adaptér tunela, keď pripojenie uspeje, a odstráni ho, keď pripojenie padne. Servery DNS, ktoré vidíte v ipconfig /all, prichádzajú počas tejto výmeny konfigurácie, vedľa adries IPv4 a IPv6 a trás. Pretože hodnota je pripnutá k rozhraniu, Set-DnsClientServerAddress zapisuje do niečoho, čo existuje len tak dlho, ako existuje pripojenie.
Tento jediný fakt vysvetľuje väčšinu zmätku okolo DNS vo VPN. Profil si môžete prezrieť aj pri odpojení, ale neexistuje rozhranie, na ktoré by sa dalo ukázať, takže prihlasovací skript, ktorý volá cmdlet proti aliasu VPN, zlyhá skôr, než sa niekto pripojí. Vysvetľuje aj zmenu, ktorá vyzerá, že sa vracia späť: nič sa nevrátilo, rozhranie bolo zničené a znovu postavené s hodnotami, ktoré poslala brána.
Nájdite alias skôr, než sa dotknete DNS
Názov profilu a alias rozhrania sú zvyčajne ten istý reťazec, ale nie sú ten istý objekt. Get-VpnConnection vypisuje profily; Get-NetAdapter vypisuje rozhrania, ktoré Windows skutočne má. Cmdlety DNS chcú to druhé a tieto dve sa rozchádzajú častejšie, než ľudia očakávajú, najmä keď klient pridá k názvu adaptéra opis ako "(RAS)".
Ak profil neexistuje, PowerShell môže vytvoriť natívny záznam. Typ tunela a overenie sa musia zhodovať s tým, čo ponúka brána, pretože nezhoda sa prejaví pri pripájaní, nie pri vytváraní:
Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
-TunnelType Ikev2 -EncryptionLevel Required `
-AuthenticationMethod Eap -AllUserConnection
Pripojte sa raz a potom prečítajte skutočný alias skôr, než napíšete akýkoľvek príkaz DNS:
rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"
Aplikujte prepísanie v správnom poradí
Poradie je dôležitejšie ako syntax. Adaptér musí byť aktívny, alias sa musí prekladať a účet musí mať povolenie meniť nastavenia rozhrania. Pripojenie pre používateľa zvyčajne prijme zmenu od prihláseného používateľa; pripojenie pre všetkých používateľov vytvorené s -AllUserConnection spravidla potrebuje prostredie s vyššími právami.
Samotný cmdlet je jeden riadok, zdokumentovaný v referencii Set-DnsClientServerAddress od Microsoftu:
Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4
Dva režimy zlyhania stojí za to rozpoznať na prvý pohľad. Nesprávny alias vyvolá chybu cmdletu a to je dobrý výsledok, pretože ticho by bolo horšie. Správny cmdlet bez viditeľného účinku zvyčajne znamená, že sa pozeráte na nesprávny adaptér: zostávajúci adaptér tunela z iného klienta, fyzickú sieťovú kartu s podobným opisom alebo druhý virtuálny adaptér vytvorený nástrojom na siete v izolovanom prostredí.
Prečo môže opätovné pripojenie zrušiť zmenu
Prepísanie patrí jednej inštancii rozhrania. Keď klient adaptér zbúra a pri ďalšom pripojení ho znova postaví, poslané hodnoty sa znova použijú a váš zoznam je preč. Niektorí klienti vytvárajú rozhranie nanovo pri každom pripojení; iní ho používajú celý čas trvania relácie. Porovnajte index rozhrania v Get-NetAdapter medzi dvoma pripojeniami a budete vedieť, aké správanie máte.
Existujú tri trvalé odpovede a ich vrstvenie vytvára vlastné chyby. Prípona DNS špecifická pre pripojenie plus pravidlo NRPT posiela len interný priestor mien internému prekladaču a verejné mená necháva na pokoji. Nastavenie skupinovej politiky alebo MDM použité na pripojenie VPN nastaví DNS pri pripojení bez akéhokoľvek skriptu. Naplánovaná úloha, ktorá reaguje na udalosť pripojenia a znova spustí cmdlet, je hrubá možnosť, ale funguje a zanechá záznam. Vyberte jedného vlastníka DNS a zapíšte, ktorý to je.
Interné názvy s jednou menovkou tiež potrebujú zoznam na vyhľadávanie prípon. Set-DnsClientGlobalSetting -SuffixSearchList platí pre celý počítač, takže mení preklad pre každý adaptér v počítači vrátane Ethernetu. Otestujte ho na laboratórnom počítači, kým sa dostane do image.
Overte preklad, nielen nastavenie
Prekladač uvedený na adaptéri dokazuje len to, že hodnota bola zapísaná. Opýtajte sa zamýšľaného servera priamo a potom sa opýtajte obvyklou cestou:
Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example
Rozdelenie vám povie, kde je porucha. Priama otázka odpovie a obyčajná otázka zlyhá: nastavenie adaptéra alebo zoznam prípon nie je v platnosti. Zlyhajú obe: prekladač je cez tunel nedostupný, takže pred ďalším zásahom do DNS sa pozrite na trasy a pravidlá firewallu. Priama otázka zlyhá, kým obyčajná odpovie odinakiaľ: rozdelený DNS je nesprávne nakonfigurovaný a interný názov odpovedá verejný prekladač, čo je problém politiky skôr, než je problémom pripojenia.
Spustite test dvakrát, raz hneď po pripojení a raz po odpojení a opätovnom pripojení, a porovnajte výstup Get-DnsClientServerAddress z oboch behov. Ak sa poslaná hodnota vrátila pri druhom pripojení, prepísanie žilo a zomrelo s adaptérom a obstojí len pravidlo NRPT alebo cesta politiky z predchádzajúcej časti. Uložte oba prepisy a časové značky pripojenia; vyriešia otázku, či to vydrží, rýchlejšie ako ďalšie kolo úprav.