L2TP/IPsec échoue : isolez IPsec, l'authentification du tunnel ou la connexion PPP

Trois choses s'authentifient dans une seule connexion L2TP/IPsec, et une seule concerne la personne qui se connecte. IPsec prouve les extrémités du tunnel, la connexion de contrôle L2TP peut prouver à nouveau les pairs avec son propre secret, puis PPP prouve le compte utilisateur à l'intérieur de la session. Un échec à n'importe quelle étape ressemble à une erreur de connexion générique dans la fenêtre du client et se présente tout autrement dans le journal du serveur. Parcourez les étapes dans l'ordre et arrêtez-vous à la première qui échoue, car toute étape située sous une étape non testée est elle aussi non testée.

Trois étapes d'authentification, trois identités différentes

IPsec prouve à qui appartiennent les extrémités, à l'aide d'une clé pré-partagée ou d'un certificat. Cette identité appartient à des machines ou à des passerelles, jamais à l'humain devant le clavier. Quand les pairs ne parviennent pas à s'accorder à cette étape, aucun paquet L2TP n'est échangé.

La connexion de contrôle L2TP peut ajouter un second échange défi-réponse, distinct, piloté par un secret partagé que les deux extrémités doivent détenir.

La RFC 2661 rend cette authentification de la connexion de contrôle facultative, ce qui explique pourquoi la même erreur produit des symptômes différents sur deux serveurs. Un déploiement qui n'a jamais configuré de secret de tunnel saute l'étape entièrement ; celui qui l'a configuré d'un seul côté échoue avant même que PPP ne soit proposé. PPP authentifie ensuite l'utilisateur avec PAP, CHAP ou MSCHAPv2 et remet le nom à un magasin de comptes qui peut être local, dans chap-secrets ou sur RADIUS. Un mot de passe erroné à ce stade vous laisse tout de même avec un tunnel qui fonctionne et une session qui a échoué.

Lisez le point d'arrêt avant de modifier une configuration

Commencez par ipsec --version pour savoir si la sortie d'état appartient à strongSwan ou à Libreswan. Lisez ensuite le journal du serveur, et non la fenêtre du client, car le serveur note quelle étape a refusé.

Une seule ligne tranche généralement le ticket : une plainte sur IKE ou sur les propositions est la première étape, un message de la connexion de contrôle est la deuxième, et un rejet de méthode PPP ou de compte est la troisième. Copiez cette ligne dans le ticket avec l'horodatage. Deviner depuis le côté client gaspille la seule preuve que vous possédez déjà.

Gardez le matériel de clé et les mots de passe hors de ce copier-coller ; le nom de l'étape oriente le travail, et une clé pré-partagée divulguée rouvre le ticket avec de pires conséquences.

Première étape : IPsec dispose-t-il d'une association ?

Lancez ipsec statusall sur strongSwan ou ipsec whack --status sur Libreswan et cherchez une association enfant établie avec des compteurs non nuls. ip xfrm state montre la vue du noyau sur les deux. Une paire de SA installée dont les compteurs grimpent signifie que la première étape est faite et que vous pouvez continuer.

L'absence totale d'association oriente vers l'adresse du pair, le jeu de propositions ou la clé pré-partagée, et parfois vers un équipement qui réécrit UDP 500 tout en abandonnant UDP 4500. Une association qui s'établit puis disparaît au bout de quelques secondes est généralement un décalage de durée de vie entre les deux extrémités et non un problème d'identifiants. Vérifiez si les deux côtés listent les mêmes propositions de chiffrement et de hachage avant de retaper quoi que ce soit. Sinon, aucune clé ne fonctionnera jamais.

Arrêtez-vous tant que l'association manque. Modifier les options PPP à ce moment ne change rien et cache la vraie panne à la personne suivante.

Deuxième étape : la connexion de contrôle L2TP s'est-elle authentifiée ?

Une fois IPsec monté, surveillez le démon L2TP pour voir si une connexion de contrôle atteint un état établi, car PPP ne peut pas commencer avant. Un refus sur la connexion de contrôle signifie que le secret du tunnel diffère entre les extrémités, ou qu'une extrémité exige un secret que l'autre n'envoie jamais. Les clients exposent souvent un seul champ libellé secret partagé, et il appartient normalement à IPsec plutôt qu'à L2TP. Le remplir ne configure pas le secret du tunnel, et l'effacer ne le désactive pas.

Si aucun des deux côtés n'a de secret de tunnel configuré, sautez cette étape et traitez plutôt l'échec de la connexion de contrôle comme un problème de joignabilité. Confirmez qu'UDP 1701 atteint le démon et que les deux extrémités s'accordent sur la même encapsulation. Une règle de pare-feu écrite pour l'une de ces deux conditions est une cause fréquente de connexion qui ne s'ouvre qu'à moitié.

Seule une session qui commence à négocier PPP a réellement franchi l'étape du tunnel.

Troisième étape : PPP rejette-t-il le compte ?

Un échec PPP se présente autrement de l'extérieur : le tunnel est établi, la session démarre et le démon journalise un échec de méthode d'authentification ou un rejet de compte. Lisez la méthode nommée dans ce message. PAP et CHAP échouent pour des raisons différentes, et un serveur qui refuse l'une rejettera un client qui n'offre que celle-là.

Sur un serveur Linux, examinez le fichier d'options que le démon transmet à PPP, généralement /etc/ppp/options.xl2tpd, et confirmez quelles méthodes sont acceptées et où les comptes sont résolus. Un nom qui existe dans RADIUS mais pas dans le fichier de secrets local échoue proprement et ressemble à un mauvais mot de passe. Vérifiez ensuite que le client propose une méthode que le serveur accepte, et non une plus forte que le serveur refuse de négocier. Changer la clé pré-partagée pour réparer cette étape fait perdre un après-midi et ne change rien.

Quand la session finit par monter, l'attribution d'adresses, le DNS et les routes ne sont toujours pas vérifiés, et chacun échoue silencieusement à sa manière. Gardez les trois couches séparées dans vos notes : une clé correcte avec un compte erroné échoue toujours, et réparer une couche n'en répare jamais une autre.