Serveur PPTP derrière un routeur domestique : corrigez d'abord 1723 et GRE

PPTP derrière un routeur domestique échoue de deux façons indépendantes, et les confondre coûte une soirée entière. L'une des pannes est un trou de redirection : le routeur laisse passer TCP 1723 et jette le protocole IP 47, donc le client reste bloqué sur l'erreur 619. L'autre est un problème de taille : le tunnel monte, s'authentifie, puis se fige quand un paquet de taille pleine doit passer. Déterminer laquelle des deux vous avez est le premier vrai pas ; le reste compare ce que votre routeur peut exprimer, pas quelle marque est la meilleure.

Deux transports, et un seul a un port

PPTP se scinde en deux transports : une connexion de contrôle sur TCP 1723, et des trames PPP emballées dans du GRE amélioré, c'est-à-dire le protocole IP 47. GRE n'a pas de numéro de port, donc une règle écrite comme redirection du port 1723 ne peut pas le couvrir, quelle que soit la façon dont l'interface web nomme le champ. Un routeur grand public propose généralement une case nommée passthrough PPTP au lieu d'une règle de protocole, et cette case fait deux tâches : elle laisse passer le protocole 47 à travers le pare-feu et elle apprend au NAT à suivre le flux GRE. Sur un routeur Linux, ces tâches sont des modules séparés et des règles séparées, ce qui explique qu'un passthrough à moitié configuré produit encore un canal de contrôle fonctionnel. Découvrez quelle moitié est présente avant de changer quoi que ce soit.

Le pare-feu du serveur lui-même doit aussi autoriser le protocole 47 depuis l'adresse du routeur. Un pare-feu d'hôte qui n'accepte que 1723/tcp reproduit l'erreur 619 depuis l'intérieur du LAN, ce qui fait qu'une redirection cassée et une règle d'hôte cassée semblent identiques.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

Si les modules manquent, chargez-les avec sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre et rendez le chargement permanent, car un redémarrage qui oublie l'assistant retransforme un tunnel fonctionnel en erreur 619. La règle de redirection ne doit accepter le protocole 47 que vers l'adresse du serveur, pas tout le LAN. La définition de RFC 2637 sépare le chemin de contrôle et le chemin de données, et c'est pourquoi aucun écran de redirection de port ne décrit PPTP complètement.

Case de passthrough ou règle de protocole explicite

Une case de passthrough qui ne fait qu'ouvrir le pare-feu est plus proche du correct qu'un ALG qui réécrit les identifiants d'appel. La moitié pare-feu est prévisible, puisque le protocole 47 est soit accepté soit rejeté, et les compteurs disent lequel. La moitié réécriture est là où les fabricants diffèrent, car les identifiants d'appel PPTP sont par tunnel et un NAT qui les modifie doit suivre chaque appel qu'il touche. Quand un client se connecte et que deux ne le font pas, l'ALG est le premier suspect.

Une règle de NAT de destination pour 1723 pose aussi un problème de propriété. Si une règle ancienne envoie encore 1723 vers un hôte qui a cessé de faire tourner le serveur, les paquets atterrissent sur un port fermé et le service PPTP du routeur lui-même cesse de répondre, ce qui se lit comme une panne de pare-feu mais est en réalité une cible obsolète. Lisez la règle et sa destination avant d'en ajouter une seconde. Sur les routeurs qui terminent PPTP eux-mêmes, la règle WAN entre en concurrence avec le service intégré, alors choisissez un seul propriétaire pour 1723 et le protocole 47.

Deux clients derrière le même NAT sont le cas qui sépare une redirection simple d'une redirection astucieuse. Rediriger le protocole 47 sans réécrire les identifiants d'appel se comporte généralement mieux qu'un assistant qui essaie de les corriger.

Mesurez le tunnel avant d'accuser le routeur

PPTP réduit la charge utile, et cette réduction est de l'arithmétique, pas un mystère. Chaque paquet du tunnel porte un en-tête IP externe, un en-tête GRE amélioré, un en-tête PPP et, avec le chiffrement, un en-tête MPPE. Quand le chemin ne peut pas transporter la trame résultante, les petits paquets passent, la connexion s'achève, et la session se bloque la première fois qu'un transfert de fichier ou une poignée de main TLS envoie un paquet de taille pleine.

Calculez le nombre au lieu de le deviner. Le GRE amélioré coûte 8 octets, PPP coûte 4, MPPE coûte 4, et l'en-tête IP externe coûte 20, donc le tunnel avale 36 octets avant toute charge utile. Sur un WAN PPPoE qui plafonne à 1492, le plus grand MTU PPP qui tient est 1492 moins 36, soit 1456. Réglez mtu et mru sur cette valeur dans les options PPP et retestez avec un ping sans fragmentation.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

Le ping mesure le chemin, pas le tunnel : 1464 octets de charge utile plus 28 octets d'en-têtes IP et ICMP remplissent exactement une trame de 1492 octets. Si ce ping échoue, baissez le nombre jusqu'à ce qu'il passe et retirez 36 du résultat. Un MTU de tunnel réglé au-dessus de la limite du chemin produit le gel sans une seule ligne de journal qui mentionne la taille.

PPTP, L2TP/IPsec ou OpenVPN sur le même routeur

Le même routeur peut porter n'importe lequel des trois tunnels courants, et la différence tient à ce qu'il doit exprimer. PPTP a besoin de deux règles dans deux couches différentes. L2TP sur IPsec a besoin d'UDP 500 et 4500 pour l'échange de clés et, sauf si NAT-T le porte, du protocole 50 pour la charge utile. OpenVPN a besoin d'un seul port UDP et d'aucun assistant.

La colonne L2TP n'est pas automatiquement plus amicale que GRE. ESP est le protocole IP 50 et n'a pas de port non plus, donc un routeur qui peine avec le protocole 47 peut peiner avec le protocole 50 pour la même raison. NAT-T existe pour envelopper ESP dans UDP 4500, et quand les deux extrémités le prennent en charge la règle du protocole 50 devient inutile. C'est une propriété des extrémités, pas de la case PPTP du routeur. Confirmez l'encapsulation que le client a réellement négociée avant d'écrire des règles pour les deux.

OpenVPN est l'option avec le moins de pièces mobiles côté routeur. Un port UDP, une redirection, aucun assistant de suivi de connexions et aucune réécriture d'identifiants d'appel. L'échange est un client qu'il faut installer plutôt qu'un composeur intégré, et c'est souvent la seule raison pour laquelle PPTP reste dans la conversation.

Ce qu'il faut réparer et ce qu'il faut remplacer

Corriger la redirection et le MTU vous donne un tunnel qui fonctionne, pas un tunnel que vous devriez garder. L'authentification MSCHAPv2 de PPTP est attaquable depuis des années, et un tunnel fonctionnel transporte des identifiants qui peuvent être récupérés hors ligne. Si l'appareil distant peut faire tourner L2TP/IPsec ou OpenVPN, traitez la réparation comme une mesure temporaire avec une date.

La décision se résume à ce que l'extrémité distante prend en charge et à combien de temps l'arrangement doit durer. Un appareil hérité qui ne parle que PPTP reçoit la réparation ; tout ce qui peut installer un client est migré.

Avant de fermer le ticket, confirmez que le client survit à un gros transfert et pas seulement à une connexion, et que le routeur tient encore sa règle du protocole 47 après un redémarrage. Un tunnel qui passe une copie de fichier et meurt après la mise à jour de firmware suivante n'a jamais été terminé.