Journal de débogage L2TP vide ? L’erreur est probablement dans le journal

Vous lancez l’assistant L2TP avec le débogage, vous regardez le terminal, et il s’arrête sans rien d’utile à l’écran. Ce n’est pas un indicateur de débogage cassé. Une connexion L2TP de NetworkManager, c’est quatre processus qui coopèrent, et seuls certains d’entre eux écrivent dans le terminal que vous regardez. Le reste des preuves est dans le journal du système, à un filtre de distance.

Quatre processus, deux destinations de journal

La connexion commence par IPsec, qui est libreswan ou strongSwan selon l’installation. Ensuite le démon L2TP, traditionnellement xl2tpd et dans certaines compilations kl2tpd, fait tourner le tunnel. Enfin pppd gère l’authentification et l’adressage à l’intérieur.

Le service auxiliaire coordonne ces pièces et imprime sa propre progression. Le démon IPsec et pppd rendent compte généralement via le journal du système, ce qui explique pourquoi le terminal affiche une connexion qui échoue alors que la raison se trouve dans un fichier que vous n’avez pas ouvert.

Cette séparation explique aussi pourquoi une erreur de PSK et une erreur de mot de passe se ressemblent depuis le bureau : les deux produisent une déconnexion générique, et l’étape qui a échoué n’est visible que dans la sortie de chaque processus. C’est toute la raison pour laquelle le journal compte ici. Un message générique sur le bureau, quatre auteurs possibles derrière.

Récupérez une tentative, puis lisez l’ordre

Reproduisez une fois, avec un profil connu et une heure connue, puis lisez une fenêtre étroite plutôt que tout le démarrage. Répéter les tentatives en changeant les réglages transforme le journal en un mélange qui ne peut pas être interprété.

Ces commandes sélectionnent les processus participants pour le démarrage en cours, et il vaut la peine de confirmer le chemin du greffon sur votre distribution :

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Des champs répétés dans une seule invocation sélectionnent l’union de ces processus, ce qui conserve la séquence dans l’ordre chronologique. Sur un système basé sur Debian, la requête équivalente est dpkg -L ; l’intérêt est de trouver où vit réellement l’assistant avant d’essayer de le lancer à la main.

Trois conditions décident de la suite

Lisez la première étape qui échoue, puis choisissez en conséquence. Si IPsec signale un échec de proposition ou d’authentification du pair, le tunnel ne s’est jamais formé, et changer le mot de passe PPP ne peut pas aider.

Si le tunnel s’est formé et que pppd a rejeté la connexion, le secret partagé était déjà correct et le problème d’identifiants est un cran plus haut. Si pppd a négocié une adresse et que l’échec apparaît plus tard, les deux fonctionnent et le problème restant est le routage, le DNS ou la politique propre au serveur.

Ces trois branches couvrent presque toute déconnexion générique, et elles se décident par le processus qui a journalisé la dernière erreur, non par le message d’erreur qui paraît le plus alarmant.

Il vaut aussi la peine de confirmer quel backend IPsec est installé avant de toucher à un réglage de débogage. Une option de journalisation écrite pour strongSwan ne fait rien quand libreswan tourne, et la connexion continuera d’échouer au même endroit pendant que vous modifiez un fichier que personne ne lit.

Le mode débogage laisse des fichiers

Le flux de débogage d’origine lance le service à la main avec un indicateur de débogage, et ce mode peut laisser en place des fichiers de configuration d’exécution générés lorsque la connexion se termine.

Ces fichiers contiennent du matériel d’authentification : la clé pré-partagée, des identifiants, ou les deux. Une configuration générée copiée dans une fenêtre de discussion est une divulgation d’identifiants, pas un extrait de journal. Supprimez les lignes secrètes avant de partager quoi que ce soit, et effacez le répertoire à la fin de l’enquête. Traitez-les comme des secrets, extrayez les lignes précises dont vous avez besoin pour un rapport, et effacez-les ensuite plutôt que de coller un répertoire dans un ticket.

L’instance manuelle doit aussi être coordonnée avec la normale. Lancer une copie de débogage alors que le service possède déjà le greffon produit deux propriétaires et un journal qui mélange les deux, ce qui est pire que pas de sortie de débogage du tout.

Restaurez ensuite l’assistant normal

Quand l’enquête se termine, arrêtez l’instance manuelle, supprimez les fichiers d’exécution conservés et reconnectez-vous par le chemin normal afin que la personne suivante voie une configuration qui correspond à la réalité.

Vérifiez ensuite le résultat à la couche qui a échoué, pas à l’icône du bureau :

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Une session qui s’authentifie, reçoit une adresse et route vers la destination prévue est le résultat que vous déboguiez. Un terminal silencieux pendant une tentative ratée ne vous dit qu’une chose : où la sortie n’a pas été écrite.