Le client VPN supprime votre route ajoutée ? Utilisez une table de politiques

Un /24 pour une imprimante de laboratoire disparaît entre deux appels à ip route show, et le journal du client dit seulement que le réseau a changé. Rien n’était faux dans la commande, le préfixe ou vos privilèges. Un client d’entreprise qui possède le modèle de routage de l’hôte réaffirme ce modèle dès que quelqu’un d’autre le modifie, si bien que l’entrée que vous avez ajoutée est supprimée comme un intrus. Lutter contre lui dans la même table est une position perdue. La solution est de cesser complètement de rivaliser pour cette table et de placer l’exception là où le moniteur ne regarde jamais.

Le moniteur explique la route disparue

Démontrez-le avant de redesigner quoi que ce soit : lisez la table, ajoutez le préfixe, attendez quelques secondes, relisez. Si l’entrée est absente et que vous n’avez rien saisi pour la supprimer, un agent surveille. Trouvez le processus qui possède ce comportement et lisez son journal autour du moment où la route disparaît, car le même service gère généralement le tunnel, les filtres de paquets et la configuration du résolveur. Le tuer pour que votre route tienne est un échange que vous regretterez à la prochaine reconnexion.

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

Le préfixe et l’interface ci-dessus sont des espaces réservés. Copier un nom d’interface depuis un exemple qui fonctionne sur une autre machine est la raison la plus fréquente pour laquelle cette démonstration ne produit absolument rien.

Une seconde table est invisible pour le moniteur

L’agent ne reconstruit que la table qu’il possède. Donnez à l’exception sa propre table plus une règle qui y envoie les destinations correspondantes, et la table principale ne change jamais, donc l’agent n’a rien à corriger. C’est toute l’idée : un espace de noms de routes que quelqu’un d’autre maintient, et un autre que vous seul touchez.

L’échange, c’est la maintenance. Deux objets peuvent diverger, et la position de la règle dans la liste compte autant que la route dans la table qu’elle sélectionne.

Construisez l’exception, puis faites-la gagner

Créez la table, installez la route et ajoutez une règle qui sélectionne la table pour cette destination. La préférence décide si votre règle est consultée avant ou après celles que le client a insérées, et une règle classée plus tard n’est jamais atteinte, donc le nombre fait partie de la conception et non de la décoration. Demandez ensuite au noyau ce qu’il ferait réellement, ce qui est une autre question que ce que vous avez configuré.

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get résout la route que le noyau utiliserait, y compris l’appareil et l’adresse source. Il n’imprime pas l’identifiant de la table, alors associez-le à ip rule show lorsque vous devez confirmer quelle table l’a emporté. Ensemble, ils répondent à la seule question qui compte : le trafic vers cette adresse sort-il là où vous le vouliez ?

D’autres formes de la même idée

Le motif se généralise dès que vous cessez de penser en destinations. Un sous-réseau local peut rester joignable tandis que le tunnel conserve la route par défaut. Les réponses d’un serveur SSH rattaché au LAN peuvent sortir par l’interface par laquelle elles sont arrivées au lieu de disparaître dans le tunnel. Et une règle basée sur l’interface peut pousser tout ce qui arrive sur une interface sans fil dans le tunnel, tandis que le trafic que l’hôte génère lui-même reste sur Ethernet :

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

Ce dernier cas correspond à l’interface entrante plutôt qu’à la destination, ce qui est un autre type de règle et un autre modèle mental. Le trafic transféré a aussi besoin de net.ipv4.ip_forward activé, et l’extrémité distante doit router la plage source en retour ou la traduire ; une règle sur une machine ne crée jamais l’autre moitié du chemin.

Traitez la règle comme jetable

Les règles et les routes de table vivent en mémoire. Après une reconnexion, l’appareil du tunnel peut être renommé, l’adresse attribuée peut bouger, et une règle contenant l’ancienne valeur cesse silencieusement de correspondre. Réappliquez tout le changement depuis un seul script qui le possède, puis revérifiez ip rule show, le nom actuel de l’appareil et un ip route get récent contre une destination réelle avant de faire confiance à l’exception.

Deux limites survivent à tout soin. Le client contrôle toujours ses propres règles de filtrage et la configuration du résolveur, et une exception de routage ne supplante ni l’une ni l’autre. Si le client supprime aussi votre règle de politique, les voies prises en charge sont sa propre politique de tunnel divisé ou un client qui vous laisse gérer les routes, comme OpenConnect ; corriger un binaire d’un fournisseur pour faire taire son moniteur est un engagement de maintenance assorti d’une vérification d’intégrité.

Écrivez le numéro de table, la préférence et la destination dans une note à côté du script. Sinon, la personne suivante trouve une règle qui surclasse le tunnel sans aucun moyen de savoir pourquoi.