Ustawianie DNS na adapterze VPN w Windows za pomocą programu PowerShell i weryfikacja

Połączenie VPN w Windows nie przechowuje serwerów DNS w profilu, który edytujesz w Ustawieniach. Gdy tunel się podnosi, klient negocjuje konfigurację IP z bramą, brama przesyła listę resolverów, a Windows stosuje ją do adaptera tunelu. Ten adapter to osobny interfejs od twojego Wi-Fi czy Ethernetu, a lista należy do interfejsu, nie do profilu. Gdy wiesz, który obiekt posiada wartość, nadpisanie jej w programie PowerShell to jedna komenda; sprawienie, by nadpisanie przetrwało ponowne połączenie, to część, która wymaga decyzji.

Który obiekt posiada adres

RAS tworzy adapter tunelu, gdy połączenie się powiedzie, i usuwa go, gdy połączenie padnie. Serwery DNS widoczne w ipconfig /all pojawiają się podczas tej wymiany konfiguracji, obok adresów IPv4 i IPv6 oraz tras. Ponieważ wartość jest przypisana do interfejsu, Set-DnsClientServerAddress zapisuje do czegoś, co istnieje tylko tak długo, jak długo istnieje połączenie.

Ten jeden fakt wyjaśnia większość zamieszania wokół DNS w sieciach VPN. Profil można obejrzeć po rozłączeniu, ale nie ma interfejsu, na który można by wskazać, więc skrypt logowania wywołujący polecenie cmdlet na aliasie VPN zawodzi, zanim ktokolwiek się połączy. Wyjaśnia to też zmianę, która wygląda na cofniętą: nic się nie cofnęło, interfejs został zniszczony i odtworzony z wartościami przesłanymi przez bramę.

Znajdź alias, zanim dotkniesz DNS

Nazwa profilu i alias interfejsu to zwykle ten sam ciąg znaków, ale nie ten sam obiekt. Get-VpnConnection wyświetla profile; Get-NetAdapter wyświetla interfejsy, które Windows faktycznie ma. Polecenia cmdlet DNS chcą drugiego, a te dwa rozjeżdżają się częściej, niż ludzie się spodziewają, szczególnie gdy klient dodaje do nazwy adaptera opis taki jak "(RAS)".

Jeśli profil nie istnieje, program PowerShell może utworzyć wpis natywny. Typ tunelu i uwierzytelnianie muszą odpowiadać temu, co oferuje brama, bo niezgodność ujawnia się przy połączeniu, a nie przy tworzeniu:

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

Połącz się raz, a potem odczytaj prawdziwy alias, zanim napiszesz jakiekolwiek polecenie DNS:

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

Zastosuj nadpisanie we właściwej kolejności

Kolejność jest ważniejsza niż składnia. Adapter musi być podniesiony, alias musi się rozwiązywać, a konto musi mieć pozwolenie na zmianę ustawień interfejsu. Połączenie dla użytkownika zwykle przyjmuje zmianę od zalogowanego użytkownika; połączenie dla wszystkich użytkowników utworzone z -AllUserConnection zazwyczaj wymaga powłoki z podniesionymi uprawnieniami.

Samo polecenie cmdlet to jedna linijka, opisana w dokumentacji Set-DnsClientServerAddress firmy Microsoft:

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

Dwa tryby awarii warto rozpoznawać na pierwszy rzut oka. Błędny alias daje błąd z polecenia cmdlet i to jest dobry wynik, bo cisza byłaby gorsza. Poprawne polecenie cmdlet bez widocznego efektu zwykle oznacza, że patrzysz na niewłaściwy adapter: pozostały adapter tunelu po innym kliencie, fizyczną kartę sieciową o podobnym opisie albo drugi adapter wirtualny utworzony przez narzędzie sieciowe działające w izolowanym środowisku.

Dlaczego ponowne połączenie może cofnąć zmianę

Nadpisanie należy do jednej instancji interfejsu. Gdy klient zrywa adapter i odbudowuje go przy następnym połączeniu, przesłane wartości są stosowane ponownie i twoja lista znika. Niektórzy klienci tworzą interfejs od nowa przy każdym połączeniu; inni używają go przez cały czas trwania sesji. Porównaj indeks interfejsu w Get-NetAdapter na dwóch połączeniach i będziesz wiedzieć, jakie zachowanie masz.

Istnieją trzy trwałe odpowiedzi, a ich nakładanie tworzy własne błędy. Sufiks DNS specyficzny dla połączenia plus reguła NRPT wysyła tylko wewnętrzną przestrzeń nazw do wewnętrznego resolvera i zostawia nazwy publiczne w spokoju. Ustawienie zasad grupy lub MDM zastosowane do połączenia VPN ustawia DNS w momencie połączenia bez żadnego skryptu. Zaplanowane zadanie, które reaguje na zdarzenie połączenia i ponownie uruchamia polecenie cmdlet, jest opcją toporną, ale działa i zostawia dziennik. Wybierz jednego właściciela DNS i zapisz, który to jest.

Wewnętrzne nazwy z jedną etykietą też potrzebują listy wyszukiwania sufiksów. Set-DnsClientGlobalSetting -SuffixSearchList działa na całej maszynie, więc zmienia rozwiązywanie dla każdego adaptera w komputerze, łącznie z Ethernetem. Przetestuj to na maszynie laboratoryjnej, zanim trafi do obrazu.

Weryfikuj rozwiązywanie, nie tylko ustawienie

Resolver wymieniony na adapterze dowodzi tylko, że wartość została zapisana. Zapytaj docelowy serwer bezpośrednio, a potem zapytaj zwykłą ścieżką:

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

Podział mówi, gdzie leży błąd. Zapytanie bezpośrednie odpowiada, a zwykłe zawodzi: ustawienie adaptera lub lista sufiksów nie działa. Oba zawodzą: resolver jest nieosiągalny przez tunel, więc zanim znowu dotkniesz DNS, sprawdź trasy i reguły zapory. Zapytanie bezpośrednie zawodzi, a zwykłe odpowiada skądinąd: podzielony DNS jest źle skonfigurowany i na wewnętrzną nazwę odpowiada publiczny resolver, co jest problemem polityki, zanim staje się problemem łączności.

Uruchom test dwa razy, raz zaraz po połączeniu, a raz po rozłączeniu i ponownym połączeniu, i porównaj dane wyjściowe Get-DnsClientServerAddress z obu uruchomień. Jeśli przesłana wartość wróciła przy drugim połączeniu, nadpisanie żyło i umarło razem z adapterem, a utrzyma się tylko reguła NRPT lub trasa zasad z poprzedniej sekcji. Zachowaj oba zapisy i znaczniki czasu połączenia; rozstrzygają pytanie, czy ustawienie się utrzymuje, szybciej niż kolejna runda poprawek.