Lo scopo di questa esperienza è di imparare a creare la configurazione per collegare due sedi fra loro via un tunnel ottenuto con openvpn.
il setup di questa esperienza è il seguente
- due firewall che usano una connessione tap che via l’host principale (la vostra macchina) vi permette la connessione ad internet.
- due client che servono per testare la configurazione
Il file principale su cui dovete concentrarvi è /etc/openvpn/ che contiene la configurazione del tunnel openvpn
Il tunnel fra le sedi può essere ottenuto almento in 3 modi differenti:
- vtun: molto semplice grazie ad una script di configurazione
- openvpn: ottimo per collegare anche client remoti, oggetto del presente laboratorio
- ipsec: più complesso in generale
Questa esperienza mette a disposizione molte differenti configurazioni e spetta voi fare partire quelle di interesse. Le configurazioni hanno un nome comprendente un numero ed una descrizione:
01_udp_nocrypt.conf
due configurazioni con lo stesso numero su due client differenti sono fatte per lavorare assieme, ad esempio:
20e_server_udp_route.conf
20_udp_client.conf
Lavoreranno assieme relativamente su server e client. Ogni configurazione con il 20 viene usata con il 20 indipendentemente dalla lettera.
Alcune configurazioni sono presenti per mostrare.... che non funzionano!
Useremo i terminali per fare partire i tunnel a mano: ovpn file.conf quindi per potere successivamente eseguire comandi di diagnostica (tcpdump) dovremo raggiungere questi firewall via ssh. Guardate il loro ip con ifconfig o più comodamente con ipl.
OpenVPN può essere usato in configurazioni alla pari (un tunnel per unire due sedi) o in configurazioni client server con molti server (ad esempio il firewall della scuola per permettere a tutti i docenti di entrare).
Non è possibile trattare in questo laboratorio il tema complesso della crittazione a chiave pubblica/privata. Mi limito a dire che OpenVPN si basa su crittografia asimmetrica, è necessario creare delle chiavi (analoghe a quelle usate per ssh) e dei certificati che possono essere visti come dei lasciapassare concessi da una autorità ad un utente per un certo tempo. Il certificato funziona solo unitamente alla chiave. Sul server deve anche essere presente una chiave Diffie-Hellman.
La generazione delle chiavi è accennata nell’esercizio sotto riportato.
Estratto da wikipedia:
La crittografia asimmetrica, conosciuta anche come crittografia a coppia di chiavi, crittografia a chiave pubblica/privata o anche solo crittografia a chiave pubblica è un tipo di crittografia dove, come si evince dal nome, ad ogni attore coinvolto è associata una coppia di chiavi:
Vediamo quali file ci sono:
# cd /etc/openvpn # ls -1 *conf 01_udp_nocrypt.conf ## opzioni base, senza crittazione 02_udp_crypto.conf 03_udp_crypto_comp.conf # con crittazione - richiede certificati 04_udp_pass.conf 10_tcp_nocrypt.conf 12_tcp_crypt.conf 13_tcp_crypt_comp.conf 20a_server_udp_linear.conf # versione server per road warrier 20b_server_udp.conf 20c_server_udp_sub.conf 20d_server_udp_route.conf 20e_server_udp_route.conf 21_server_tcp.conf 22_server_auth_pass_verify.conf 31_tcp_proxy.confci concentreremo in particolare su 01, 03, 20
ovpn 01_udp_nocrypt.conf
questa è una configurazione particolarmente semplice che non prevede neppure crittazione. Verifichiamo cosa succede al passaggio usando tcpdump. Per farlo facciamo prima patire un ping cli da cli2:
fw:~# ipl lo: 127.0.0.1/8 eth1: 192.168.11.254/24 eth0: 10.16.0.1/24 ==> GW 10.16.0.254 - main tun0: 10.99.99.1 peer 10.99.99.2 fw:~# tcpdump -ni eth1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 11:53:31.730425 IP 192.168.12.1 > 192.168.11.1: ICMP echo request, id 53763, seq 338, length 64 11:53:31.731740 IP 192.168.11.1 > 192.168.12.1: ICMP echo reply, id 53763, seq 338, length 64Sull’interfaccia interna notiamo che i pcchetti sono di tipi icmp ovvero il protocollo usato da ping. Notate che per ogni request c’è un reply:
fw:~# tcpdump -ni eth0 not port ssh tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 12:05:38.879542 IP 10.16.0.2.1194 > 10.16.0.1.1194: UDP, length 84 12:05:38.880556 IP 10.16.0.1.1194 > 10.16.0.2.1194: UDP, length 84Sull’interfaccia eth0 gli argomenti passati a tcpdump evitano che venga mostrato tutto il traffico ssh, necessario a noi per connetterci. Qui i pacchetti sono udp: sono i pacchetti generati da openvpn che racchiudono le informazioni che noi inviamo (nel caso nostro i pacchetti icmp)
provate ad aggiungere una regola di firewalling per evitare che passi traffico da cli
Aggiungiamo la crittazione e la compressione, su fw facciamo partire:
ovpn 03_udp_crypto_comp.confAnalogamente sniffiamo il traffico
Guardiamo la configurazione, anzitutto dobbiamo quale ip remoto contattare e che protocollo usare:
remote fw1 proto udpPoi dobbiamo configurare la crittazione indicando la chiave Diffie-Hellman, il certificato della certificate Authority e le chiavi ed i certificati di client e server rispettivamente:
tls-client dh keys/dh1024.pem ca keys/ca.crt cert keys/client-fw2.crt key keys/client-fw2.keyDa ultimo occorre configurare il device di rete virtuale usato per la connessione:
dev tun ifconfig 10.0.0.2 10.0.0.1 255.255.255.0
Analizziamo la configurazione di un server, ovvero la configurazione che useremo per permettere ad utenti remoti di connettersi alla rete scolastica (docenti/genitori/alunni):
ovpn 20e_server_udp_route.conf ovpn 20_udp_client.confVa notato che questa configurazione non è analoga alla precedente e che se si vuole che coesistano occorre attivare due server openvpn differenti con configurazioni differenti.
Facciamo partire il server 20e su fw.
Spostiamoci su cli2 e verifichiamo che non riusciamo a pingare cli, verifichiamo la stessa cosa su fw2. Attiviamo ora il tunnel da cli2 a fw. Questo simula ad esempio una persona che da casa passi attraverso il proprio firewall e arrivi al server della scuola per connettersi alle risorse della scuola:
ovpn 20_udp_client.confusiamo il terminale libero su fw2 per connetterci via ssh a cli2 e da li provare un ping verso cli:
cli2:~# ping cli PING cli (192.168.11.1) 56(84) bytes of data. 64 bytes from cli (192.168.11.1): icmp_seq=1 ttl=63 time=4.30 ms 64 bytes from cli (192.168.11.1): icmp_seq=2 ttl=63 time=1.65 ms
Eseguiamo questo esercizio avvalendoci di mercurial per verificare il prodotto dei singoli comandi.
Spostiamoci nella cartella del tool pkitool e creiamo un repository di mercurial dopo avere pulito le chiavi esistenti:
# mkdir /root/easy-rsa # cp -av /usr/share/doc/openvpn/examples/easy-rsa/2.0 /root/easy-rsa # cd /root/easy-rsa/2.0/ # hg init # hg ci -A -m initPreparazione certificati. OpenVPN richiede per un funzionamento sicuro l’utilizzo di certificati crittocrafici (chiave pubblica/privata). Generiamoli:
# nano vars (editare i dati) # . vars # ./clear-all # hg st M vars ? keys/index.txt ? keys/serialche indica che sono stati generati due file (contraddistinti dal ?) e modificato il file vars, salviamo questo “stato” e procediamo a generare la Certificate Authoriity:
# hg ci -m "clear-all + vars" -A ./pkitool –-initcavediamo quali file sono stati generati:
# hg st ? keys/ca.crt ? keys/ca.keyche mostra che abbiamo prodotto due file nuovi (certificato e chiave) memorizziamo questa situazione:
# hg ci -m "ca: chiave e certificato" -A adding keys/ca.crt adding keys/ca.keyproduciamo ora chiave e certificato per il server:
./pkitool –server srv-isiProciamo la chiave ed il certificato per i client, che può essere spostato sui client (anche Windows ovviamente):
./pkitool client1 (pkitool –pass client1)E da ultimo produciamo a lunga chiave Diffie-Helmann:
./build-dh (diffie-helmann) (operazione lunga!) la posizione nel filesystem dove mettere i certificati è scritta nel file di confgurazione di openvpn.