ZeroShell    Forum
   Feed Feed
EnglishEnglish     ItalianoItaliano     French     Spanish                Zeroshell on LinkedIn LinkedIn       Facebook      Twitter ZeroTruth una interfaccia per il Captive Portal

      Cosa è?
      Screenshots
      Licenza
      Annunci
      Mailing List
      Forum
      English Forum
      Documentazione
      FAQ
      Hardware
      Download
      Update On-line
      Kerberos Tutorial  
      Note Legali
      Contattami


  Più in dettaglio:
      Hotspot Router
      Accounting
      Shibboleth SP
      Grafici e Prestazioni
      Net Balancer
      Router UMTS
      Proxy con Antivirus
      Filtri Web
      WiFi Access Point
      OpenVPN Client
      OpenVPN Server
      QoS
      OpenDNS
      Kerberos 5
      NIS e LDAP
      Certificati X.509
      RADIUS
      VPN
      Firewall


Valid HTML 4.01 Transitional




Gateway VPN Host-to-LAN usando OpenVPN

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

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);
  • 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.
Interfaccia Web per OpenVPN
Interfaccia Web per OpenVPN. Fai click sull'immagine per ingrandire.

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) 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.

Domini di autenticazione OpenVPN
Fonti di autenticazione per OpenVPN. Fai click sull'immagine per ingrandire.

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 @dominio dallo 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 di sottostante e si compiano i seguenti passi:

OpenVPN e autenticazione con certificati digitali X.509
Configurazione dell'autenticazione con certificati digitali. Fai click sull'immagine per ingrandire.

  • 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 OpenVPN
Statistiche. Fai click sull'immagine per ingrandire.


OpenVPN logss
Messaggi di log. Fai click sull'immagine per ingrandire.


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 forma username@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.



    Copyright (C) 2005-2013 by Fulvio Ricciardi