Erreur 789 L2TP/IPsec sous Windows : créez le profil et figez la proposition

L’erreur 789 sur une connexion L2TP de Windows signifie que le tunnel est mort à l’intérieur de l’échange de sécurité IPsec, ce qui se produit bien avant que Windows n’envoie un mot de passe utilisateur où que ce soit. Réessayer le mot de passe, ou le réinitialiser dans l’annuaire, ne peut pas faire avancer cette étape. Ce qui la fait avancer, c’est de reconstruire la connexion depuis PowerShell avec la proposition que la passerelle offre réellement, car l’assistant des Paramètres choisit les transformations IPsec en silence et ne vous montre jamais ce qu’il a choisi. Voici le mode opératoire pour cela : créez le profil, figez la proposition, puis utilisez une table des étapes pour que le code suivant vous dise quelque chose.

Créez le profil sans l’assistant

Add-VpnConnection écrit une entrée native du carnet d’adresses, donc le résultat est le même objet que l’application Paramètres modifiera plus tard. Exécutez-le depuis une session élevée quand la connexion doit exister pour chaque compte de la machine, ou depuis le contexte utilisateur quand elle doit rester privée :

Add-VpnConnection -Name "Contoso L2TP" `
  -ServerAddress 203.0.113.10 `
  -TunnelType L2tp `
  -EncryptionLevel Required `
  -AuthenticationMethod MSChapv2 `
  -RememberCredential -Force

Faites correspondre -AuthenticationMethod à ce que la passerelle propose. MSChapv2, EAP et PAP ne sont pas interchangeables, et un profil qui exige une méthode que le serveur n’acceptera pas échoue avant même que le moindre enregistrement utilisateur soit consulté. Gardez -EncryptionLevel Required pour tout ce qui est réel ; Optional laisse Windows accepter un tunnel non chiffré si le pair en propose un, ce qui est un raccourci de laboratoire et non un réglage à livrer.

Si vous passez -L2tpPsk, cette clé pré-partagée est écrite dans le profil sur le disque, d’où quiconque peut lire le profil sur cette machine peut la récupérer. Utilisez un certificat pour authentifier le pair quand la passerelle le prend en charge, et quand une PSK est inévitable, gardez-la hors du dépôt et hors de l’historique du shell au lieu de la coller dans chaque exécution d’approvisionnement.

Figez la proposition au lieu d’accepter les valeurs par défaut

Windows remplit lui-même les transformations IPsec, et c’est pourquoi deux machines ayant une connexion apparemment identique peuvent échouer différemment contre la même passerelle. Set-VpnConnectionIPsecConfiguration est la manière prise en charge de les figer :

Set-VpnConnectionIPsecConfiguration -ConnectionName "Contoso L2TP" `
  -AuthenticationTransformConstants SHA256128 `
  -CipherTransformConstants AES128 `
  -EncryptionMethod AES128 `
  -IntegrityCheckMethod SHA256 `
  -DHGroup Group14 `
  -PfsGroup None `
  -PassThru -Force

Cet ensemble est un arrangement L2TP/IPsec courant, pas une réponse universelle. Chaque paramètre accepte une liste fixe de valeurs, et une combinaison que la plateforme ne peut pas mapper revient comme une erreur de cmdlet au lieu d’un profil discrètement affaibli. Traitez une telle erreur comme une affirmation sur les valeurs, pas sur vos autorisations.

Copiez la proposition depuis la documentation de la passerelle ou depuis ses réglages actifs de phase 1 et de phase 2, et ne changez qu’un champ à la fois, uniquement pendant que la passerelle journalise les transformations qu’elle refuse. Parcourir cinq champs produit une connexion qui fonctionne par accident et un enregistrement qui n’explique rien à la personne suivante.

Lisez un échec par étape, pas par le texte de l’erreur

789 appartient à une famille de codes qui se ressemblent tous dans la boîte de dialogue du client. Placez le code face à l’étape à laquelle il appartient avant de retoucher le profil :

Les deux rôles des informations d’identification comptent ici. Une clé pré-partagée ou un certificat authentifie les pairs l’un envers l’autre, tandis que MSChapv2 ou EAP vous authentifie à l’intérieur du tunnel. Réinitialiser un mot de passe utilisateur ne peut pas corriger le premier, un nouveau secret partagé ne peut pas corriger le second, et changer les deux d’un coup détruit la preuve de celui qui était faux.

Sur le chemin du certificat, vérifiez l’horloge du client, la chaîne de confiance et l’identité attendue par la passerelle avant d’envisager d’assouplir la validation. Désactiver la validation transforme un 789 visible en un tunnel qui se connecte en faisant confiance au mauvais pair, et rien dans le client ne vous dira que cela s’est produit. liste des erreurs d’accès à distance de Microsoft est la référence pour les codes eux-mêmes, et elle sépare les échecs de la couche de sécurité des échecs de connexion.

Vérifiez des deux côtés avant de le déclarer corrigé

Relisez le profil, mais ne vous attendez pas à voir la proposition dans la sortie. Get-VpnConnection rapporte le nom, l’adresse du serveur, le type de tunnel, le niveau de chiffrement et la méthode d’authentification, et il ne sait rien des transformations, donc la relecture confirme que l’entrée existe et pointe vers le bon hôte :

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

Composez depuis la ligne de commande pour obtenir un numéro au lieu d’une boîte de dialogue : rasdial "Contoso L2TP" renvoie le même code d’échec que l’interface renverrait, et rasdial "Contoso L2TP" /disconnect l’efface entre les tentatives. Lisez ensuite le côté passerelle pour cette même tentative. Un ipsec statusall de strongSwan ou un journal IKE du routeur indique quelle proposition est arrivée et laquelle a été refusée, et comparer cela aux valeurs du cmdlet est la seule étape qui prouve vraiment que les deux extrémités se sont mises d’accord.

Une connexion réussie n’est pas la ligne d’arrivée. Ouvrez l’application qui compte pour l’utilisateur, car les routes, le DNS poussé et les réglages de tunnel fractionné échouent une fois le tunnel monté et ne produisent aucune boîte de dialogue d’erreur.

Automatisez-le, et revenez en arrière proprement

L’installation sans surveillance est la raison de scripter cela, et l’étape de composition est là où les informations d’identification fuient. rasdial les prend sur sa ligne de commande, où d’autres utilisateurs locaux et la plupart des collecteurs de journaux peuvent les lire :

subprocess.run(["rasdial", "Contoso L2TP"], check=True)

Préférez une information d’identification limitée au compte qui exécute la tâche, ou laissez le profil la stocker avec -RememberCredential, plutôt que de passer un mot de passe en argument dans une tâche planifiée. Les commandes d’approvisionnement elles-mêmes peuvent être répétées sans risque avec -Force, mais elles superposeront volontiers une ancienne proposition, donc une réexécution n’aide que si le script porte les valeurs actuelles.

Les profils persistent entre les redémarrages et survivent à la configuration de passerelle pour laquelle ils ont été créés. Quand la proposition de la passerelle change, supprimez l’entrée et recréez-la au lieu d’empiler un second jeu de valeurs : Remove-VpnConnection -Name "Contoso L2TP" -Force, puis répétez les deux cmdlets avec le nouveau jeu.

Bouclez avec quatre contrôles qui vivent à côté du script : Get-VpnConnection montre le type de tunnel et le niveau de chiffrement attendus ; la passerelle journalise une phase 1 et une phase 2 terminées pour l’adresse de votre client ; rasdial renvoie un succès et l’application s’ouvre ; et la proposition consignée dans le script correspond au réglage actuel de la passerelle. Quand le prochain 789 arrive, cette comparaison prend des minutes au lieu d’un après-midi.