Manuale operativo: integrare due clienti OpenVPN separatamente

Due clienti su un solo host sembrano un blocco server in più e una seconda porta. Diventa un altro progetto quando elenchi tutto ciò che un cliente possiede davvero: un listener, un pool di tunnel, un’identità, file di fiducia, route e un calendario di revoca. Salta uno di questi elementi e il secondo cliente eredita silenziosamente una parte del primo. Crea una scheda per cliente e compilala prima che il primo client si connetta.

Assegna una scheda delle risorse completa per cliente

Prenota l’intero insieme: porta pubblica, sottorete del tunnel, percorso di configurazione, destinazione dei log, nome dell’istanza di servizio e dispositivo. È nominarli come gruppo che impedisce la classica copia di un file funzionante che contiene ancora il pool o l’interfaccia del primo cliente. I valori sono esempi, non porte riservate, quindi controlla cosa usa già l’host. Un servizio che parte non è la stessa cosa di un cliente completo.

Tieni la scheda accanto alla configurazione e aggiornala ogni volta che un valore cambia. La documentazione che si allontana dalla realtà è peggio di nessuna documentazione.

Mantieni il materiale di fiducia all’interno di ogni cliente

Un’autorità emittente separata per cliente rende il confine facile da ragionare e tiene la chiave di firma fuori dall’host esposto a Internet. Anche una radice condivisa può funzionare, ma un’ancora comune non trasforma due servizi in un unico dominio di appartenenza. Decidi quali catene accetta ogni listener e quali identità client autorizza, poi annota entrambe. Non rimuovere certificati da una catena per tentativi ed errori finché qualcosa non si connette.

La chiave privata del server stesso appartiene a un file protetto per cliente, non a una directory di modelli replicata insieme alla configurazione.

Separa le reti oltre ai processi

Due processi su due porte condividono ancora un host e una tabella di routing se non li separi. Conferma cosa è in ascolto prima di fidarti del progetto.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

Il controllo del listener mostra quale processo possiede ogni porta pubblica, e la verifica mostra se un certificato client si concatena all’ancora prevista. Nessuno dei due output dimostra che il client di A non possa raggiungere la sottorete di B, quindi definisci la politica di origine e destinazione, le route di ritorno e qualsiasi servizio condiviso di proposito. Gli spazi dei nomi di rete o i container separano i contesti di routing e riducono la commistione accidentale, ma non sono un confine completo di tenant da soli. Scegli un meccanismo di isolamento più forte quando il modello di minaccia lo richiede.

Consegna la revoca prima della cessione

Un deployment di certificati non è completo finché la revoca non ha un percorso di consegna. Controlla l’emittente e la finestra di validità della CRL come parte dell’onboarding.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

L’ispezione della CRL riporta quando l’elenco è stato emesso e quando scade, e lo stato del servizio conferma che l’istanza che lo legge è in esecuzione. Aggiorna l’elenco secondo il calendario della politica di emissione anche quando non è stato revocato nulla di nuovo, perché una CRL scaduta può rifiutare ogni client. Pubblica un file completo invece di lasciare che i lettori incontrino una scrittura parziale, e convalida la firma prima del deployment. Registra chi possiede l’emissione, l’esercizio dell’endpoint e la dismissione, così che spegnere il cliente A non disturbi B.

Poi esegui la coppia di accettazione: un client consentito raggiunge il proprio servizio, e una credenziale di A viene rifiutata dal listener di B. Questo è il confine espresso come test.