Importer un profil VPN dans PowerShell avec Add-VpnConnection

Add-VpnConnection ne crée que des profils Windows natifs. Associez le couple tunnel et authentification à la passerelle, fixez la portée délibérément, puis testez les routes et le DNS.

Il n'existe aucune applet Import-VpnProfile, et la plus proche, Add-VpnConnection, ne lit jamais un fichier .ovpn ou .conf. Elle assemble un profil Windows natif à partir des paramètres que vous fournissez, et c'est pourquoi le premier point de contrôle ici est le format de fichier et non la ligne de commande. Si la passerelle parle SSTP, IKEv2, L2TP/IPsec ou PPTP, Windows peut posséder le profil et le reste de la liste s'applique. Si l'on vous a remis un fichier OpenVPN ou WireGuard, arrêtez-vous à la première étape : ces clients possèdent leurs propres importateurs.

Étape 1 : vérifier le profil que Windows peut réellement posséder

Exécutez Get-Command -Module VpnClient sur la machine avant toute chose. Windows 10, Windows 11 et Server 2016 ou ultérieur fournissent le module ; s'il manque, aucun script copié ne fera accepter un profil natif à cet hôte. Les applets qui comptent sont Add-VpnConnection, Get-VpnConnection et Remove-VpnConnection, et la liste des paramètres de la référence Add-VpnConnection vaut une lecture complète.

Natif signifie que la pile VPN de Windows termine le tunnel. Cela couvre IKEv2, souvent avec un certificat machine ; SSTP, qui est du TLS avec une authentification utilisateur ou par certificat à l'intérieur ; et L2TP/IPsec avec une clé prépartagée. Un fichier .ovpn est un script OpenVPN, pas une connexion Windows : il transporte des directives telles que remote, cipher ou tls-auth dont la pile Windows n'a aucune idée. Un .conf WireGuard raconte la même histoire avec PrivateKey et AllowedIPs ; convertir l'un en l'autre n'est pas un choix de paramètre mais une autre implémentation de tunnel.

Il existe une troisième branche. Si un administrateur vous remet un document XML VPNv2 CSP ou un profil Intune, c'est la voie MDM, appliquée par la pile de provisionnement et non par Add-VpnConnection. Ne traduisez pas ces noms de nœuds en paramètres PowerShell ; demandez plutôt quel mécanisme applique le XML.

Étape 2 : associer le type de tunnel à la méthode d'authentification

-TunnelType et -AuthenticationMethod sont deux paramètres distincts, et la passerelle ne se soucie que de la combinaison. Un bon et l'autre mauvais, et vous obtenez un profil qui ne se connecte à rien, ou qui se bloque avec le tunnel déjà monté. Fixez les deux explicitement au lieu de faire confiance à une valeur par défaut choisie pour un autre service.

  • IKEv2 avec MachineCertificate : le client présente un certificat d'ordinateur ; définissez aussi -EncryptionLevel Required.
  • SSTP avec Eap : d'abord le tunnel TLS, puis PEAP/MSCHAPv2 ou un certificat à l'intérieur d'EAP. Cela exige le XML de l'étape 3.
  • SSTP, L2TP ou PPTP avec MSChapv2, Chap ou Pap : nom d'utilisateur et mot de passe simples, sans bloc EAP.
  • L2TP avec MSChapv2 et -Lt2pPsk : la PSK couvre la moitié IPsec, l'utilisateur couvre PPP ; les deux doivent correspondre au serveur.

Un splat garde les valeurs au même endroit :

$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 renvoie l'objet que Windows vient d'écrire, ce qui permet de l'inspecter sans second appel. Si le nom existe déjà, l'applet refuse de s'exécuter ; -Force l'écrase, ce qui est le mauvais réflexe sur un portable de production, car cela jette silencieusement ce que quelqu'un a configuré à la main.

Étape 3 : remettre correctement le matériel d'identification

Les mots de passe, les clés prépartagées et les blocs EAP sont l'endroit où ces scripts cassent d'ordinaire. -EapConfigXmlStream attend un XmlDocument, pas un chemin, donc lisez et convertissez le fichier d'abord. Passer une chaîne produit une erreur de conversion qui ressemble à un problème de schéma et pousse les gens à réécrire un XML qui n'a jamais été faux.

$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

Ce XML ne s'invente pas à partir d'un extrait de blog. Il nomme le type de méthode EAP et l'authentification interne, et la passerelle compare les deux à sa stratégie. Une méthode interne incompatible échoue une fois la poignée de main TLS terminée, ce qui ressemble exactement à un mauvais mot de passe sans en être un. Prenez le XML auprès de qui exploite la passerelle, ou exportez-le depuis un profil qui fonctionne déjà.

Pour IKEv2, la moitié certificat est une recherche dans le magasin. -MachineCertificateIssuerFilter prend un objet certificat, et Windows s'en sert pour trouver un certificat client utilisable dans LocalMachine\My. Le certificat a besoin d'une clé privée et d'une chaîne à laquelle le serveur fait confiance ; si l'un des deux manque, l'authentification échoue sans détail utile, alors vérifiez d'abord le magasin :

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

Gardez les secrets hors du fichier de script. Une PSK passée en ligne de commande ou cuite dans un .ps1 finit dans les historiques, les sessions enregistrées et les dépôts partagés, et -RememberCredential met les identifiants utilisateur en cache pour plus tard, transformant un test ponctuel en autorisation durable.

Étape 4 : décider de la portée avant la première exécution

La même applet écrit dans deux carnets d'adresses différents. Sans -AllUserConnection, le profil vous appartient et vit sous %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk. Avec, depuis une invite élevée, le profil va dans %ProgramData%\Microsoft\Network\Connections\Pbk\rasphone.pbk et est visible de tous les comptes, y compris l'écran de connexion.

La portée n'est pas cosmétique. Un profil pour tous les utilisateurs est ce qu'un compte de service, une tâche planifiée ou un scénario de pré-ouverture de session peuvent utiliser ; un profil par utilisateur est invisible pour les trois. Les objets se lisent aussi différemment : Get-VpnConnection liste les entrées de l'utilisateur courant, Get-VpnConnection -AllUserConnection celles de toute la machine. Choisissez-en un maintenant, et traitez tout changement ultérieur comme une suppression puis une recréation plutôt qu'une modification :

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

Étape 5 : tester ce qu'un tunnel doit réellement fournir

Une icône connectée prouve que le tunnel est monté et rien d'autre. Connectez-vous d'abord en ligne de commande pour que les échecs arrivent sous forme de texte et non de boîte de dialogue, puis relisez ce que Windows a enregistré :

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

Les deux échecs que les utilisateurs signalent alors que l'état affiche encore Connected sont le DNS et le routage. Résolvez un nom interne et vérifiez quel serveur a répondu ; un profil sans -DnsSuffix peut tunneliser parfaitement et échouer à chaque résolution intranet. Regardez ensuite la route par défaut : tunneling divisé coupé, la route 0.0.0.0/0 de plus faible métrique doit pointer vers l'interface VPN, et activé, seuls les préfixes attendus doivent le faire. Si les deux semblent corrects et que le trafic meurt quand même, le problème est au-delà du profil, dans la stratégie ou le filtre de la passerelle.

Quand la connexion échoue d'emblée, le code restreint l'étape à revoir :

  • 691 : la passerelle a rejeté les identifiants. Revenez à l'étape 3, pas au tunnel.
  • 809 : la poignée de main IKEv2 ne s'est jamais terminée. Vérifiez UDP 500 et 4500, et la confiance du certificat.
  • 789 : la clé prépartagée L2TP/IPsec manque ou est fausse.
  • 868 : le nom du serveur ne s'est pas résolu. Corrigez le DNS avant de modifier le profil.

Gardez la commande qui fonctionne à côté des réglages qu'elle encode, pour que la personne suivante puisse reconstruire au lieu de rétro-concevoir le profil depuis l'interface. Si vous devez reconstruire, supprimez l'entrée et recréez-la avec les mêmes paramètres ; rapiécer un profil à moitié configuré laisse derrière des routes obsolètes et un état d'authentification. Et si le fichier n'a jamais été natif, revenez au client qui le possède. Un .ovpn déguisé en profil IKEv2 n'est pas un import, c'est un ticket de support.

Articles similaires