DNS instellen op een Windows-VPN-adapter met PowerShell en daarna verifiëren

Een Windows-VPN-verbinding slaat geen DNS-servers op in het profiel dat je in Instellingen bewerkt. Wanneer de tunnel tot stand komt, onderhandelt de client de IP-configuratie met de gateway, stuurt de gateway een lijst met resolvers en past Windows die toe op de tunneladapter. Die adapter is een aparte interface naast je Wi-Fi of Ethernet, en de lijst hoort bij de interface, niet bij het profiel. Zodra je weet welk object de waarde bezit, is het overschrijven ervan in PowerShell één opdracht; het ervoor zorgen dat de overschrijving een herverbinding overleeft, is het deel dat een beslissing vraagt.

Welk object bezit het adres

RAS maakt de tunneladapter aan wanneer de verbinding slaagt en verwijdert hem wanneer de verbinding wegvalt. De DNS-servers die je in ipconfig /all ziet, komen binnen tijdens die configuratie-uitwisseling, naast de IPv4- en IPv6-adressen en de routes. Omdat de waarde aan de interface hangt, schrijft Set-DnsClientServerAddress naar iets dat alleen bestaat zolang de verbinding bestaat.

Dat ene feit verklaart het grootste deel van de verwarring rond VPN-DNS. Een profiel kun je bekijken terwijl je niet verbonden bent, maar er is geen interface om naar te wijzen, dus een aanmeldscript dat de cmdlet op de VPN-alias aanroept, mislukt voordat iemand verbonden is. Het verklaart ook een wijziging die terug te draaien lijkt: niets werd teruggedraaid, de interface werd vernietigd en opnieuw opgebouwd met de waarden die de gateway stuurde.

Vind de alias voordat je DNS aanraakt

Profielnaam en interfacealias zijn meestal dezelfde tekenreeks, maar het zijn niet hetzelfde object. Get-VpnConnection somt profielen op; Get-NetAdapter somt de interfaces op die Windows werkelijk heeft. De DNS-cmdlets willen de tweede, en die twee lopen vaker uiteen dan mensen verwachten, vooral wanneer de client een beschrijving zoals "(RAS)" aan de adapternaam toevoegt.

Als het profiel niet bestaat, kan PowerShell een native vermelding maken. Het tunneltype en de authenticatie moeten overeenkomen met wat de gateway biedt, want een verschil komt bij het verbinden naar voren en niet bij het aanmaken:

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

Verbind één keer en lees daarna de echte alias voordat je een DNS-opdracht schrijft:

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

Pas de overschrijving in de juiste volgorde toe

Volgorde is belangrijker dan syntaxis. De adapter moet actief zijn, de alias moet worden omgezet en het account moet toestemming hebben om interface-instellingen te wijzigen. Een verbinding per gebruiker accepteert de wijziging meestal van de aangemelde gebruiker; een verbinding voor alle gebruikers die met -AllUserConnection is gemaakt, vereist doorgaans een verhoogde shell.

De cmdlet zelf is één regel, gedocumenteerd in Microsofts Set-DnsClientServerAddress-referentie:

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

Twee faalwijzen zijn de moeite waard om in één oogopslag te herkennen. Een verkeerde alias levert een fout van de cmdlet op, en dat is de goede uitkomst, want stilte zou erger zijn. Een correcte cmdlet zonder zichtbaar effect betekent meestal dat je naar de verkeerde adapter kijkt: een achtergebleven tunneladapter van een andere client, een fysieke NIC met een vergelijkbare beschrijving, of een tweede virtuele adapter die door een sandbox-netwerktool is gemaakt.

Waarom een herverbinding de wijziging ongedaan kan maken

De overschrijving hoort bij één exemplaar van de interface. Wanneer de client de adapter afbreekt en hem bij de volgende verbinding opnieuw opbouwt, worden de verzonden waarden opnieuw toegepast en is je lijst weg. Sommige clients maken de interface bij elke verbinding opnieuw aan; andere hergebruiken hem voor de hele sessie. Vergelijk de interface-index in Get-NetAdapter tussen twee verbindingen en je weet welk gedrag je hebt.

Er bestaan drie duurzame antwoorden, en het stapelen ervan veroorzaakt eigen fouten. Een verbindingsspecifiek DNS-suffix plus een NRPT-regel stuurt alleen de interne naamruimte naar de interne resolver en laat openbare namen met rust. Een groepsbeleids- of MDM-instelling op de VPN-verbinding zet DNS bij het verbinden zonder enig script. Een geplande taak die op de verbindingsgebeurtenis reageert en de cmdlet opnieuw uitvoert, is de botte optie, maar hij werkt en laat een logboek achter. Kies één eigenaar voor DNS en schrijf op welke dat is.

Interne namen met één label hebben ook een suffixzoeklijst nodig. Set-DnsClientGlobalSetting -SuffixSearchList geldt voor de hele machine, dus het verandert de resolutie voor elke adapter op de computer, inclusief Ethernet. Test het op een labmachine voordat het in een image belandt.

Verifieer de resolutie, niet alleen de instelling

Een resolver die op een adapter staat, bewijst alleen dat er een waarde is geschreven. Vraag de bedoelde server rechtstreeks en vraag daarna via het normale pad:

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

De splitsing vertelt je waar de fout zit. De directe query antwoordt en de gewone query mislukt: de adapterinstelling of de suffixlijst is niet actief. Beide mislukken: de resolver is niet bereikbaar via de tunnel, dus kijk naar routes en firewallregels voordat je DNS weer aanraakt. De directe query mislukt terwijl de gewone query elders vandaan antwoordt: split-DNS is verkeerd geconfigureerd en een interne naam wordt beantwoord door een openbare resolver, wat een beleidsprobleem is voordat het een verbindingsprobleem is.

Voer de test twee keer uit, één keer direct na het verbinden en één keer na een onderbreking en herverbinding, en vergelijk de uitvoer van Get-DnsClientServerAddress uit beide runs. Als de verzonden waarde bij de tweede verbinding terug is, heeft de overschrijving met de adapter geleefd en is hij ermee gestorven, en alleen de NRPT- of beleidsroute uit de vorige sectie houdt stand. Bewaar beide transcripten en de tijdstempels van de verbinding; die beslechten de vraag of het blijft sneller dan nog een ronde aanpassingen.