DNS beállítása Windows VPN-adapteren PowerShell-lel, majd ellenőrzés
A Windows a belső DNS-t az adapterhez rendeli, nem a VPN-profilhoz. Csatlakozás után állítsd be PowerShellben, majd teszteld, hogy egy újracsatlakozás megtartja-e.
A Windows VPN-kapcsolat nem tárolja a DNS-kiszolgálókat abban a profilban, amelyet a Beállításokban szerkesztesz. Amikor az alagút felépül, a kliens egyezteti az IP-konfigurációt az átjáróval, az átjáró elküldi a feloldók listáját, a Windows pedig alkalmazza azt az alagút adapterére. Ez az adapter külön illesztőfelület a Wi-Fi vagy Ethernet illesztőfelületedhez képest, és a lista az illesztőfelülethez tartozik, nem a profilhoz. Ha egyszer tudod, melyik objektum birtokolja az értéket, a felülírás PowerShellben egyetlen parancs; a felülírás újracsatlakozáson át való megőrzése az a rész, amely döntést igényel.
Melyik objektum birtokolja a címet
A RAS akkor hozza létre az alagút adapterét, amikor a kapcsolat létrejön, és akkor távolítja el, amikor a kapcsolat megszakad. A ipconfig /all kimenetében látott DNS-kiszolgálók e konfigurációcsere során érkeznek meg, az IPv4- és IPv6-címek, valamint az útvonalak mellett. Mivel az érték az illesztőfelülethez kapcsolódik, a Set-DnsClientServerAddress olyanba ír, ami csak addig létezik, amíg a kapcsolat fennáll.
Ez az egyetlen tény magyarázza a VPN DNS-e körüli zavar nagy részét. A profil kapcsolat nélkül is megvizsgálható, de nincs illesztőfelület, amelyre mutathatnánk, ezért a bejelentkezési szkript, amely a cmdletet a VPN-aliasra hívja, még azelőtt meghiúsul, hogy bárki csatlakozna. Ugyanez magyarázza azt a változást is, amely visszaállni látszik: semmi nem állt vissza, az illesztőfelület megsemmisült és újraépült az átjáró által küldött értékekkel.
Találd meg az aliast, mielőtt a DNS-hez nyúlsz
A profilnév és az illesztőfelület-alias általában ugyanaz a karakterlánc, de nem ugyanaz az objektum. A Get-VpnConnection a profilokat listázza; a Get-NetAdapter azokat az illesztőfelületeket, amelyekkel a Windows valóban rendelkezik. A DNS-cmdletek az utóbbit akarják, és a kettő gyakrabban tér el egymástól, mint az emberek gondolnák, különösen amikor a kliens olyan leírást fűz az adapter nevéhez, mint a "(RAS)".
Ha a profil nem létezik, a PowerShell natív bejegyzést hozhat létre. Az alagút típusának és a hitelesítésnek egyeznie kell azzal, amit az átjáró kínál, mert az eltérés a csatlakozáskor jelentkezik, nem a létrehozáskor:
Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
-TunnelType Ikev2 -EncryptionLevel Required `
-AuthenticationMethod Eap -AllUserConnection
Csatlakozz egyszer, majd olvasd ki a valódi aliast, mielőtt bármilyen DNS-parancsot írnál:
rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"
A felülírást a megfelelő sorrendben alkalmazd
A sorrend fontosabb a szintaxisnál. Az adapternek fel kell lennie, az aliasnak fel kell oldódnia, és a fióknak engedélyezve kell lennie az illesztőfelület beállításainak módosítása. A felhasználónkénti kapcsolat általában elfogadja a módosítást a bejelentkezett felhasználótól; a -AllUserConnection kapcsolóval létrehozott, minden felhasználóra érvényes kapcsolat általában emelt szintű parancsértelmezőt igényel.
Maga a cmdlet egyetlen sor, amelyet a Microsoft Set-DnsClientServerAddress-referenciája dokumentál:
Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4
Két hibaesetet érdemes első pillantásra felismerni. A rossz alias hibát vált ki a cmdletből, és ez a jó kimenet, mert a csend rosszabb lenne. A helyes cmdlet látható hatás nélkül általában azt jelenti, hogy rossz adaptert nézel: egy másik kliens által hátrahagyott alagút-adaptert, egy hasonló leírású fizikai hálózati kártyát, vagy egy izolált hálózati eszköz által létrehozott második virtuális adaptert.
Miért törölheti az újracsatlakozás a módosítást
A felülírás egyetlen illesztőfelület-példányhoz tartozik. Amikor a kliens lebontja az adaptert, és a következő csatlakozáskor újraépíti, a küldött értékek ismét alkalmazódnak, és a listád eltűnik. Egyes kliensek minden csatlakozáskor újra létrehozzák az illesztőfelületet; mások a munkamenet teljes élettartama alatt újrahasználják. Hasonlítsd össze az illesztőfelület indexét a Get-NetAdapter kimenetében két kapcsolat között, és megtudod, melyik viselkedés jellemző nálad.
Három tartós megoldás létezik, és ezek egymásra halmozása saját hibákat szül. Egy kapcsolatspecifikus DNS-utótag és egy NRPT-szabály csak a belső névteret küldi a belső feloldónak, a nyilvános neveket pedig békén hagyja. A VPN-kapcsolatra alkalmazott csoportházirend- vagy MDM-beállítás csatlakozáskor állítja be a DNS-t, szkript nélkül. Az ütemezett feladat, amely a kapcsolat eseményére reagál és újra futtatja a cmdletet, a nyers megoldás, de működik, és naplót hagy maga után. Válassz egyetlen felelőst a DNS-hez, és írd le, melyik az.
Az egyszerű címkés belső nevekhez utótag-keresőlista is kell. A Set-DnsClientGlobalSetting -SuffixSearchList gépszintű, ezért minden adapter feloldását megváltoztatja a gépen, az Ethernetét is. Teszteld laboratóriumi gépen, mielőtt bekerül egy rendszerképbe.
A feloldást ellenőrizd, ne csak a beállítást
Az adapteren felsorolt feloldó csak azt bizonyítja, hogy egy érték bekerült. Kérdezd meg közvetlenül a szándékolt kiszolgálót, majd a normál útvonalon is:
Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example
A különbség megmondja, hol a hiba. A közvetlen lekérdezés válaszol, a sima lekérdezés meghiúsul: az adapter beállítása vagy az utótaglista nem érvényesül. Mindkettő meghiúsul: a feloldó nem érhető el az alagúton keresztül, ezért nézd meg az útvonalakat és a tűzfal-szabályokat, mielőtt újra a DNS-hez nyúlnál. A közvetlen lekérdezés meghiúsul, miközben a sima lekérdezés máshonnan válaszol: a megosztott DNS hibásan van beállítva, és egy belső névre nyilvános feloldó válaszol, ami szabályozási probléma, mielőtt kapcsolódási probléma lenne.
Futtasd a tesztet kétszer, egyszer közvetlenül csatlakozás után, egyszer pedig leválasztás és újracsatlakozás után, és hasonlítsd össze a Get-DnsClientServerAddress kimenetét a két futásból. Ha a küldött érték visszatér a második kapcsolatnál, a felülírás az adapterrel együtt élt és halt meg, és csak az előző szakasz NRPT- vagy házirend-útvonala fog tartósan működni. Őrizd meg mindkét átiratot és a csatlakozási időbélyegeket; ezek gyorsabban eldöntik a megmaradás kérdését, mint a szerkesztések újabb köre.