Délai d’expiration L2TP sous Ubuntu 22.04 : le bogue de tunnel d’xl2tpd

Le bureau affiche une connexion en cours, IPsec signale un succès, et l’interface PPP n’apparaît jamais. Dans syslog, le même numéro de tunnel se répète jusqu’à ce que la tentative expire sur UDP 1701. Avant de modifier la clé pré-partagée ou la configuration du serveur, reconnaissez cette forme : sur Ubuntu 22.04, il s’agit généralement d’une régression d’empaquetage dans xl2tpd, et le serveur était correct tout le temps.

Ce que vous dit la paire de lignes répétée dans syslog

Une session qui échoue imprime une paire de lignes à intervalles réguliers : le démon ne trouve pas de tunnel pour un message de contrôle entrant, puis vide les identifiants d’appel et de tunnel qui lui ont été remis. Plus tard, le compteur de nouvelles tentatives atteint sa limite et la connexion se ferme sur un délai d’expiration au port 1701. Les adresses et les identifiants sont accessoires ; c’est la forme qui compte. IKE s’est achevé, le trafic de contrôle L2TP est arrivé, et le démon n’a pas pu l’associer à un tunnel qu’il avait déjà créé.

La panne se situe donc entre le contrôle L2TP et PPP. Rien du secret, des options PPP ou du sous-réseau distant n’a encore été éprouvé.

Confirmez qu’IPsec a réellement réussi

Deux vérifications séparent cela d’un problème d’identifiants, et toutes deux précèdent toute modification de paquet.

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

La sortie d’état liste la connexion et son état, et un tunnel établi signifie que la phase un et la phase deux sont terminées. Une ligne de journal sur une clé partagée manquante pointe vers le secret et rien d’autre, alors arrêtez-vous et corrigez cela en premier. Lorsqu’IPsec est établi et que le délai d’expiration L2TP apparaît encore, le démon reste le suspect. Conservez les lignes exactes d’une tentative plutôt qu’une journée entière de nouvelles tentatives.

Vérifiez la compilation d’xl2tpd, pas le nom de version

La compilation jammy d’xl2tpd 1.3.16 d’Ubuntu a activé l’optimisation à l’édition de liens, ce qui a cassé l’analyse de l’identifiant de tunnel dans la réponse SCCRP du serveur. Le démon écarte alors les paquets de contrôle d’un tunnel qu’il a lui-même créé. La chaîne de version compte plus que le nom de la distribution.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

Le paquet corrigé est 1.3.16-1ubuntu0.1, donc une compilation sans ce suffixe est antérieure à la correction. La sortie de politique montre quel candidat une mise à niveau installerait, et la liste des retenues explique pourquoi une correction n’est pas arrivée. Là où le paquet est disponible, mettez-le à niveau et reconnectez-vous via le profil normal au lieu d’éditer des fichiers à la main. Ne reconstruisez pas de modules et ne changez pas le secret tant que l’ancienne compilation est encore installée.

Vérifiez PPP après le changement

Une mise à niveau réussie se prouve à la couche qui était cassée. Vérifiez que PPP est monté, et pas seulement que l’icône a changé.

ip -4 addr show ppp0
ip route | grep ppp

La liste des interfaces devrait afficher une adresse locale et une adresse de pair, et la table de routage devrait porter les préfixes du tunnel. Syslog devrait montrer le tunnel accepté et pppd signalant les deux adresses, sans lignes répétées de tunnel introuvable. Si PPP est actif et que le trafic échoue encore, regardez ensuite le routage ou l’MTU, car l’étape L2TP a terminé son travail. Notez la version de paquet qui fonctionne dans les notes de la machine, afin qu’une réinstallation future ne rétablisse pas la compilation cassée.

Là où le paquet corrigé n’est pas disponible, les alternatives documentées sont une compilation locale depuis les sources 1.3.16 ou 1.3.17, un passage à kl2tpd ou une rétrogradation épinglée. Chacune comporte un coût de maintenance qu’il vaut la peine de consigner.