Pourquoi un joker dans une directive route d’OpenVPN ne peut pas fonctionner

la route installe des préfixes d’adresse, donc un motif de nom d’hôte n’a rien à comparer. Utilisez un préfixe pour les réseaux et un proxy ou un fichier PAC lorsque les domaines doivent décider.

L’intention est raisonnable : envoyer tout ce qui concerne un domaine d’entreprise par le tunnel et laisser le reste tranquille. La directive modifiée installe des routes, et une route n’a aucune notion de nom d’hôte à comparer. Chaque tentative d’y écrire un joker produit soit une erreur d’analyse, soit, pire, une route qui fonctionne aujourd’hui par hasard parce que le nom s’est résolu en une seule adresse. On demande à deux mécanismes différents de faire le travail de l’autre.

Ce qu’une route installe et ce qu’elle ne lit jamais

Une entrée de route indique qu’un préfixe de destination est joignable via une interface. Le noyau compare les paquets à ces préfixes, donc les seuls identifiants en jeu sont des adresses et des masques. Un nom d’hôte n’apparaît jamais dans la décision de transfert, et c’est pourquoi on ne peut pas y comparer un motif.

OpenVPN peut accepter un nom résoluble dans certains paramètres de route, et cette tolérance est une source de confusion. Le nom est résolu pendant l’application de la configuration, produisant une ou plusieurs adresses qui deviennent des routes ordinaires. Après cela, le nom disparaît complètement de l’image.

Une route construite à partir d’un nom est donc un instantané, pas une règle. Elle couvre ce à quoi ce nom s’est résolu au moment où le tunnel a démarré, ce qui est exactement le comportement que vous ne voulez pas pour une famille d’hôtes qui change. Un enregistrement qui se déplace demain laisse la route pointer vers hier.

Quand la destination est réellement un préfixe

Si la cible est un réseau privé connu, écrivez le préfixe. Pour un exemple de l’espace de documentation, un seul hôte et un sous-réseau ressemblent à ceci :

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Les deux entrées nomment des adresses et des masques, et les deux survivent aux changements DNS parce que rien en elles ne dépend d’un nom. C’est tout l’avantage : la route est une affirmation sur la topologie plutôt que sur une recherche qui a eu lieu une fois.

N’extrapolez pas un grand préfixe à partir d’une seule réponse DNS. Un nom d’hôte qui se résout en une adresse ne vous dit rien de la taille du réseau derrière, et un préfixe deviné est la façon dont un tunnel finit par capturer du trafic que personne ne comptait y faire passer. Demandez le préfixe réel au propriétaire du réseau au lieu de l’inférer d’une recherche.

Quand l’unité de travail est un nom d’hôte

La sélection par domaine exige quelque chose qui lise le domaine, c’est-à-dire un composant de couche applicative. La réponse habituelle est un proxy HTTP qui vit de l’autre côté du tunnel, le client choisissant quelles requêtes lui envoyer.

Un fichier de configuration de proxy peut exprimer ce choix. Les règles illustratives ci-dessous envoient un domaine et ses sous-domaines vers un proxy et tout le reste en direct :

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

La comparaison du nom exact couvre le domaine lui-même, et la comparaison de suffixe couvre ses enfants sans correspondre à un nom qui se termine simplement par des caractères similaires. Les deux sont nécessaires, et en omettre une produit une règle qui semble correcte et saute l’apex ou un imposteur.

Ces règles choisissent un proxy ; elles n’en créent pas et ne changent aucune route du système d’exploitation. L’adresse du proxy a toujours besoin de son propre chemin à travers le tunnel, et les requêtes marquées comme directes suivent toujours la politique de routage que la machine possède déjà.

Ce que l’option proxy ne couvre pas

Les programmes qui ignorent la configuration de proxy du navigateur ne seront affectés par rien de tout cela. Les outils en ligne de commande, les programmes de mise à jour et les applications dotées de leur propre pile réseau prennent la table de routage, pas le fichier PAC, donc ces cas nécessitent un mécanisme par application pris en charge ou une autre conception. Inventoriez les clients qui comptent avant de promettre que la règle du navigateur couvre le flux de travail.

Revenir en direct n’est pas non plus une échappatoire. Si la politique de routage de la machine envoie déjà tout dans le tunnel, une requête marquée comme directe y reste, car le choix du proxy et la table de routage sont des décisions différentes prises à des couches différentes.

La résolution de noms est une troisième question distincte. Choisir quelles requêtes vont vers un proxy ne dit rien sur le résolveur qui y répond, et traiter les deux comme un seul réglage produit des fuites invisibles jusqu’à ce que quelqu’un teste depuis l’extérieur. Décidez où chaque requête reçoit sa réponse et écrivez cette décision à côté de la règle de proxy. Un résolveur qui change parce que le tunnel s’est levé déplacera la réponse en silence.

Tester les deux chemins, pas seulement celui qui va bien

Testez un nom d’hôte qui devrait correspondre, un nom d’hôte qui ne devrait pas, et l’apex du domaine, car l’apex est le cas le plus souvent manqué par une règle de suffixe seule. Confirmez ensuite quel chemin chaque requête a réellement pris au lieu de l’inférer du chargement de la page.

Enfin, testez la branche d’échec. Un proxy injoignable devrait échouer d’une manière que vous avez décidée à l’avance, plutôt que de retomber silencieusement sur une connexion directe. La référence des options réseau documente précisément les paramètres de route ; la moitié domaine de cette conception vit entièrement en dehors d’elle.

Articles similaires