route-gateway n’est pas redirect-gateway : ce qui change réellement

Votre tunnel monte, le sous-réseau privé répond, et la navigation ordinaire disparaît toujours dans le VPN alors que quelqu’un a supprimé la ligne de passerelle du profil. Cette combinaison est l’empreinte de la mauvaise directive qui a été modifiée. Ce qui a été retiré donnait au client un prochain saut pour les routes qu’il installe ; ce qui continuait à capturer le trafic venait d’ailleurs et a été poussé par le serveur. La couverture et le prochain saut sont deux tâches distinctes, et une seule décide si les destinations publiques utilisent le tunnel.

La ligne que vous avez supprimée était un prochain saut, pas un commutateur de politique

Chaque route que le client installe a besoin d’une adresse de passerelle vers laquelle pointer, et la directive de passerelle est la source de cette adresse lorsqu’une route n’en nomme aucune. Supprimez-la et ces routes n’ont plus rien à quoi s’accrocher, elles ne s’installent donc pas ou atterrissent sur un chemin qui ne mène nulle part. Le sous-réseau privé est exactement ce qu’une telle route transportait.

Pendant ce temps, le comportement qui a survécu a un autre auteur : une option de redirection dans le bloc poussé, qui déplace le trafic sortant ordinaire vers le tunnel selon ses drapeaux. Supprimer la passerelle ne la désactive pas et ne l’affaiblit pas. Le résultat est le pire des deux états, avec le trafic public toujours capturé et la destination privée qui justifiait le tunnel désormais inaccessible. C’est pourquoi la seconde modification, faite dans le même esprit, ne change rien non plus.

Quatre leviers, quatre tâches différentes

Quatre directives sont citées de façon interchangeable dans cette discussion, et une seule d’entre elles gouverne la couverture, c’est-à-dire quelles destinations passent par le tunnel. Une deuxième fixe le prochain saut qu’utilisent les routes, une troisième installe un seul préfixe, et une quatrième jette tout ce que le serveur a poussé, y compris les routes privées dont le déploiement a besoin. Le tableau les classe selon ce qu’un administrateur cherche à changer plutôt que selon le nom, car ce sont les noms qui causent la confusion. Traitez-les comme quatre décisions distinctes et choisissez celle que vous voulez réellement annuler.

En pratique, les quatre arrivent souvent dans un même bloc poussé, ligne après ligne, ce qui les fait ressembler à des parties d’un seul réglage. Elles ne le sont pas, et la référence OpenVPN les documente comme des mécanismes distincts précisément pour cette raison. Déterminer quelle décision vous annulez est le travail ; la modification tient en une ligne.

Filtrez la ligne poussée, conservez le prochain saut

Si la couverture que vous contestez arrive comme une option poussée, la réponse étroite consiste à ignorer cette option par son nom et à laisser le reste du bloc poussé intact. Écrit comme un filtre, cela ressemble à la ligne ci-dessous, et cela appartient au profil du client concerné, pas à la configuration du serveur.

pull-filter ignore "redirect-gateway"

L’étroitesse est le point. Comme le filtre compare un préfixe de texte, un motif plus court correspond aussi à la directive du prochain saut, ce qui retire exactement l’information dont dépendent les routes privées et reproduit l’erreur d’origine sous un nouveau costume. Un filtre n’agit aussi que sur les options poussées, il ne touche donc jamais une ligne équivalente écrite localement ou imposée par un gestionnaire de réseau. Reconnectez-vous ensuite, car une session active ne réévalue pas ce que le serveur a poussé.

Lisez la recherche, pas la table

Après avoir rechargé le profil, demandez au noyau où deux destinations iraient réellement : une à l’intérieur du préfixe privé et une sur l’internet public. Un vidage complet de la table principale est plus difficile à lire et plus facile à mal lire, car une route peut exister et perdre malgré tout face à une correspondance plus spécifique. En routage par politiques, la règle, la table et l’adresse source font aussi partie du contrôle.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

La variante def1 mérite d’être connue, car elle laisse l’ancienne entrée par défaut visible tandis qu’une paire de demi-défauts gagne la recherche. Une ligne 0.0.0.0/0 dans la sortie ne prouve donc rien en soi. La recherche répond à la question à laquelle la liste ne fait que sembler répondre.

DNS, IPv6 et la route privée doivent encore fonctionner

Refuser une redirection IPv4 ne dit rien du résolveur, donc une option DNS poussée peut continuer à envoyer des requêtes dans le tunnel alors que les routes semblent correctes. Un défaut IPv6 peut faire de même pour une famille d’adresses que le contrôle IPv4 n’a jamais touchée. Les deux exigent une décision explicite plutôt qu’une supposition. Confirmez ensuite que le service privé répond toujours, car un tunnel divisé qui a perdu sa route privée n’est pas un tunnel divisé, c’est un tunnel cassé.

Un outil plus large mérite un avertissement : route-nopull jette toutes les routes poussées et toutes les options DNS poussées, ce qui arrête certainement le tunnel complet et casse tout aussi certainement les routes privées dont dépend le déploiement, c’est donc un marteau bien plus gros qu’un filtre par nom visant une seule option. Vérifiez la destination privée, une destination publique et le résolveur après chaque changement, et considérez une poignée de main terminée comme la preuve de rien d’autre que la poignée de main.