Add-VpnConnection : pourquoi la PSK casse et pourquoi l'adresse reste

Un profil VPN Windows est une entrée de carnet d'adresses, et PowerShell est un moyen de modifier cette entrée. Deux échecs découlent de cette distinction : une clé pré-partagée qui arrive au serveur déjà corrompue, et une adresse de serveur qui semble à jour mais n'est pas celle que le prochain tunnel composera. Les deux se voient plus facilement si vous traitez le profil comme un état stocké plutôt que comme une commande que vous avez lancée. Le parcours suit l'ordre des modifications : créer, changer, portée, relire.

Construire le profil avec une clé littérale

Add-VpnConnection accepte la clé pré-partagée L2TP via -L2tpPsk. PowerShell traite la chaîne avant que l'applet de commande ne la reçoive, et entre guillemets doubles un signe dollar lance une référence de variable tandis qu'un backtick lance une séquence d'échappement. Une clé qui contient l'un ou l'autre arrive plus courte, ou avec un caractère différent, et le profil est créé avec succès avec le mauvais secret.

L'échec apparaît ensuite à l'authentification IPsec, où le tunnel refuse de monter. C'est pourquoi une erreur de guillemets est si souvent signalée comme un problème côté serveur : le profil existe, le nom est correct et le secret est discrètement faux.

Les guillemets simples sont la solution, et ils doivent entourer toute la valeur. Si l'entrée existe déjà avec une mauvaise clé, -Force la remplace, ou supprimez et recréez le profil puis testez avec une nouvelle connexion :

Add-VpnConnection -Name "Contoso-L2TP" -ServerAddress vpn.contoso.example -TunnelType L2tp -L2tpPsk 'n3w$ecret!2026' -AuthenticationMethod Pap -RememberCredential -Force

Gardez le vrai secret hors de l'historique du shell et des scripts partagés. Lisez-le à l'exécution depuis le magasin approuvé et passez la variable plutôt que le littéral, ce qui évite entièrement le problème de guillemets.

Changer l'adresse, puis se reconnecter

Set-VpnConnection prend des paramètres séparés par des espaces, pas une syntaxe d'affectation. Écrire -ServerAddress = "203.0.113.10" passe un jeton supplémentaire, et l'applet de commande soit échoue, soit enregistre autre chose que ce que vous vouliez. La forme correcte est -Name "Office L2TP" -ServerAddress 203.0.113.10.

Même avec la bonne syntaxe, la modification n'atteint pas un tunnel déjà monté. Une connexion établie conserve l'adresse qu'elle a composée jusqu'à sa déconnexion, donc tester la même session ne prouve rien sur la nouvelle valeur. Déconnectez, modifiez, reconnectez-vous et confirmez l'adresse du pair dans les détails de la connexion.

Certaines propriétés ne se modifient pas sur place. Quand l'applet de commande refuse, notez les paramètres existants, supprimez le profil et recréez-le avec les valeurs corrigées, et conservez les réglages d'origine du tunnel et de l'authentification. Un script qui ne doit changer que le numéro de téléphone peut modifier l'entrée du carnet via l'API RAS au lieu de tout recréer. Quelle que soit la voie choisie, confirmez ensuite les valeurs stockées au lieu de vous fier au silence de la commande.

Savoir quel carnet vous avez modifié

Un profil par utilisateur vit dans le répertoire des connexions réseau de cet utilisateur, et un profil pour tous les utilisateurs vit dans le répertoire machine, sous l'arborescence des données de programme. Ce sont des entrées distinctes avec des portées distinctes, et modifier l'une laisse l'autre intacte.

C'est pourquoi une modification peut sembler disparaître : le script s'est exécuté sous un compte et le test sous un autre. Utilisez -AllUserConnection quand le profil appartient à la machine, et vérifiez la même portée quand vous le relisez.

Relire le profil avant de tester

Demandez à Windows ce qu'il a stocké plutôt que ce que vous avez passé :

Get-VpnConnection -Name "Office L2TP" | Select-Object Name, ServerAddress, TunnelType, AuthenticationMethod

Comparez cette sortie à l'intention, puis lancez une nouvelle connexion. Si la composition échoue, consultez le journal du client RAS dans l'Observateur d'événements avant de modifier à nouveau le profil, car le journal nomme l'étape qui a échoué.

Gardez le schéma d'authentification intact pendant la modification. Une commande qui change l'adresse mais abandonne le certificat ou la configuration EAP produit un échec qui semble sans rapport avec la modification, et exporter le profil qui fonctionne au préalable vous donne de quoi restaurer au lieu d'une supposition.