Perché copiare la configurazione del server OpenVPN su una filiale non funziona

Copiare la configurazione del server che funziona, cambiare un paio di indirizzi e chiamarla profilo di filiale di solito produce una connessione. È il peggior esito, perché la filiale gira poi con il ruolo sbagliato, espone materiale che non dovrebbe lasciare il concentratore e lascia un'associazione di rotta che nessuno ricorda di aver creato. La connessione nasconde tre problemi insieme, e il tunnel sale prima che qualcuno li controlli.

Trattare la filiale come un pari con identità e ruolo di rete propri è ciò che rende corretto il profilo. La correzione non è una copia migliore, e il resto di questa pagina riguarda ciò che un client dovrebbe davvero tenere.

Due ruoli che sembrano un solo file

In modalità TLS i due pari hanno compiti complementari. Un lato ascolta, detiene il certificato e la chiave del server e decide quali client possono connettersi. L'altro lato avvia, verifica l'ascoltatore e presenta la propria identità.

Un file di server contiene direttive che su un client non hanno senso: un indirizzo di ascolto e una porta, un pool di indirizzi da distribuire e spesso un elenco di push per impostazioni che i client dovrebbero ricevere. Copiarle su una filiale produce un dispositivo che cerca di essere contemporaneamente ascoltatore e client.

La chiave privata è la parte che conta di più. Un client non deve mai portare la chiave privata del server, e non ha bisogno nemmeno della chiave di firma della CA. Un certificato di CA è materiale di fiducia pubblico; la chiave di firma appartiene a dove vengono emessi i certificati.

Cosa deve contenere un profilo di filiale

Un profilo di filiale ha bisogno dell'endpoint remoto e del trasporto, dell'identità del server attendibile, del certificato e della chiave propri della filiale, e delle rotte e impostazioni DNS che la filiale richiede davvero. Nient'altro è obbligatorio.

Tenere l'identità della filiale separata per sito. Due filiali che condividono un certificato significano che revocarne una disattiva l'altra, e i registri del concentratore non riescono a distinguerle. Un'identità per sito è ciò che fa funzionare sia la traccia di controllo sia la storia della revoca.

Attenzione ai flussi degli apparati. Il pacchetto Client Export di pfSense genera profili per i contesti Remote Access idonei, e il suo elenco di server include solo server configurati in una modalità Remote Access. Un server sito a sito di un'altra modalità non compare, e questa assenza è informazione, non un invito a copiare i segreti del server.

Se l'apparato non esporta il profilo che serve, usa il suo flusso client sito a sito documentato oppure costruisci il profilo dall'esempio supportato della versione installata. Esporta un backup del server verso la filiale solo se il piano è ripristinare un server, cosa che non è. Un backup porta anche il materiale privato del concentratore, quindi spostarlo su una filiale è una decisione di gestione delle chiavi, non un trasferimento di file. Tienilo sul concentratore e genera l'identità del client dove vengono emessi i certificati.

L'associazione tra pari e rete è separata

Un client di filiale che si connette con successo non può ancora far passare traffico per la sua LAN finché il concentratore non sa che questo pari possiede quel prefisso. Quell'associazione vive sul concentratore, legata all'identità del client, ed è separata dalla rotta propria della filiale verso le reti remote. Senza di essa, gli host della filiale sembrano raggiungibili nelle statistiche del tunnel e non lo sono in pratica. Il registro del concentratore è il luogo dove confermare se l'associazione è stata applicata.

Aggiungere una rotta nel sistema operativo del concentratore non è lo stesso che dire a OpenVPN quale client possiede il prefisso. Senza l'associazione per client, il pacchetto raggiunge l'interfaccia del tunnel e viene scartato perché nessun pari rivendica la destinazione.

Lato filiale, l'esigenza corrispondente è una rotta verso le reti che deve raggiungere, più un router LAN che sappia restituire il traffico alla filiale. La proprietà lato server e le rotte di destinazione lato client sono oggetti distinti, e un tunnel che funziona dimostra solo il primo salto. Annota entrambe nelle note di passaggio della filiale, perché l'ingegnere successivo ne troverà solo una.

Dimostrare che la filiale è il pari che credete

Verificate l'identità prima di verificare il traffico. Il registro del concentratore dovrebbe mostrare il nome comune del certificato della filiale, e l'indirizzo ricevuto dal client dovrebbe corrispondere al pool o all'assegnazione fissa che intendevate. Se il registro mostra un altro nome, il profilo porta l'identità di qualcun altro.

Poi verificate l'associazione inviando una richiesta da un host della filiale a una risorsa lato concentratore e confermate che riesce con l'indirizzo di origine atteso. Provate una destinazione che la filiale non deve raggiungere e confermate che fallisce, perché una rotta permissiva che funziona per caso non è la stessa cosa di una politica corretta.

Infine revocate l'identità della filiale e confermate che la connessione fallisce mentre il certificato del concentratore e gli altri siti continuano a funzionare. Se la revoca rompe il concentratore, ruoli e identità sono stati condivisi da qualche parte, e questo è il risultato che vale la pena riportare alla progettazione.

Una filiale finita è una con un'identità documentata, un profilo solo client, un'associazione tra pari e rete sul concentratore e un percorso di ritorno provato. Invertire il testo in un file di server non ve ne dà nessuna.