Een VPN-profiel importeren in PowerShell met Add-VpnConnection

Er bestaat geen cmdlet Import-VpnProfile, en de naam die er het dichtst bij komt, Add-VpnConnection, leest nooit een .ovpn- of .conf-bestand. Die stelt een native Windows-profiel samen uit parameters die je zelf meegeeft, en daarom is het eerste controlepunt hier het bestandsformaat en niet de opdrachtregel. Als de gateway SSTP, IKEv2, L2TP/IPsec of PPTP spreekt, kan Windows het profiel beheren en geldt de rest van de lijst. Kreeg je een OpenVPN- of WireGuard-bestand, stop dan bij stap één: die clients hebben hun eigen importeurs.

Stap 1: bevestig welk profiel Windows echt kan beheren

Voer Get-Command -Module VpnClient uit op de machine voordat je iets anders doet. Windows 10, Windows 11 en Server 2016 of nieuwer leveren de module mee; ontbreekt hij, dan zorgt geen enkel overgenomen script ervoor dat deze host een native profiel accepteert. De cmdlets die ertoe doen zijn Add-VpnConnection, Get-VpnConnection en Remove-VpnConnection, en de parameterlijst in de Add-VpnConnection-referentie is het waard om één keer helemaal door te nemen.

Native betekent dat de Windows-VPN-stack de tunnel beëindigt. Dat omvat IKEv2, vaak met een machinecertificaat; SSTP, wat TLS is met gebruikers- of certificaatauthenticatie erbinnen; en L2TP/IPsec met een pre-shared key. Een .ovpn-bestand is een OpenVPN-script, geen Windows-verbinding: het bevat richtlijnen zoals remote, cipher of tls-auth waar de Windows-stack geen enkel begrip van heeft. Een WireGuard .conf is hetzelfde verhaal met PrivateKey en AllowedIPs; het ene in het andere omzetten is geen parameterkeuze maar een andere tunnelimplementatie.

Er is nog een derde tak. Krijg je van een beheerder een VPNv2 CSP XML-document of een Intune-profiel, dan is dat het MDM-pad, toegepast door de provisioning-stack en niet door Add-VpnConnection. Vertaal die knooppuntnamen niet naar PowerShell-parameters; vraag liever welk mechanisme de XML toepast.

Stap 2: koppel het tunneltype aan de authenticatiemethode

-TunnelType en -AuthenticationMethod zijn afzonderlijke parameters, en de gateway kijkt alleen naar de combinatie. Heb je de ene goed en de andere fout, dan krijg je een profiel dat nergens mee verbindt, of dat blijft hangen terwijl de tunnel al staat. Zet beide expliciet in plaats van een standaardwaarde te vertrouwen die voor een andere dienst is gekozen.

• IKEv2 met MachineCertificate: de client toont een computercertificaat; zet ook -EncryptionLevel Required.
• SSTP met Eap: eerst de TLS-tunnel, daarna PEAP/MSCHAPv2 of een certificaat binnen EAP. Dit vereist de XML uit stap 3.
• SSTP, L2TP of PPTP met MSChapv2, Chap of Pap: gewone gebruikersnaam en wachtwoord, geen EAP-blob.
• L2TP met MSChapv2 en -Lt2pPsk: de PSK dekt de IPsec-helft, de gebruiker dekt PPP; beide moeten overeenkomen met de server.

Een splat houdt de waarden op één plek:

$p = @{
  Name                 = "Corp IKEv2"
  ServerAddress        = "vpn.example.com"
  TunnelType           = "Ikev2"
  AuthenticationMethod = "MachineCertificate"
  EncryptionLevel      = "Required"
  SplitTunneling       = $false
  DnsSuffix            = "corp.example.com"
}
Add-VpnConnection @p -PassThru

-PassThru geeft het object terug dat Windows zojuist heeft geschreven, zodat je het zonder tweede aanroep kunt bekijken. Bestaat de naam al, dan weigert de cmdlet te draaien; -Force overschrijft hem, wat op een productielaptop de verkeerde reflex is, omdat het stilzwijgend weggooit wat iemand met de hand heeft ingesteld.

Stap 3: geef het referentiemateriaal correct door

Wachtwoorden, pre-shared keys en EAP-blobs zijn de plek waar deze scripts meestal stuklopen. -EapConfigXmlStream wil een XmlDocument, geen pad, dus lees het bestand eerst en cast het. Een tekenreeks doorgeven levert een conversiefout op die klinkt als een schemaprobleem en mensen XML laat herschrijven die nooit fout was.

$eap = [xml](Get-Content -Raw .\peap-mschapv2.xml)
Add-VpnConnection -Name "Corp SSTP" -ServerAddress "sstp.example.com" `
  -TunnelType Sstp -AuthenticationMethod Eap `
  -EapConfigXmlStream $eap -EncryptionLevel Required

Die XML verzin je niet uit een blogfragmentje. Hij noemt het EAP-methodetype en de interne authenticatie, en de gateway vergelijkt beide met zijn beleid. Een niet-passende interne methode faalt nadat de TLS-handshake is afgerond, wat er precies uitziet als een verkeerd wachtwoord en het niet is. Haal de XML bij wie de gateway beheert, of exporteer hem uit een profiel dat al werkt.

Voor IKEv2 is de certificaathlelft een opzoeking in de opslag. -MachineCertificateIssuerFilter neemt een certificaatobject, en Windows gebruikt het om een bruikbaar clientcertificaat in LocalMachine\My te vinden. Het certificaat heeft een privésleutel en een keten nodig die de server vertrouwt; ontbreekt een van beide, dan mislukt de authenticatie zonder bruikbare details, dus controleer eerst de opslag:

Get-ChildItem Cert:\LocalMachine\My |
  Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) } |
  Select-Object Subject, Issuer, Thumbprint, NotAfter

Houd geheimen buiten het scriptbestand. Een PSK die op de opdrachtregel meegaat of in een .ps1 wordt gebakken, belandt in transcripten, opgeslagen sessies en gedeelde repositories, en -RememberCredential cachet gebruikersreferenties voor later, waarmee een eenmalige test een blijvende machtiging wordt.

Stap 4: bepaal de scope vóór de eerste run

Dezelfde cmdlet schrijft naar twee verschillende telefoonboeken. Zonder -AllUserConnection is het profiel van jou en staat het onder %APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk. Met de schakelaar, vanuit een verhoogde prompt, gaat het profiel naar %ProgramData\Microsoft\Network\Connections\Pbk\rasphone.pbk en is het zichtbaar voor elk account, inclusief het aanmeldscherm.

Scope is niet cosmetisch. Een profiel voor alle gebruikers is wat een serviceaccount, een geplande taak of een scenario vóór aanmelding kan gebruiken; een profiel per gebruiker is voor alle drie onzichtbaar. De objecten worden ook anders uitgelezen: Get-VpnConnection somt de vermeldingen van de huidige gebruiker op, Get-VpnConnection -AllUserConnection de machinebrede. Kies er nu één, en behandel een latere wijziging als verwijderen en opnieuw aanmaken in plaats van bewerken:

# elevated prompt
Remove-VpnConnection -Name "Corp IKEv2" -Force
Add-VpnConnection -Name "Corp IKEv2" -ServerAddress "vpn.example.com" `
  -TunnelType Ikev2 -AuthenticationMethod MachineCertificate `
  -EncryptionLevel Required -AllUserConnection

Stap 5: test wat een tunnel echt moet leveren

Een verbonden pictogram bewijst alleen dat de tunnel overeind staat en niets meer. Verbind eerst vanaf de opdrachtregel, zodat fouten als tekst binnenkomen en niet als dialoogvenster, en lees daarna terug wat Windows heeft vastgelegd:

rasdial "Corp IKEv2"
Get-VpnConnection -Name "Corp IKEv2" |
  Select-Object Name, ServerAddress, TunnelType, ConnectionStatus, SplitTunneling
Get-NetRoute -DestinationPrefix "0.0.0.0/0"

De twee storingen die gebruikers melden terwijl de status nog steeds Verbonden zegt, zijn DNS en routering. Los een interne naam op en kijk welke server antwoord gaf; een profiel zonder -DnsSuffix kan perfect tunnelen en toch elke intranet-opzoeking laten mislukken. Kijk dan naar de standaardroute: met split tunneling uit moet de route 0.0.0.0/0 met de laagste metriek naar de VPN-interface wijzen, en met split tunneling aan alleen de prefixen die je verwacht. Zien beide er goed uit en valt het verkeer alsnog weg, dan ligt het probleem voorbij het profiel, in beleid of in het gatewayfilter.

Als de verbinding helemaal niet tot stand komt, vernauwt de code de stap die je opnieuw moet bekijken:

• 691: de gateway wees de referenties af. Ga terug naar stap 3, niet naar de tunnel.
• 809: de IKEv2-handshake is nooit afgerond. Controleer UDP 500 en 4500, en het vertrouwen in het certificaat.
• 789: de L2TP/IPsec pre-shared key ontbreekt of is verkeerd.
• 868: de servernaam is niet opgelost. Repareer DNS voordat je het profiel aanpast.

Bewaar de werkende opdracht naast de instellingen die hij vastlegt, zodat de volgende persoon opnieuw kan opbouwen in plaats van het profiel uit de gebruikersinterface te reverse-engineeren. Moet je toch opnieuw opbouwen, verwijder dan de vermelding en maak hem opnieuw aan met dezelfde parameters; een half geconfigureerd profiel patchen laat verouderde routes en authenticatiestatus achter. En was het bestand nooit native, ga dan terug naar de client die er eigenaar van is. Een .ovpn die als IKEv2-profiel is opgetuigd is geen import, het is een supportticket.