L2TP/IPsec se connecte sur un réseau et reste sans réponse sur un autre

Le même portable, le même profil et le même mot de passe fonctionnent dans un bâtiment et échouent dans un autre. Cette comparaison est la preuve la plus utile du ticket, et c’est généralement la première chose qu’on écarte. Entre deux réseaux d’accès, l’échange passe par une traduction d’adresses différente, des filtres différents et des assistants de routeur différents. Garder le client fixe et ne changer que le réseau est la façon de découvrir lequel de ces éléments compte.

Fixez le client avant de comparer les réseaux

Ne changez rien sur l’appareil avant d’avoir consigné le cas qui fonctionne : version du client, contenu du profil, nom du serveur et heure de la connexion réussie. Reproduisez ensuite la panne sur le second réseau pendant la même session, afin que l’état du client soit aussi identique que possible. Un profil modifié entre les deux tentatives invalide toute la comparaison. L’objectif est une seule variable, et cette variable est le réseau.

Confirmez d’abord l’accès internet ordinaire sur le réseau défaillant, y compris un portail invité s’il en existe un. Un portail jamais validé produit un délai d’attente qui ressemble exactement à un tunnel filtré, et cette vérification prend une minute.

Quatre étapes, quatre messages d’erreur différents

Une connexion L2TP/IPsec traverse quatre étapes, et RFC 3193 décrit la disposition qui lie les deux premières. La négociation IKE est l’endroit où un chemin filtré produit un délai d’attente silencieux. L’authentification IPsec est l’endroit où une discordance de certificat ou de clé prépartagée produit au contraire un rejet explicite. La mise en place du tunnel L2TP est l’endroit où une association de sécurité établie peut malgré tout ne mener nulle part, et la connexion PPP est l’endroit où un identifiant erroné produit enfin un échec visible. Lisez le journal de l’étape qui s’est arrêtée, pas de la dernière ligne imprimée.

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

Le journal de strongSwan indique si l’échange IKE a atteint une proposition et si le pair a répondu tout court, ce qui sépare l’accessibilité de la politique. Le journal de xl2tpd reprend là où IPsec s’arrête, si bien qu’une association de sécurité établie sans rien dans ce journal désigne l’étape L2TP. La requête de route confirme que le client envoie vers l’adresse de serveur que vous croyez, ce qui attrape une réponse DNS périmée héritée du réseau précédent. Ensemble, les trois sorties nomment une étape plutôt qu’un symptôme.

Comparez la profondeur NAT et le comportement de l’assistant

La traversée NAT place le trafic protégé sous encapsulation UDP lorsqu’une traduction est détectée, de sorte que les numéros de port qui portent une session fonctionnelle peuvent différer de ceux d’un schéma statique. Autoriser un seul paquet d’établissement ne prouve rien sur le reste de l’échange, et une analyse de ports externe ne peut pas vous dire comment le pair traite le trafic authentifié valide. Une seconde couche de traduction change encore la donne, car la correspondance existe désormais deux fois et expire selon deux calendriers différents. La traduction de niveau opérateur sur une connexion mobile est la raison habituelle pour laquelle un profil de bureau fonctionnel échoue sur un partage de connexion de téléphone.

Les assistants de routeur varient autant que les réseaux. Certains firmwares interceptent et réécrivent l’échange, d’autres cessent simplement de le rejeter, et d’autres n’appliquent le réglage qu’en mode hérité. Lisez la description que le firmware donne lui-même de la case à cocher, et lorsqu’un mode de compatibilité existe, testez-le comme un changement délibéré plutôt que trois à la fois.

Client sortant, serveur entrant : deux problèmes différents

Un client sortant et un serveur entrant ont besoin d’une accessibilité amont différente, et une fonction de passage qui aide le premier ne fait rien pour le second. Un routeur domestique qui laisse le portable joindre une passerelle distante n’accepte pas pour autant les connexions entrantes vers un serveur derrière lui. Confondre les deux vous envoie chercher une redirection de port qui n’a jamais été le problème. Précisez le rôle de l’appareil défaillant avant de comparer quoi que ce soit.

Après un changement pris en charge, répétez la même connexion et notez l’étape atteinte. Conservez ensemble le profil fonctionnel et la note sur le réseau défaillant, et ne réinitialisez pas les identifiants et ne réinstallez pas le client, car cela écarte la preuve sur laquelle la comparaison était bâtie.