Questo documento, il cui scopo è di descrivere la realizzazione di un Gateway OpenVPN per Virtual Private Network di tipo Host-to-LAN mediante Zeroshell, è suddiviso nelle seguenti sezioni:
- Perché utilizzare OpenVPN come sistema di VPN
- La configurazione di Default per le VPN Host-to-LAN con OpenVPN
- Autenticazione OpenVPN con Username e Password
- Autenticazione OpenVPN con certificati digitali X.509
- VPN in modalità Routed o Bridged
- Statistiche e messaggi di log per le VPN
Perché utilizzare OpenVPN come sistema di VPN
Benché Zeroshell sia in grado di lavorare come gateway VPN Host-to-LAN già dalla sua prima release, lo poteva fare soltanto con il protocollo IPSec/L2TP. Questa combinazione di due tunnel, di cui il primo (IPSec) autenticato dall’IKE con certificati X.509 ed il secondo (L2TP) con username e password verificati dal KDC Kerberos 5 locale, ha mostrato subito i suoi limiti:
- Non si può evitare di distribuire un certificato digitale X.509 con la relativa chiave privata a tutti gli utenti che vogliono accedere in VPN alla loro LAN. Tale vincolo impone, a un’organizzazione che indenda offrire un servizio di Virtual Private Network ai suoi utenti, di dotarsi di una PKI (Public Key Infrastructure) capace di firmare e gestire i certificati X.509. Zeroshell gestisce una rudimentale Certification Authority, ma comunque la sua gestione potrebbe essere un onere gravoso per talune organizzazioni;
- Dopo l’autenticazione con certificato non si può evitare di autenticarsi anche con username e password. Questa doppia autenticazione, in alcuni casi, rappresenta una perdita di tempo. Ciò è vero, soprattutto quando il certificato X.509 è memorizzato in una Smart Card, che non solo rappresenta già un’alta garanzia di sicurezza che rende superflua la seconda autenticazione, ma lo sblocco della chiave privata custodita nella SC richiede anch’esso l’immissione di un codice PIN;
- La configurazione dei VPN client L2TP/IPSec è complicata anche sui sistemi operativi che includono nativamente il supporto per tale modello di VPN;
- Nel caso un client si trovi dietro un router che esegue il NAT o il server stesso abbia un IP di una sottorete privata, l’utilizzo di IPSec comporta dei problemi di autenticazione dei pacchetti, dovuti al fatto, che i NAT Gateway ne alterano l’Header. La soluzione al problema, consiste nella configurazione sui NAT Router, di tecniche non standard di VPN pass-through oppure nell’abilitare il NAT-T (NAT Traversal) che incapsula IPSec in UDP (porta 4500). Benché il funzionamento del NAT-T è standardizzato, il suo utilizzo va negoziato tra client e server VPN in base all’effettiva necessità e ciò può essere ulteriore fonte di problemi.
Per eliminare questa serie di inconvenienti, a partire dalla release 1.0.beta7 di Zeroshell, si è affiancato ad IPSec/L2TP anche il supporto di OpenVPN per le VPN di tipo Host-to-LAN. È giusto precisare che Zeroshell, utilizza OpenVPN per la realizzazione di VPN Site-to-Site Routed/Bridged con supporto per le VLAN 802.1q, già dalla release 1.0.beta1. Proprio in virtù della stabilità e della flessibilità dimostrata da OpenVPN nel caso di VPN LAN-to-LAN, si è ritenuto utile utilizzarlo anche per risolvere il problema delle VPN Host-to-LAN. Sotto sono elencate le caratteristiche del servizio OpenVPN server configurato su Zeroshell:
- La configurazione del servizio OpenVPN avviene completamente mediante interfaccia Web (vedi figura 1);
- Oltre all’autenticazione con certificati digitali X.509, che richiede il possesso da parte di ogni utente di un certificato e della sua chiave privata, è disponibile anche l’autenticazione con solo username e password. In quest’ultimo caso, le credenziali possono essere convalidate non solo grazie al database interno (Kerberos 5), ma anche con un server RADIUS esterno o un KDC Kerberos 5 esterno come per esempio quello di Microsoft Active Directory. Per ulteriori dettagli vedi la nota *;
- Come testimoniato nel documento Configurazione di un client OpenVPN su sistemi Windows, Linux, Mac OS X e Windows Mobile per Pocket PC esiste la possibilià di installare un client OpenVPN, con un’interfaccia grafica di gestione, sulla maggior parte dei sistemi operativi disponibili;
- OpenVPN configurato per utilizzare i dispositivi TAP (Interfacce Ethernet Software), incapsula all’interno del tunnel criptato con SSL, che costituisce la VPN, vere e proprie trame Ethernet. Il vantaggio di ciò è nella possibilità di poter mettere in bridge (routing in layer 2) le interfacce Ethernet fisiche che collegano il Gateway VPN alla LAN con le VPN che collegano i client remoti. Grazie al bridging, i client remoti risultano connessi direttamente a livello di Datalink e quindi senza routing IP che impedirebbe il transito di protocolli di rete non IP come per esempio SPX/IPX di Novell NetWare, AppleTalk o NetBeui. Inoltre anche il broacast Ethernet transita nella VPN, permettendo per esempio di utilizzare lo stesso server DHCP sia sulla LAN che per gli host remoti;
- Infine, OpenVPN è un sistema molto forte dal punto di vista della sicurezza. Oltre ad utilizzare gli algoritmi crittografici più robusti messi a disposizione da OpenSSL, è stato scritto con un’attenzione particolare, nel tentativo di evitare quanto più è possibile falle di sicurezza dovute ad errori di programmazione.
1. Interfaccia Web per OpenVPN
La configurazione di Default per le VPN Host-to-LAN con OpenVPN
La
configurazione di default di OpenVPN per VPN Host-to-LAN è tale da
rendere l’attivazione del servizio quanto più semplice possibile.
Infatti, per potersi collegare in VPN a Zeroshell è sufficiente cliccare
sul flag Enabled della sezione [VPN]->[Host-to-LAN (OpenVPN)] (vedi figura) che farà partire il processo openvpn il
quale si mette in ascolto per le connessioni in entrata. Per una rapida
configurazione anche dei client si può utilizzare il file di
configurazione zeroshell.ovpn disponibile
nella sezione di download. I parametri che vengono specificati in
questo file di configurazione per client, sono tali da rispecchiare la
configurazione di default del gateway VPN ed è pertanto sufficiente
modificare soltanto l’indirizzo IP o l’hostname a cui connettersi, ma
per ulteriori dettagli sulla configurazione dei client VPN si faccia
riferimento al seguente How-To.
In seguito, sono elencate le
caratteristiche della configurazione di default, insieme alla
motivazione che ha portato a tale scelta. Può risultare utile, come
riepilogo, dare uno sguardo alla figura che corrisponde appunto alla
configurazione iniziale di OpenVPN.
- OpenVPN permette di scegliere il protocollo di trasporto UDP o TCP in cui incapsulare il tunnel criptato con SSL. Zeroshell per default utilizza TCP, poiché in caso di caduta della VPN per problemi di connettività, ha dimostrato estrema rapidità nel rinegoziare la connessione. Con UDP invece, in caso ci sia un’interruzione involontaria del servizio, client e server ritentano la connessione solo dopo un certo numero di secondi regolato dal parametro –ping-restart n. Tuttavia, è doveroso precisare, che quando si utilizza il TCP per trasportare tunnel al cui interno viaggiano altre connessioni, che a loro volta possono essere TCP o UDP, si verifica un overhead maggiore rispetto al caso in cui si utilizzi UDP. La causa di ciò è da ricercare nel fatto, che il TCP, essendo un protocollo orientato alla connessione, effettua dei controlli di integrità che nel caso di incapsulamento di VPN sono ridondanti, visto che l’integrità dei dati viene ricontrollata nuovamente per i flussi che attraversano la VPN. Si è però verificato praticamente, che tale overhead è di fatto trascurabile e le prestazioni ottenibili con il TCP sono molto prossime a quelle ottenibili con UDP. A spingere ulteriormente verso l’utilizzo del TCP è stata anche la considerazione del fatto, che le porte TCP sono bloccate molto meno frequentemente sui firewall rispetto a quelle UDP.
- Oltre al protocollo è possibile scegliere anche la porta su cui accettare le connessioni dei client. Per default, Zeroshell utilizza la porta 1194, visto che questa è quella ufficiale assegnata dallo IANA a OpenVPN.
- L’autenticazione è impostata in maniera che ci si autentichi soltanto con username e password corrispondenti ad utenti locali di Zeroshell. L’autenticazione con certificati digitali X.509 o verso server RADIUS e server Kerberos 5 esterni non è abbastanza intuitiva da poter far parte della configurazione di default.
- Benché l’autenticazione dei client con X.509 sia disabilitata per default, il server OpenVPN necessita comunque di un certificato per poter stabilire un canale criptato con i client VPN. Per default tale certificato corrisponde a quello generato automaticamente da Zeroshell al primo startup.
- Per default, Zeroshell fa lavorare OpenVPN in routing mode con IP appartenenti alla subnet 192.168.250.0/255.255.255.0, con default gateway e DNS 192.168.250.254 (se stesso). Inoltre, il source NAT è abilitato per default, in modo da evitare di dover configurare route statiche o abilitare il protocollo RIP versione 2 sui router, per poter raggiungere i client connessi in VPN.
- Infine, la compressione LZO e la cifratura del traffico sono abilitate. Tuttavia, queste due caratteristiche non possono essere configurate dall’interfaccia web e non è quindi possibile disabilitarle.
A questo punto, dato uno sguardo alla configurazione iniziale delle VPN Host-to-LAN, possiamo vedere nei prossimi paragrafi come adattare il comportamento di Zeroshell alle proprie esigenze. Si noti da subito, che OpenVPN è un software estremamente configurabile grazie ai suoi numerosi parametri, ma l’interfaccia web di Zeroshell permette di agire solo su un numero limitato di essi. Nel tentativo di arginare il problema, la pagina di configurazione prevede un campo Command Line Parameters, da cui si possono passare i parametri direttamente al processo openvpn.
Autenticazione OpenVPN con Username e Password
Agendo sulla casella di scelta Authentication (vedi figura 1) si può scegliere la modalità di autenticazione, cioè se questa deve avvenire solo con username e password, con certificato digitale X.509 o con entrambi. Nel caso di autenticazione con username e password, possono essere utilizzate diverse fonti per la convalidazione delle credenziali. Zeroshell seleziona il provider di autenticazione corretto basandosi sul dominio indicato nello username, che deve essere nella forma username@dominio. Se l’utente omette di indicare il dominio, Zeroshell utilizza il dominio di default che vedremo in seguito come impostare e che inizialmente corrisponde al database locale degli utenti. Le fonti di autenticazione possono essere dei server Kerberos 5, dei realm Kerberos in cross autenticazione (relazione di fiducia) con il KDC locale oppure dei server RADIUS esterni. Facendo riferimento alla figura di sottostante vediamo come configurare i domini di autenticazione.
2. Fonti di autenticazione per OpenVPN
Cliccando sul bottone [+] nel frame Password Authentication si apre un form in cui configurare il dominio di autenticazione.
Dominio Kerberos 5
Se si tratta di un realm Kerberos 5, inserirne il nome nel campo Domain Name e selezionare l’opzione External Kerberos 5 Realm oppure Trusted Kerberos 5 Realm.
Nel primo caso viene effettuata una semplice convalida di credenziali
provando ad acquisire un TGT (Ticket Granting Ticket) per l’utente. Nel
secondo invece, oltre all’acquisizione di un TGT, si tenta anche di
ottenere un ticket di servizio valido sfruttando la relazione di fiducia
tra il REALM locale di Zeroshell e quello esterno. È chiaro che questo
secondo caso offre un più alto livello di sicurezza, dovuto alla
verifica dell’autenticità del server Kerberos esterno, ma richiede uno
sforzo più elevato nella configurazione, in quanto è necessario
impostare la relazione di fiducia agendo sia su Zeroshell che sul KDC
esterno.
Si tenga presente che in questa fase viene
specificato solo il nome del dominio, ma non quali sono i server
Kerberos autoritari per tale realm. Il modo con cui Zeroshell è in grado
di capire quale KDC contattare per convalidare le credenziali
dell’utente remoto che si vuole connettere in VPN, si configura nel form
che si attiva da [Kerberos 5]->[Realms]. Da qui si può aggiungere il
realm esterno con la lista dei relativi server Kerberos oppure attivare
il discovery automatico che presuppone l’utilizzo da parte dei DNS dei
record SRV specifici per Kerberos.
Nel caso si voglia permettere agli utenti
di un dominio Microsoft Active Directory di autenticarsi su OpenVPN è
sufficiente tenere conto che su ogni controller di dominio Windows
2000/2003 è attivo un server Kerberos in grado di autenticare gli
utenti. Perciò è sufficiente dichiarare il dominio Active Directory
come External Kerberos 5 Realm e aggiungere il realm con l’elenco
dei Domain Controller nel form [Kerberos 5]->[Realms]. Poiché i DNS
di Active Directory gestiscono i record SRV relativi a Kerberos, si
potrebbe semplicemente attivare il discovery automatico, invece di
dichiarare quali sono i Domain Controller.
Infine, nel frame Password Authentication si noti la presenza del flag Automatically authorize any trusted Kerberos 5 Realm.
Se lo si attiva, tutti gli utenti appartenenti ai realm con i quali
intercorre una relazione di cross autenticazione potranno autenticarsi
in VPN, senza la necessita di aggiungere ognuno di tali domini come
descritto sopra.
Dominio RADIUS
Se gli
utenti devono essere autenticati da un server RADIUS esterno è
necessario inserire il nome del dominio e scegliere l’opzione RADIUS Proxy Domain.
Poiché OpenVPN utilizza il meccanismo del proxying interrogando il
FreeRADIUS locale che poi si impegna a smistare la richiesta di
autenticazione al RADIUS competente, è necessario assicurarsi prima di
tutto che questo sia attivo e poi aggiungere il server RADIUS esterno
nella lista dei server proxy che si ottiene da [RADIUS]->[Proxy].
Sempre in questa lista va specificato lo Shared Secret del server RADIUS esterno.
Si tenga presente che in base alla
configurazione del server RADIUS esterno, quando si effettua la
richiesta di autenticazione, può essere necessario eliminare la parte @dominiodallo username. In tal caso, quando si aggiunge il server RADIUS in [RADIUS]->[Proxy] disattivare il flag No Strip.
Se poi si vuole delegare per qualsiasi
richiesta di autenticazione RADIUS che non ricada tra i domini
esplicitamente definiti, un server RADIUS che si impegni a soddisfare la
richiesta direttamente o deleghi a sua volta un altro server,
aggiungere un RADIUS di Default selezionando Default nella casella Realm Type.
Infine, così come nel caso dell’autenticazione Kerberos 5, si noti nel frame Password Authentication la presenza del flag Automatically authorize any Proxy RADIUS Domain . Abilitando tale flag, anche se un dominio non è esplicitamente autorizzato viene comunque tentata un’autenticazione proxy.
Esaminata la configurazione lato server per quel che riguarda l’autenticazione con username e password, è opportuno evidenziare che affinché il client VPN richieda l’immissione delle credenziali è necessario define l’opzione auth-user-pass nel suo file di configurazione o sulla linea di comando di openvpn.
Autenticazione OpenVPN con certificati digitali X.509
L’autenticazione con certificati
digitali X.509, in cui ogni utente che si voglia connettere in VPN
necessita di un certificato digitale e della relativa chiave privata,
può essere richiesta con o senza l’autenticazione con username e
password a seconda che si scelga rispettivamente l’opzione X.509 Certificate + Password oppure Only X.509 Certificate dalla casella di scelta Authentication.
Nel primo caso, se l’autenticazione X.509
viene conclusa con successo, si passa ad una seconda autenticazione
realizzata con Kerberos 5 o RADIUS come descritto in precedenza. In
genere, quando si ricorre a questa doppia autenticazione, il certificato
digitale X509 non è personale dell’utente, ma è un certificato host
assegnato alla macchina. Ciò comporta una non precisa identificazione
dell’utente (visto che più utenti possono connettersi dallo stesso
sistema) e pertanto vengono richiesti anche username e password.
Nel secondo caso invece si utilizzano
certificati personali assegnati all’utente in cui l’utente viene
identificato dal Common Name (campo CN) del certificato. Ciò rende
superflua un’ulteriore richiesta di credenziali.
Affinché un certificato client (sia esso
personale assegnato all’utente o host assegnato alla macchina) venga
riconosciuto come valido dal gateway OpenVPN sono necessarie due
condizioni: la prima è che la Certification Authority (brevemente CA)
che ha firmato il certificato sia nell’archivio delle Trusted CAs di Zeroshell; la seconda condizione è che tale CA sia autorizzata a convalidare l’accesso in VPN.
Per ottenere queste due condizioni, si faccia riferimento alla figura sottostante e si compiano i seguenti passi:
Configurazione dell’autenticazione con certificati digitali
- Cliccare sul pulsante [Authentication] nel frame X.509 Configuration. Come si può vedere sono caricati tre certificati di Autorità di Certificazione. Benché tutti i certificati digitali firmati da queste CA sono ritenuti autentici, soltanto quelli corrispondenti alla Certification Authority con il segno di spunta sono autorizzati alla connessione VPN. Nel nostro caso si tratta dei certificati rilasciati dalla CA di esempio di Zeroshell;
- Cliccare sul pulsante [Trusted CAs Manager] e dal form che appare importare il certificato in formato PEM (codifica Base-64) dell’Autorità di Certificazione che si desidera autorizzare. Qualora si disponga di una Certificate Revocation List (CRL) per la pubblicazione dei certificati revocati, la si può caricare seguendo la stessa procedura seguita per l’importazione della CA stessa. Grazie alla CRL, i certificati che risultino revocati non avranno accesso al gateway VPN;
- Tornando al form OpenVPN X.509 Authentication si noterà che la CA appena importata è ritenuta una fonte di certificazione attendibile. Per autorizzare il collegamento in VPN ai client che dispongono di un certificato rilasciato da tale Autorità di Certificazione è sufficiente apporre il segno di spunta nella casella di controllo corrispondente e premere il bottone [Save] per salvare.
VPN in modalità Routed o Bridged
Dalla
release 1.0.beta7 di Zeroshell, si può notare che durante lo startup
viene creata e configurata automaticamente l’interfaccia virtuale VPN99.
Si tratta di un dispositivo TAP, cioè di un’interfaccia Ethernet
software mediante cui OpenVPN aggancia il tunnel criptato con SSL e ne
permette la gestione da parte del Kernel come se si trattase di una
qualunque altra scheda di rete Ethernet. Ciò implica che a tale
interfaccia gli si può assegnare un indirizzo IP e configurare
opportunamente il routing oppure renderla parte di un bridge insieme ad
altre interfacce Ethernet. A seconda che si opti per la prima
possibilità o per la seconda (dove la VPN99 è membro di un bridge), le
connessioni VPN saranno in routing oppure in bridging.
È ovvio che nel caso si scelga il Routed
Mode, l’indirizzo IP assegnato all’interfaccia VPN99 deve corrispondere
al default gateway assegnato ai client VPN. Ma di ciò non ci si dovrebbe
occupare manualmente, visto che Zeroshell assegna automaticamente
l’indirizzo IP alla VPN99 quando si configura il servizio di Virtual
Private Network.
Infine, è importante sottolineare che per
come è configurato OpenVPN su Zeroshell, i client contemporaneamente
connessi in VPN sono isolati tra di loro e quindi non possono comunicare
se non con il gateway. Tale scelta è stata dettata da criteri di
sicurezza con cui per esempio si vuole evitare che un client VPN possa
mettere in promiscuo la sua interfaccia virtuale e sniffare traffico
di cui non è il destinatario. Tuttavia, se si ritiene che nella propria
situazione sia necessario che i VPN client comunichino anche tra di
loro, è sufficiente inserire il parametro –client-to-client nella casella di testo Command Line Parameters dell’interfaccia web. Tale parametro abiliterà una visibilità in layer 2 a carico del processo openvpn e
non del Kernel che permette ai client di vedersi. Poiché non è il
Kernel ad occuparsi di tale comunicazione, non c’è alcuna speranza di
configurare il Firewall (Netfilter) in modo da impedire alcuni tipi di
traffico tra i client della Virtual Private Network.
Statistiche e messaggi di log per le VPN
Statistiche
Messaggi di log
Note
(*) Il modo con cui vengono convalidate le credenziali utente dipende da come è configurato il server OpenVPN. Zeroshell permette di aggiungere più domini di autenticazione, ognuno dei quali può essere autenticato su KDC Kerberos 5 (locale, esterno o mediante cross-autenticazione) oppure su un server RADIUS esterno. Uno di tali domini è quello di Default, intendendo con ciò che l’utente nello specificare lo username non è obbligato ad indicarlo esplicitamente. Negli altri casi, lo username deve essere nella formausername@domain (es. fulvio@example.com). Si noti che il dominio non è case sensitive, visto che se si tratta di un REALM Kerberos V, Zeroshell lo converte automaticamente in maiuscolo.