Pianificate le sottoreti prima di una VPN tra sedi: rinumerate o traducete

Due uffici usano entrambi 192.168.1.0/24 perché nessuno ha pianificato altro, e ci si aspetta che il tunnel risolva la cosa. Non può: un router non può far sì che lo stesso indirizzo privato significhi due luoghi diversi. Il lavoro che lo impedisce avviene prima che venga digitato il primo parametro del tunnel.

Inventariate ogni gamma, comprese quelle che avete dimenticato

Raccogliete le LAN, i segmenti dei server, i pool di client per l'accesso remoto, le gamme VPC nel cloud e qualsiasi rete di container o overlay a cui gli host devono arrivare. I pool di client sono quelli che la gente dimentica, e si sovrappongono a una gamma d'ufficio sorprendentemente spesso perché entrambi sono stati scelti dallo stesso valore predefinito. Includete la rete di gestione e qualsiasi segmento fuori banda.

Annotate proprietario, gateway, scopo e se il prefisso deve essere raggiungibile dall'altra sede. Un prefisso che non deve mai attraversare il tunnel non deve essere univoco, e saperlo riduce il lavoro di rinumerazione.

Trattate IPv6 a parte, perché il suo piano e le sue sovrapposizioni sono indipendenti.

Confrontate i prefissi, non gli indirizzi familiari

Due reti con indirizzi host diversi possono comunque sovrapporsi, perché la sovrapposizione è una proprietà delle maschere e non dei numeri che la gente ricorda. 10.20.0.0/16 contiene 10.20.30.0/24 che qualcuno lo dica ad alta voce o no. Confrontate coppie di prefissi complete e verificate gli aggregati rispetto alle reti più piccole che contengono. Per questo il controllo appartiene a un foglio di calcolo e non alla testa di qualcuno.

Lo stesso controllo vale per il pool di client della VPN stessa e per qualsiasi gamma tradotta che pensate di introdurre, perché una gamma tradotta che va in collisione è peggio della sovrapposizione originale.

Basta una tabella di prefissi con maschere; un diagramma senza maschere no.

Decidete cosa deve davvero attraversare

Una sede può contenere trenta sottoreti mentre una rete di servizio ha bisogno dell'accesso remoto. Partite da quel requisito e annunciate solo ciò che serve, perché annunci più piccoli e regole di accesso corrispondenti sono più facili da rivedere e più difficili da allargare per errore. Annunciare ogni gamma privata in uso è un'abitudine che trasforma un tunnel in un ponte. Più stretto è l'annuncio, minore è il raggio d'impatto di un errore futuro.

Il DNS privato deve restituire indirizzi che i client previsti possono raggiungere, quindi un nome che punta a una gamma non annunciata o sovrapposta resta rotto anche quando la risoluzione riesce.

Scrivete la lista di accesso prima della configurazione del tunnel, non dopo che fallisce.

Rinumerate o traducete, e conoscete il costo

La rinumerazione di una rete è di solito il rimedio più chiaro a lungo termine, e tocca prenotazioni, dispositivi, DNS, regole del firewall e tutto ciò che ha un indirizzo inciso in una configurazione. La traduzione di una gamma di accesso è l'alternativa quando la rinumerazione non è pratica, e costa l'identità di origine più una classe di protocolli che incorporano indirizzi nei payload. Sceglietene una e portatela a termine, perché una rete a metà rinumerata è peggio di entrambe le opzioni.

Qualunque scegliate, documentate sia l'indirizzo originale sia quello presentato, perché ogni successiva conversazione di risoluzione dei problemi ha bisogno di entrambi.

Un aggiramento senza percorso di ritorno non è un aggiramento.

Usate una matrice di rotte come test di accettazione

Concludete con una matrice: prefisso locale, prefisso remoto, servizio consentito e gateway di ritorno. Quella tabella è il test di accettazione quando il tunnel sale, ed è anche il documento che leggerà l'ingegnere successivo. Testate da host reali nelle sottoreti scelte e non dai gateway.

Un ping tra indirizzi del tunnel prova che il tunnel esiste e nulla del piano di indirizzamento dietro.

Tenete la matrice con la configurazione del tunnel, e la prossima aggiunta di sede partirà dai dati invece che dalla memoria. La guida all'inoltro di strongSwan copre il lato gateway una volta che il piano esiste.