Come mantenere leggibile un piano di indirizzi IPv6 per VPN un anno dopo
Un piano leggibile dice quale prefisso appartiene a quale sito e come tornano le risposte. Annota ruoli, notazione, delega e rotte di ritorno accanto a ogni voce.
Due domande decidono se un piano di indirizzi merita il suo posto: quale prefisso appartiene a quale sito e come una risposta esce da quel sito. Rispondi a entrambe in un colpo solo e chi fa manutenzione può cambiare un peer senza interrogare nessuno. Tutto il resto del documento esiste per sostenere quelle due risposte. Ciò che non ne sostiene nessuna è decorazione.
A cosa deve rispondere un lettore prima di toccare un peer
La compressione fa sembrare gli indirizzi ordinati, e l'ordine non è struttura. Struttura è sapere quale intervallo ha delegato il provider, quale hai scelto, quale è un pool di client e quale sta dietro a un sito.
Scrivi per il collega che arriva il trimestre prossimo e deve aggiungere un secondo sito. Nulla nella pagina gli dice da dove viene un prefisso, a meno che la voce non lo faccia. Salta questo passaggio e il primo cambiamento diventa archeologia.
Cosa deve portare ogni riga del piano
Quattro campi rendono una voce verificabile: quanto è lungo il prefisso, chi lo possiede, dove va il traffico dopo e quale componente distribuisce il valore. Confrontali con la configurazione in esecuzione e ogni disaccordo emerge da solo. Un next hop puntato a un tunnel rimosso il mese scorso sembra sbagliato subito invece di confondersi con il resto.
Tieni i ruoli su righe separate anche quando due di essi condividono un prefisso oggi. Fonderli trasforma una separazione successiva in qualcosa che si legge come una nuova assegnazione anziché come una correzione.
| 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 |
Dove testo canonico e sintassi di configurazione divergono
RFC 5952 fissa una sola forma testuale per un indirizzo: minuscole, niente zeri iniziali e la sequenza più lunga di gruppi zero compressa esattamente una volta. Usala in note, ticket e registri delle modifiche così due documenti si confrontano senza conversione. I lettori che incontrano due grafie dello stesso indirizzo iniziano a cercare una differenza che non c'è. La coerenza qui costa poco ed elimina un'intera classe di falsi allarmi.
I file di configurazione obbediscono alle proprie regole, e non sono regole di leggibilità. Un indirizzo abbinato a una porta richiede le parentesi anche quando l'indirizzo nudo non le richiede, e una copia da una nota a un file di configurazione perde questa distinzione senza avvisare. Assegna un nome alla forma usata da ogni campo, altrimenti il piano provoca proprio l'errore di trascrizione che doveva prevenire.
Due notazioni vanno bene purché ciascuna sia etichettata. È la mescolanza non etichettata che invita all'errore.
Dove compaiono intervalli sovrapposti e percorsi di ritorno mancanti
La sovrapposizione sopravvive agli altri errori perché nulla sembra sbagliato finché due siti rispondono per lo stesso intervallo. Etichetta il sito e genera prefissi univoci locali con la procedura documentata invece di copiare un esempio.
Un elenco di client non spiega mai in che direzione viaggia la risposta. Annota il percorso di ritorno del gateway LAN accanto all'intervallo peer che il tunnel trasporta, e la voce spiega una sottorete remota che riceve richieste e resta in silenzio. Esegui i controlli qui sotto sulla macchina e confrontali con la voce. Un piano che contraddice ip -6 route è un piano che la gente smette di leggere.
ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0
La raggiungibilità non è autorizzazione, e un prefisso non implica mai una politica. Scrivi l'accesso previsto accanto alla rotta a cui si applica. Altrimenti il lettore successivo tratta un indirizzo del piano come permesso di raggiungere ogni servizio dietro di esso.
Come il piano sopravvive al terzo sito
Segna ogni prefisso come delegato, assegnato localmente o instradato in altro modo. Per tutto ciò che può spostarsi, nomina il processo che lo sposta. Poi elenca i record DNS e le regole del firewall che devono cambiare nella stessa finestra, perché un aggiornamento del prefisso che si ferma al router è fatto a metà.
Dopo un cambiamento, raggiungi una risorsa dietro ogni confine toccato dal cambiamento prima di modificare il documento. Un piano che descrive la rete del mese scorso è peggio di nessuno, dato che le persone si fidano. Tieni elencate le assegnazioni ritirate con la data in cui sono sparite, così nessuno le riemette per sbaglio. I segreti restano fuori dal file; un piano spiega la rete, non la apre.
Conserva il piano dove le modifiche vengono riviste, accanto alla configurazione che descrive. Un documento che nessuno rilegge marcisce più in fretta della rete che mappa.