Le PPTP MikroTik décroche ? Réparez la route vers le serveur

Un client PPTP sous RouterOS se connecte, fait passer un peu de trafic, puis se tait, et le journal ressemble à un problème d’identifiants ou de serveur. Ce n’est généralement ni l’un ni l’autre. Le tunnel transporte ses propres paquets parce que la route vers le serveur correspond aussi à la route que le tunnel a installée. Le pair cesse d’entendre le routeur, et la session meurt alors que l’interface prétend encore être active.

Le correctif est une route, ou un réglage, qui garde le serveur joignable par le WAN physique. Lequel dépend de si le routeur doit être une passerelle de tunnel complet.

Le symptôme : se connecte, fait passer du trafic, meurt

Le schéma se répète à chaque reconnexion, et c’est le premier indice utile. Un mot de passe refusé échoue avant que l’interface monte, une mauvaise configuration du pare-feu bloque généralement un sens, et une boucle de routage laisse l’interface s’établir puis l’étrangle. Regardez les compteurs : le tunnel montre une rafale de paquets initiaux puis plus rien, tandis que l’interface WAN continue d’émettre des copies encapsulées. C’est un routeur qui renvoie sa propre sortie vers lui-même.

PPTP rend cela facile à déclencher parce que le transport est de l’IP simple vers l’adresse du serveur, pas un tunnel dont l’extrémité distante se trouve dans un autre sous-réseau. Tout ce qui redirige cette adresse redirige le transport avec elle.

Pourquoi le tunnel avale ses propres paquets

Quand le client se connecte, il installe une route dont la passerelle est l’interface du tunnel. Si le profil installe aussi une route par défaut, alors toute destination sans correspondance plus précise, y compris l’adresse publique du serveur, se résout vers le tunnel. Le routeur encapsule le paquet, adresse le paquet extérieur au serveur et cherche à nouveau la route : même destination, même défaut, même tunnel. Selon la version, cette récursion est rejetée, mise en file ou bouclée jusqu’à ce que le pair abandonne et coupe la session.

Les fabricants d’appliances ajoutent souvent automatiquement une route d’hôte pour leur propre serveur, précisément pour éviter cela. RouterOS ne le suppose pas, l’opérateur doit donc exprimer l’exception ou éviter la route par défaut dès le départ.

Épinglez l’adresse du serveur sur le WAN

Ajoutez la route la plus étroite possible : un /32 pour l’adresse publique du serveur, avec la passerelle du fournisseur comme prochain saut, sur l’interface qui atteint internet. Un /32 bat toute route par défaut par la longueur du préfixe, et une distance plus faible gagne si une autre route pour le même préfixe existe déjà. Reconnectez-vous ensuite et confirmez que la route est active, pas seulement présente dans la liste.

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

Si la passerelle du fournisseur est apprise par DHCP, utilisez l’adresse de passerelle installée par DHCP, ou liez la route à l’interface si la version le permet. Une passerelle codée en dur qui change au bail suivant est une panne différée. Vérifiez l’adresse après une reconnexion du WAN, car c’est là qu’une passerelle obsolète apparaît et que le tunnel recommence à décrocher.

Ou empêchez le tunnel de revendiquer la route par défaut

Une agence qui n’a besoin que d’un seul LAN distant devrait garder le profil PPTP complètement à l’écart de la route par défaut. Désactivez cette option dans le profil client et ajoutez à la place une route spécifique pour le préfixe distant via l’interface du tunnel. Le trafic ordinaire reste sur le WAN, le transport du tunnel garde son chemin naturel, et la table de routage devient plus facile à expliquer. C’est la meilleure conception pour une agence qui a besoin d’un sous-réseau, pas pour un routeur censé être la sortie du site.

Le tunnel complet a ses propres exigences : routage par politique pour des sources choisies, un plan pour le trafic de retour et une décision sur ce qui se passe quand le tunnel tombe. Rien de tout cela n’est résolu par la route d’hôte, qui ne maintient le transport en vie.

Vérifiez par couches, puis fermez le trou de gestion

Testez par couches : pingez l’adresse publique du serveur avant de vous connecter, pingez la passerelle distante après la connexion, puis pingez un hôte du LAN distant. Ajoutez masquerade sur l’interface du tunnel si les hôtes derrière le routeur ont besoin que les réponses reviennent par elle.

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

Redémarrez ensuite le routeur ou forcez une reconnexion du WAN et répétez les trois pings, car une route qui n’existe que dans la configuration en cours ne survivra pas. Une configuration exportée vers un fichier de sauvegarde puis restaurée plus tard est l’autre endroit où cela casse, puisque la route peut manquer à l’export si elle a été ajoutée à l’exécution.

Enfin, limitez Winbox et la gestion web à des adresses source connues avant de publier un changement de VPN ou de route. Un routeur qui termine des tunnels est une cible de gestion, et le port 80 ouvert au monde est une constatation plus grave que la route que vous venez de réparer.