Codes d’erreur VPN sous Windows : quelle étape a échoué et quoi journaliser

Ouvrez la boîte de dialogue VPN de Windows après un échec : elle vous donne un numéro et une phrase, et la phrase est généralement la moitié la moins utile. Le numéro désigne l’étape de la connexion qui a échoué, et l’étape détermine quel journal, quel réglage et quelle équipe regarder ensuite. Parcourir les étapes dans l’ordre prend une dizaine de minutes et évite la séquence bien connue : réinstaller les adaptateurs, changer de protocole et réinitialiser la pile pour réparer un compte auquel on n’a jamais permis de composer.

Lire le numéro comme une étape

Une connexion native traverse quatre jalons. Elle atteint le serveur et établit une liaison, elle négocie la sécurité, elle authentifie l’utilisateur, et elle applique l’adressage et le routage. Un échec à chacun laisse des preuves différentes, et un code qui appartient à une étape ne dit rien d’utile sur les autres.

L’erreur à éviter est de traiter le code comme une gravité. Un échec de liaison et un échec d’autorisation se lisent tous deux comme "impossible de se connecter", et ils n’ont rien d’autre en commun. La gravité dit à quel point c’est urgent ; l’étape dit quoi ouvrir.

Étape un : la liaison et la tentative de composition

829 signifie que la liaison sous-jacente est tombée. Le code ne dit pas si le pair distant a cessé de répondre, si un intermédiaire a tué la session ou si une stratégie côté client l’a fermée. Un code d’achèvement de composition comme 703 est encore plus précoce : la tentative n’a jamais atteint le stade d’une liaison, ce qui pointe souvent vers le profil, l’état du service ou une stratégie locale.

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

La requête d’événements est la partie que les gens sautent. Un enregistrement côté client avec un horodatage et un nom d’interface vaut plus que la boîte de dialogue, car il dit si la tentative a seulement quitté la machine. Aucun enregistrement et aucune réponse de l’écouteur signifient un problème d’accessibilité, et aucune modification du client n’y change rien.

Si le même profil fonctionne sur un autre réseau, arrêtez-vous ici. Le code décrit une condition de chemin et non une erreur de configuration, et la prochaine comparaison utile est celle des deux captures plutôt qu’une nouvelle réinstallation.

Étape deux : PPP et la liaison du miniport

720 se situe entre la liaison et l’utilisateur. Le tunnel s’est levé, puis la couche PPP n’a pas pu négocier une adresse ou un protocole de contrôle, ce qui est souvent un problème de liaison côté client et non un identifiant rejeté. Cette distinction est toute la valeur du code : il dit que l’identifiant n’a jamais été atteint, donc le compte n’est pas le suspect.

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

Lire ces deux sorties est plus instructif que réinitialiser quoi que ce soit. Un miniport présent mais non démarré, ou une liaison de protocole désactivée par un autre logiciel, produit exactement l’échec de cette étape. Les deux se réparent sans toucher au reste de la pile. Une réinitialisation complète, en revanche, supprime l’adressage et l’état de filtrage qui n’avaient rien à voir avec la panne.

Étape trois : identité et autorisation

691 signifie que les identifiants ont été rejetés. 649 signifie que le compte n’est pas autorisé à composer, et 812 signifie qu’une stratégie d’accès distant a refusé la connexion. Ce sont des décisions, pas des pannes de transport, et le client ne peut que les signaler.

Les preuves sont de l’autre côté. Demandez à l’opérateur de la passerelle la tentative à cet horodatage et la stratégie qui a correspondu ; demandez au propriétaire de l’annuaire si le compte a l’autorisation de composer et s’il figure dans le groupe exigé par la stratégie. Changer le type de tunnel ou réinstaller le client ne peut pas modifier une décision prise à propos d’une identité.

Une habitude utile à cette étape est d’écrire dans le ticket la chaîne de compte exacte, préfixe de domaine compris. Un nombre surprenant de cas 691 sont des identifiants enregistrés pour le mauvais domaine, et cela se voit dans la chaîne de compte et non dans les réglages du protocole.

Étape quatre : connecté, et rien ne fonctionne

Une connexion peut aboutir et rester inutile. Elle détient une adresse, le client signale un succès, et chaque requête de l’application expire. Rien dans la boîte de dialogue ne le reflète, et il n’y a aucun code à consulter. À ce stade, la boîte de dialogue est terminée et les preuves utiles sont ailleurs.

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Si la route manque, le serveur ne l’a pas poussée ou le client l’a abandonnée. Si la route existe et que le nom échoue, la résolution est le problème. Si les deux fonctionnent et que l’application échoue encore, vous avez dépassé le tunnel et vous êtes dans la configuration de l’application elle-même.

Limitez les changements à une couche par test. Chaque modification faite avant la tentative suivante devient une partie du contexte du code suivant, et un code qui décrit votre dernière modification est pire que pas de code du tout.

Une tentative, un changement, un enregistrement

Quelle que soit l’étape, l’enregistrement doit contenir le code, le message, le nom du profil, l’horodatage et le réseau sur lequel vous étiez. Cinq champs, et chacun d’eux est déjà devant vous dans la boîte de dialogue ou le journal du client. Cet ensemble est assez petit pour être collé dans un ticket et assez précis pour qu’une autre personne le reproduise.

Placez ensuite cet horodatage à côté de l’enregistrement de l’autre côté. Le tableau en haut de cette page indique quelle étape possède chaque divergence. Sans le second enregistrement, le code ne fait que réduire la recherche ; avec lui, l’étape est tranchée. La comparaison est ce qui transforme un numéro en diagnostic plutôt qu’en supposition.

Cette habitude couvre presque toute panne VPN native sous Windows, et aucune des branches n’exige de réinstaller quoi que ce soit. La boîte de dialogue vous disait toujours laquelle vous aviez ; le travail consiste à refuser de les traiter toutes comme le même problème.