PPTP se connecte puis se bloque derrière un NAT Linux : l’assistant GRE

Quelqu’un redirige le port 1723, le client atteint le serveur, l’authentification commence, puis tout s’arrête sans erreur. La conclusion naturelle est un mot de passe erroné, alors le mot de passe est retapé trois fois. La redirection était correcte et les identifiants étaient corrects. Ce qui a cassé, c’est un second protocole que la redirection n’a jamais couvert, et un réglage par défaut du noyau qui a discrètement cessé d’aider avec lui.

La redirection n’a jamais été le problème

Une règle de redirection de port décrit le trafic TCP ou UDP. Elle ne peut pas décrire une charge utile qui bascule vers un autre protocole IP au milieu d’une session, et PPTP fait exactement cela.

C’est pourquoi la connexion semble saine jusqu’au moment où elle se bloque. La partie qu’une règle de port peut gouverner a réussi, et la partie qu’elle ne peut pas gouverner est celle qui a échoué.

TCP pour le contrôle, GRE pour les données

L’appel est négocié sur TCP 1723. Une fois établi, la charge utile passe dans GRE, protocole IP 47, qui ne porte aucun numéro de port. Une règle qui s’appuie sur des ports n’a rien à comparer.

Ce que GRE transporte, c’est un identifiant d’appel dans son en-tête, et le traducteur NAT doit réécrire ce champ de façon cohérente dans les deux sens, sinon les deux moitiés de la session cessent de s’accorder. Une direction réécrite et l’autre non produit une session qui s’authentifie puis jette chaque paquet de données. C’est exactement la forme du symptôme : succès, puis silence.

GRE nu sans PPTP n’a pas besoin d’une telle réécriture, c’est pourquoi un tunnel GRE simple peut fonctionner à travers un routeur qui échoue pour un client PPTP sur le même chemin.

Quatre modules et un sysctl qui les a désactivés

Deux modules gèrent l’encapsulation, nf_conntrack_proto_gre et nf_nat_proto_gre. Deux autres gèrent l’identifiant d’appel, nf_conntrack_pptp et nf_nat_pptp. Charger le dernier de ceux-ci entraîne les autres par dépendances, donc une liste de modules devrait montrer les quatre.

Les instructions plus anciennes utilisent un préfixe ip_ de l’époque 2.6. Ces commandes peuvent sembler s’exécuter sans rien charger, vérifiez donc la liste chargée plutôt que le code de sortie.

Les avoir chargés ne suffit plus. Depuis Linux 4.7, le sysctl net.netfilter.nf_conntrack_helper vaut 0 par défaut, ce qui désactive l’attribution automatique d’assistants pour les nouveaux flux. Un routeur peut avoir tous les modules et ne rien traduire pour autant. Vérifiez la valeur effective avant de revoir la liste des modules.

Soit vous réactivez l’attribution automatique globalement, soit vous attachez l’assistant aux flux qui en ont besoin et vous laissez tout le reste tranquille :

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

La seconde option est celle à préférer. Elle limite le comportement au trafic PPTP au lieu de réactiver l’attribution automatique sur tout le routeur.

Ouvrir un protocole qui n’a pas de ports

Une règle de pare-feu qui autorise 1723 ne dit rien du protocole 47. Sous firewalld, autorisez le protocole sur la zone qui fait face au client. Sous iptables simple, acceptez le protocole gre dans la chaîne d’entrée.

Capturez ensuite des deux côtés. Des paquets qui quittent le client sans qu’aucune réponse n’arrive signifient que le chemin de retour est filtré, et c’est une panne différente d’un identifiant rejeté.

Après la connexion, la limite de taille

GRE insère un en-tête, et PPP à l’intérieur en ajoute davantage, donc une liaison qui fonctionne annonce une MTU bien en dessous de 1500. Les petites réponses se chargent et les grosses calent, ce qui ressemble à un second problème sans rapport qui apparaît au moment même où le premier est résolu.

Lisez la MTU sur l’adaptateur PPP du client et conciliez-la avec le calcul propre du routeur au lieu de baisser les chiffres jusqu’à ce que quelque chose marche. Les paquets de taille maximale qui partent sans que rien ne revienne pointent vers cette limite et non vers la traduction.

Réparer le chemin remet l’utilisateur au travail, et cela ne fait pas de PPTP un bon choix. MS-CHAPv2 et RC4 sont dépréciés depuis longtemps, alors traitez le chargement des modules comme un correctif temporaire et prévoyez le passage à un protocole maintenu.