Come dimensionare lo spazio di indirizzamento per una VPN multi-sito

Quanto debba essere grande la sottorete VPN non ha risposta finché non si nominano gli indirizzi che si stanno contando. In un progetto sono i due estremi di un collegamento tunnel numerato, in un altro è la LAN dell’ufficio dietro un tunnel basato su criteri, e in un terzo è l’infrastruttura riservata di un gateway gestito. Tre oggetti, tre budget, e la maggior parte degli errori di dimensionamento nasce dal riempire una colonna con il numero di un’altra.

Quattro ruoli, quattro domande diverse

Il trasporto esterno è l’indirizzo a cui si connette un peer, quindi la sua dimensione segue il vostro indirizzamento pubblico o quello del provider, mai il numero di dispositivi dietro. I collegamenti tunnel interni esistono solo nei progetti che numerano un’interfaccia virtuale, e lì il conteggio segue le adiacenze della topologia. I prefissi delle LAN protette seguono le reti reali e il loro piano di crescita. L’infrastruttura riservata dal provider segue ciò che documenta il servizio gestito.

Solo il terzo di questi ha un rapporto con quante postazioni portatili contiene l’ufficio. Proprio questa confusione spiega la maggior parte delle discussioni.

Scrivete i quattro ruoli come colonne separate prima di aprire una calcolatrice. Ognuno riceve la propria allocazione, il proprio responsabile e la propria ipotesi di crescita, e nessuno eredita la dimensione di un altro. Quando un progetto non ha un collegamento interno numerato, quella colonna è vuota anziché piccola, e una colonna vuota è un fatto che vale la pena registrare per il prossimo revisore.

Contare i blocchi: quanto costa davvero una /30

Un collegamento punto a punto richiede due indirizzi e consuma un blocco la cui dimensione dipende dalla piattaforma. Una /30 contiene quattro indirizzi, due dei quali di solito sono utilizzabili, quindi dodici collegamenti consumano quarantotto indirizzi nel piano mentre offrono ventiquattro estremi. Una /31 contiene due indirizzi ed entrambi sono utilizzabili, il che dimezza l’aritmetica, ma solo dove entrambi gli estremi lo accettano.

RFC 3021 definisce il modello a due indirizzi, e il supporto è una proprietà degli estremi e del servizio, non delle buone intenzioni. Un’API del provider può imporre il proprio requisito di maschera su un’opzione di tunnel interno, e un RFC generale non annulla un vincolo documentato. Verificate cosa dichiara la vostra piattaforma prima di riassumere il budget, perché la differenza tra quarantotto e ventiquattro indirizzi decide se il piano entra nell’intervallo riservato. Fate l’aritmetica invece di fidarvi alla fine di una lunga giornata.

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

Moltiplicate solo dopo che la topologia è stabilita. Dodici collegamenti separati e un overlay multipunto con dodici partecipanti producono totali molto diversi dallo stesso numero di sedi.

La sottorete del gateway gestito non è un pool di client

Un servizio gestito spesso riserva una sottorete per la propria infrastruttura di gateway, e quella sottorete viene consumata dal servizio anziché consegnata ai client. Ha una dimensione documentata, talvolta un nome documentato, e nessun rapporto con quante utenze si collegano. Trattarla come il pool di indirizzi per le macchine remote produce un progetto che si esaurisce al primo mattino affollato.

Leggete il requisito del provider come un costo fisso, come trattereste un’unità rack. Non fa parte del budget del prefisso protetto.

La stessa lettura vale per i nomi. Una sottorete il cui scopo documentato è l’infrastruttura di gateway è infrastruttura per convenzione in quel servizio, e rinominarla per adattarla al vostro schema rompe la distribuzione invece di migliorare il diagramma. Mantenete i nomi e le dimensioni del provider, e spendete il vostro schema di numerazione sulle parti che controllate.

Documentate il piano perché sopravviva alla seconda sede

Un piano che vive nella testa di un solo ingegnere fallisce alla prima sovrapposizione tra un prefisso di ufficio e l’intervallo predefinito di un router domestico. Pubblicate le allocazioni con i loro responsabili e indicate quale estremo di ogni collegamento assegna quale indirizzo. Le rotte o i selettori vanno comunque annunciati, perché numerare un collegamento interno non pubblica una LAN da solo.

Registrate l’ipotesi di crescita dietro ogni blocco, perché è la parte che nessun lettore successivo può ricostruire dai soli indirizzi.

Poi provate il piano contro i casi scomodi: una sede che arriva con un prefisso che usate già, un collegamento il cui estremo remoto è gestito da qualcun altro, e una regione il cui requisito del provider differisce dal primo che avete documentato. Se uno di questi impone una riprogettazione, quello che avevate era un diagramma e non una politica. Un piano che li sopravvive è abbastanza breve da stare nel repository accanto alla configurazione del tunnel, che è esattamente dove la persona successiva lo cercherà.