Comment garder lisible un plan d'adressage de VPN IPv6 un an plus tard
Un plan lisible indique quel préfixe appartient à quel site et comment les réponses reviennent. Notez les rôles, la notation, la délégation et les routes de retour à côté de chaque entrée.
Deux questions décident si un plan d'adressage mérite sa place : quel préfixe appartient à quel site, et comment une réponse ressort de ce site. Répondez aux deux en une seule passe et un mainteneur peut modifier un pair sans interroger personne. Tout le reste du document existe pour soutenir ces deux réponses. Ce qui ne soutient ni l'une ni l'autre est de la décoration.
Ce qu'un lecteur doit pouvoir répondre avant de toucher à un pair
La compression rend les adresses nettes, et la netteté n'est pas de la structure. La structure, c'est savoir quelle plage le fournisseur a déléguée, laquelle vous avez choisie, laquelle est un pool de clients et laquelle se trouve derrière un site.
Écrivez pour le collègue qui arrivera le trimestre prochain et devra ajouter un second site. Rien sur la page ne lui dit d'où vient un préfixe, sauf si l'entrée le fait. Omettez cela et le premier changement tourne à l'archéologie.
Ce que chaque ligne du plan doit porter
Quatre champs rendent une entrée vérifiable : la longueur du préfixe, son propriétaire, la destination suivante du trafic et le composant qui distribue la valeur. Confrontez-les à la configuration en cours et tout désaccord apparaît de lui-même. Un prochain saut pointant vers un tunnel supprimé le mois dernier paraît faux immédiatement au lieu de se fondre dans l'ensemble.
Gardez les rôles sur des lignes séparées même quand deux d'entre eux partagent un préfixe aujourd'hui. Les fusionner transforme une séparation ultérieure en quelque chose qui se lit comme une nouvelle allocation plutôt qu'une correction.
| Entry | Fields to record | Why a reviewer needs it |
|---|---|---|
| Endpoint addresses | Prefix, owning side, session initiator | Firewall rules and peer config both read it |
| Tunnel interfaces | Prefix and length, next hop, interface name | Shows the path a packet actually takes |
| Client allocations | Pool range, size, distributing component | Shows room left before a redesign |
| Downstream networks | Prefix, site label, return route | Explains a reply that never arrives |
Là où le texte canonique et la syntaxe de configuration divergent
RFC 5952 fixe une seule forme textuelle pour une adresse : minuscules, pas de zéros initiaux, et la plus longue suite de groupes nuls compressée une seule fois. Utilisez-la dans les notes, les tickets et les journaux de changement pour que deux documents se comparent sans conversion. Les lecteurs qui rencontrent deux orthographes d'une même adresse se mettent à chercher une différence qui n'existe pas. La cohérence ici ne coûte rien et élimine toute une classe de fausses alertes.
Les fichiers de configuration suivent leurs propres règles, et ce ne sont pas des règles de lisibilité. Une adresse accompagnée d'un port exige des crochets même quand l'adresse nue n'en a pas, et une copie d'une note vers un fichier de configuration perd cette distinction sans avertir. Nommez la forme qu'utilise chaque champ, sinon le plan provoque l'erreur de transcription qu'il devait empêcher.
Deux notations conviennent tant que chacune est étiquetée. C'est le mélange non étiqueté qui invite à l'erreur.
Où apparaissent les plages qui se chevauchent et les chemins de retour manquants
Les chevauchements survivent aux autres erreurs parce que rien ne paraît faux tant que deux sites répondent de la même plage. Étiquetez le site et générez les préfixes uniques locaux par la procédure documentée au lieu de copier un exemple.
Une liste de clients n'explique jamais dans quel sens le retour voyage. Notez le chemin de retour de la passerelle du LAN à côté de la plage pair que le tunnel transporte, et la note explique un sous-réseau distant qui reçoit des requêtes et reste silencieux. Lancez les vérifications ci-dessous sur la machine et comparez-les à l'entrée. Un plan qui contredit ip -6 route est un plan que les gens cessent de lire.
ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0L'accessibilité n'est pas une autorisation, et un préfixe n'implique jamais une politique. Écrivez l'accès prévu à côté de la route à laquelle il s'applique. Sinon, le prochain lecteur traite une adresse du plan comme une permission d'atteindre tous les services situés derrière elle.
Comment le plan survit au troisième site
Marquez chaque préfixe comme délégué, attribué localement ou routé autrement. Pour tout ce qui peut bouger, nommez le processus qui le fait bouger. Listez ensuite les enregistrements DNS et les règles de pare-feu qui doivent changer dans la même fenêtre, parce qu'une mise à jour de préfixe qui s'arrête au routeur n'est qu'à moitié faite.
Après un changement, atteignez une ressource derrière chaque frontière touchée par le changement avant de modifier le document. Un plan qui décrit le réseau du mois dernier est pire qu'aucun, puisque les gens lui font confiance. Gardez les allocations retirées listées avec la date de leur disparition pour que personne ne les réattribue par accident. Les secrets restent hors du fichier ; un plan explique le réseau, il ne l'ouvre pas.
Rangez le plan là où les changements sont relus, à côté de la configuration qu'il décrit. Un document que personne ne relit pourrit plus vite que le réseau qu'il cartographie.