Gardez les routes privées et abandonnez la redirection : tunnel divisé OpenVPN
Un tunnel réservé aux réseaux privés exige deux règles : les préfixes privés le traversent, la navigation ordinaire conserve son chemin local. Supprimer une route par défaut n’est pas une politique.
Le tunnel monte, l’application se charge, puis tout le reste sur l’ordinateur portable commence à se comporter bizarrement. C’est la forme habituelle d’une politique réservée aux réseaux privés, mise en œuvre en supprimant une ligne. Retirer une route par défaut poussée change bien l’endroit où va le trafic, mais ne dit pas où le trafic devrait aller à la place, et ne touche pas du tout à la résolution de noms. Une politique a besoin de deux moitiés positives avant de pouvoir être testée.
Supprimer la redirection n’est que la moitié du changement
Une redirection en tunnel complet et une politique réservée aux réseaux privés diffèrent par ce qu’elles affirment du monde. La redirection revendique chaque destination, tandis que la politique privée revendique une liste et laisse le reste tranquille. Supprimer la revendication sans écrire la liste produit un client qui n’atteint rien hors du réseau local, ce qui ressemble à une panne de routage plutôt qu’à un manque de politique. Écrivez la liste avant de retirer la revendication, et l’ordre de ces deux étapes cesse alors d’avoir de l’importance.
Les deux moitiés sont des exigences, pas des valeurs par défaut. Les préfixes privés doivent entrer dans le tunnel, et les destinations ordinaires doivent conserver le chemin qu’elles avaient avant la connexion.
Si une organisation impose le tunnel complet, rien de tout cela ne s’applique. La conception réservée aux réseaux privés appartient aux déploiements où le routage divisé est approuvé.
pull-filter est une correspondance, pas un interrupteur
La directive pull-filter retire les options poussées dont le nom correspond à un préfixe, et c’est tout ce qu’elle fait. Ignorer la redirection laisse chaque autre option poussée en place, ce qui est généralement ce que vous voulez : les routes, les paramètres DNS et la valeur de passerelle de route arrivent toujours. Elle ne peut pas non plus retirer une directive écrite dans le profil local, car le filtrage s’applique à ce que le serveur pousse.
Résistez à la tentation d’ignorer chaque option commençant par route. Ce motif écarte aussi les routes privées dont la connexion a besoin, et il peut faire perdre les informations de passerelle dont dépend le tunnel.
route-nopull est une décision plus large qu’il n’y paraît. Il empêche le client d’accepter les routes poussées et les options de type DHCP en bloc, ce qui est une politique différente du filtrage d’une seule option.
Écrivez la liste des routes depuis l’application vers l’extérieur
Partez de ce que l’utilisateur ouvre réellement, puis ajoutez les éléments de support. Une application à 10.60.20.15 implique son sous-réseau 10.60.0.0/16, et un nom privé implique le résolveur qui y répond. Un utilisateur qui a demandé une seule application a donc besoin de deux destinations et d’une décision DNS. Tout ce qui dépasse cette liste est hors périmètre par construction, et c’est ce qui garde la politique vérifiable.
Sur un serveur coopératif, cela devient deux routes poussées, et aucune des deux n’est une redirection. Conservez la topologie du tunnel et les valeurs de passerelle de route fournies par le service existant.
Lorsque seuls certains utilisateurs ont besoin de cette politique, appliquez-la par client ou par groupe. Changer le routage de tout le monde pour corriger le besoin d’une seule équipe, c’est ainsi qu’un tunnel divisé devient une panne.
| Destination | Intended path |
|---|---|
10.60.0.0/16 | Tunnel, for the approved application services |
10.61.0.53/32 | Tunnel, to reach the internal resolver |
corp.example queries | Internal resolver, selected per namespace |
| Everything else | Local path and local resolver |
Faites suivre le même chemin au DNS
Une route vers le résolveur n’est pas une politique de résolveur. Sur un client systemd-resolved, le résultat sémantique est un domaine de routage pour l’espace de noms privé pointant vers le résolveur interne, et c’est ce qui fait que seuls ces noms l’utilisent. Un client Windows a besoin à la place de son propre mécanisme de politique d’espaces de noms. Une ligne de serveur DNS dans le profil n’installe ni l’un ni l’autre à elle seule.
Vérifiez ce que le système d’exploitation a sélectionné plutôt que ce que le profil a demandé. Sous Linux, resolvectl status affiche le domaine et le serveur par liaison ; sous Windows, la table de politique d’espaces de noms constitue la preuve équivalente.
Gardez le résolveur joignable à travers le tunnel, sinon la politique pointe vers une adresse qui ne peut pas être interrogée. Une adresse de résolveur que le tunnel n’atteint pas transforme une politique qui fonctionne en expiration de délai.
Vérifiez les deux moitiés lors d’une reconnexion
Reconnectez le client après le changement et inspectez la route effective vers une adresse privée et vers une adresse publique. Résolvez ensuite un nom privé et un nom public et confirmez que chacun a utilisé le résolveur prévu. Le chargement d’un site public ne prouve que la seconde moitié, et c’est la moitié qui fonctionne généralement par accident.
Consignez la politique terminée en une phrase : ces préfixes et ces noms utilisent cette connexion, tout le reste suit le chemin local. Gardez-la ensuite dans le profil plutôt que de réparer les réglages de la carte après chaque connexion.