Les échecs d'écriture GRE sur pptpd ne sont pas un problème de mot de passe

Échec d'écriture GRE dans le journal, et le premier réflexe est de réinitialiser le mot de passe de l'utilisateur. Ce réflexe est presque toujours faux. Ces messages décrivent le chemin des données, pas la vérification des identifiants : le client a peut-être réussi son authentification puis s'est bloqué à l'étape où il s'enregistre sur le réseau. Deux messages différents désignent deux pannes différentes, et aucun ne se règle avec un nouveau mot de passe.

Deux messages, deux pannes différentes

Un échec de lecture signifie que les paquets GRE n'atteignent jamais le démon ou sont abandonnés à l'entrée. La connexion de contrôle peut sembler parfaitement saine alors que rien ne traverse le chemin des données. L'authentification est la seule chose qui a manifestement fonctionné.

Un échec d'écriture signifie généralement que la session a négocié quelque chose que le noyau ou le client ne peut pas utiliser. Le canal de contrôle s'est terminé, et les options convenues lors de cet échange ne correspondent pas à ce que les extrémités peuvent réellement faire. C'est un désaccord de configuration, pas un événement d'authentification.

Lisez lequel des deux apparaît avant de changer quoi que ce soit. Ils vous mènent à des couches différentes, et les traiter comme un seul symptôme est la raison pour laquelle le même serveur est corrigé deux fois pour des raisons sans rapport. La ligne de journal est le seul diagnostic gratuit dont vous disposez.

Le protocole 47 n'est pas le port 47

PPTP utilise TCP 1723 pour établir l'appel et GRE pour transporter la charge utile. GRE est le protocole IP 47, pas un numéro de port, donc une règle de pare-feu qui ouvre le port 47 n'autorise rien d'utile.

Un routeur sur le chemin a besoin d'une fonction de passthrough PPTP ou d'une autorisation GRE explicite. Sans cela, la poignée de main TCP se termine et le tunnel ne transporte jamais de paquet, ce qui produit exactement l'échec de lecture ci-dessus. Les règles sur le port 47 dans un pare-feu sont l'après-midi le plus souvent perdu de ce protocole.

Observez les deux directions à la fois sur le serveur au lieu de deviner quel côté abandonne le trafic : tcpdump -ni any port 1723 or proto gre.

Si 1723 montre l'établissement de l'appel alors que GRE reste silencieux, le blocage est en amont de l'hôte. Si GRE arrive et que le démon échoue encore, le problème est local et les options sont le prochain endroit à regarder.

Autorisez GRE là où l'hôte transfère réellement

Insérer une règle forward pour GRE est un test raisonnable sur un hôte qui transfère du trafic de tunnel, et ce n'est pas une politique. Une règle de test qui accepte tout d'un protocole est un diagnostic, pas une conception. Laissez-la assez longtemps pour apprendre quelque chose, puis remplacez-la par une règle limitée.

Ajoutez une règle input pour les paquets adressés au serveur lui-même, car la chaîne forward ne les voit pas. Regardez ensuite les compteurs de la règle avant et après une tentative de connexion, ce qui vous dit si les paquets arrivent tout court.

Rendez la règle persistante via le service de pare-feu de la distribution au lieu de la relancer après chaque redémarrage. Sur un hôte nftables, faites correspondre ip protocol gre à la fois dans la chaîne input et dans la chaîne forward.

Vérifiez que le module ppp_generic est également chargé, et contrôlez si le suivi des connexions abandonne la direction de retour. Les deux produisent des pannes qui ressemblent à un problème de pare-feu sans en être un. Un module du noyau manquant ressemble exactement à un protocole bloqué jusqu'à ce que vous vérifiiez.

Adaptez les options au client que vous avez réellement

Le correctif de l'autre rapport se trouve dans /etc/ppp/pptpd-options, où la recette refuse PAP, CHAP et MSCHAP, commente les lignes require correspondantes et conserve MPPE avec état. Cette recette a été écrite pour un mélange de clients, et la copier aveuglément casse le cas courant. Lisez les lignes de refus comme une déclaration sur les clients que l'auteur avait, pas comme une recommandation.

Un client Windows a normalement besoin de MS-CHAPv2 avec MPPE-128. Conservez ces exigences et retirez uniquement les options que le client ne peut réellement pas négocier.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Désactiver le chiffrement pour faire réussir une connexion est une dégradation, pas une réparation. Testez une telle variante sur un lien de laboratoire, puis rétablissez le chiffrement avant que le service n'affronte de vrais clients. La connexion qui fonctionne de façon non sécurisée est pire que celle qui échoue honnêtement.

Lisez le numéro d'erreur du client

Le code numérique du client resserre l'étape plus vite que le journal du serveur. Lisez-le avant de lire quoi que ce soit d'autre. 691 signifie que les identifiants ont été refusés, 721 signifie que le serveur n'a jamais répondu, et 619 signifie que la connexion a chuté. Deux minutes avec le numéro économisent une heure avec la configuration.

Comparez ce code au journal du serveur avant de modifier quoi que ce soit, et retestez avec le même client après chaque changement. Sinon, une seconde panne se cache derrière la première et le correctif semble inefficace.

Quand la connexion réussit et qu'aucun trafic ne circule, GRE reste le suspect. C'est le moment de revenir à la capture plutôt qu'au magasin d'identifiants.