Ce que route-nopull d’OpenVPN empêche réellement le serveur de pousser

Vous avez mis route-nopull dans un profil client pour empêcher le tunnel d’avaler votre route par défaut, et voilà que le sous-réseau du bureau est injoignable alors que le client affiche toujours « connecté ». Les deux observations sont vraies, et rien n’a échoué. L’indicateur demande au client d’ignorer les routes et les entrées DHCP que le serveur pousse, ce qui est une consigne plus étroite que ce que la plupart des gens attendent en l’ajoutant. Ce qui reste, c’est un tunnel fonctionnel sans opinion sur les destinations qui devraient l’utiliser.

Cet écart est toute la décision dont traite cet article. Soit le serveur décrit le réseau, soit c’est le client, et l’indicateur confie cette tâche au client sans en faire quoi que ce soit pour vous.

Ce que l’indicateur désactive au moment de la connexion

Un client OpenVPN qui tire reçoit normalement du serveur après l’authentification un paquet : des routes, une redirection de la passerelle par défaut, des serveurs DNS et quelques directives de réglage. Avec route-nopull en vigueur, le client accepte toujours la session, vérifie toujours les certificats, négocie toujours les chiffrements et les keepalives, et monte toujours l’interface. Ce qu’il abandonne, c’est l’application des lignes route poussées et des lignes dhcp-option poussées, DNS compris.

La confusion vient d’un voyant vert à côté d’une application morte. Le tunnel existe ; la correspondance des destinations vers ce tunnel, non. Rien dans le panneau d’état du client ne distingue « connecté et routant » de « connecté et inerte », car du point de vue du tunnel les deux sont le même état.

Pourquoi un tunnel vivant peut ne rien router

L’interface apparaît avec sa propre adresse et, sur une liaison point à point, souvent rien de plus précis qu’une route d’hôte vers le pair. Un sous-réseau privé ne devient joignable que lorsqu’une route pointe vers cette interface avec le bon préfixe, et pousser étant désactivé, cette route n’arrive jamais. Le profil téléchargé ne peut généralement pas aider non plus, car il a été écrit en supposant que le serveur fournirait exactement ces informations. Voilà pourquoi l’interface peut sembler saine pendant que le sous-réseau reste sombre.

Lire le profil ne prouve donc que très peu. Lisez plutôt l’état en cours, sur la machine connectée :

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Une adresse sans route de sous-réseau dans la deuxième commande est la signature de ce problème. La troisième commande répond alors à la question qui intéresse vraiment les utilisateurs, car elle indique l’interface que le noyau choisirait pour une destination précise plutôt que la liste que vous espériez voir utilisée. Si elle répond par votre liaison physique, le tunnel n’est pas du tout sur le chemin.

La résolution de noms échoue pour une raison liée, non pour une raison distincte. Les entrées dhcp-option DNS poussées sont ignorées par le même indicateur, donc les requêtes pour des hôtes internes partent vers le résolveur que le réseau local a fourni. Ce résolveur n’a pas de zone pour le bureau, donc la requête échoue ou renvoie une réponse publique, et la panne ressemble à un problème de serveur alors qu’il s’agit d’un problème de configuration du client. Tester une adresse avant un nom est ce qui sépare les deux.

Choisir entre l’indicateur et un filtre de préfixe

Les deux options règlent des formes différentes de la même plainte, et c’est le mauvais choix qui produit l’état connecté mais inutile. L’une remplace la politique poussée en bloc, tandis que l’autre la modifie par préfixe. Le tableau donne la version courte, et le paragraphe qui suit couvre la partie qui surprend les gens.

pull-filter est un comparateur de préfixes à trois verbes, il peut donc accepter une famille de lignes, les ignorer silencieusement ou rejeter la connexion d’emblée quand un préfixe apparaît. Ce dernier comportement est celui qui vaut la peine d’être connu : une règle de rejet transforme un désaccord de politique en poignée de main ratée plutôt qu’en omission silencieuse. Le manuel d’OpenVPN 2.6 liste les préfixes acceptés et la sémantique exacte de chaque verbe.

Une voie médiane courante consiste à rejeter seulement redirect-gateway et à laisser les routes du bureau et le DNS arriver comme prévu. Cela maintient le push pour les parties que le serveur comprend mieux que vous, tout en empêchant la seule ligne qui prendrait le dessus sur votre route par défaut.

Ajouter des routes et un résolveur à la main

Si vous gardez l’indicateur, le profil doit dire ce que le serveur aurait dit. Les directives route côté client s’appliquent après l’établissement de la connexion, elles fonctionnent donc à côté de l’indicateur au lieu d’être bloquées par lui. Mettez-les dans le profil, pas dans une ligne de commande interactive, sinon la prochaine reconnexion ne reproduira pas l’état fonctionnel.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

La ligne DNS est dans une position inconfortable : c’est une directive côté client, mais certains clients ne l’appliquent que via l’intégration DNS de la plateforme, qui peut l’écraser lorsque la liaison change. Sur un hôte systemd, régler le résolveur directement sur l’interface du tunnel est plus prévisible que d’espérer que le client gagne le concours de priorités :

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Le domaine de routage compte autant que l’adresse. Sans lui, les requêtes pour des noms publics peuvent aussi être envoyées au résolveur interne, et tout résolveur interne qui refuse la récursion cassera la navigation tout en laissant la zone privée fonctionner. Avec lui, seuls les noms sous ce suffixe sont routés vers le résolveur du tunnel et tout le reste suit la liaison physique.

Vérifier le résultat : adresse, nom et chemin extérieur

Trois tests séparent les défaillances possibles. Récupérez l’adresse privée par IP, puis le même hôte par nom, puis un site public ordinaire. Une IP qui fonctionne avec un nom qui échoue désigne le résolveur ; une IP qui échoue avec un nom qui fonctionne désigne le routage ; les deux en échec signifient généralement que le tunnel n’est pas sur le chemin.

Regardez ensuite vers l’extérieur plutôt que vers l’intérieur. La route propre de l’extrémité du tunnel doit survivre au changement, et tout blocage doit être limité au tunnel sans capturer l’extrémité. Un client qui continue à naviguer après la chute du tunnel est un problème de politique, pas de routage, et il n’apparaîtra dans aucun des trois tests ci-dessus.

Écrivez la liste finale dans la documentation du profil : les routes, le résolveur, les domaines et la raison d’être de chacun. Une reconnexion qui reproduit le même tableau est la seule preuve que la politique locale est complète. Si les applications échouent encore avec le tunnel actif et les trois tests réussis, l’endroit suivant à regarder est la classe des problèmes connecté mais hors ligne plutôt que des certificats déjà vérifiés.