Le VPN Windows ne se connecte pas ? Associez le code au journal des événements

Vendredi, cela fonctionnait. Lundi, le même client Windows répond par une boîte de dialogue indiquant que la tentative de connexion a échoué, et la phrase en dessous est une que vous avez déjà vue pour une douzaine de problèmes sans rapport. Cette boîte de dialogue est la fin d'une chaîne, pas son début. Windows cache l'étape où la tentative est réellement morte, et deux petits éléments de preuve la nomment : le code de résultat numérique et un événement RasClient de cette même minute. Voici l'ordre que j'utilise — fixez la tentative, lisez le code, extrayez l'événement, puis changez exactement une couche.

Le texte de la boîte de dialogue est la dernière étape, pas la cause

La phrase que vous lisez est choisie une fois la tentative déjà déroulée. « La connexion a été interrompue par l'ordinateur distant avant que la connexion ne soit établie » apparaît quand un serveur raccroche en pleine négociation, quand IPsec a échoué avant même que votre nom d'utilisateur soit envoyé, et quand une stratégie a refusé le tunnel d'emblée. Trois responsables différents, une phrase. Traitez la formulation comme une classe de symptômes et ne la laissez rien orienter tant que le code ne l'approuve pas.

Ce que vous pouvez encore fixer, c'est la tentative elle-même. Notez le nom de la connexion, le type de tunnel stocké dans le profil — PPTP, L2TP/IPsec, SSTP ou IKEv2 —, l'heure à la seconde près et le code. Si vous n'êtes pas sûr du protocole qui a réellement tourné, ouvrez %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk et lisez l'entrée plutôt que de vous fier à votre mémoire ; un profil réutilisé pour un nouveau protocole conserve son ancien nom d'affichage.

Lisez le nombre avant de lire les mots

Les codes se répartissent en trois étapes, et l'étape compte plus que la formulation exacte : un échange d'authentification atteint puis refusé, un serveur qui n'a jamais répondu, ou une négociation qui s'est effondrée après la montée du lien. 691 est du premier type — la vérification des informations d'identification s'est exécutée et a échoué, que ce soit à cause d'un mauvais mot de passe, d'un compte verrouillé ou expiré, ou d'un protocole d'authentification que le serveur n'accepte pas. 812 est aussi un refus, mais avec des informations d'identification valides : une stratégie sur le serveur d'accès distant a décidé contre vous. Microsoft tient la liste des codes d'erreur de connexion commutée et VPN canonique, et cela vaut la peine d'y lire votre numéro avant de chercher le texte du message.

809 est la classe opposée : rien n'est revenu. C'est un problème de chemin — TCP 443 filtré pour SSTP, GRE bloqué pour PPTP, UDP 500 et 4500 ou ESP abandonnés pour le passthrough IPsec. Un nouveau mot de passe ne peut pas y remédier, et un certificat neuf non plus. 720 signifie que le lien est monté et que PPP n'a jamais terminé la négociation, ce qui pointe vers une incompatibilité de protocole ou un serveur qui n'a pas pu attribuer d'adresse. 789, ou 13801 en IKEv2, c'est l'identité à l'intérieur d'IPsec : un certificat dont le sujet ne correspond pas au nom que vous composez, une chaîne non approuvée, ou une clé prépartagée qui diffère entre les deux extrémités.

Extrayez l'événement RasClient de cette même minute

Dans l'Observateur d'événements, Windows Logs > Application filtré sur la source RasClient est le premier endroit où regarder. L'article de Microsoft sur l'erreur 720 renvoie à l'événement 20227 de ce journal. Le même fournisseur émet d'autres identifiants pour d'autres résultats, alors lisez le message et le code de résultat intégré au lieu de traiter l'ID comme le diagnostic ; une boîte de dialogue générique plus un 20227 portant 720 est déjà une histoire bien plus étroite.

Depuis PowerShell, sans cliquer dans l'interface graphique :

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

Un résultat vide est instructif. Il signifie généralement que la numérotation n'est jamais allée assez loin pour que RAS consigne quoi que ce soit, ou que le logiciel qui a échoué n'est pas du tout le client natif — les clients tiers gardent leurs propres diagnostics et n'écrivent souvent rien dans le journal Application. Vérifiez le journal de l'éditeur avant de conclure que la journalisation des événements est cassée.

Construisez une seule chronologie au lieu d'un tas d'événements

Les boucles de nouvelle tentative fabriquent du bruit. Cinq reconnexions automatiques laissent un amas d'événements, et la tentation est de les lire comme une seule séquence à cause unique. Ce sont cinq tentatives distinctes, et seules certaines ont atteint un serveur. Prenez une fenêtre de deux ou trois minutes, un nom de connexion, et listez chaque événement avec son propre code avant d'interpréter quoi que ce soit.

Demandez ensuite où la tentative s'est arrêtée. Quand la passerelle ou le backend d'authentification ne garde aucune trace pour cet horodatage, le client ne l'a jamais atteint, et vous regardez un problème d'accessibilité. Quand le backend montre une requête et un refus, la décision a été prise là, et la classe informations d'identification ou stratégie s'applique. Comparez les horloges avant de comparer les heures : les clients rapportent l'heure locale, beaucoup de passerelles journalisent en UTC, et un décalage fera qu'une paire parfaitement corrélée semblera sans rapport.

Pour une capture reproductible, composez depuis la ligne de commande et laissez-la imprimer le résultat :

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

La console affiche le numéro que l'interface graphique cache derrière un texte amical, et l'exécuter deux fois vous dit si le code est stable ou intermittent.

Ce que chaque étape vous dit de changer

Nommer l'étape n'est utile que si cela réduit l'ensemble des changements à une seule couche :

• 691 — authentification : la méthode EAP que propose le client face à celle que le serveur accepte, l'état du compte, l'expiration du mot de passe, l'autorisation d'accès commuté.
• 812 — stratégie du serveur : la stratégie d'accès distant ou la règle NPS qui correspond à cet utilisateur et à cette fenêtre horaire.
• 809 — accessibilité : les règles de pare-feu sur le chemin, le NAT et le passthrough de protocole, le port dont le type de tunnel choisi a besoin.
• 720 — négociation PPP : incompatibilité de protocole d'authentification, attribution d'adresse, un réglage PPP côté serveur.
• 789 / 13801 — identité IPsec : sujet du certificat face au nom que vous composez, chaîne d'approbation, clé prépartagée.

Changez l'un de ces éléments, retestez le même profil et notez le nouveau code. Un code différent après un changement est un progrès plutôt qu'une contradiction : vous avez déplacé la panne vers une étape ultérieure, et c'est à cela que ressemble la réparation d'une poignée de main multi-étapes. Ce qu'il ne faut pas faire, c'est modifier le pare-feu, le certificat et le mot de passe en une seule séance puis créditer celui qui est arrivé en dernier.

Partagez les preuves, pas l'environnement

Les messages d'événement sont plus riches qu'ils n'en ont l'air. Ils portent le nom de la connexion, le compte, souvent le nom ou l'adresse interne de la passerelle, et parfois une empreinte de certificat. Gardez l'original là où il doit être, et construisez une copie expurgée séparée pour quiconque d'autre ; retaper la chronologie de mémoire perd exactement les détails qui la rendent utile.

Une passation qui sera traitée a besoin de cinq champs : le code, l'étape à laquelle il appartient, le client et le type de tunnel, l'horodatage avec son fuseau horaire, et si la passerelle a vu la requête. Tout le reste est facultatif. Avec ces cinq, la personne suivante peut distinguer un débat sur les informations d'identification d'un débat sur le routage sans répéter l'investigation.

Avant de clore quoi que ce soit, rejouez la tentative sur le même profil et confirmez où le code atterrit maintenant. Un succès y met fin ; un échec différent signifie que l'étape d'origine est corrigée et que vous tenez la suivante.