Dopo lo script di configurazione, qualcuno deve essere responsabile del server VPN
Lo script può costruire il server, ma non può assumere la politica di accesso, il percorso di aggiornamento o il rollback. Definite il passaggio di consegne prima di eseguirlo.
Due lavori diversi vengono venduti come uno: trasformare una macchina in un server VPN e aggiungere un client VPN a un portatile che deve unirsi al gateway di qualcun altro. Uno script di configurazione risponde al primo e non può rispondere al secondo, qualunque cosa suggerisca il suo README. Prendete il progetto setup-ipsec-vpn come esempio concreto: costruisce un server IPsec/L2TP, Cisco IPsec o IKEv2 su un host Linux supportato con Libreswan e xl2tpd. È un contratto di distribuzione per un server, non una ricetta generale per qualsiasi macchina. Decidete quale lavoro avete prima che lo script venga eseguito, perché tutto ciò che segue riguarda il server.
Siate onesti sull’host
Una macchina che termina anche qualcos’altro, o il cui firewall è gestito da un piano di controllo cloud invece che dal sistema operativo, è un’installazione diversa da una macchina virtuale pulita. Annotate il protocollo che abilitate e la versione che usate, poi verificate entrambi rispetto all’elenco di supporto del progetto, non rispetto a un post di blog dell’anno scorso.
Abilitare il servizio non apre la strada verso di esso. Per IPsec la rete davanti all’host deve consentire UDP 500 e 4500 e, a seconda della distribuzione, il protocollo ESP stesso. Uno script che termina con successo dietro un gruppo di sicurezza che scarta il protocollo 50 ha prodotto un server che nessuno può raggiungere, e nulla nell’output dell’installer lo dirà.
Cosa prende davvero in carico l’installer
Aspettatevi un file di configurazione e di segreti IPsec, una configurazione del demone L2TP, opzioni PPP e unità systemd che ora possiedono quelle porte. Il README del progetto afferma che i file di configurazione esistenti vengono salvati prima delle modifiche, il che è utile e non è la stessa cosa di un backup dell’host. Decidete quali componenti saranno aggiornati dai pacchetti della distribuzione e quali rieseguendo o riscrivendo lo script, perché sono due percorsi di manutenzione con modalità di errore diverse.
Fissate la revisione che avete approvato. Un URL di download che serve il ramo predefinito attuale può restituire contenuti diversi il mese prossimo, quindi annotate il commit o la release che avete eseguito e conservatene una copia. Quella sola abitudine trasforma uno stato non attribuibile in qualcosa su cui una seconda persona può ragionare alle due di notte.
Cosa lo script non può darvi
L’automazione produce un’installazione funzionante e si ferma lì. Non decide quali risorse private il tunnel debba raggiungere, che è una questione di politica di accesso su cui il firewall dell’host e la rete a monte hanno entrambi un parere. Non decide chi riceve le credenziali, come vengono consegnate né come viene rimosso l’accesso di una persona quando se ne va. E non decide come viene ripristinata la macchina dopo un aggiornamento difettoso, che è la parte che di solito si scopre nel momento peggiore possibile.
I profili client e i segreti mostrati sono materiale di accesso, non registri di installazione. Un profilo generato incollato in un canale condiviso è un account, e lo stesso standard vale per le schermate del riepilogo di configurazione. Tenete un inventario protetto dello stato di identità necessario a ripristinare il servizio e annotate quali di quelle credenziali sono state revocate da allora.
Il primo client è il test di accettazione
Accettate la distribuzione da un client autorizzato, con il protocollo che avete realmente abilitato. Verificate che il nome privato si risolva, che il percorso di ritorno funzioni, che una riconnessione si comporti correttamente e che una destinazione fuori dall’insieme consentito venga rifiutata. Un accesso riuscito da un’altra applicazione client non è prova di quella che avete distribuito.
Se la combinazione che volete non è più supportata, scegliete un percorso mantenuto prima dell’installazione. Rianimare una vecchia release, indebolire l’autenticazione o rieseguire uno script inspiegato sono rinvii, non piani di manutenzione, e ciascuno rende il passaggio di consegne più difficile.
Scrivete la pagina di passaggio
Tenetela breve: il server, la revisione che l’ha costruito, le porte necessarie, i componenti e i loro responsabili degli aggiornamenti, le risorse consentite, il percorso delle credenziali e la procedura di ripristino. Aggiungete la via console o fuori banda che userete quando è stata una modifica al tunnel a rompere l’accesso. Allora la persona successiva eredita un servizio invece di un comando che teme di eseguire due volte.
Rivedete quella pagina quando cambia l’host, e non solo quando qualcosa si rompe. Un documento di passaggio che non viene mai letto è un documento che ha smesso silenziosamente di essere vero.