Pianificate gli intervalli di indirizzi VPN privati prima che i siti entrino in collisione

Due siti che usano entrambi 192.168.1.0/24 possono raggiungere internet e comunque non raggiungersi. Il gateway non segnala alcun errore; installa una sola rotta per quel prefisso e invia ogni pacchetto al peer che l’ha rivendicato per primo. Nulla nell’handshake, nella lista dei cifrari o nella metrica dell’interfaccia dice quale peer sbaglia. La pianificazione degli indirizzi è la parte del progetto che risolve la questione prima che qualcuno si connetta.

Inventariate ogni spazio che deve essere raggiungibile

Annotate gli intervalli che devono essere instradati, non solo quelli che state configurando. Significa LAN dei siti, pool di clienti VPN, sottoreti cloud, reti di gestione e fuori banda, segmenti di laboratorio e le reti da cui gli utenti si collegano di solito da casa. Un router domestico fornito come 192.168.1.0/24 non è ipotetico, e lo stesso prefisso compare in hotel e centri congressi. L’inventario è una tabella di prefisso, proprietario e scopo, ed è l’unico artefatto che impedisce di assegnare due volte lo stesso intervallo.

Aggiungete i prefissi che prevedete nell’anno successivo, perché un piano che copre solo oggi fallisce al primo nuovo sito. Segnate in ogni riga chi può modificarla, non solo chi la possiede.

È il riuso che rende difficile tutto questo: lo spazio privato è finito e ogni organizzazione considera 10.0.0.0/8 come proprio. Un piano non può promettere che nessuna LAN ospiti futura finirà su uno dei vostri prefissi, quindi il progetto deve dire cosa succede quando accade. Due regole fanno la maggior parte del lavoro. Mettete i pool di clienti in un unico blocco contiguo che potete riassumere, e non assegnate mai un intervallo che un altro team instrada già. Tutto il resto è un registro che qualcuno tiene aggiornato.

Perché una sovrapposizione sconfigge la tabella di instradamento

Una rotta è un prefisso più un prossimo salto, e l’inoltro sceglie il prefisso corrispondente più lungo. Quando due peer rivendicano entrambi 192.168.1.0/24, la tabella ne tiene una sola voce, così il traffico di entrambi i siti esce dallo stesso tunnel. Il secondo sito non è configurato male; è irraggiungibile perché il primo risponde per gli stessi indirizzi. Nessuna metrica può separarli, perché la corrispondenza avviene prima che le metriche siano consultate.

Il guasto è asimmetrico e facile da leggere male. Gli host del sito A raggiungono il gateway e alcuni servizi, mentre quelli del sito B non rispondono a nulla, e il registro mostra un tunnel sano in entrambe le direzioni. Quel modello è una collisione di indirizzi e non un guasto di autenticazione o del firewall, e confermarlo richiede un dump della tabella confrontato con l’inventario.

Dimensionate deliberatamente il pool di clienti e gli intervalli dei siti

Un pool di clienti VPN è un intervallo che il gateway distribuisce un indirizzo alla volta, quindi la sua dimensione limita la concorrenza. Un /24 contiene 254 indirizzi utilizzabili, il che è generoso per un team piccolo e stretto per una filiale che esegue container; un /22 non costa nulla in più dentro lo spazio privato e toglie la discussione. Mantenete il pool contiguo e lontano da ogni LAN di sito, così la rotta riassuntiva verso i clienti non inghiotte mai un sito. Riservate l’intervallo anche mentre il pool è vuoto, perché un intervallo non scritto è quello che assegnerà l’ingegnere successivo.

I siti ricevono intervalli dimensionati per gli host previsti più la crescita, allineati su un confine che si riassume in modo pulito. Gli spazi deliberati tra assegnazioni non costano nulla e comprano spazio per aggregare più avanti.

Poi controllate la direzione che le persone dimenticano: il percorso di ritorno. Ogni router di sito ha bisogno di una rotta verso il pool di clienti, e il concentratore ha bisogno di una rotta verso ogni prefisso di sito che serve. Una tabella di prefissi ordinata senza via di ritorno al pool resta un progetto rotto, e il sintomo è una connessione unidirezionale che non risponde a nulla. Tenete entrambe le direzioni nella stessa tabella e riesaminatela ogni volta che si aggiunge un sito.

La traduzione e la rinumerazione risolvono problemi diversi

Quando una sovrapposizione esiste già, ci sono due opzioni oneste e una disonesta. La rinumerazione elimina la collisione in modo permanente e costa una finestra di manutenzione più ogni indirizzo codificato che avete dimenticato. La traduzione degli indirizzi mappa l’intervallo privato di un lato in un altro intervallo al bordo del tunnel, il che lascia entrambi i siti intatti ma aggiunge stato, rompe i protocolli che incorporano indirizzi e rende i registri più difficili da leggere. L’opzione disonesta è una rotta host verso un singolo server, che supera una prova e fallisce tutto il resto.

Scegliete in base al controllo e alla durata. Un sito che possedete e potete pianificare appartiene al percorso della rinumerazione; una rete partner che non potete toccare, usata per una sola applicazione, è candidata alla traduzione con una mappatura documentata. Scrivete quella mappatura, perché una traduzione che esiste solo dentro un file di configurazione scompare nel momento in cui il file viene sostituito.

Testate dal lato remoto prima di distribuire

Testate da una rete che non ospita il gateway, perché la LAN del gateway nasconde la maggior parte degli errori di instradamento. Collegate un client dietro un normale router domestico, poi raggiungete un servizio su ogni sito e uno dentro il pool di clienti. Testate anche la direzione inversa, da un host di sito al client, perché i percorsi di ritorno falliscono in modo indipendente. Un test che fa solo ping al gateway dimostra che il tunnel è attivo e nulla di più.

Tenete intervalli, proprietari e mappature di traduzione in un unico registro condiviso che il sito successivo legge prima di assegnare qualsiasi cosa. Riesaminatelo quando si aggiunge un sito, e trattate un intervallo non documentato come un difetto e non come una sorpresa.

Il registro è il risultato. Un piano che vive nella memoria di tre persone fallisce la prima volta che una di loro è in ferie, e una sovrapposizione trovata in produzione costa più di quanto sarebbe costata la tabella.