|
|
<- Il g77 e un esempio di applicazione in fisica classica come strumento di studio scolastico nelle scienze - Indice Generale - Copertina - Il progetto Utopia -> |
|
Sistemi Liberi
di Vincenzo "aspinall" Giacchina
L'articoloOpenVPN è una soluzione Open Source che opera in user space, creando un tunnel point-to-point TCP over UDP che permette, come si vedrà nel corso di questo articolo, la creazione di VPN. |
La necessità primaria di aziende, cooperative, società o
qualunque altro genere di organizzazione è lo scambio di dati ed
informazioni fra sedi remote.
Le VPN (Virtual Private Network) permettono di collegare reti private
attraverso una rete pubblica (Internet). I vantaggi offerti da questa
tecnologia sono molteplici, ma sono tali dal punto di vista della sicurezza? Possiamo
realmente fidarci di trasmettere dati sensibili attraverso Internet? La
crittografia dei dati è alla base del concetto di VPN.
Esistono soluzioni proprietarie che utilizzano Server VPN, come Cisco, che
è basata su IPSEC. Altre soluzioni IPSEC sono implementate a livello
Network e tutto il protocollo è progettato per essere realizzato con
una modifica allo stack IP in kernel space.
OpenVpn è una soluzione Open Source che opera in user space, creando un tunnel point-to-point TCP over UDP che permette, come vedremo più avanti, la creazione di VPN.
Le VPN, per comunicare, usano un sistema di tunnelling. Questo evita anche attacchi di tipo spoofing (mascherare il proprio indirizzo IP): cerchiamo di seguito di capire il perché. Un'intera codifica del pacchetto è impossibile, perché durante la trasmissione dello stesso è processato da altri router per essere indirizzato a destinazione. Le VPN criptano tutto il pacchetto, header incluso, e allegano a questo un altro header non criptato che contiene le informazioni che riguardano il gateway VPN di destinazione. Altre informazioni contenute nell'header del pacchetto che stiamo trasmettendo in modo sicuro non saranno soggette ad attacco di cracker.
Con il termine crittografia, viene definita l'arte delle scritture
segrete. La trasformazione crittografica (da testo in chiaro a testo cifrato
e viceversa) può avvenire in molteplici modi, ognuno dei quali prende
il nome di "algoritmo di cifratura". Ciò che rende possibile questa
trasformazione prende il nome di "chiave".
Scomponendo la routine crittografica nelle sue componenti fondamentali,
cifratura e decifratura, essa sarà simmetrica se le due operazioni
vengono eseguite utilizzando un'unica chiave. Quando, invece, vengono
attuate utilizzando due chiavi differenti, una pubblica ed una privata, la
procedura diventa asimmetrica.
In un contesto di crittografia simmetrica, è chiaro che la
trasmissione della chiave stessa e la sua conservazione devono essere molto
accurate.
OpenVPN, il software che utilizzeremo per creare la nostra VPN, implementa anche questo tipo di crittografia, basato sulla condivisione di una chiave segreta fra le postazioni della VPN. La crittografia dei dati in contesto simmetrico verrà realizzata con l'algoritmo blowfish.
I sorgenti di OpenVPN sono reperibili sul sito http://www.openvpn.net/, dove vengono
messi a disposizione anche pacchetti RPM.
Prima di installare OpenVPN, è necessario procurarsi le librerie lzo,
che permettono la compressione dei dati, e sono sempre reperibili sulla home
page sopra riportata.
L'installazione da RPM si riduce ad un semplice comando:
# rpm -ivh openvpn-2.0.0.i386.rpm |
Il sorgente viene compilato in questo modo:
# ./configure # make && make install |
Consiglio sempre di leggere il file INSTALL che si trova nei sorgenti e le relative opzioni del configure.
OpenVPN lavora esclusivamente in user space con l'ausilio dei device
TUN/TAP, permettendo la creazione di interfacce virtuali che consentono di
instaurare connessioni point-to-point.
Lavorando in user space, OpenVPN non necessita della modifica del pacchetto IP
al livello Internet, cosa invece necessaria per l'utilizzo di IPSEC (VPN
basate su IPSEC necessitano la ricompilazione del kernel per supportare
l'alterazione del pacchetto IP).
Dopo aver compilato i sorgenti e quindi installato il software, dobbiamo creare prima di tutto la chiave privata per l'inizializzazione del tunnel.
# openvpn -genkey -secret key.txt |
Una volta creata la chiave segreta e posizionata dentro /etc/openvpn/, dobbiamo creare il file di configurazione per il server (/etc/openvpn/config.ovpn).
dev tap secret /etc/openvpn/key.txt ping 10 verb 1 mute 10 ifconfig 10.0.1.1 255.255.255.252 lport 5002 |
La configurazione del gateway VPN (client) è identica a quella vista precedentemente. Ovviamente dobbiamo copiare la chiave segreta e posizionarla nella directory /etc/openvpn/ e creare il file di configurazione (/etc/openvpn/config.ovpn), che deve essere di questo tipo:
remote ip.pubblico.del.server rport 5002 dev tap ifconfig 10.0.1.2 255.255.255.252 secret /etc/openvpn/key.txt ping 10 verb 1 mute 10 |
Una volta installato e configurato OpenVPN, non ci resta che lanciare il demone in entrambi i gateway e provare la VPN.
# openvpn --config /etc/openvpn/config.ovpn \ --log-append /var/log/openvpn.log -daemon |
Appena lanciato il demone, la VPN dovrebbe essere instaurata. Per sicurezza, leggiamo il file di log /var/log/openvpn.log.
Tue Apr 26 22:12:06 2005 OpenVPN 2.0_rc19 i386-redhat-linux [SSL] [LZO] [EPOLL] built on Apr 2 2005 Tue Apr 26 22:12:06 2005 TUN/TAP device tap0 opened Tue Apr 26 22:12:06 2005 /sbin/ip link set dev tap0 up mtu 1500 Tue Apr 26 22:12:06 2005 /sbin/ip addr add dev tap0 10.0.1.1/30 broadcast 10.0.1.3 Tue Apr 26 22:12:06 2005 UDPv4 link local (bound): [undef]:5002 Tue Apr 26 22:12:06 2005 UDPv4 link remote: [undef] Tue Apr 26 22:12:16 2005 Peer Connection Initiated with x.x.x.x:1194 Tue Apr 26 22:12:17 2005 Initialization Sequence Completed |
Proviamo realmente se la VPN è funzionante.
# ping -c 2 10.0.1.2 PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data. 64 bytes from 10.0.1.2: icmp_seq=0 ttl=64 time=141 ms 64 bytes from 10.0.1.2: icmp_seq=1 ttl=64 time=137 ms --- 10.0.1.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 137.484/139.436/141.388/1.952 ms, pipe 2 |
La VPN è perfettamente funzionante.
Definiamo VPN GW-to-LAN una VPN realizzata tra due gateway, di cui uno di questi offre la possibilità di raggiungere la propria rete locale. Scenari di questo tipo sono molto comuni in contesti aziendali, ad esempio con i cosiddetti road warrior (utenti mobili), che leggono la posta interna o accedono ad un CMR locale, raggiungendo server interni con un ottimo livello di sicurezza.
In questo contesto, utilizzeremo un bridge ethernet, che per definizione ci aiuta a far comunicare tra di loro segmenti di rete diversi, che verrà posto tra il device tap e la nostra ethernet che collega il gateway alla LAN.
Per poter sfruttare la funzionalità del bridging ethernet, il kernel deve aver compilato o implementato il modulo bridging.o e necessariamente si dovranno installare le bridging utils, che potete trovare sul sito http://bridge.sourceforge.net/.
Dopo esserci assicurati che il nostro kernel abbia il supporto per il bridging (non scoraggiatevi se i kernel recenti lo implementano nativamente), possiamo creare un ipotetico scenario e vedere la sua configurazione.
GW1 10.0.1.1 -
|
INTERNET
|
-> GW2 tap0 10.0.1.2 --------------
|
eth2 192.168.11.1
|
\|/
LAN
|
|
è 192.168.11.2 |
Questa configurazione non permette al GW1 di raggiungere la LAN, per fare questo dobbiamo aggiungere un bridge al GW2, che faccia bridging tra l'interfaccia tap0 e la scheda ethernet eth2.
GW1 10.0.1.1 - | INTERNET | -> GW2 10.0.1.2 -------------- | BRIDGE br0 192.168.11.1 | \|/ LAN | | è 192.168.11.2 |
Nel GW2, ovvero nel client, dobbiamo creare l'interfaccia br0 che, come abbiamo detto precedentemente, verrà realizzata tramite le bridging utils.
Inizialmente, creiamo il device tap0 e assicuriamoci che OpenVPN non sia in esecuzione.
openvpn --mktun --dev tap0 |
Ora creiamo l'interfaccia br0 e impostiamo il bridging tra le due interfacce.
brctl addbr br0 brctl addif br0 eth2 brctl addif br0 tap0 |
Le due interfacce non devono avere indirizzo IP, perché farà tutto il bridge.
ifconfig tap0 0.0.0.0 promisc up ifconfig eth2 0.0.0.0 promisc up |
Non rimane che impostare l'IP a br0 che, ovviamente, dovrà essere quello che precedentemente aveva impostato l'interfaccia eth2.
ifconfig br0 192.168.11.1 netmask 255.255.255.0 up |
Appena attivata br0, troveremo la relativa rotta nella tabella di routing.
192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 |
La VPN è pronta per essere instaurata, lanciamo nuovamente il demone su GW2 (client) e diamo uno sguardo al relativo file di log.
Wed Apr 27 00:45:18 2005 /sbin/ip link set dev tap1 up mtu 1500 Wed Apr 27 00:45:18 2005 /sbin/ip addr add dev tap1 10.0.1.2/30 broadcast 10.0.1.3 Wed Apr 27 00:45:19 2005 UDPv4 link local (bound): [undef]:1194 Wed Apr 27 00:45:19 2005 UDPv4 link remote: GW1:5002 Wed Apr 27 00:45:22 2005 Peer Connection Initiated with GW1:5002 Wed Apr 27 00:45:22 2005 Initialization Sequence Completed |
GW1, ovvero 10.0.1.1, dovrebbe essere in grado di raggiungere 192.168.11.2: ci servirà solo dirgli che tutti i pacchetti che avranno come destinazione la sottorete 192.168.11.0/24 dovranno passare dal GW 10.0.1.2. Per far questo, eseguiremo sul server:
route add -net 192.168.11.0 netmask \ 255.255.255.0 gw 10.0.1.2 dev tap0 |
Ovviamente, la stessa rotta di destinazione sarà impostata sul client della LAN 192.168.11.2, per poter ricevere una risposta. Il client dovrà essere istruito secondo la strada che il pacchetto dovrà percorrere per ritornare a 10.0.1.1.
Questa rotta, nel caso il GW2, quindi il proprio GW VPN, sia anche la macchina che fa il NAT per l'intera subnet, quindi il default gateway, non costituirà un problema, perché comunque il pacchetto verrà mandato al gateway VPN 192.168.11.1, quindi al bridge.
In caso contrario, in cui default gateway del client sia diverso dal GW VPN, bisognerà inserire la seguente rotta:
route add -net 10.0.1.0 netmask 255.255.255.252 gw 192.168.11.1 dev interfaccia_lan |
Sperando che non vi siate persi per strada, proviamo ad effettuare un ping dal GW1 al PC della LAN remota.
ping -c 2 192.168.11.2 PING 192.168.11.2 (192.168.11.2) 56(84) bytes of data. 64 bytes from 192.168.11.2: icmp_seq=0 ttl=63 time=141 ms 64 bytes from 192.168.11.2: icmp_seq=1 ttl=63 time=133 ms --- 192.168.11.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 133.292/137.538/141.785/4.262 ms, pipe 2 |
La VPN GW-to-LAN è funzionante.
Se avete seguito attentamente le precedenti configurazioni e sono riuscito a spiegarmi discretamente bene, configurare una VPN LAN-to-LAN non dovrebbe essere assolutamente difficile, basterà impostare in entrambi i GW della VPN un bridge per la comunicazione tra le due sottoreti locali.
Ecco uno scenario ipotetico:
172.16.2.11
/|\
|
LAN
|
eth1 172.16.251.251
|
-> GW1 10.0.1.1 -
|
|
INTERNET
|
-> GW2 10.0.1.2 ------
|
eth2 192.168.11.1
|
\|/
LAN
|
\|/
192.168.11.2 |
In un contesto simile, dove 172.16.251.251 è l'host di una sottorete 172.16.0.0/16 e deve comunicare con 192.168.11.2, ci troviamo in una situazione in cui deve essere posizionato un bridge in entrambi i gateway VPN, permettendo così il routing tra due sottoreti.
Nell'esempio VPN GW-to-LAN, abbiamo creato un bridge nel GW VPN per il bridging con la rete locale. Adesso dobbiamo fare la stessa cosa su GW1, ovvero 10.0.1.1.
br0 172.16.251.251
|
-> GW1 10.0.1.1 --
|
INTERNET
|
-> GW2 10.0.1.2 --------------
|
BRIDGE br0 192.168.11.1 |
Seguendo la stessa procedura, creiamo l'interfaccia br0 su GW1.
openvpn --mktun --dev tap0 brctl addbr br0 brctl addif br0 eth1 brctl addif br0 tap0 ifconfig tap0 0.0.0.0 promisc up ifconfig eth2 0.0.0.0 promisc up ifconfig br0 172.16.251.251 netmask 255.255.0.0 up |
Creato il bridge e lanciato OpenVPN, i pacchetti provenienti dalla LAN del GW1 che avranno come destinazione 192.168.0.0/24, passeranno da tap1 e saranno in grado di raggiungere la LAN remota. Creando il bridge, il demone OpenVPN crea una nuova interfaccia chiamata tap1, quindi è necessario cambiare la rotta precedentemente inserita con il device tap0.
route add -net 192.168.11.0 netmask \ 255.255.255.0 gw 10.0.1.2 dev tap1 |
Controllando le rotta sui client della LAN, come spiegato in precedenza, la VPN LAN-to-LAN dovrebbe essere funzionante.
OpenVPN risulta sicuramente una buona scelta: vi consiglio di approfondire bene le sue particolarità, poiché quanto trattato aiuta molto nell'atto pratico, ma di certo non si spinge nel dettaglio analizzando tutte le funzionalità che il software in questione ci offre. Infine, volevo ringraziare Maria Giovanna D'Angelo, Alessandro Orlando e Giovanni Licata per l'aiuto che mi è stato dato nel breve periodo che ho avuto a disposizione per la stesura dell'articolo. Sperando di ritornare sull'argomento in futuro, vi invito, come consuetudine, a studiare e leggere la documentazione ufficiale reperibile al sito http://www.openvpn.net/.
L'autoreVincenzo "aspinall" Giacchina attualmente lavora come sistemista Unix in un'azienda fornitrice Telecom. Studia, nel tempo che trova, informatica all'università di Palermo. Il suo interesse principale è la network security. Collabora con alcune riviste del settore e spesso di notte coltiva il suo hobby: la programmazione. |
|
|
<- Il g77 e un esempio di applicazione in fisica classica come strumento di studio scolastico nelle scienze - Indice Generale - Copertina - Il progetto Utopia -> |
|