Quelle étape du VPN a échoué : IPsec, le contrôle L2TP ou l’authentification PPP

Vous avez changé le mot de passe et rien n’a bougé, car la panne n’a jamais été dans PPP. L2TP/IPsec signale une seule erreur de connexion pour cinq remises très différentes, et chaque remise a sa propre réparation. Travaillez à rebours : trouvez la dernière étape qui a réussi et ne changez que ce qui vient après. L’ordre ci-dessous décide aussi quelles preuves vous collectez en premier.

Répondez à quatre questions dans l’ordre

Forcez une nouvelle tentative, car certains clients continuent d’afficher l’erreur précédente jusqu’à ce que le profil soit déconnecté puis reconnecté. Répondez ensuite à ceci : y avait-il une association de sécurité IPsec, une connexion de contrôle L2TP et un appel sont-ils apparus, PPP a-t-il atteint un verdict d’authentification, et IPCP a-t-il donné une adresse au client ? Le premier non est l’étape que vous corrigez. Tout ce qui suit n’est pas testé, donc un nom d’utilisateur refusé ne prouve rien quand aucune association n’a jamais existé.

Synchronisez les horloges des deux côtés avant de comparer. Une nouvelle tentative qui a nettoyé IPsec et échoué à PPP ressemble à une seule panne quand le client n’affiche que le message final et que le journal du serveur conserve encore l’essai précédent. Lisez par horodatage, pas par la ligne la plus bruyante.

Quand vous n’avez que la capture d’écran de l’utilisateur, appuyez-vous sur la séparation la moins chère : une clé prépartagée erronée et un xl2tpd qui ne répond jamais produisent le même texte dans la boîte de dialogue Windows, mais l’un exige un secret changé aux deux extrémités et l’autre un démon démarré ou une règle de pare-feu sur le serveur lui-même. Un équipement intermédiaire ne peut pas supprimer le 1701 interne une fois qu’IPsec en mode transport l’a enveloppé, donc ne cherchez pas un filtre de chemin qui n’existe pas.

Ce que chaque couche possède réellement

IPsec protège les paquets entre les deux pairs ; L2TP transporte une session PPP à l’intérieur de ce chemin protégé, ce qui explique pourquoi RFC 3193 spécifie le mode transport plutôt qu’un tunnel propre. L’étiquette du client dit L2TP, donc le tunnel et la connexion semblent un seul mécanisme. Ils ne le sont pas : la connexion de contrôle L2TP authentifie les extrémités du tunnel là où un déploiement l’active, et PPP authentifie séparément l’utilisateur avec CHAP, PAP ou MS-CHAPv2 selon la politique du serveur.

Cette séparation explique les deux secrets que les gens confondent. Une clé prépartagée authentifie les pairs IPsec. Un nom d’utilisateur et un mot de passe identifient l’utilisateur auprès de PPP. Retaper le secret partagé de Windows sur un profil qui s’authentifie par certificats ne change rien à l’étape qui échoue, et modifier le mot de passe PPP ne peut pas fournir un canal protégé manquant. La même retenue s’applique au contrôle d’identité : ne désactivez pas l’identité du pair ni la validation du certificat pour obtenir un tunnel, car ce qui se connecte alors est le chemin, pas le pair.

L’authentification n’est pas non plus la fin de PPP. Une fois l’utilisateur accepté, IPCP négocie l’adresse du client et les options DNS et WINS que le serveur accepte de remettre. Un client peut réussir CHAP ou MS-CHAPv2 et se retrouver sans adresse, ce qui est une panne à l’intérieur de PPP et non un problème de routage. L2TP simple sans IPsec reste valide et non protégé, donc une connexion réussie ne prouve jamais que le trafic est protégé ; vérifiez ce que le serveur impose, pas l’étiquette du client.

Décidez à partir de la première étape manquante

Lisez le tableau par le premier élément manquant, de gauche à droite. La colonne de droite est le seul travail qui vaille à ce moment-là ; tout ce qui est à sa gauche est déjà prouvé, et le retester consomme la fenêtre d’interruption sans ajouter d’information.

Trois lignes méritent un avertissement. La ligne 1701 est là où atterrissent généralement les clients Windows derrière NAT : l’association se termine, puis rien n’arrive, et l’encapsulation est la cause, pas un mauvais mot de passe. La ligne IPCP est celle qui est mal lue comme un problème de route, parce que Windows enveloppe l’adresse manquante dans l’erreur 720 et l’icône de la barre d’état ne dit que la connexion a échoué ; cette panne se situe après l’authentification et avant le routage. La dernière ligne n’est pas du tout une panne IPsec, même si l’icône dit déconnecté.

Des commandes qui séparent les couches

Sur un serveur Linux avec strongSwan, swanctl --list-sas liste les associations établies avec leur identité de pair, et ipsec statusall couvre les hôtes strongSwan et libreswan plus anciens. En dessous, ip xfrm state montre les associations réelles du noyau, tandis que ss -lunp | grep 1701 prouve où xl2tpd est lié. Lancez xl2tpd -D au premier plan pour voir apparaître les connexions de contrôle et les appels, et activez le débogage pppd dans /etc/ppp/options.xl2tpd pour voir la méthode proposée et la réponse.

Quand les journaux montrent une authentification réussie, la question suivante est de savoir si IPCP s’est terminé. Vérifiez que ip range dans la section [lns default] de /etc/xl2tpd/xl2tpd.conf a encore des adresses libres, et que /etc/ppp/options.xl2tpd porte réellement ms-dns et ms-wins si le client les attend. Un pool épuisé et une option DNS manquante se voient différemment sur le fil : le premier laisse le client sans adresse et avec un 720, le second donne une adresse mais aucun résolveur, donc les noms échouent tandis que les ping vers des adresses brutes fonctionnent. Ni l’un ni l’autre ne se répare en ressaisissant le mot de passe.

Sur le client, le greffon L2TP de NetworkManager écrit la conversation pppd dans le journal, donc journalctl -u NetworkManager -b sépare généralement tunnel monté, authentification refusée de aucun tunnel du tout. Sous Windows, Get-VpnConnection rapporte les vrais réglages d’authentification du profil, et les événements RasClient sous Application dans l’Observateur d’événements nomment le composant en échec. Quand la boîte de dialogue est trop vague, activez netsh ras set tracing * enable.

Les captures demandent une précaution. Avec IPsec en mode transport, l’UDP 1701 interne est chiffré, donc une capture sur l’interface externe montre ESP, ou UDP 4500 sous NAT-T, et aucun L2TP. L’absence de 1701 dans une capture est attendue et ne prouve pas un port bloqué ; regardez si les compteurs ESP ou 4500 bougent.

NAT, MTU et routes : où la pile vous trompe

NAT casse les hypothèses avant que quoi que ce soit soit authentifié. ESP est son propre protocole IP, donc un équipement qui traduit le rejette sauf si les pairs encapsulent ; c’est ce qu’apporte l’UDP 4500. Sur un serveur Windows lui-même derrière un routeur domestique ou une passerelle NAT cloud, l’étape IPsec échoue avec l’erreur 789 jusqu’à ce que AssumeUDPEncapsulationContextOnSendRule soit mis à 2 sous la clé PolicyAgent et que la machine redémarre, et la panne reste indiscernable d’un port fermé. Les clients derrière NAT sont plus simples : avec une adresse publique sur le serveur, NAT-T sur UDP 4500 les transporte et cette valeur n’entre pas en jeu.

Une fois PPP monté, un MTU en trou noir imite un tunnel mort : les petits paquets passent, une poignée de main TLS ou un chargement de page se bloque, et le client peut encore afficher connecté. Abaissez le MTU de l’interface ou fixez le MSS sur la passerelle avant d’accuser le serveur. Le routage en tunnel divisé est l’autre imposteur ; un sous-réseau poussé avec le mauvais masque laisse le tunnel sain et une application inaccessible. Un nom d’hôte privé ajoute son propre saut : si la requête sort par le résolveur local, le nom échoue à se résoudre avant qu’une route soit testée.

Liste de vérification avant de toucher aux identifiants

Parcourez la liste dans l’ordre et arrêtez-vous au premier élément en échec. Chaque étape est bon marché, et chacune exclut toute une classe de modifications.

1. Confirmez que l’association existe aux deux extrémités, appariée par l’identité du pair plutôt que par une étiquette connecté.
2. Confirmez que l’UDP 1701 atteint xl2tpd ; une association sans appel est votre panne.
3. Lisez le verdict de PPP et, s’il a authentifié, le résultat d’IPCP, avant de supposer que le mot de passe est faux.
4. Seulement maintenant, ressaisissez les identifiants dans le format attendu par le serveur, car un préfixe de domaine change le compte.
5. Si cela échoue encore, capturez les deux extrémités avec des horodatages alignés et comparez étape par étape.

S’arrêter à la deuxième étape signifie un problème de chemin ou d’encapsulation, et aucune modification du mot de passe ne le fera bouger. S’arrêter à la troisième étape signifie que le journal nomme déjà la méthode ou le pool d’adresses à corriger. Dans les deux cas, le prochain changement est un que vous pouvez justifier, et vous cessez de faire le tour de réglages qui n’ont jamais été en cause.