Écrivez le chemin du paquet avant de configurer le VPN

La plupart des installations VPN commencent par un client et un profil, et le temps que le tunnel soit monté, plus personne ne peut dire quel paquet était censé le traverser. La première page de travail coûte moins cher que la troisième heure de débogage : décrivez une connexion prévue de bout en bout, sur papier, avant qu’un fichier de configuration existe. L’exercice tranche souvent une question que vous ne vous étiez pas encore posée, par exemple de savoir s’il faut une sortie vers internet, un accès distant à un sous-réseau ou une liaison entre deux sites.

Une connexion suffit pour commencer. Trois pages de topologie cachent généralement la même réponse manquante.

Décrivez une requête, pas un schéma

Commencez par l’émetteur : une plage d’adresses, une famille d’adresses et l’application qui produit le trafic. Nommez ensuite le préfixe de destination et le service qu’il porte, jusqu’au port et au protocole, car une règle qui autorise le sous-réseau mais pas le service est une règle qui ne fait rien. Les deux adresses sont tout l’enjeu, et tout le reste est la mécanique qui doit s’accorder avec elles.

Énumérez le chemin dans l’ordre : la liaison physique, le point de terminaison VPN à chaque extrémité, le tunnel lui-même et le réseau au-delà. Écrivez les noms d’interfaces si vous les connaissez, car ce détail est ce qui transforme une description en quelque chose que vous pourrez comparer plus tard à une table de routage. Ajoutez l’adresse que chaque interface utilise côté tunnel. Sans ces deux éléments, personne d’autre ne peut vérifier le relevé sur l’appareil.

Nommez maintenant l’unique connexion prévue en une seule phrase en haut de la page. Si cette phrase a besoin du mot ou, vous avez deux conceptions et vous devez les traiter séparément.

Suivez la réponse avant la requête

Un chemin qui ne décrit que le sens sortant n’est que la moitié d’un document. Suivez la réponse en retour et identifiez quel appareil connaît la plage de l’émetteur, si une traduction modifie la source à la sortie et où le paquet de retour est censé entrer. C’est sur la réponse que la plupart des installations échouent, car la requête est facile à observer et la réponse ne l’est pas.

Notez explicitement toute traduction d’adresse, y compris où elle a lieu et ce que l’extrémité distante voit alors. Un pair qui journalise une adresse et route vers une autre décrit deux conceptions différentes.

Traitez la résolution de noms comme un échange à part entière, et non comme une partie de la route de l’application. Un enregistrement interne peut avoir besoin d’un résolveur accessible uniquement par le tunnel, et un relevé de chemin qui s’arrête au préfixe de l’application ne le révélera pas. Il en va de même pour toute validation de certificat qui dépend de l’accès à une autorité interne.

Donnez un responsable à chaque décision

Pour chaque route, règle de pare-feu, sélecteur et identifiant, notez quelle configuration le contient et quelle personne peut le modifier. Un responsable par ligne est ce qui permet au document de survivre à la première demande de changement, car l’alternative est un document qui décrit l’intention et un réseau qui décrit l’historique.

Méfiez-vous de deux responsables pour une même valeur par défaut. Un script client et un gestionnaire de réseau peuvent tous deux installer des routes sans que l’un sache que l’autre existe, et une autorisation d’écoute sur la passerelle n’est pas la même permission que le transfert. Les deux cas produisent un relevé de chemin juste sur le papier et faux sur le câble.

Lorsqu’une valeur est décidée par un fournisseur plutôt que par vous, indiquez-le sur la même ligne. Un préfixe délégué par un hébergeur a un processus de changement différent de celui que vous avez choisi vous-même. Cette note épargne au prochain ingénieur un ticket de support pendant un incident. Elle explique aussi pourquoi un changement que vous avez approuvé n’a eu aucun effet.

Décrivez ce qui casse et comment vous récupérez

Pour chaque étape du chemin, indiquez ce qui s’arrête quand le tunnel disparaît et quelle connexion sortante doit rester joignable pour que vous puissiez réparer. Une conception qui perd son accès de gestion en même temps que le tunnel est une conception qui exige une visite sur site.

Le tunnel complet et le tunnel partagé ont leur place sur cette page comme un choix explicite plutôt qu’une case à cocher, car ils changent à la fois le mode de défaillance et le chemin de récupération.

Nommez un test inoffensif pour chaque étape

La joignabilité du point de terminaison, l’établissement du tunnel, l’adresse privée, le nom privé et l’autorisation applicative sont cinq observations différentes, et chacune a besoin d’un test qui ne puisse être confondu avec un autre. Un ping vers la passerelle prouve au mieux les deux premières. Une connexion au port de l’application ne prouve la quatrième et la cinquième que si le nom a été résolu par le résolveur prévu.

Écrivez le test à côté de l’étape qu’il couvre, avec la commande et la sortie attendue. Une page de chemins précis vaut mieux qu’une page de commandes qui ne dit jamais quels paquets elles devaient affecter.