Scrivi il percorso dei pacchetti prima di configurare la VPN

La maggior parte delle installazioni VPN parte da un client e da un profilo, e quando il tunnel è attivo nessuno sa più dire quale pacchetto avrebbe dovuto attraversarlo. La prima pagina di lavoro costa meno della terza ora di debug: descrivi una connessione prevista da un capo all’altro, su carta, prima che esista un file di configurazione. L’esercizio di solito risolve una domanda che non ti eri ancora posto, come se il requisito sia un’uscita verso internet, un accesso remoto a una subnet o un collegamento tra due sedi.

Una connessione basta per iniziare. Tre pagine di topologia di solito nascondono la stessa risposta mancante.

Descrivi una richiesta, non un diagramma

Inizia dal mittente: un intervallo di indirizzi, una famiglia di indirizzi e l’applicazione che origina il traffico. Poi indica il prefisso di destinazione e il servizio su di esso, fino alla porta e al protocollo, perché una regola che consente la subnet ma non il servizio è una regola che non fa nulla. I due indirizzi sono il punto centrale, e tutto il resto è il meccanismo che deve essere d’accordo con loro.

Elenca il percorso in ordine: il collegamento fisico, l’endpoint VPN a ciascuna estremità, il tunnel stesso e la rete oltre. Scrivi i nomi delle interfacce se li conosci, perché questo dettaglio è ciò che trasforma una descrizione in qualcosa che potrai confrontare con una tabella di routing. Aggiungi l’indirizzo che ogni interfaccia usa sul lato tunnel. Senza questi due dati nessun altro può verificare il registro sul dispositivo.

Ora indica l’unica connessione prevista in una sola frase in cima alla pagina. Se quella frase ha bisogno della parola o, hai due progetti e dovresti trattarli separatamente.

Segui la risposta prima della richiesta

Un percorso che descrive solo la direzione in uscita è mezzo documento. Segui la risposta al ritorno e individua quale dispositivo conosce l’intervallo del mittente, se una traduzione cambia la sorgente in uscita e dove si prevede che entri il pacchetto di ritorno. È sulla risposta che falliscono la maggior parte delle installazioni, perché la richiesta è facile da osservare e la risposta no.

Annota esplicitamente ogni traduzione di indirizzi, compreso dove avviene e cosa vede poi l’estremità remota. Un peer che registra un indirizzo e instrada verso un altro sta descrivendo due progetti diversi.

Tratta la risoluzione dei nomi come uno scambio a sé, non come parte del percorso dell’applicazione. Un record interno può richiedere un resolver raggiungibile solo attraverso il tunnel, e un registro del percorso che si ferma al prefisso dell’applicazione non lo rivelerà. Lo stesso vale per qualsiasi convalida di certificati che dipenda dal raggiungimento di un’autorità interna.

Assegna un responsabile a ogni decisione

Per ogni rotta, regola del firewall, selettore e credenziale, annota quale configurazione la contiene e quale persona può modificarla. Un responsabile per riga è ciò che fa sopravvivere il documento alla prima richiesta di modifica, perché l’alternativa è un documento che descrive l’intento e una rete che descrive la storia.

Attenzione a due responsabili di un solo valore predefinito. Uno script client e un gestore di rete possono installare rotte entrambi senza che l’uno sappia dell’altro, e un’autorizzazione di ascolto sul gateway non è lo stesso permesso dell’inoltro. Entrambi i casi producono un registro del percorso corretto sulla carta e sbagliato sul cavo.

Quando un valore è deciso da un fornitore e non da te, dillo sulla stessa riga. Un prefisso delegato da un’azienda di hosting ha un processo di modifica diverso da uno scelto da te. Quella nota risparmia al prossimo ingegnere un ticket di supporto durante un incidente. Spiega anche perché una modifica che hai approvato non ha avuto effetto.

Descrivi cosa si rompe e come ti riprendi

Per ogni fase del percorso, indica cosa si ferma quando il tunnel scompare e quale connessione in uscita deve restare raggiungibile perché tu possa riparare. Un progetto che perde l’accesso di gestione insieme al tunnel è un progetto che richiede una visita in sede.

Il tunnel completo e il tunnel diviso appartengono a questa pagina come scelta esplicita e non come casella da spuntare, perché cambiano sia la modalità di guasto sia il percorso di ripristino.

Indica un test innocuo per ogni fase

Raggiungibilità dell’endpoint, stabilimento del tunnel, indirizzo privato, nome privato e autorizzazione dell’applicazione sono cinque osservazioni diverse, e ciascuna richiede un test che non possa essere confuso con un altro. Un ping al gateway dimostra al massimo le prime due. Una connessione alla porta dell’applicazione dimostra la quarta e la quinta solo se il nome è stato risolto tramite il resolver previsto.

Scrivi il test accanto alla fase che copre, compresi il comando e l’output atteso. Una pagina di percorsi precisi batte una pagina di comandi che non dice mai quali pacchetti dovevano influenzare.