La mise à niveau d'Ubuntu a-t-elle cassé L2TP/IPsec ? Comparez les propositions IKEv1

La connexion fonctionnait jeudi, la mise à niveau a eu lieu vendredi, et lundi le client tourne sur « connecting » puis abandonne. Même portable, même serveur, même compte, même clé pré-partagée. Rien n'a été modifié dans le profil, et c'est pourquoi les suspects évidents, le mot de passe et le pare-feu, vous font perdre du temps.

Ce qui a changé, c'est la liste des transformations que votre machine accepte de proposer. Les deux piles IPsec utilisées sur Ubuntu, strongSwan et Libreswan, retirent des algorithmes qu'elles ne jugent plus sûrs, et le greffon NetworkManager qui les précède possède sa propre liste, qui évolue selon un autre calendrier. Un serveur figé sur 3DES, SHA1 et un groupe Diffie-Hellman de 1024 bits peut finir par ne plus rien entendre de ce qu'il accepte.

Ce que la mise à niveau a réellement changé

Deux couches alimentent la proposition IKEv1. Le démon fournit un ensemble de propositions par défaut compilé, et le greffon L2TP soit s'en remet à lui, soit fournit sa propre liste. Avant NetworkManager-l2tp 1.2.16, le greffon s'en remettait, donc votre proposition était ce que le démon installé jugeait raisonnable. À partir de 1.2.16, le greffon envoie une liste documentée inspirée des clients Windows et Apple, et cette liste est plus large que l'ancien défaut mais ne contient plus toutes les combinaisons héritées en tête de file.

Cette séparation explique un mode de défaillance que les gens trouvent déroutant : deux machines sur la même version d'Ubuntu peuvent se comporter différemment parce que l'une a le paquet de la distribution et l'autre un backport, et la version du démon sur les deux semble identique dans un rapport de bogue. Vérifiez la version du greffon, pas seulement celle du démon, avant de conclure que la mise à niveau n'a rien changé de pertinent.

Il y a un piège plus petit dans la même zone. Les deux démons orthographient différemment les groupes Diffie-Hellman à courbe elliptique, l'un écrit ecp384 et l'autre ecp_384. Collez la mauvaise orthographe dans la boîte de dialogue Avancé et le démon rejette le réglage comme non analysable, ce qui apparaît dans le journal comme un problème de négociation plutôt que comme une faute de frappe dans la configuration.

Lisez la défaillance avant de changer quoi que ce soit

Commencez par le backend que vous exécutez, car la réponse détermine à la fois la syntaxe et l'emplacement du journal.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

Lisez ensuite l'échange lui-même. Sur strongSwan, le démon écrit dans le journal sur une version actuelle et dans /var/log/syslog sur une plus ancienne, et la partie intéressante est la proposition qu'il envoie, pas la dernière ligne. Vous cherchez une formulation sur l'absence de proposition correspondante, ce qui est un problème d'algorithme ; un échec d'authentification, qui désigne la clé ou le compte ; ou un simple délai d'attente, qui désigne l'accessibilité.

Ces trois résultats sont bien trop souvent traités comme un seul symptôme. Un délai d'attente avec un journal de démon vide signifie que les paquets n'arrivent pas. Un rejet de proposition signifie qu'ils sont arrivés et ont été refusés. Si votre journal est silencieux, augmentez le niveau de débogage du greffon pour un essai et baissez-le ensuite, car la sortie détaillée remplit vite un journal.

La phase 1 et la phase 2 sont des paris séparés

IKEv1 négocie deux fois. Le mode principal construit l'association de sécurité IKE à partir d'un algorithme de chiffrement, d'un algorithme d'intégrité, d'un groupe Diffie-Hellman et d'une méthode d'authentification. Le mode rapide construit ensuite l'association ESP qui transportera L2TP. Un serveur est libre d'accepter la première et de rejeter la seconde, donc un profil à moitié correct échoue plus tard que prévu et ressemble à un autre bogue.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

Le point d'exclamation est la syntaxe strongSwan d'une entrée stricte : ne proposer que cette seule combinaison et rien d'autre. Sans lui, l'entrée rejoint une liste de repli, ce qui est bien quand le pair est moderne et contre-productif quand c'est un appareil doté d'une seule politique codée en dur. Considérez la paire ci-dessus comme une illustration de la forme, non comme une recommandation pour quoi que ce soit que vous construisez aujourd'hui.

Changez un champ, puis répétez le test

Sur un greffon actuel, le premier test le plus rapide consiste à vider entièrement les deux champs de proposition et à se reconnecter, car la liste par défaut fournie inclut déjà les combinaisons courantes de Windows et d'Apple. Sur un greffon plus ancien, les vider rend le contrôle à un démon qui a peut-être abandonné l'algorithme que votre serveur exige, et la panne s'aggrave.

Si vider ne suffit pas, définissez la paire stricte que votre serveur documente, une phase à la fois. Modifiez la phase 1, reconnectez-vous et lisez le journal avant de toucher à la phase 2. Quand une combinaison fonctionne enfin, notez-la à côté du modèle de serveur et de la version du greffon, car les valeurs par défaut bougeront encore et cette note est ce qui transforme la prochaine mise à niveau en vérification de cinq minutes.