L2TP, GRE ou IPsec : quelle couche doit porter la session ?

Deux questions s’emmêlent dès que L2TP, GRE et IPsec se retrouvent dans la même note de conception : quelle session je transporte, et quelle couche la protège ? Si la première est fausse, tout ce qui suit reste cohérent en interne tout en résolvant le mauvais problème — une superposition routée construite là où les utilisateurs devaient se connecter à distance, ou un concentrateur d’accès distant qui tient lieu de passerelle site à site. La feuille de travail ci-dessous impose cette distinction avant que quiconque se connecte à un équipement. Remplissez-la dans l’ordre et chaque ligne devient quelque chose que vous pouvez tester isolément.

Partez de la session, pas de la liste des protocoles

Un utilisateur distant qui détient une session PPP et une superposition routée entre deux passerelles sont deux relations réseau différentes, même lorsque les deux finissent enveloppées dans IPsec. La première termine un lien par utilisateur et exige une attribution d’adresses, une authentification d’une personne ou d’un équipement, et une politique nommant les réseaux internes que cet utilisateur peut atteindre. La seconde achemine des paquets entre des sites où personne ne se connecte.

Écrivez une phrase qui nomme laquelle des deux vous construisez, puis relisez-la comme si vous étiez la personne chargée de l’exploiter. Si la phrase a besoin du mot « et », vous construisez les deux, et la feuille a besoin de deux colonnes au lieu d’une colonne de compromis qui sert à moitié chacune. Si elle nomme un utilisateur mais aucun pool d’adresses, ou un préfixe mais aucune politique de transfert, la phrase reste incomplète. La formulation paraît bureaucratique, mais c’est l’endroit le moins coûteux pour attraper une conception qui serait sinon découverte par un ticket au support.

Attribuez à chaque couche exactement un rôle

L2TPv2 porte des sessions PPP entre ses deux extrémités. PPP mène la négociation du lien et, lorsqu’elle est négociée, l’authentification de l’utilisateur ; L2TP n’ajoute aucune cryptographie, donc un démon L2TP nu n’implémente rien de la relation de sécurité IPsec et ne trouve sa place que dans un lien auquel vous faites déjà confiance.

GRE est une encapsulation entre deux adresses. Il transporte des paquets de la couche réseau sur une superposition logique et, à lui seul, n’offre ni confidentialité ni identité de pair authentifiée. Ce n’est pas un défaut : l’en-tête a été conçu simple pour rester peu coûteux à traiter sur du matériel de transfert. La conséquence est que GRE répond à « comment je déplace ce paquet entre deux adresses » et à rien d’autre — exactement la question qu’il faut lui poser.

Il reste donc IPsec comme la couche qui sélectionne le trafic, authentifie les pairs et chiffre ce qu’on lui a demandé de protéger. Le trafic qu’elle protège est une décision de configuration qui doit correspondre à l’encapsulation que les extrémités génèrent réellement, car une politique écrite pour l’adresse externe de GRE se comporte différemment d’une politique écrite pour les préfixes internes. La spécification GRE garde visiblement séparés la charge utile, l’en-tête GRE et le protocole d’acheminement externe, et votre politique a besoin de la même séparation.

Écrivez le chemin du paquet avant la configuration

Prenez un paquet et énumérez chaque en-tête ajouté, dans l’ordre où il est ajouté, en nommant l’équipement qui l’ajoute. Pour un utilisateur en accès distant, c’est généralement PPP dans L2TP dans IPsec ; pour une superposition de sites, le paquet IP interne dans GRE dans IPsec. Si deux équipements ajoutent le même en-tête, vous avez une boucle ou un tunnel dupliqué, et aucune modification de politique n’y remédiera.

La même liste règle la MTU, car la taille interne utilisable est la MTU de chemin mesurée moins les en-têtes que vous venez d’énumérer, et rien d’autre. Ne recopiez pas un nombre depuis un message de forum : additionnez la surcharge IP externe, UDP et ESP, puis GRE ou L2TP, puis PPP là où il s’applique, et soustrayez du MTU de chemin que vous avez réellement mesuré. Les symptômes qui n’apparaissent que sur les gros transferts, ou les sessions qui s’établissent puis meurent à la première grosse réponse, remontent le plus souvent à cette addition faite au hasard.

Vérifiez chaque couche séparément, de l’extérieur vers l’intérieur

Exécutez les contrôles dans l’ordre et arrêtez-vous au premier qui échoue. Chaque ligne répond à une question différente, donc un échec pointe une colonne de la feuille au lieu d’annoncer que le tunnel est cassé.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Sur un équipement Cisco, l’équivalent dépend du rôle, et la syntaxe exacte varie selon la plate-forme et la version : show crypto session pour les pairs IPsec, les compteurs d’interface pour l’interface GRE ou tunnel, et la vérification VPDN ou PPP pour le rôle d’accès distant. Un jeu de commandes qui termine PPP ne prouve rien sur la prise en charge de GRE, et une interface GRE qui fonctionne ne prouve rien sur le service PPP, donc vérifiez le rôle que vous avez réellement configuré plutôt que celui du schéma.

Notez chaque sortie à côté de la ligne de la feuille à laquelle elle appartient. Les notes prises pendant que la panne est active valent plus qu’une topologie redessinée ensuite de mémoire.

Ordonnez le démontage, puis vérifiez à nouveau

Le démontage se fait en ordre inverse pour une raison : retirez le trafic protégé de la politique IPsec avant de supprimer l’encapsulation pour laquelle elle a été écrite, sinon la politique continue de pointer vers une interface qui n’existe plus et le prochain chargement de configuration échoue à un endroit qui semble sans rapport. Sous Linux, cela signifie supprimer les entrées d’état et de politique avant l’interface de tunnel ; sur un routeur, retirer l’entrée de crypto map ou de profil avant le tunnel.

Après la reconstruction, répétez les quatre observations de recette une par une : joignabilité externe, une association IPsec établie, une session PPP établie lorsque la conception en comporte une, et un transfert interne vers une adresse de destination réelle. Un voyant vert ne prouve rien pour les trois autres, et cet écart est la panne qui survit le plus longtemps en production — un tunnel qui est monté, chiffré, et qui ne transfère rien parce que la route interne n’a jamais été ajoutée.

Gardez la feuille remplie à côté de la configuration de l’équipement. Toute colonne que vous ne pouvez pas remplir est une couche sans rôle attribué, et une couche sans rôle attribué est généralement une couche qui ne devrait pas être dans la pile.