La documentation du tunnel divisé a besoin d’une règle DNS à côté de chaque route
Une route décide par adresse, un résolveur décide par nom. Documentez les deux sélecteurs par flux, chacun avec un test, sinon la note échoue quand le DNS bouge.
Une note de tunnel divisé qui dit « le trafic du bureau passe par le VPN » a documenté une décision et en a impliqué trois autres. Au niveau des paquets, une table de routage choisit une interface selon l’adresse de destination ; au niveau des noms, un résolveur choisit un serveur selon la requête, et ces deux choix sont faits indépendamment. C’est pourquoi un préfixe correctement documenté peut encore produire une machine qui résout un nom interne en adresse publique, ou qui ne résout rien alors que la route semble parfaite.
Deux sélecteurs, une tentative de connexion
Lorsqu’une application se connecte à files.corp.example, deux recherches ont lieu avant qu’un paquet existe. Le résolveur décide quel serveur reçoit la requête, en utilisant des domaines de recherche, des domaines de routage par lien ou une règle explicite de profil. La table de routage décide ensuite où va l’adresse résultante, en utilisant la correspondance de préfixe la plus longue avec la destination.
Rien ne relie ces deux décisions. Une zone privée peut répondre avec 10.20.4.11 tandis que la table de routage envoie 10.20.0.0/16 dans le tunnel, et la connexion fonctionne. Inversez l’une ou l’autre et elle échoue d’une manière qui ressemble à l’autre : une politique DNS correcte plus une route manquante donne un nom résolu et un délai d’attente, tandis qu’une route correcte plus un résolveur public donne une adresse qui se route proprement au mauvais endroit.
Le DNS à horizon divisé rend cela plus net. Le même nom peut renvoyer une adresse privée depuis le résolveur interne et une adresse publique depuis celui tourné vers Internet, donc une note qui n’enregistre que le préfixe ne peut pas prédire quelle adresse le client utilisera réellement. Écrivez le chemin du résolveur, sinon l’adresse est une supposition.
Ce qu’omet une note qui ne parle que de la route
Un enregistrement qui ne parle que de la route est inutilisable pour la défaillance la plus courante du tunnel divisé : les noms. L’utilisateur signale que l’intranet ne se charge pas, le tunnel est monté et le préfixe est présent. Celui qui prend le ticket n’a aucun enregistrement du résolveur qui aurait dû répondre, aucun moyen de distinguer un mauvais suffixe de recherche d’un serveur bloqué, et aucune référence à laquelle comparer.
La deuxième omission est la liste des exceptions. Un design de tunnel divisé se définit autant par ce qui reste hors du tunnel que par ce qui y entre, et les plages exclues sont généralement celles qui cassent en premier, car une route locale plus spécifique ou un filtre côté client peut annuler l’intention sans toucher au profil.
La troisième est le côté distant du tunnel. Une route client ne fait que mettre le paquet sur le fil ; la passerelle doit encore le transmettre et avoir un chemin de retour. Le guide de transmission de strongSwan rappelle que les règles de transmission et de pare-feu sur la passerelle font partie de la fonctionnalité, et non de la plomberie que l’on peut supposer acquise.
Les champs qui rendent la note exécutable
Une ligne par flux, et un flux est une destination plus un nom plus un propriétaire. Voici les champs qui survivent au contact d’un incident réel :
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
La ligne « où elle vit » est celle que les gens sautent. Un préfixe poussé par le serveur, une route ajoutée par un profil client et une route tapée dans un shell diffèrent par qui peut les modifier et par leur survie à une reconnexion. Sans ce champ, l’ingénieur suivant ne peut pas dire laquelle des trois il regarde.
Un test par règle, pas un par tunnel
Chaque ligne a besoin de deux vérifications inoffensives : une qui exerce la route et une qui exerce le nom. Pour la route, demandez quelque chose qui doit traverser le tunnel et confirmez le chemin plutôt que l’accessibilité, par exemple tracert -d 10.20.4.11 sous Windows ou ip route get 10.20.4.11 sous Linux. Pour le nom, interrogez le nom privé et notez quel serveur a répondu, en utilisant resolvectl query files.corp.example ou dig files.corp.example contre le résolveur que la note nomme.
Ajoutez aussi une attente négative : ce qui doit se produire quand le tunnel est tombé. Une application exclue sur un appareil Android ou iOS avec le blocage sans VPN activé peut n’avoir aucune connectivité du tout, et un client de bureau peut laisser la même application fonctionner pendant que le tunnel se reconnecte. Enregistrer la réponse voulue transforme « le VPN a cassé mon application » en affirmation vérifiable.
Gardez l’enregistrement avec la configuration
Stockez la note à côté du profil qu’elle décrit et versionnez-la avec ce profil. Un document dans un wiki que personne ne met à jour est une rumeur ; un tableau dans le même dépôt que les routes poussées et la politique du résolveur peut être relu dans le même changement.
Quand quelque chose casse, comparez la route appliquée et le résolveur effectif à l’enregistrement avant d’ajouter une autre exception. Deux des trois causes courantes — une ancienne règle d’espace de noms et un processus auxiliaire hors de la politique de l’application — ressemblent exactement à une panne VPN et sont invisibles si la note ne liste que des préfixes.
Avant de déclarer la note terminée, confirmez qu’elle répond par écrit à ceci : quel préfixe, pour quelle famille d’adresses ; quel espace de noms privé, répondu par quel résolveur ; quels noms restent délibérément publics ; où chaque règle est configurée et qui la possède ; et la commande qui prouve la route et celle qui prouve le nom. Si l’un de ces éléments manque, le prochain incident sera diagnostiqué de zéro.