Le pull-filter d'OpenVPN correspond à plus que la route voulue

Vous ajoutez une ligne pour conserver votre route par défaut locale, et ensuite le tunnel n'atteint plus le serveur DNS interne. La ligne était pull-filter ignore "route", ce qui ne signifie pas « ignore cette route ». Cela signifie « abandonne toute option poussée dont le texte commence par ces cinq lettres », et sur un serveur normal cela inclut route-gateway, route-metric et route-ipv6 ainsi que les routes elles-mêmes. La liste de contrôle ci-dessous est ce que je parcours avant de toucher à un profil que quelqu'un d'autre doit utiliser.

Le filtre agit uniquement sur les options poussées

pull-filter agit sur les lignes d'option que le serveur envoie après l'établissement du tunnel, et sur rien d'autre. Les options écrites dans votre fichier local ne sont pas concernées, pas plus que le trafic des applications. Si vous espériez empêcher un processus d'utiliser le tunnel, c'est complètement le mauvais outil et aucune combinaison de filtres n'y parviendra.

Cette portée est utile, car elle signifie que vous pouvez laisser la configuration du serveur tranquille et tout de même en refuser une partie localement. C'est aussi une limite qui mérite d'être notée dans le ticket : un filtre change ce que ce client accepte, pas ce que le serveur propose. Il n'a aucun effet sur les autres utilisateurs du même profil. Il ne survit pas non plus à un passage à un autre client qui n'implémente pas l'option, ce qui mérite d'être su avant de bâtir un flux de travail dessus.

Confirmez ce que le serveur envoie réellement avant d'écrire le motif. À verbosité élevée, le client imprime la chaîne d'options poussées qu'il a reçue, et c'est la seule source honnête pour le texte exact auquel vous comparez :

sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpn

Lisez la ligne poussée comme une liste d'options séparées par des virgules, et notez que les noms d'option et leurs arguments sont séparés par des espaces. Votre texte de filtre est comparé à ce flux, c'est pourquoi les espaces comptent autant à l'étape suivante.

La correspondance est un préfixe, donc les espaces font tout

La comparaison est un préfixe de chaîne, pas un nom d'option analysé. "route" correspond donc à route-gateway 10.8.0.1, route-ipv6 2001:db8::/32 et route-metric 100. Un espace final le resserre sur la famille que vous vouliez probablement, et le préfixe complet le resserre encore sur une destination précise.

La dernière ligne est celle qui piège les gens pendant le travail en tunnel divisé. Conserver votre propre résolveur est un choix légitime, et cela signifie que chaque nom interne dépend désormais d'un résolveur qui ne peut pas voir la zone privée. C'est une conséquence à accepter exprès, pas un effet secondaire à découvrir en production.

La correspondance par préfixe signifie aussi qu'une règle peut s'élargir plus tard en silence. Quand le serveur ajoute une option qui commence par votre texte, votre filtre se met à s'y appliquer sans que personne n'édite votre profil. C'est le mode de défaillance contre lequel il faut concevoir, et l'atténuation est de faire correspondre autant de l'option que possible plutôt qu'aussi peu que possible.

Trois verbes aux trois résultats différents

accept, ignore et reject ne sont pas trois orthographes de la même idée. Ils diffèrent par ce que le client fait d'une correspondance et par le fait que quelqu'un l'apprenne ou non.

ignore écarte l'option correspondante en silence, ce que vous voulez pour un réglage que vous avez remplacé délibérément. reject l'écarte et fait protester le client, ce que vous voulez quand son absence doit être visible dans un journal plutôt que découverte plus tard. accept est la forme positive, utilisée quand vous construisez une liste d'autorisations plutôt que retirez des options individuelles.

Quel que soit le verbe utilisé, les filtres s'appliquent dans l'ordre où ils apparaissent, donc deux règles qui se chevauchent produisent un résultat dépendant de l'ordre et très difficile à relire. Gardez une règle par intention et mettez le texte le plus précis dans chacune. Si vous avez besoin d'une liste d'autorisations, préférez quelques règles accept à un tas de règles ignore qui reviennent au même. Les relecteurs peuvent alors lire le fichier de haut en bas et prédire le résultat, et c'est le seul test qui passe à l'échelle.

Vérifiez la route et le résolveur appliqués, pas le profil

Un filtre qui semble correct dans le fichier peut encore vous laisser avec un tunnel qui ne route rien d'utile. Vérifiez l'effet sur le système en marche, où les options poussées ont déjà été appliquées ou écartées :

ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/

Les deux premières lignes vous disent si la route par défaut poussée est arrivée et combien d'entrées statiques ont survécu. La requête au résolveur montre quel serveur l'interface du tunnel utilise réellement, et c'est généralement là qu'une surprise DNS apparaît. La dernière ligne répond à la seule question qui compte pour un utilisateur.

Testez les deux sens pendant que vous y êtes. Une règle qui garde votre internet local fonctionnel mais casse en silence la résolution de noms interne passe un contrôle superficiel et échoue à la première tâche réelle, alors incluez une ressource interne et un site public dans le même test.

Consignez l'exception et son propriétaire

Un filtre est une exception à la conception de l'exploitant, alors écrivez-le avec une raison et un point de revue. « Ignore les routes poussées pour conserver la route par défaut locale » est relisible ; une ligne nue dans un profil ne l'est pas, et la personne suivante la supprimera ou l'étendra au hasard.

La version compte aussi ici. Le comportement de correspondance et la syntaxe exacte acceptée ont été affinés au fil d'OpenVPN 2.4, 2.5 et 2.6, alors confirmez le motif dans le manuel de la version que vous livrez et non dans un message de forum sur une version plus ancienne. Le manuel d'OpenVPN 2.6 documente l'option et sa règle de correspondance.

Enfin, convenez de l'exception avec la personne qui administre le serveur. Un filtre côté client qui contredit une politique délibérée du serveur est un incident de support qui attend le prochain audit, et il est bien moins coûteux de le régler avant que le profil ne parte qu'après que quelqu'un a remarqué que les routes manquent.