DNS auf einem Windows-VPN-Adapter mit PowerShell setzen und prüfen

Windows bindet Tunnel-DNS an den Adapter, nicht an das VPN-Profil. Setzen Sie es nach dem Verbinden in PowerShell und testen Sie dann, ob ein erneutes Verbinden es behält.

Eine Windows-VPN-Verbindung speichert DNS-Server nicht in dem Profil, das Sie in den Einstellungen bearbeiten. Wenn der Tunnel hochkommt, handelt der Client die IP-Konfiguration mit dem Gateway aus, das Gateway schiebt eine Resolver-Liste, und Windows wendet sie auf den Tunneladapter an. Dieser Adapter ist eine eigene Schnittstelle, getrennt von Ihrem Wi-Fi oder Ethernet, und die Liste gehört zur Schnittstelle, nicht zum Profil. Sobald Sie wissen, welches Objekt den Wert besitzt, ist das Überschreiben in PowerShell ein Befehl; das Überschreiben ein erneutes Verbinden überleben zu lassen, ist der Teil, der eine Entscheidung braucht.

Welches Objekt besitzt die Adresse

RAS erstellt den Tunneladapter, wenn die Verbindung gelingt, und entfernt ihn, wenn die Verbindung abbricht. Die DNS-Server, die Sie in ipconfig /all sehen, kommen während dieses Konfigurationsaustauschs, neben den IPv4- und IPv6-Adressen und den Routen. Weil der Wert an die Schnittstelle gebunden ist, Set-DnsClientServerAddress schreibt in etwas, das nur existiert, solange die Verbindung existiert.

Diese eine Tatsache erklärt den größten Teil der Verwirrung um VPN-DNS. Ein Profil lässt sich im getrennten Zustand prüfen, aber es gibt keine Schnittstelle, auf die man zeigen könnte, also scheitert ein Anmeldeskript, das das Cmdlet gegen den VPN-Alias aufruft, bevor überhaupt jemand verbunden ist. Sie erklärt auch eine Änderung, die zurückzuspringen scheint: nichts sprang zurück, die Schnittstelle wurde zerstört und mit den vom Gateway übermittelten Werten neu aufgebaut.

Finden Sie den Alias, bevor Sie DNS anfassen

Profilname und Schnittstellen-Alias sind meist dieselbe Zeichenkette, aber sie sind nicht dasselbe Objekt. Get-VpnConnection listet Profile auf; Get-NetAdapter listet die Schnittstellen auf, die Windows tatsächlich hat. Die DNS-Cmdlets wollen die zweite, und die beiden weichen häufiger voneinander ab, als man erwartet, besonders wenn der Client dem Adapternamen einen Zusatz wie "(RAS)" anhängt.

Wenn das Profil nicht existiert, kann PowerShell einen nativen Eintrag anlegen. Tunneltyp und Authentifizierung müssen zu dem passen, was das Gateway anbietet, denn eine Abweichung zeigt sich bei der Verbindung, nicht bei der Erstellung:

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

Verbinden Sie sich einmal und lesen Sie dann den echten Alias, bevor Sie irgendeinen DNS-Befehl schreiben:

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

Wenden Sie das Überschreiben in der richtigen Reihenfolge an

Die Reihenfolge ist wichtiger als die Syntax. Der Adapter muss oben sein, der Alias muss sich auflösen lassen, und das Konto muss Schnittstelleneinstellungen ändern dürfen. Eine Verbindung pro Benutzer akzeptiert die Änderung meist vom angemeldeten Benutzer; eine Verbindung für alle Benutzer, die mit -AllUserConnection erstellt wurde, braucht in der Regel eine erhöhte Shell.

Das Cmdlet selbst ist eine Zeile, dokumentiert in Microsofts Referenz zu Set-DnsClientServerAddress:

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

Zwei Fehlerbilder sollte man auf Anhieb erkennen. Ein falscher Alias erzeugt einen Fehler des Cmdlets, und das ist das gute Ergebnis, denn Stille wäre schlimmer. Ein korrektes Cmdlet ohne sichtbare Wirkung bedeutet meist, dass Sie den falschen Adapter ansehen: einen übrig gebliebenen Tunneladapter eines anderen Clients, eine physische NIC mit ähnlicher Beschreibung oder einen zweiten virtuellen Adapter, den ein Sandbox-Netzwerkwerkzeug angelegt hat.

Warum ein erneutes Verbinden die Änderung rückgängig machen kann

Das Überschreiben gehört zu einer Schnittstelleninstanz. Wenn der Client den Adapter abbaut und ihn bei der nächsten Verbindung neu aufbaut, werden die übermittelten Werte erneut angewandt, und Ihre Liste ist weg. Manche Clients erzeugen die Schnittstelle bei jeder Verbindung neu; andere verwenden sie für die Dauer der Sitzung wieder. Vergleichen Sie den Schnittstellenindex in Get-NetAdapter über zwei Verbindungen hinweg, und Sie wissen, welches Verhalten Sie haben.

Es gibt drei dauerhafte Antworten, und sie zu stapeln erzeugt eigene Fehler. Ein verbindungsspezifisches DNS-Suffix plus eine NRPT-Regel schickt nur den internen Namensraum an den internen Resolver und lässt öffentliche Namen in Ruhe. Eine Group-Policy- oder MDM-Einstellung, die auf die VPN-Verbindung angewandt wird, setzt DNS beim Verbinden ohne jedes Skript. Eine geplante Aufgabe, die auf das Verbindungsereignis reagiert und das Cmdlet erneut ausführt, ist die grobe Option, aber sie funktioniert und hinterlässt ein Protokoll. Wählen Sie einen Eigentümer für DNS und schreiben Sie auf, welcher es ist.

Interne Namen mit einer einzigen Bezeichnung brauchen außerdem eine Suffixsuchliste. Set-DnsClientGlobalSetting -SuffixSearchList gilt maschinenweit, ändert also die Auflösung für jeden Adapter auf der Maschine, auch Ethernet. Testen Sie es auf einer Labormaschine, bevor es in ein Image geht.

Prüfen Sie die Auflösung, nicht nur die Einstellung

Ein Resolver, der auf einem Adapter steht, beweist nur, dass ein Wert geschrieben wurde. Fragen Sie den vorgesehenen Server direkt und dann über den normalen Pfad:

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

Die Aufteilung sagt Ihnen, wo der Fehler sitzt. Direkte Abfrage antwortet und die einfache Abfrage scheitert: Die Adaptereinstellung oder die Suffixliste ist nicht wirksam. Beide scheitern: Der Resolver ist durch den Tunnel nicht erreichbar, also prüfen Sie Routen und Firewallregeln, bevor Sie DNS wieder anfassen. Direkte Abfrage scheitert, während die einfache Abfrage von woanders antwortet: Split DNS ist falsch konfiguriert und ein interner Name wird von einem öffentlichen Resolver beantwortet, was ein Richtlinienproblem ist, bevor es ein Konnektivitätsproblem ist.

Führen Sie den Test zweimal aus, einmal direkt nach dem Verbinden und einmal nach einem Trennen und erneuten Verbinden, und vergleichen Sie die Get-DnsClientServerAddress Ausgabe beider Läufe. Wenn der übermittelte Wert bei der zweiten Verbindung wieder da ist, hat das Überschreiben mit dem Adapter gelebt und ist mit ihm gestorben, und nur die NRPT- oder Richtlinienroute aus dem vorigen Abschnitt hält. Bewahren Sie beide Protokolle und die Verbindungszeitstempel auf; sie klären die Frage, ob es hält, schneller als eine weitere Runde Bearbeitungen.

Ähnliche Artikel