Qui possède l’adresse, la route, le DNS et le pare-feu sur un VPN Linux ?

Deux scripts qui se disputent la même route, c’est la forme habituelle d’un problème de VPN Linux classé comme bogue de routage. Un composant crée l’appareil tunnel, un autre ajoute une route par défaut, un troisième réécrit la configuration du résolveur, et un quatrième recharge les règles du pare-feu. Chacun peut défaire le travail d’un autre, et le gagnant est simplement celui qui s’est exécuté en dernier. La question à laquelle il vaut la peine de répondre n’est pas quel paquet installer, mais quel composant fait autorité pour chaque élément d’état.

Écrivez cette carte une fois, et la plupart des échecs de reconnexion cessent d’être mystérieux. Quatre objets comptent : l’appareil et ses adresses, les routes et les règles de politique, la configuration DNS et le pare-feu.

L’appareil et ses adresses

Un appareil tunnel est créé soit par un gestionnaire qui connaît le profil, soit par un démon que quelqu’un a lancé à la main. Les deux arrangements fonctionnent seuls ; les mélanger non. Si NetworkManager possède le profil, laissez-lui aussi posséder l’appareil, et ne démarrez pas de processus OpenVPN non géré visant le même nom de tunnel.

Notez qui supprime l’appareil à la fin de la session. Un appareil qui survit à sa session est la source la plus courante d’adresses périmées et de la confusion qui s’ensuit.

Routes et règles de politique

C’est sur les routes que les conflits de propriété causent des dégâts visibles. Un gestionnaire de connexion installe une route par défaut pour le tunnel plus une route plus spécifique pour le réseau distant ; un script écrit à la main ajoute alors sa propre route par défaut avec une métrique différente et gagne ou perd discrètement selon le moment. Décidez quelles entrées sont liées à la connexion, lesquelles sont une politique permanente et quel composant les rafraîchit après une reconnexion. Ensuite, tenez les autres composants hors de cette table.

Les règles de politique méritent la même clarté, car une règle qui pointe vers une table que personne ne remplit produit un trou noir qui ressemble exactement à un tunnel mort. Si une règle existe pour forcer le trafic quelque part, la table qu’elle sélectionne doit être maintenue par le même propriétaire.

Le DNS a toujours un propriétaire distinct

Un démon de résolution tourne comme son propre processus sous sa propre identité, il n’hérite donc pas par accident des décisions de routage du tunnel. Quand le VPN pousse des serveurs DNS, quelque chose doit traduire cela en une configuration par lien que le résolveur honore, et quelque chose doit la retirer ensuite.

Le mythe consiste à croire qu’écrire un serveur de noms dans le profil change l’endroit où vont les requêtes. Cela change ce qu’on dit au résolveur, pas la socket que le résolveur utilise en amont. Testez avec une requête et une consultation de route au lieu de faire confiance au fichier.

L’état du pare-feu, et qui le restaure

Les règles de pare-feu sont l’objet le plus souvent écrasé sur un hôte VPN. Un gestionnaire peut ajouter des règles NAT ou de transfert par connexion, tandis qu’un service de pare-feu au démarrage recharge un jeu de règles enregistré et les efface. Choisissez une seule autorité pour la politique et faites de l’autre un consommateur, ou acceptez qu’un redémarrage change silencieusement le comportement. Les exceptions liées à la connexion appartiennent à un fichier que le même propriétaire charge, pas à une commande iptables tapée pendant le dépannage.

Si des règles doivent survivre à une reconnexion, dites-le explicitement. Si elles ne doivent pas, dites-le aussi, car le prochain ingénieur supposera la réponse la plus commode.

Cycle de vie : démarrage, reconnexion, démontage

Donnez un propriétaire à chacun de ces trois moments. Au démarrage, décidez ce qui prépare les prérequis et dans quel ordre. Lors d’un redémarrage à chaud, rappelez-vous que l’appareil peut survivre alors que l’état de session non, donc un validateur doit s’exécuter plutôt qu’un créateur. Au démontage, retirez seulement ce que cette connexion a créé, car réinitialiser toutes les routes ou vider tout le pare-feu n’est pas la même chose que mettre un tunnel hors service.

Pour l’observation, ip monitor link address route montre les changements du noyau au fur et à mesure, mais il rapporte des événements plutôt qu’une intention : une route supprimée ne dit rien sur le processus qui l’a supprimée. Associez-le à la carte de propriété, et un arrêt déroutant devient une courte liste de candidats.

Les exclusions ont aussi un coût. Marquer toute une classe d’appareils comme non gérée pour échapper à un conflit confie cet état à personne, ce qui est une décision plutôt qu’un correctif.