Tunnel OpenVPN

Tunnel OpenVPN#

I tunnel net-to-net di OpenVPN stabiliscono connessioni sicure tra due reti separate, come ad esempio le filiali di un’azienda, tramite internet. Queste connessioni utilizzano i protocolli SSL/TLS per la cifratura e l’autenticazione, garantendo la riservatezza e l’integrità dei dati.

La connessione è gestita da 2 firewall NethSecurity, ciascuno con un ruolo specifico. Quando si crea una connessione OpenVPN net2net, un firewall avrà il ruolo di server mentre l’altro NethSecurity si collegherà come client. Un NethSecurity può essere contemporaneamente server e client per tunnel differenti; tutti i tunnel utilizzano la modalità routed di OpenVPN.

L’interfaccia dei tunnel OpenVPN è stata progettata per una connessione semplice tra due dispositivi NethSecurity. Per questo motivo, è volutamente limitata e non espone tutti i parametri che possono essere configurati con OpenVPN per collegarsi a un dispositivo di terze parti. Per connettersi a un dispositivo di terze parti, si consiglia di utilizzare il protocollo IPsec.

Configurazione#

Per collegare due firewall tramite un tunnel OpenVPN, è necessario prima configurare il firewall server e successivamente quello client. Il server deve disporre di almeno un indirizzo IP pubblico per essere raggiungibile dal client, mentre il client può anche non avere indirizzi IP pubblici. La configurazione del firewall server richiede solo pochissimi parametri; ove possibile, tutti i parametri sono già compilati automaticamente per evitare errori e velocizzare il processo. Una volta configurato il firewall server, sarà possibile scaricare la configurazione client da importare sull’altro firewall.

Procedere come segue:#

Accedere alla pagina dei tunnel OpenVPN, spostarsi sulla scheda Tunnel server e fare clic su Aggiungi tunnel server.

Inserire tutti i campi obbligatori, ma si noti:

  • Endpoint pubblici è un elenco di indirizzi IP o nomi host che i client possono utilizzare per raggiungere il server tunnel OpenVPN

  • Reti locali è un elenco di reti locali che saranno accessibili dal server remoto. Se la topologia è impostata su p2p, lo stesso elenco verrà riportato nel campo Reti remote del client.

  • Reti remote, è un elenco di reti dietro il server remoto che saranno accessibili dagli host nella rete locale

  • Dopo che la configurazione è stata salvata, fare clic sull’azione Scarica e selezionare Client configuration

  • Accedere al firewall client, al tunnel OpenVPN, spostarsi nella scheda Tunnel client, fare clic su Importa configurazione

Topologia#

I tunnel possono avere due tipi di topologie: subnet e p2p (Point to Point).

Subnet#

Subnet è la topologia predefinita e quella consigliata: nella topologia subnet, il server accetterà le connessioni e agirà come server DHCP per ogni client connesso.

In questo scenario il server autenticherà i client utilizzando certificati TLS e invierà le route locali al client remoto.

P2P#

In una topologia p2p, l’amministratore deve configurare un server per ciascun client; in questo scenario, l’unico metodo di autenticazione supportato è il PSK (Pre-Shared Key).

  • assicurarsi di scambiare il PSK utilizzando un canale sicuro (come SSH o HTTPS)

  • l’amministratore deve selezionare un IP per entrambi gli endpoint

  • le route verso le reti remote devono essere configurate su ciascun endpoint

Funzionalità avanzate#

L’interfaccia web consente la configurazione di funzionalità avanzate come:

  • Host remoto multipli: è possibile specificare più indirizzi di server remoti per la ridondanza; il client OpenVPN tenterà di connettersi a ciascun host nell’ordine indicato

  • Protocollo: OpenVPN è progettato per funzionare in modo ottimale su UDP, ma la compatibilità con TCP è prevista per situazioni in cui UDP non può essere utilizzato.

  • Compressione: se abilitata, i dati inviati attraverso il tunnel VPN verranno compressi. Questa opzione è disabilitata per impostazione predefinita anche per motivi di sicurezza. La compressione è raramente essenziale al giorno d’oggi, poiché il traffico internet è generalmente già altamente compresso e ottimizzato.

  • Digest: l’algoritmo di digest utilizzato per trasformare un blocco di dati di dimensione arbitraria in un output di dimensione fissa. Se non viene selezionato esplicitamente, il server e il client tenteranno di negoziare il miglior digest disponibile su entrambi i lati.

  • Cipher: l’algoritmo crittografico utilizzato per cifrare tutto il traffico. Se non viene selezionato esplicitamente, il server e il client tenteranno di negoziare il miglior cipher disponibile su entrambi i lati.

  • Imporre una versione minima di TLS: Consente di scegliere una versione minima di TLS; in tal caso, saranno consentite solo le connessioni provenienti da dispositivi che utilizzano una versione uguale o superiore a quella selezionata.

Tunnel OpenVPN multipli#

Se un NethSecurity deve agire come server VPN per più firewall remoti, è necessario creare un tunnel OpenVPN dedicato per ciascun peer remoto. Il modello supportato dall’interfaccia utente e raccomandato prevede una coppia server/client per ogni connessione site-to-site; ad esempio, un firewall centrale collegato a tre firewall remoti dovrebbe avere tre tunnel server OpenVPN separati, ciascuno con la propria configurazione client importata sul relativo firewall remoto.

Questo approccio consente di gestire ciascun tunnel in modo indipendente, con configurazione, certificati, rotte, stato, monitoraggio e risoluzione dei problemi separati. Inoltre, impedisce che eventuali problemi su una connessione remota influenzino la gestione operativa delle altre.

Non utilizzare un singolo tunnel server OpenVPN condiviso da più client remoti per configurazioni site-to-site gestite dall’interfaccia utente.

Problema MTU e Frammentazione dei Pacchetti#

Per impostazione predefinita, le istanze del tunnel OpenVPN create su NethSecurity vengono inizializzate con i seguenti valori:

  • Unità Massima di Trasmissione - tun_mtu = 1500

  • Dimensione massima del segmento - mssfix = 1450.

Questi sono i valori predefiniti di OpenVPN, generalmente adatti alla maggior parte degli ambienti di rete, che dovrebbero essere modificati solo in caso di problemi di connettività dovuti alla frammentazione dei pacchetti.

Gli utenti VPN possono riscontrare problemi di connettività a causa della frammentazione dei pacchetti. L’interfaccia LAN ha un MTU di 1500 per impostazione predefinita, ma quando i pacchetti vengono criptati per la trasmissione tramite VPN, la dimensione aumenta, causando la perdita di pacchetti. Per risolvere questo problema, è necessario abbassare l’MTU e l’MSS sul tunnel OpenVPN. Non sono richieste modifiche lato client.

I valori di MTU e MSS possono essere regolati direttamente nell’interfaccia utente, sia durante la creazione iniziale del tunnel sia successivamente modificandolo tramite il pulsante Modifica, nella sezione Opzioni avanzate del drawer. In alternativa, è possibile regolare i due valori di configurazione utilizzando l’interfaccia a riga di comando sul firewall:

uci set openvpn.ns_<name>.tun_mtu='1300'
uci set openvpn.ns_<name>.mssfix='1250'
uci commit openvpn.ns_<name>
/etc/init.d/openvpn restart ns_<name>

I valori di tun_mtu e mssfix potrebbero dover essere regolati in base al proprio ambiente di rete specifico. Un MTU più basso garantisce che i pacchetti rientrino nei limiti del tunnel OpenVPN senza frammentazione. A seconda di fattori come la latenza di rete o l’overhead, potrebbe risultare che valori leggermente diversi funzionino meglio per la propria configurazione.

Per informazioni più specifiche, consultare la documentazione ufficiale di OpenVPN.

Gestione della scadenza dei certificati#

Come menzionato nella sezione Gestione della scadenza dei certificati, i tunnel OpenVPN si basano anch’essi su certificati ed è fondamentale monitorare le loro date di scadenza per evitare problemi di connettività.

Quando viene creato un nuovo tunnel OpenVPN, il sistema genera una nuova PKI (Public Key Infrastructure), composta dalla CA, dal server e da un singolo certificato client (a differenza delle connessioni Road Warrior, che prevedono un certificato per ogni utente).

Tutte le informazioni sulle date di scadenza dei certificati sono disponibili nella tabella OpenVPN Tunnels, dove per ogni tunnel viene mostrata un’icona a forma di lente d’ingrandimento. Facendo clic su di essa si apre una finestra modale con tutti i dettagli sulla configurazione del tunnel, inclusi i certificati e le rispettive date di scadenza.

Sul lato server, la finestra modale mostra le informazioni sui certificati per la CA, il server e i certificati client. Sul lato client, mostra solo i certificati CA e client.

Nella tabella dei tunnel, viene mostrata un’icona di avviso quando almeno uno di questi certificati scadrà entro 30 giorni o è già scaduto. Aprendo la finestra modale dei dettagli del tunnel, è possibile vedere quale certificato sta per scadere e la sua data di scadenza.

Per impostazione predefinita, tutti i certificati vengono generati con una validità di 3650 giorni (10 anni).

Una connessione tra i due firewall verrà interrotta quando almeno un certificato scade, secondo i tre possibili scenari descritti nella sezione OpenVPN Road Warrior.

Per verificare se il tunnel OpenVPN è disconnesso a causa della scadenza del certificato, è possibile ispezionare i log del firewall e cercare messaggi relativi a OpenVPN, situati nel file /var/log/messages.

Esempio:

grep 'VERIFY ERROR:' /var/log/messages

La ricerca restituisce messaggi come il seguente:

Feb  9 13:02:07 NethSec openvpn(ns_roadwarrior1)[8031]: VERIFY ERROR: depth=1, error=certificate has expired
Feb  9 13:02:07 NethSec openvpn(ns_roadwarrior1)[8031]: VERIFY ERROR: depth=0, error=certificate has expired

Queste righe indicano che la connessione non funziona a causa della scadenza del certificato. Il problema può essere relativo al certificato CA (depth=1), al certificato del server (depth=0), o a entrambi.

Per verificare la validità dei certificati, è possibile utilizzare i seguenti comandi openssl.

# client
openssl x509 -in /etc/openvpn/{vpn-instance}/pki/issued/client.crt -text -noout | grep 'Not After'
# server
openssl x509 -in /etc/openvpn/{vpn-instance}/pki/issued/server.crt -text -noout | grep 'Not After'
# CA
openssl x509 -in /etc/openvpn/{vpn-instance}/pki/ca.crt -noout -dates -subject -issuer -serial

Il segnaposto {vpn-instance} deve essere sostituito con il nome della propria istanza OpenVPN (ad esempio ns_roadwarrior1).

Di seguito sono riportati i passaggi per rinnovare i certificati in ciascuno scenario e ripristinare la connessione.

Certificato client scaduto#

In questo scenario, il certificato client deve essere rinnovato lato server e poi scaricato e importato nuovamente lato client.

  1. Accedere al firewall del server e navigare alla sezione Tunnel OpenVPN.

  2. Fare clic sul menu ︙ a destra del tunnel e selezionare Rigenera certificati.

  3. Scaricare il nuovo certificato client e importarlo sul lato client.

Queste operazioni creeranno nuovi certificati server e client senza influire sul certificato CA (che si presume sia ancora valido in questo caso). In questo scenario, l’utilizzo del nuovo certificato client sul firewall client è obbligatorio per ripristinare la connessione, quindi è necessario scaricarlo e importarlo sul lato client il prima possibile per ridurre al minimo i tempi di inattività.

Certificato del server scaduto#

In questo scenario, il certificato del server deve essere rinnovato lato server. Utilizzare la stessa azione Rigenera certificati descritta nello scenario precedente. È possibile continuare a utilizzare il certificato client esistente (se ancora valido) e scaricare/importare quello appena generato in un secondo momento. Il nuovo certificato client scadrà lo stesso giorno del nuovo certificato server.

Per quanto riguarda il rinnovo del certificato server Road Warrior, la considerazione sul comportamento del client è la stessa: se il rinnovo del certificato viene effettuato mentre i client sono connessi, è necessario che il client si disconnetta e poi si riconnetta al server per ripristinare la connessione, mentre se il rinnovo del certificato viene effettuato mentre i client sono disconnessi (modalità consigliata), la connessione verrà automaticamente ripristinata quando tenteranno nuovamente di connettersi.

Certificato CA scaduto#

In questo scenario, è necessario procedere con la generazione di una nuova PKI completa.

  1. Accedere al terminale del firewall del server.

  2. Eseguire i seguenti comandi:

ns-openvpn-renew-ca {vpn-instance}
service openvpn restart

Questi comandi genereranno un nuovo certificato CA, oltre a nuovi certificati server e client firmati dalla nuova CA. In questo scenario, è obbligatorio scaricare e importare la nuova configurazione client sul lato client per ripristinare la connessione, quindi assicurarsi di eseguire questa operazione il prima possibile per ridurre al minimo i tempi di inattività.

Tutte le considerazioni rimangono le stesse delle connessioni Road Warrior. Se il certificato scaduto è il certificato CA, è necessario generare una nuova PKI completa, mentre se il certificato scaduto è quello del server o del client, è possibile rigenerarlo utilizzando l’azione dedicata.