Le tunneling divisé PPTP ne fonctionne pas : corrigez d’abord le chemin GRE

Regardez une connexion PPTP monter et il est facile de croire que le plus dur est fait : le client s’authentifie, un adaptateur ppp0 ou WAN Miniport apparaît et la fenêtre d’état passe au vert. Puis la première requête vers un hôte interne expire, et le profil est mis en cause. En pratique, il y a deux couches indépendantes à franchir : le transport externe qui porte TCP 1723 et GRE, et la politique interne qui décide quelles destinations utilisent l’interface PPP. Un état vert prouve seulement que la première couche a négocié ; il ne dit rien de la seconde.

Suivez le client du profil jusqu’à la socket de contrôle

Ouvrez le journal du client et trouvez le point où il contacte le serveur. PPTP ouvre d’abord une connexion TCP vers le port 1723 et négocie les paramètres du tunnel sur ce canal. Si cette étape échoue, rien de ce qui suit n’a d’importance, et l’erreur nomme généralement l’adresse du serveur ou un délai expiré.

Confirmez la connexion de contrôle sur le réseau avant de toucher à une route. Sur le client ou un port miroir, capturez TCP 1723 pour une tentative de connexion :

sudo tcpdump -ni any 'tcp port 1723' -c 20

Une poignée de main terminée et une session établie signifient que le canal de contrôle externe fonctionne. Un SYN qui ne reçoit jamais de SYN-ACK pointe vers un pare-feu, une mauvaise adresse de serveur ou un fournisseur qui filtre le port. Une poignée de main suivie d’une réinitialisation immédiate signifie souvent que le serveur a refusé les identifiants ou le type de tunnel.

GRE est un second protocole, pas un port

PPTP transporte la charge PPP dans GRE amélioré, le protocole IP 47, qui n’a pas de numéro de port qu’un routeur puisse suivre. C’est pourquoi une règle autorisant TCP 1723 peut encore laisser le tunnel sans chemin de données. Les appareils NAT avec état doivent comprendre l’identifiant d’appel dans GRE pour remapper les réponses, et beaucoup ne le font pas. La spécification PPTP garde le canal de contrôle et la charge GRE comme des pièces distinctes, et votre plan de test doit faire de même.

Surveillez le protocole 47 dans la même capture, puis comparez ce qui sort avec ce qui revient :

sudo tcpdump -ni any 'proto gre' -c 20

Des paquets qui sortent sans réponse, alors que TCP 1723 reste sain, sont la signature classique d’un GRE bloqué. Le passthrough PPTP sur un routeur grand public est une fonction de ce micrologiciel précis, donc un réseau d’hôtel qui fonctionne ne prouve rien pour le suivant. Si le routeur n’offre pas de passthrough et que vous ne pouvez pas le changer, le problème est le choix du protocole, pas la table de routage.

Prouvez que le tunnel déplace un paquet

Une fois GRE actif, la négociation PPP attribue une adresse à l’interface du client. Lisez l’attribution au lieu de la supposer :

ip -4 addr show ppp0

Pingez l’adresse du pair affichée comme destination du lien point à point. Une réponse à ce stade prouve que le chemin encapsulé fonctionne de bout en bout et que le serveur répond à l’intérieur du tunnel. Si le pair répond mais pas les hôtes internes, le transport externe est correct et la panne s’est déplacée vers l’intérieur.

Faites-le avant d’ajouter une route divisée. Un changement de route effectué alors que le transport est cassé crée une seconde variable et masque la première.

Écrivez la politique divisée, DNS compris

Le routage divisé est une liste de décisions, pas une case à cocher. Chaque préfixe privé qui doit traverser le tunnel a besoin d’une route via l’interface PPP, et chaque préfixe qui doit rester local doit en être absent. Une route vers un sous-réseau applicatif sans route correspondante vers son résolveur privé est un moyen courant de créer une panne qui ressemble à une application cassée.

Vérifiez la décision que prend le noyau pour une adresse de chaque catégorie :

ip route get 10.20.5.10
ip route get 203.0.113.25

La première doit nommer ppp0, la seconde la passerelle ordinaire. Si les deux nomment la même interface, la politique n’est pas divisée du tout. Ajoutez l’adresse du serveur DNS lui-même à la liste tunnelisée, sinon la résolution de noms pour les hôtes internes sort par le résolveur local et ne renvoie rien d’utile.

Une vérification reproductible en cinq étapes

Exécutez les couches dans l’ordre et arrêtez-vous à la première qui échoue : canal de contrôle, visibilité de GRE, réponse du pair PPP, route divisée pour une adresse interne et une requête applicative via le tunnel. Chaque étape a sa propre commande, donc une défaillance est attribuable au lieu d’être mystérieuse.

Une version compacte pour un client Linux ressemble à ceci :

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Sous Windows, le même ordre s’applique avec route print et l’état de l’adaptateur affiché dans le client. PPTP est un protocole hérité, et si le serveur propose SSTP ou IKEv2, migrer est généralement un meilleur usage du temps que de régler un chemin qui dépend du passage du protocole 47 à chaque saut. Vérifiez le certificat et le contrat d’authentification du remplacement au lieu de copier un ancien profil dans une nouvelle version.