L2TP sans IPsec sous Linux : xl2tpd, pppd et NAT

Le L2TP nu est du PPP dans une enveloppe, et rien d'autre. Il transporte vos trames ; il ne les chiffre pas et ne prouve pas qui se trouve à l'autre bout, ce qui explique que presque chaque déploiement glisse IPsec en dessous. Des raisons honnêtes de faire tourner la version brute existent encore : un banc de laboratoire, une étape de migration ou un lien déjà à l'intérieur d'un autre chemin protégé.

Si vous y allez quand même, inscrivez cet avertissement dans la note de conception et laissez-le-y. Ce qui suit est le chemin opérationnel que j'utilise sur des hôtes de la famille Debian et RHEL : quel fichier s'occupe de quoi, le MTU qui évite le blocage classique et les règles de transfert qui rendent le tunnel utile.

Trois fichiers se partagent le travail

xl2tpd termine la connexion de contrôle et confie chaque session à un démon PPP, si bien que la configuration se répartit entre deux programmes qui ne lisent jamais les fichiers de l'autre. L'écouteur vit dans /etc/xl2tpd/xl2tpd.conf, dans une section [lns default] qui nomme le vivier d'adresses avec ip range, l'extrémité serveur avec local ip et la remise à PPP avec pppoptfile. Activez require authentication = yes, laissez length bit et flow bit activés, et choisissez un vivier que rien d'autre sur l'hôte n'utilise déjà.

La politique PPP appartient au fichier que cette option nomme, normalement /etc/ppp/options.xl2tpd : auth, les refus pour pap, chap et mschap, require-mschap-v2, un MTU et un MRU de 1460, et une adresse DNS que le client peut joindre une fois le lien monté. Les identifiants sont encore un troisième fichier, /etc/ppp/chap-secrets, où le deuxième champ doit correspondre au nom de la section LNS et où le quatrième peut épingler une adresse précise du vivier.

Pourquoi le tunnel se connecte puis se bloque

Une trame Ethernet de 1500 octets ne tient pas dans un chemin qui dépense déjà des octets pour ses propres en-têtes. L'en-tête IPv4 extérieur coûte 20, UDP coûte 8 et l'en-tête L2TP environ 12, ce qui laisse 1460 pour PPP et sa charge utile. C'est justement annoncer ce chiffre plus petit dans PPP qui empêche les gros paquets d'être fragmentés ou abandonnés en silence quelque part au milieu.

Le symptôme est un tunnel qui semble sain jusqu'à l'arrivée de trafic réel : les pings et les messages de contrôle passent, une copie de fichier se bloque, rien dans le journal ne l'explique. Baissez le MTU et le MRU ensemble aux deux extrémités. Ne régler que le client transforme souvent un blocage net en blocage intermittent, ce qui est plus difficile à diagnostiquer.

Un port porte deux conversations

L'UDP 1701 se trouve sous les deux moitiés du protocole, et ce seul fait casse plus de règles de pare-feu que n'importe quelle autre partie de l'installation. D'abord viennent une demande de début de connexion de contrôle et sa réponse ; la demande de session et la confirmation qui suivent n'établissent rien de plus que la paire d'identifiants. PPP prend ensuite le relais, avec le contrôle de lien, puis l'authentification, puis le protocole de contrôle IP pour fixer les adresses. Chaque étape a son propre vocabulaire dans le journal, et aucune ne s'annonce comme un échec L2TP.

Lire une capture exactement dans cet ordre vous dit quelle étape a échoué, et un échec d'authentification PPP ne se réparera pas en modifiant xl2tpd. Le port partagé explique un autre échec courant : une règle qui n'autorise que les premiers paquets d'un flux laisse la session s'établir puis bloque le transfert. Autorisez 1701 pour toute la conversation, dans les deux sens.

Rendre le tunnel utile : transfert et NAT

Une session en soi n'atteint que le serveur. L'accès Internet des clients demande le transfert, une règle NAT pour le vivier sur le lien montant et un DNS que le client peut réellement interroger une fois le lien monté. Le vivier doit aussi rester hors de la plage du LAN, sinon les réponses adressées aux clients sont livrées localement au lieu d'être renvoyées dans le tunnel.

Sur le serveur, activez le transfert avec sysctl -w net.ipv4.ip_forward=1, traduisez le vivier avec iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, puis acceptez le trafic sortant du tunnel avec une règle FORWARD pour -i ppp0 -o eth0 et le trafic de retour avec la règle miroir plus -m state --state RELATED,ESTABLISHED. Rendez ces règles persistantes entre les redémarrages, car un serveur qui revient sans elles ressemble exactement à une configuration L2TP cassée.

Atteindre le LAN du serveur lui-même est une autre tâche : ajoutez une route de retour pour le vivier sur le routeur du LAN, ou du proxy ARP sur le serveur. Cacher les clients derrière NAT alors que quelque chose dans le LAN doit les adresser directement ne fait que programmer une seconde séance de débogage pour plus tard.

Ce que la pile brute ne fait pas, et comment le vérifier

Aucune partie de cette pile ne chiffre les trames PPP, et rien en elle n'authentifie l'extrémité distante comme le serveur que vous avez réellement choisi. MS-CHAPv2 protège bien l'échange d'identifiants d'un écouteur qui ne fait qu'observer, mais un attaquant placé sur le chemin peut encore interférer avec la session. Le client natif de Windows ne propose L2TP qu'en combinaison avec IPsec, alors comptez sur Linux, le micrologiciel des routeurs et des clients tiers comme homologues. Traitez la configuration brute comme un palier de diagnostic, jamais comme l'endroit où s'arrêter.

Vérifiez dans un ordre fixe : lancez xl2tpd -D au premier plan, surveillez le journal pour l'étape PPP, lisez l'adresse attribuée dans ip addr aux deux extrémités, puis capturez l'UDP 1701 pour confirmer que les données circulent une fois la session montée. Si les quatre concordent et que le trafic échoue encore, la faute est au routage, au NAT ou au MTU, pas au L2TP lui-même.