Quali ruoli software richiede un gateway OpenVPN senza schermo

Una macchina dedicata a un gateway OpenVPN richiede un’installazione server supportata e il software per le attività che svolge davvero. Un menu di installazione che offre SSH, hosting web e altri ruoli server non è un elenco di prerequisiti di OpenVPN. Un’installazione senza schermo è del tutto ragionevole. L’importante è separare tre compiti: trasportare il tunnel, amministrare l’host ed emettere credenziali.

Questo è l’ordine di inventario che uso, con il controllo che chiude ogni passaggio.

1. Dare al servizio tunnel il proprio pacchetto e profilo

La guida del server OpenVPN di Ubuntu usa il pacchetto openvpn della distribuzione con una riga di comando e una configurazione del servizio. Lo stesso pacchetto funge da client Linux, e la configurazione sceglie il ruolo.

Ciò significa che installare una GUI client non è ciò che trasforma l’host in un server, e rimuoverla non è ciò che lo rende senza schermo. Annota quale profilo legge l’istanza in esecuzione, perché un secondo file di configurazione nella stessa directory può essere caricato senza che nessuno lo noti, e il demone riporta successo in entrambi i casi. Quando esistono due profili, il gestore dei servizi decide quale vince, e quella decisione appartiene ai tuoi appunti e non a una supposizione.

2. Decidere il percorso di amministrazione prima del tunnel

OpenSSH proviene da un pacchetto openssh-server separato e gira come servizio proprio. È utile quando un amministratore deve raggiungere la macchina via SSH, ma OpenVPN non ha bisogno di un server SSH per scambiare pacchetti VPN. Una console locale o un canale di gestione della piattaforma approvato è un altro percorso valido. Decidi su quale conti prima di cambiare routing o filtraggio, perché un nuovo tunnel non dovrebbe mai essere l’unico modo non testato di ripararsi da solo.

3. Emettere le credenziali dal proprietario approvato

L’esempio di Ubuntu installa easy-rsa accanto a OpenVPN per costruire una piccola PKI, che è un ruolo di emissione di credenziali e non un servizio tunnel in esecuzione. Se l’organizzazione ha già un processo di emissione approvato, usalo invece di creare una CA non correlata solo perché un tutorial ne include una. Tieni la chiave privata e il certificato del gateway distinti dalla chiave di firma della CA, e scegli deliberatamente la posizione di firma e di backup. Copiare ogni file PKI su ogni host non è un requisito software.

4. Lasciare i plugin desktop ai desktop

Un editor NetworkManager o un plugin di importazione ha uno scopo su una macchina che usa quel flusso di lavoro. Non è una funzione server aggiuntiva necessaria perché il gateway parla OpenVPN.

Scegli un solo proprietario per la connessione, e non avviare una seconda copia dello stesso profilo gestita dal desktop.

5. Accettare il gateway con un client reale

Meno pacchetti non è un gateway finito. Il server ha ancora bisogno di un listener approvato, identità, route, inoltro dove serve, una politica firewall ristretta e il percorso di ritorno previsto. Annota dove compaiono i suoi log e come vengono applicati gli aggiornamenti, perché queste due risposte decidono come verrà diagnosticato un guasto in seguito.

Un progetto con uscita su internet e un progetto con accesso a una rete privata hanno requisiti di inoltro diversi, quindi decidi quale stai costruendo prima di aprire qualsiasi cosa. Avvia un client approvato e controlla la risorsa prevista invece dell’indicatore del tunnel. Poi riavvia il servizio in modo controllato e conferma il percorso di avvio senza sorveglianza, perché un gateway che si alza solo mentre qualcuno guarda non è ancora distribuito.