Importera en VPN-profil i PowerShell med Add-VpnConnection

Det finns ingen Import-VpnProfile-cmdlet, och den som ligger närmast, Add-VpnConnection, läser aldrig en .ovpn-fil eller en .conf-fil. Den bygger ihop en inbyggd Windows-profil av de parametrar du skickar in, och därför är den första kontrollpunkten här filformatet och inte kommandoraden. Om gatewayen talar SSTP, IKEv2, L2TP/IPsec eller PPTP kan Windows äga profilen och resten av listan gäller. Om du har fått en OpenVPN- eller WireGuard-fil ska du stanna vid steg ett: de klienterna äger sina egna importerare.

Steg 1: Bekräfta vilken profil Windows faktiskt kan äga

Kör Get-Command -Module VpnClient på datorn innan du gör något annat. Windows 10, Windows 11 och Server 2016 eller senare levereras med modulen; saknas den får inget kopierat skript den här värden att acceptera en inbyggd profil. De cmdlets som spelar roll är Add-VpnConnection, Get-VpnConnection och Remove-VpnConnection, och parameterlistan i referensen för Add-VpnConnection är värd att läsa en gång i sin helhet.

Inbyggt betyder att Windows VPN-stack avslutar tunneln. Det omfattar IKEv2, ofta med ett maskincertifikat; SSTP, som är TLS med användar- eller certifikatautentisering inuti; och L2TP/IPsec med en fördelad nyckel. En .ovpn-fil är ett OpenVPN-skript, inte en Windows-anslutning: den bär direktiv som remote, cipher eller tls-auth som Windows-stacken inte har något begrepp om. En WireGuard-.conf är samma sak med PrivateKey och AllowedIPs; att konvertera den ena till den andra är inte ett parameterval utan en annan tunnelimplementering.

Det finns en tredje gren. Om en administratör ger dig ett VPNv2 CSP XML-dokument eller en Intune-profil är det MDM-vägen, som tillämpas av provisioneringsstacken i stället för av Add-VpnConnection. Översätt inte de nodnamnen till PowerShell-parametrar; fråga i stället vilken mekanism som tillämpar XML:en.

Steg 2: Para ihop tunneltypen med autentiseringsmetoden

-TunnelType och -AuthenticationMethod är separata parametrar, och gatewayen bryr sig bara om kombinationen. Får du den ena rätt och den andra fel får du en profil som inte ansluter till något, eller som hänger sig med tunneln redan uppe. Ange båda uttryckligen i stället för att lita på ett standardvärde som valdes för en annan tjänst.

• IKEv2 med MachineCertificate: klienten visar upp ett datorcertifikat; ange även -EncryptionLevel Required.
• SSTP med Eap: först TLS-tunnel, sedan PEAP/MSCHAPv2 eller ett certifikat inuti EAP. Detta kräver XML:en i steg 3.
• SSTP, L2TP eller PPTP med MSChapv2, Chap eller Pap: vanligt användarnamn och lösenord, ingen EAP-blob.
• L2TP med MSChapv2 och -Lt2pPsk: PSK:n täcker IPsec-halvan, användaren täcker PPP; båda måste matcha servern.

En splat håller värdena på ett ställe:

$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 returnerar objektet som Windows just skrev, så du kan granska det utan ett andra anrop. Om namnet redan finns vägrar cmdleten att köra; -Force skriver över det, vilket är fel reflex på en produktionslaptop eftersom det tyst kastar bort det någon konfigurerat för hand.

Steg 3: Lämna över autentiseringsmaterialet på rätt sätt

Lösenord, fördelade nycklar och EAP-blobbar är där de här skripten brukar gå sönder. -EapConfigXmlStream vill ha ett XmlDocument, inte en sökväg, så läs och typa om filen först. Att skicka en sträng ger ett konverteringsfel som låter som ett schemaproblem och får folk att skriva om XML som aldrig var fel.

$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

Den XML:en ska man inte hitta på utifrån ett bloggutdrag. Den namnger EAP-metodtypen och den inre autentiseringen, och gatewayen jämför båda mot sin policy. En inre metod som inte matchar misslyckas efter att TLS-handskakningen har slutförts, vilket ser precis ut som ett felaktigt lösenord och inte är det. Ta XML:en från den som driver gatewayen, eller exportera den från en profil som redan fungerar.

För IKEv2 är certifikathalvan en sökning i certifikatarkivet. -MachineCertificateIssuerFilter tar ett certifikatobjekt, och Windows använder det för att hitta ett användbart klientcertifikat i LocalMachine\My. Certifikatet behöver en privat nyckel och en kedja som servern litar på; saknas något av det misslyckas autentiseringen utan användbar information, så kontrollera arkivet först:

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

Håll hemligheter borta från skriptfilen. En PSK som skickas på kommandoraden eller bakas in i en .ps1 hamnar i transkript, sparade sessioner och delade repon, och -RememberCredential cachar användaruppgifter för senare, vilket förvandlar ett engångstest till en bestående behörighet.

Steg 4: Bestäm omfånget före första körningen

Samma cmdlet skriver till två olika telefonböcker. Utan -AllUserConnection tillhör profilen dig och ligger under %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk. Med den, från en förhöjd prompt, syns profilen för alla konton, inklusive inloggningsskärmen, och hamnar i %ProgramData%\Microsoft\Network\Connections\Pbk\rasphone.pbk.

Omfång är inte kosmetiskt. En all-användarprofil är det ett tjänstekonto, en schemalagd uppgift eller ett scenario före inloggning kan använda; en per-användarprofil är osynlig för alla tre. Objekten läses också olika: Get-VpnConnection listar den aktuella användarens poster, Get-VpnConnection -AllUserConnection listar de maskinvida. Välj en nu, och behandla en senare ändring som radera och återskapa i stället för redigera:

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

Steg 5: Testa vad en tunnel faktiskt måste leverera

En ansluten ikon bevisar att tunneln kom upp och inget annat. Anslut från kommandoraden först så att fel kommer som text och inte som en dialog, och läs sedan av vad Windows registrerade:

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

De två fel användare rapporterar medan statusen fortfarande säger Ansluten är DNS och routning. Slå upp ett internt namn och kontrollera vilken server som svarade; en profil utan -DnsSuffix kan tunnla perfekt och ändå misslyckas med varje intranätsuppslag. Sedan titta på standardrutten: med delad tunnling avstängd ska rutten 0.0.0.0/0 med lägst metric peka in i VPN-gränssnittet, och med den påslagen ska bara de prefix du förväntar dig göra det. Om båda ser rätt ut och trafiken ändå dör ligger problemet bortom profilen, i policy eller i gatewayfiltret.

När anslutningen misslyckas helt pekar koden ut vilket steg du ska gå tillbaka till:

• 691: gatewayen avvisade uppgifterna. Gå tillbaka till steg 3, inte till tunneln.
• 809: IKEv2-handskakningen slutfördes aldrig. Kontrollera UDP 500 och 4500 samt certifikatförtroendet.
• 789: den fördelade nyckeln för L2TP/IPsec saknas eller är fel.
• 868: servernamnet gick inte att slå upp. Åtgärda DNS innan du redigerar profilen.

Håll det fungerande kommandot bredvid inställningarna det kodar, så att nästa person kan bygga om i stället för att baklängeskonstruera profilen från gränssnittet. Om du måste bygga om ska du ta bort posten och återskapa den från samma parametrar; att lappa en halvkonfigurerad profil lämnar kvar inaktuella rutter och autentiseringstillstånd. Och om filen aldrig var inbyggd ska du gå tillbaka till klienten som äger den. En .ovpn uppklädd som IKEv2-profil är ingen import, det är en supportbiljett.