L2TP se connecte, mais la négociation PPP échoue : à quelle phase ?

Le tunnel IPsec s’établit, le client affiche un pair protégé, puis la connexion meurt avant que quoi que ce soit n’atteigne le sous-réseau privé. Cet écart est PPP qui fait son propre travail : les options de liaison, l’authentification de l’utilisateur et l’attribution d’adresse ont toutes lieu après que le tunnel chiffré existe. Rien dans un échange réussi de première phase ne fournit un mot de passe ni une adresse interne. Lisez les phases dans l’ordre et la panne se nomme souvent d’elle-même.

Le tunnel n’est que la première couche

L2TP transporte des trames PPP dans un tunnel protégé par IPsec, ce qui signifie que deux négociations indépendantes doivent réussir avant qu’un paquet puisse être routé. L’extérieure prouve que les deux extrémités s’accordent sur les clés et les identités. L’intérieure décide des paramètres de liaison, de l’authentification de l’utilisateur et de l’adresse que reçoit le client.

Une panne à l’intérieur de PPP ressemble à un tunnel cassé dans chaque client qui n’affiche qu’un seul voyant d’état. La traiter comme un problème de tunnel mène à renouveler les clés, redémarrer des services et finalement remplacer un secret partagé qui n’a jamais été faux. La distinction utile est bon marché : si l’échange avec le pair s’est terminé et que le client est passé à une invite de nom d’utilisateur ou à une étape d’authentification, le tunnel va bien. Tout ce qui suit ce point appartient à PPP.

Lisez la dernière phase qui a réussi

Parcourez le journal vers l’avant et arrêtez-vous à la première phase qui n’a pas abouti. LCP vient d’abord, puis l’authentification, puis IPCP pour les paramètres IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Un délai d’attente LCP signifie que les deux extrémités ne se sont jamais accordées sur les options de liaison de base, ce qui est un profil incompatible ou un protocole interne bloqué, pas un mauvais mot de passe. Un rejet d’authentification explicite est le cas inverse : la liaison est montée et un côté a refusé les identifiants. Un délai d’attente IPCP après une authentification réussie indique des pools d’adresses ou une politique de serveur. Chacun a un propriétaire différent et une réparation différente, et c’est pourquoi la phase compte plus que le texte final de l’erreur.

Gardez l’extrait de journal avec le nom de la phase dans le ticket. Une queue collée sans la frontière de phase invite le lecteur suivant à deviner, et deviner ici coûte une heure.

Entente entre le client et le serveur

Les deux extrémités doivent accepter la même méthode d’authentification, et un profil enregistré peut en demander une que le serveur a retirée le trimestre dernier. Les déploiements gérés cachent aussi le côté serveur, où le motif du rejet est généralement enregistré pour l’utilisateur plutôt que pour l’appareil.

Activez une méthode prise en charge plutôt que chaque option héritée, car un client qui en propose cinq masque laquelle a échoué. Demandez à l’administrateur la politique côté serveur et le rejet exact, ce qui n’oblige personne à publier un mot de passe. Une méthode héritée activée pour sauver un seul client a tendance à se propager à chaque profil qui copie le fichier.

Vérifiez l’adresse, pas la connexion

Une connexion terminée n’est pas une session utilisable. IPCP négocie l’adresse interne, et un pool épuisé ou une politique qui refuse le client peuvent encore laisser un tunnel connecté sans rien à router.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Vérifiez d’abord l’adresse interne, puis la route et le résolveur pour la ressource dont vous avez réellement besoin. Une adresse interne n’est pas la sortie publique qu’annonce un site web, et confondre les deux envoie les gens chercher une fuite qui n’existe pas. Testez la ressource privée par adresse avant de la tester par nom, pour qu’une panne DNS ne soit pas prise pour une panne de routage.

Écrivez la phase, la méthode et l’adresse dans une seule note et datez-la. Si le même compte échoue à nouveau dans un mois, cette note fait la différence entre une vérification de cinq minutes et une nouvelle enquête. Des pannes à des phases différentes sont des incidents différents, même quand le client affiche une seule boîte de dialogue.