Openvpn: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
 
(94 versioni intermedie di 10 utenti non mostrate)
Riga 1: Riga 1:
=Introduzione=
{{Versioni compatibili|Wheezy|Jessie}}{{Gateway-Router}}
Una VPN (''Virtual Private Network'') e' un tipo di interconnessione tra computer che permette, sul piano logico, di comprendere in una LAN (''Local Area Network'') computer residenti in qualsiasi parte del pianeta.
== Introduzione ==
Solitamente si considera una LAN come una rete di computer  locali, identificati da un indirizzo e una classe di ip (es: 192.168.0.0/24, 10.0.0.0/24 etc.). Con un collegamento VPN, un computer che si trovi fisicamente al di fuori di tale LAN, puo' risultarne un perfetto membro.  
Una VPN (''Virtual Private Network'') è un tipo di interconnessione tra computer che permette, sul piano logico, di comprendere in una LAN (''Local Area Network'') macchine residenti in qualsiasi parte del pianeta e soprattutto, di '''cifrare''', il traffico scambiato tra le stesse.<br/>
Solitamente si considera una LAN come una rete di computer  locali, identificati da un indirizzo e una classe di IP (es: 192.168.0.0/24, 10.0.0.0/24 etc.). Con un collegamento VPN, un computer che si trovi fisicamente al di fuori di tale LAN, può risultarne un perfetto membro.  


Tre computer, quindi, che si trovassero rispettivamente a Madrd, Londra e Roma potrebbero, grazie ad una vpn, creare la seguente rete:
Tre computer, quindi, che si trovassero rispettivamente a Madrid, Londra e Roma potrebbero, grazie ad una VPN, creare la seguente rete:
<pre>                                                   
<pre>                                                   
______________                      _______________  
______________                      _______________  
Riga 15: Riga 16:
                   |_____________|
                   |_____________|
</pre>
</pre>
La tecnica che permette di creare connessioni sicure attraverso reti insicure consiste nell' utilizzare un [[glossario:Tunneling | tunnel]] criptato attraverso il quale far transitare le nostre comunicazioni, rendendole di fatto invisibili all' esterno.
La tecnica che permette di creare connessioni sicure attraverso reti insicure consiste nell'utilizzare un [[Tunneling|tunnel]] criptato attraverso il quale far transitare le nostre comunicazioni, rendendole di fatto indecifrabili all'esterno.


==Prima di cominciare==
=== VPN commerciali per utenti comuni ===
La prima cosa da fare e' verificare in /dev la presenza della dir '''net''' contenente il device virtuale '''tun'''. Se tutto cio' non ci fosse, crearlo con:
 
Negli ultimi anni hanno cominciato a proliferare servizi di VPN commerciali indirizzati agli utenti comuni e non alle imprese. Tali servizi non mirano a creare una rete di computer in senso canonico, ma si propongono invece come nodi di uscita per il traffico generato da chi sottoscrive il servizio.
In pratica in tale scenario l'utente crea una rete condivisa col proprietario del server VPN in modo che tutto il traffico generato dall'utente sia diretto al server VPN, il quale poi lo smisterà normalmente attraverso la rete internet. Questo significa che i destinatari del traffico dell'utente vedranno come IP sorgente quello del server VPN e non quello del router-gateway dell'utente.
Usare una VPN conferisce quindi una certo grado di anonimato, almeno per gli utenti comuni che non passano il loro tempo a progettare attentati, minacciare politici e istituzioni, ecc. Inoltre permette di aggirare eventuali filtraggi del proprio traffico dati ad opera del proprio ISP, finalizzato per esempio ad impedire o semplicemente ostacolare l'uso di certi applicativi.
A dispetto di quanto sostenuto da chi offre questo genere di servizi il vero fine di una VPN è la cifratura delle connessioni, non l'anonimato, quindi un ipotetico dissidente politico che vivesse in un regime autoritario non dovrebbe usare una VPN per garantirsi l'anonimato, ma dovrebbe usare TOR (o meglio dovrebbe usare una VPN insieme a TOR).
La seconda cosa da tenere presente quando si sottoscrive un servizio di questo tipo è che si compie un atto di fiducia nei confronti di chi fornisce la VPN, infatti non esiste alcun modo per verificare indipendentemente che una certa azienda non registri o manipoli in alcun modo il traffico dati dei suoi utenti. Per questo è estremamente importante scegliere con cura il servizio, analizzando le faq, gli how-to, come sono scritti i termini di servizio, da quanto tempo è in attività, dove ha sede l'azienda e se il tale paese ha o meno leggi di "data retention".
Affidarsi a aziende poco serie, o peggio truffatori, in questo caso potrebbe infatti risultare peggio che non usare proprio alcuna VPN.
 
== Installazione ==
 
A prescindere da quello che si vuole fare il primo passo è installare OpenVPN:
 
<pre># apt-get install openvpn</pre>
 
== Creare una propria VPN ==
 
{{Box|Nota|Questa guida è stata scritta anni prima ed è ragionevolmente valida fino a Jessie. Una guida più recente è questa: [[Debian come server VPN]]}}
 
=== Prima di cominciare ===
La prima cosa da fare è verificare in <code>/dev</code> la presenza della directory <code>'''net'''</code> contenente il device virtuale <code>'''tun'''</code>. Se tutto ciò non ci fosse, crearlo con:
<pre>
<pre>
mkdir /dev/net && mknod /dev/net/tun c 10 200
# mkdir /dev/net && mknod /dev/net/tun c 10 200
</pre>
</pre>
..tirare su il rispettivo modulo e far si che al boot venga caricato:
tirare su il rispettivo modulo e far che al boot venga caricato:
<pre>
<pre>
# modprobe tun
# modprobe tun
# echo "tun" >> /etc/modules
# echo "tun" >> /etc/modules
</pre>
</pre>
{{Box|Nota|La creazione del device virtuale '''/dev/net/tun''' permettera' sia a tun che a tap di funzionare e di poter essere richiamati dall' applicazione al momento della connessione (''modo dinamico'') ; ed e' lo stesso device che permette ad Openvpn di crearsi quei device in modo permanente (''modo statico'').
{{Box|Nota|La creazione del device virtuale <code>'''/dev/net/tun'''</code> permetterà sia a <code>tun</code> che a <code>tap</code> di funzionare e di poter essere richiamati dall'applicazione al momento della connessione (''modo dinamico'') ; ed è lo stesso device che permette ad Openvpn di crearsi quei device in modo permanente (''modo statico'').
}}
}}


Infine abilitare il forwarding:
Infine abilitare il forwarding:
<pre>
<pre>
echo 1 > /proc/sys/net/ipv4/ip_forward
# echo 1 > /proc/sys/net/ipv4/ip_forward
</pre>
</pre>


==Openvpn & Iptables==
=== Openvpn e Iptables ===
Diamo le opportune regole al firewall:
Diamo le opportune regole al firewall:
<pre>
<pre>
Sul server:
iptables -A INPUT -p udp --dport 5000 -s 10.0.0.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p udp �dport 5000 -s 10.0.0.0/24 -m state �state NEW,ESTABLISHED,RELATED -j ACCEPT  
iptables -A INPUT -s 10.0.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT
Sui client:
iptables -A INPUT -p udp dport 5000 -s 10.0.0.0/24 -m state state NEW,ESTABLISHED,RELATED -j ACCEPT
</pre>
</pre>


=Generazione delle chiavi=
=== Generazione delle chiavi ===
Se non l'abbiamo gia' fatto:
Se non l'abbiamo già fatto:
<pre>
<pre>
# apt-get update && apt-get install openvpn
# apt-get update && apt-get install openvpn
</pre>
</pre>
    
    
Effettuiamo il collegamento fra due macchine, una chiamata in maniera molto originale '''server''' e una '''client'''. <br>Queste due macchine sono di due diversi utenti che possono risiedere ovunque nel mondo. La macchina server sara' quella in ascolto.
Effettuiamo il collegamento fra due macchine, una chiamata in maniera molto originale '''server''' e una '''client'''. <br>
Spostiamoci sul server, esattamente in /etc/openvpn e creiamo la nostra chiave con:  
Queste due macchine sono di due diversi utenti che possono risiedere ovunque nel mondo. La macchina server sarà quella in ascolto.<br>
Spostiamoci sul server, esattamente in <code>/etc/openvpn</code> e creiamo la nostra chiave con:  
<pre>
<pre>
# openvpn --genkey --secret zmo.key
# openvpn --genkey --secret zmo.key
</pre>
</pre>
Una volta creata dovremmo poterla copiare nella stessa dir del client. Questo passaggio dovrebbe essere fatto nel piu' sicuro dei modi ad esempio tramite mail crittografate, o utilizzando scp (''dalla suite Openssh'').
Una volta creata dovremmo poterla copiare nella stessa directory del client. Questo passaggio dovrebbe essere fatto nel più sicuro dei modi ad esempio tramite mail crittografate, o utilizzando <code>scp</code> (''dalla suite Openssh'': vedi la guida [[OpenSSH: file di configurazione]]).<br>
Utilizzando queste chiavi su tutti gli host (''crittografia simmetrica'') otteniamo una  notevole cifratura del nostro canale in maniera davvero rapida.
Utilizzando queste chiavi su tutti gli host (''crittografia simmetrica'') otteniamo una  notevole cifratura del nostro canale in maniera davvero rapida.


=Collegamento=
==== Configurazione chiavi condivise ====
==Configurazione shared-keys==
Spostiamoci sul server e creiamo in <code>/etc/openvpn</code> il file <code>server.conf</code> editandolo così:
Spostiamoci sul server e creiamo in /etc/openvpn il file server.conf editiandolo cosi':
<pre>
<pre>
dev tap
dev tap
Riga 71: Riga 88:
</pre>
</pre>


;'''dev''': identifica il device utilizzato per il tunnel. I possibili device utilizzabili da openvpn sono tun e tap. La differenza tra i due device e' fondamentale, in quanto tun si adopera per la trasmissione di pacchetti IP (''una specie di ppp'') e tap invece per la trasmissione di frame ethernet (''una specie di eth''). Per la creazione di lan virtuali o per la condivisione di risorse come file-server, ftp-server, dobbiamo usare tap.
;<code>'''dev'''</code>: identifica il device utilizzato per il tunnel. I possibili device utilizzabili da openvpn sono <code>tun</code> e <code>tap</code>. La differenza tra i due device è fondamentale, in quanto <code>tun</code> si adopera per la trasmissione di pacchetti IP (''una specie di <code>ppp</code>'') e <code>tap</code> invece per la trasmissione di frame ethernet (''una specie di <code>eth</code>''). Per la creazione di LAN virtuali o per la condivisione di risorse come file-server, ftp-server, dobbiamo usare <code>tap</code>.
;'''port''': socket dell'applicazione, il default e' la 5000, deve essere la stessa da ogni capo della vpn. E' da sottolineare che sul server invece di ''port'' si scrivera' '''lport''' (''local'') mentre sui client '''rport''' (''remote'').
;<code>'''port'''</code>: socket dell'applicazione, il default è la 5000, deve essere la stessa da ogni capo della VPN. È da sottolineare che sul server invece di <code>''port''</code> si scriverà <code>'''lport'''</code> (''local'') mentre sui client <code>'''rport'''</code> (''remote'').
;'''ifconfig''': determina l'ip dell'interfaccia virtuale (''tun o tap'').  
;<code>'''ifconfig'''</code>: determina l'IP dell'interfaccia virtuale (''<code>tun</code> o <code>tap</code>'').  
;'''secret''': a questa stringa diamo il path della key creata in precedenza con openvpn.
;<code>'''secret'''</code>: a questa stringa diamo il path della key creata in precedenza con openvpn.
;'''verb''': verb definisce il grado di verbose stampato a video in output durante l'esecuzione (''da 0 a 11 sono spiegati dando openvpn --help'').
;<code>'''verb'''</code>: "verb" definisce il grado di verbose stampato a video in output durante l'esecuzione (''da 0 a 11 sono spiegati dando <code>openvpn --help</code>'').


Adesso sul client creiamo il file '''/etc/openvpn/client.conf''' cosi':
Adesso sul client creiamo il file <code>'''/etc/openvpn/client.conf'''</code> così:
<pre>
<pre>
remote www.hostremoto.net (che ovviamente corrispondera' al server)
remote www.hostremoto.net (che ovviamente corrisponderà al server)
dev tap  
dev tap  
rport 5000
rport 5000shared-keys
ifconfig 10.0.0.2 255.255.255.0
ifconfig 10.0.0.2 255.255.255.0
secret /etc/openvpn/zmo.key
secret /etc/openvpn/zmo.key
Riga 87: Riga 104:
</pre>
</pre>


;'''remote''': a remote diamo l'ip pubblico della macchina alla quale ci connetteremo, oppure l'hostname come nell'esempio.
;<code>'''remote'''</code>: a remote diamo l'IP pubblico della macchina alla quale ci connetteremo, oppure l'hostname come nell'esempio.


A questo punto lanciamo il collegamento su entrambe le macchine, indicando al programma di attenersi alle regole appena definite nei rispettivi server.conf e client.conf:
A questo punto lanciamo il collegamento su entrambe le macchine, indicando al programma di attenersi alle regole appena definite nei rispettivi <code>server.conf</code> e <code>client.conf</code>:
<pre>
<pre>
# openvpn --config /etc/openvpn/xxxx.conf
# openvpn --config /etc/openvpn/xxxx.conf
Riga 110: Riga 127:
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
</pre>
</pre>
Nlla riga ''inet addr'' vengono indicati ip, broadcast e netmask.<br>
Nella riga <code>inet addr</code> vengono indicati IP, broadcast e netmask.<br>
Proviamo a pingare l'host che sappiamo connesso:
Proviamo a pingare l'host che sappiamo connesso:
<pre>
<pre>
Riga 117: Riga 134:
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=258 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=258 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=135 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=135 ms
</pre>
</pre>
In questo modo disporremo rapidamente di un canale cifrato relativamente sicuro, per lo scambio di dati privati.
In questo modo disporremo rapidamente di un canale cifrato relativamente sicuro, per lo scambio di dati privati.


==Configurazione SSL/TLS==
=== Configurazione SSL/TLS ===
===Openvpn & Openssl===
==== Openvpn e Openssl ====
Adesso, avvalendoci di SSL/TLS, configureremo un CA (''Certificate Authority'') che servira' a firmare i certificati degli host e a rendere disponibile il proprio; creeremo le rispettive chiavi (''una anche per il CA stesso'') facendo in modo che ognuno detenga una chiave e un certificato firmato. Infine, per lo scambio sicuro di tali dati, creeremo un Diffie-Hellman.
Adesso, avvalendoci di SSL/TLS, configureremo un CA (''Certificate Authority'') che servirà a firmare i certificati degli host e a rendere disponibile il proprio; creeremo le rispettive chiavi (''una anche per il CA stesso'') facendo in modo che ognuno detenga una chiave e un certificato firmato. Infine, per lo scambio sicuro di tali dati, creeremo un Diffie-Hellman.
<pre>
<pre>
apt-get install openssl
# apt-get install openssl
</pre>
</pre>


===Configurazione CA===
==== Configurazione CA ====
Il CA risiedera' sul server, ma distinguiamo le entita' in questo modo:  
Il CA risiederà sul server, ma distinguiamo le entità in questo modo:  
CA Server Client0 Client1...<br>
CA Server Client0 Client1...<br>
Occupiamoci del CA; facciamogli generare una sua chiave (''.key''), un suo certificato (''.csr'') e facciamogli firmare il suo certificato (''.crt''). Dunque, sempre sul server, torniamo in /etc/openvpn (''la chiave precedentemente usata, zmo.key, non serve piu' '').
Occupiamoci del CA; facciamogli generare una sua chiave (<code>ca.key</code>), una sua richiesta di certificato (<code>rich.ca</code>), facciamogliela autofirmare (<code>ca.cert</code>) e depositare successivamente su ogni host. Dunque, sempre sul server, torniamo in <code>/etc/openvpn</code>.
   
   
<pre>
<pre>
Riga 139: Riga 156:
e is 65537 (0x10001)
e is 65537 (0x10001)


# openssl req -new -key ca.key -out ca.csr
# openssl req -new -key ca.key -out rich.ca
You are about to be asked to enter information that will be incorporated
You are about to be asked to enter information that will be incorporated
into your certificate request.
into your certificate request.
Riga 152: Riga 169:


<pre>
<pre>
# openssl x509 -req -in ca.csr -signkey ca.key �out ca.crt
# openssl x509 -req -in rich.ca -signkey ca.key -out ca.cert
Signature ok
Signature ok
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
Getting Private key
Getting Private key
</pre>
</pre>
Ricapitolando dovremmo aver creato '''ca.crt ca.csr''' e '''ca.key'''.
Ricapitolando dovremmo aver creato <code>'''ca.key rich.ca'''</code> e <code>'''ca.cert'''</code>.
Bene, siamo sempre sul server. Per fare ordine, creiamo una dir e riponiamoci i file del CA creati:
<pre>
# mkdir CA && mv ca* CA
</pre>


===TLS-Server & TLS-Client===
==== TLS-Server & TLS-Client ====
Occupiamoci ora di server e client, la loro configurazione e' quasi uguale:
Occupiamoci ora di server e client, la loro configurazione è pressoché uguale.<br>
Sul server:
Sul server:
<pre>
<pre>
# openssl genrsa -out server.key
# openssl genrsa -out server.key
# openssl req -new -key ca.key -out server.csr
# openssl req -new -key server.key -out rich.ser
</pre>
</pre>
Facciamo firmare al CA il certificato del server:
Facciamo firmare al CA la richiesta di certificato del server:
<pre>
<pre>
# openssl x509 -req -in server.csr -CA CA/ca.crt -CAkey CA/ca.key -CAcreateserial -out server.crt
# openssl x509 -req -in rich.ser -CA ca.cert -CAkey ca.key -CAcreateserial -out ser.cert
</pre>
</pre>
Sul server creiamo anche il Diffie-Hellman:
Sul server creiamo anche il Diffie-Hellman:
Riga 178: Riga 191:
# openssl dhparam -out dh.pem 1024
# openssl dhparam -out dh.pem 1024
</pre>
</pre>
{{Box|Nota|L'input format di default adottato da dhparam e' PEM. Per usare DER usare il flag �inform. Per una ulteriore consultazione del flag dhparam, fare riferimento a questa pagina: [http://www.mkssoftware.com/docs/man1/openssl_dhparam.1.asp openssl dhparam]
{{Box|Nota|Il format di default adottato da <code>dhparam</code> è PEM (''adozione standard di Unix''). Per una ulteriore consultazione del flag <code>dhparam</code>, fare riferimento a questa pagina: Openssl dhparam<sup>[[#Riferimenti|[1]]]</sup>
}}
}}


Riga 184: Riga 197:
<pre>
<pre>
# openssl genrsa -out client.key
# openssl genrsa -out client.key
# openssl req -new -key ca.key -out client.csr
# openssl req -new -key client.key -out rich.cli
</pre>
</pre>
Spediamo il certificato al CA (''che risiede sul server''), facciamocelo firmare e rispedire in /etc/openvpn (''stessa procedura del server per la firma'').
Spediamo il certificato al CA (''che risiede sul server''), facciamocelo firmare e rispedire in <code>/etc/openvpn</code> (''stessa procedura del server per la firma'').


'''Server.conf''',br>
<code>'''Server.conf'''</code><br>
Compilare cosi' il file per il server:
Compilare così il file per il server:
<pre>
<pre>
dev tap
dev tap
Riga 195: Riga 208:
tls-server
tls-server
dh dh.pem
dh dh.pem
ca CA/ca.crt
ca ca.cert
cert server.crt
cert ser.cert
key server.key
key server.key
lport 5000
lport 5000
Riga 202: Riga 215:
</pre>
</pre>


'''Client.conf'''<br>
<code>'''Client.conf'''</code><br>
Compilare cosi' il file per il client:
Compilare così il file per il client:
<pre>
<pre>
remote www.hostremoto.net (che ovviamente corrispondera' al server)
remote www.hostremoto.net (che ovviamente corrisponderà al server)
dev tap
dev tap
ifconfig 10.0.0.2 255.255.255.0
ifconfig 10.0.0.2 255.255.255.0
tls-client
tls-client
ca ca.crt
ca ca.cert
cert client.crt
cert cli.cert
key client.key
key client.key
rport 5000
rport 5000
Riga 216: Riga 229:
</pre>
</pre>


Una volta compilati i file, lanciamo openvpn su entrambe le macchine come precedentemente:
Una volta compilati i file, lanciamo <code>openvpn</code> su entrambe le macchine come in precedenza:
<pre>
<pre>
openvpn �config xxxx.conf
openvpn –config xxxx.conf
</pre>
</pre>


=Demonizzare Openvpn=
=== Avviare Openvpn come servizio ===
==Lo script /etc/init.d/openvpn==
==== Lo script <code>/etc/init.d/openvpn</code> ====
Come gia' accennato in precedenza, con l'installazione tramite apt viene aggiunto lo script '''/etc/init.d/openvpn'''. Questo script, che demonizza openvpn, una volta lanciato va a cercare nella dir /etc/openvpn il file con estensione '''.conf''' che dovra' corrispondere al file di configurazione. Dico questo poiche' in varie documentazioni lo troverete con estensioni diverse (''es: .ovpn etc..'') che lo script non riconoscerebbe come valido.  
Questo script, che demonizza <code>openvpn</code>, una volta lanciato va a cercare nella dir <code>/etc/openvpn</code> il file con estensione <code>'''.conf'''</code> che dovrà corrispondere al file di configurazione. Dico questo poiché in varie documentazioni lo troverete con estensioni diverse (''es: .ovpn etc..'') che lo script non riconoscerebbe come valido.  
<pre>
<pre>
# /etc/init.d/openvpn start
# /etc/init.d/openvpn start
</pre>
</pre>
Una volta avviato lo script attivera' il demone. Per impostarlo al boot:
Una volta avviato lo script attiverà il [[demone]]. Per impostarlo al boot:
<pre>
<pre>
# update-rc.d openvpn defaults
# update-rc.d openvpn defaults
</pre>
</pre>
Per rimuoverlo dal boot:
==Openvpn & log==
<pre>
Per loggare l'output in un file qualunque (''anche se non esiste verra' creato'') aggiungere la riga al file .conf:
# update-rc.d -f openvpn remove
</pre>
 
==== Openvpn & log ====
Per loggare l'output in un file qualunque (''anche se non esiste verrà creato'') aggiungere la riga al file <code>.conf</code>:
<pre>
<pre>
log /var/log/openvpn.log
log /var/log/openvpn.log
</pre>
</pre>
Il file di log sara'piu' o meno forbito in base al valore che avremo dato al parametro '''verb'''.
Il file di log sarà più o meno forbito in base al valore che avremo dato al parametro <code>'''verb'''</code>.
 
=== Conclusioni ===
Openvpn<sup>[[#Riferimenti|[2]]]</sup> permette la creazione di VPN da applicativo ad applicativo, non necessitando quindi di modifiche nel [[kernel]] come nel caso di VPN che implementino IPSEC. Gira sulle principali piattaforme allacciando quindi OS diversi. Anche se lo standard IPSEC è una realtà nei dispositivi di rete hardware, il livello di sicurezza che <code>openvpn</code> può raggiungere è indiscutibile.
 
== Usare una VPN commerciale ==
 
Molti fornitori di servizi VPN a pagamento supportano tra i diversi client anche e soprattutto OpenVPN. Se tutto quello che vuole fare l'utente è collegarsi direttamente dal proprio computer allora la questione è molto semplice, infatti chi scrive ha provato due differenti servizi ed in entrambi i casi la procedura è stata immediata e senza alcun tipo di problema.
Se invece si vuole stabilire un unico tunnel per tutta la propria rete domestica la cosa diventa più complessa, ma in ogni caso è necessario scaricare in anticipo i file di configurazione che il fornitore mette a disposizione (si veda più sotto per un paio di esempi). Generalmente ogni fornitore mette a disposizione un file di configurazione per ogni località in cui ha un proprio server. Detti file hanno spesso estensione <code>.ovpn</code> e sono pressoché identici tra loro, fatto salvo l'indirizzo (o gli indirizzi) dei server cui connettersi.
{{Box|Nota|Il client openvpn crea sempre un'interfaccia di rete aggiuntiva chiamata <code>tun0</code> per gestire la connessione col server VPN. Tale interfaccia ha un suo indirizzo IP privato appartenenete ad una subnet diversa da quella già in uso sul computer client.
}}
{{Warningbox|
* Il client OpenVPN apporterà delle modifiche alla tabella di routing del proprio computer in modo che tutte le connessioni dirette a subnet esterne alla propria LAN (cioè a internet) siano forzate ad usare l'interfaccia <code>tun0</code>, cioè a transitare attraverso il server VPN. Oltre a ciò verrà aggiunto anche un secondo gateway che avrà precedenza superiore a quello predefinito dell'utente. Alla chiusura della connessione VPN saranno automaticamente ripristinate le impostazioni originali.
* I file di configurazione forniti dai fornitori della rete VPN non sono pensati per situazioni in cui un utente ha molteplici tunnel attivi, pertanto in tali situazioni l'utente dovrà necessariamente costruirsi dei file di configurazione personalizzati in modo che ogni tunnel non vada in conflitto con gli altri (questo caso non è trattato)}}
 
=== Uso singolo ===
 
Come già detto collegarsi ad un server VPN direttamente dal computer in uso è estremamente facile, è infatti possibile usare il client <code>openvpn</code> da terminale, oppure l'apposita funzionalità di network-manager (o altro client, ma qui si tratterà solo il caso di network-manager.
In entrambi i casi è
 
==== Terminale ====
 
Aprire un terminale e digitare:
 
<pre>$ openvpn --config nome_file_configurazione.ovpn</pre>
 
Verranno richiesti nome utente e password, dopo di che a video compariranno i log di quello che succede e la connessione risulterà stabilita. La finestra del terminale deve restare aperta fintanto che si vuole rimanere collegati alla VPN, pertanto potrebbe fare comodo usare un applicativo come GNU/Screen per eseguire il predetto comando.
Per terminare la connessione è sufficiente premere '''<code>CTRL+C</code>'''.<br>
Volendo poi verificare che l'IP visibile dall'esterno sia effettivamente diverso da quello assegnato dal proprio provider internet è possibile digitare:
 
<pre>$ curl ipinfo.io/ip</pre>
 
Oppure caricare una delle tante pagine web che mostrano il proprio IP pubblico.
 
==== Network-Manager ====
 
# Aprire l'editor delle connessioni di network-manager e cliccare sulla voce ''Connessione''
# Dal menù selezionare ''importa VPN'' e quindi aprire il file di configurazione scaricato dal proprio fornitore VPN
# Alla domanda ''Vuoi copiare i tuoi certificati in /home/kwisatzhaderach/.local/share/networkmanagement/certificates/?'' premere ''OK''
# Nell'editor di connessioni dovrebbe ora comparire una nuova connessione, selezionarla e quindi premere ''Modifica'' dal menù in alto.
# Nella scheda ''VPN (openvpn)'' è necessario compilare i campi ''Nome utente'' e ''Password'' con i propri dati. Premere ''OK''
 
A questo punto la connessione è pronta e sarà sufficiente selezionarla da Network-Manager per avviarla (esattamente come qualsiasi altra connessione).
 
=== Uso gateway ===
 
È generalmente conveniente effettuare il collegamento al server VPN dal router, in modo da avere un unico tunnel da cui far passare tutto il traffico in uscita invece che creare un tunnel per ogni dispositivo. Tale scelta è particolarmente conveniente se il proprio fornitore di VPN limita il massimo numero di connessioni che possono essere attive contemporaneamente (che è la prassi).
Sebbene più ordinata come soluzione tale approccio potrebbe generare problemi nel caso si abbiano dei servizi che accettano nuove connessioni provenienti da internet, tipo un webserver, infatti in genere ogni fornitore configura i client della propria VPN in modo che tutto il traffico sia automaticamente dirottato attraverso il tunnel VPN. Il problema è che non è scontato che dia anche la possibilità di aprire le porte necessarie, o quanto meno un numero adeguato.
In tal caso c'è poco da fare e si avranno due possibili scenari:
* se si vuole far passare tutti i servizi attraverso il tunnel VPN allora non si potrà far altro che eseguire contemporaneamente solo un numero di servizi pari al numero di porte disponibili.
* se si è disposti a non far passare uno o più servizi attraverso il tunnel VPN, tipo un web server, allora si tratta "solo" di configurare il computer che funge da router opportunamente.
 
A prescindere dal proprio scenario la configurazione di openvpn è la medesima e prevede l'utilizzo di openvpn come servizio. Digitando da terminale <code>ls -hl /etc/openvpn/</code> apparirà quanto segue:
<pre>
drwxr-xr-x 2 root root client
drwxr-xr-x 2 root root server
-rwxr-xr-x 1 root root update-resolv-conf
</pre>
Il file <code>update-resolv-conf</code> è uno script che viene installato automaticamente insieme ad openvpn e serve per permettere al server vpn cui ci si collega di spingere al nostro computer gli indirizzi dei server DNS del fornitore VPN stesso, in modo che la nostra macchina usi tali DNS e non quelli normalmente usati. Si veda la sezione con gli esempi dei file di configurazione per maggiori informazioni in merito.<br>
Le sottocartelle <code>client</code> e <code>server</code> permettono di separare i file di configurazione relativi al client VPN da quelli di un eventuale server (un computer potrebbe teoricamente essere usato sia per creare più tunnel verso altri server VPN che per fungere esso stesso da server VPN), ma il loro utilizzo non è obbligatorio, infatti si può semplicemente mettere tutto in <code>/etc/openvpn/</code>.
È tuttavia fondamentale sapere che l'utilizzo di ciascuna cartella dipende strettamente da come viene avviato il servizio VPN, infatti openvpn può essere avviato con tre comandi diversi:
<pre>
# systemctl start openvpn@nome_file_configurazione
# systemctl start openvpn-client@nome_file_configurazione
# systemctl start openvpn-server@nome_file_configurazione
</pre>
Nel primo caso il file di configurazione <code>nome_file_configurazione</code> deve obbligatoriamente trovarsi in <code>/etc/openvpn/</code>, mentre negli altri due rispettivamente in <code>/etc/openvpn/client/</code> e <code>/etc/openvpn/server/</code>. Si possono avere molteplici file di configurazione nella stessa cartella e tutti possono essere nominati come meglio si crede, tuttavia quando si avvia il servizio il nome specificato dopo il carattere '''<code>@</code>''' dovrà necessariamente coincidere con quello effettivamente presente nella corrispondente cartella. È altresì necessario che ogni file di configurazione abbia estensione '''<code>.conf</code>''', quindi se i file di configurazione scaricati hanno estensione '''<code>.ovpn</code>''' questi dovranno essere opportunamente rinominati.
Oltre ai file di configurazione è anche necessario che nella stessa cartella siano presenti i relativi file contenenti la credenziali per accedere alle varie VPN (si veda la sezione sottostante con gli esempi di file di configurazione).
Oltre al comando '''<code>start</code>''' sono supportati anche altri comandi, quali '''<code>restart</code>''', '''<code>stop</code>''', '''<code>status</code>''', ecc.


=Conclusioni=
A questo punto la connessione al proprio server VPN dovrebbe essere attiva, ma il traffico proveniente da altre macchine non sarà accettato se prima non si è abilitato il reindirizzamento a livello del kernel. Vedere [http://guide.debianizzati.org/index.php/Pppoeconf#IP_forwarding questa guida] per sapere come fare.
[www.openvpn.net Openvpn] permette la creazione di vpn da applicativo ad applicativo, non necessitando quindi di modifiche nel kernel come nel caso di vpn che implementino IPSEC. Gira su le principali piattaforme allacciando quindi OS diversi.Anche se lo standard IPSEC e' una realta' nei dispositivi di rete hardware, il livello di sicurezza che openvpn puo' raggiungere e' indiscutibile.
 
Normalmente i fornitori VPN non lasciano porte aperte, quindi in teoria non vi sarebbe alcun bisogno di configurare un firewall sulla propria macchina, tuttavia fidarsi bene e non fidarsi è meglio ed è dunque opportuno configurare delle regole anche per l'interfaccia <code>tun0</code>. Si veda per esempio [http://guide.debianizzati.org/index.php/Debian_e_iptables#Uso_di_una_VPN_commerciale questa guida].
 
==== Avvio automatico ====
 
Per avviare automaticamente la connessione VPN all'avvio del computer è sufficiente usare l'apposito comando di <code>systemd</code>:
<pre># systemctl enable openvpn-client@nome_file_configurazione</pre>
dove <code>nome_file_configurazione</code> è il file di configurazione <code>/etc/openvpn/client/nome_file_configurazione.conf</code> del proprio client.
Di converso per disabilartne l'avvio automatico è sufficiente impartire:
<pre># systemctl disable openvpn-client@nome_file_configurazione</pre>
 
==== Scenario misto ====
 
Nel caso si abbia necessità di rendere un servizio, come un webserver, accessibile direttamente senza passare dal tunnel VPN è possibile procedere come segue.
{{Suggerimento|Prima di procedere si consiglia la lettura delle guide dedicate a [[Iproute2]] e [[Debian e iptables | IPtables]].}}
1 - Creare una nuova tabella di routing, che sarà chiamata per semplicità "tab1" (come descritto per esempio nella sezione ''Aggiungere tabelle di routing'' della guida di [[Iproute2]]).<br>
2 - Aggiungere le rotte standard del proprio computer a "tab1", ovvero le rotte definite in automatico dalla propria macchina quando non è in esecuzione alcun servizio VPN. Per esempio nel caso di macchina che funge da gateway sfruttando [[pppoeconf]] potrebbero essere sufficienti i seguenti due comandi:
<pre>
# ip route add default dev ppp0 table tab1
# ip route add 192.168.1.0/24 dev eth0 src 192.168.1.172 table tab1
</pre>
Dove si suppone che la macchina su cui è in esecuzione il servizio abbia IP <code>192.168.1.172</code><br>
3 - Aggiungere una regola per cui si dichiara che per i pacchetti provenienti dall'interfaccia con cui ci si connette ad internet, ad esempio <code>ppp0</code>, è necessario usare la tabella di routing "tab1" invece di quella principale
<pre># ip rule add from AAA.BBB.CCC.DDDD table tab1</pre>
Dove con <code>AAA.BBB.CCC.DDDD</code> si intende l'IP associato all'interfaccia <code>ppp0</code>, cioè quello pubblico effettivamente attribuitoci dal nostro ISP (e non quindi quello del server VPN di uscita). Da notare che anche nel caso non si usasse <code>pppoeconf</code> l'ip da specificare sarebbe sempre quello dell'interfaccia attraverso cui transita il traffico internet (<code>eth1</code> in questo esempio), anche se privato e non pubblico.<br>
4 - Aggiungere delle regole al firewall per assicurarsi di non poter mischiare il traffico tra l'interfaccia internet, es. <code>ppp0</code>, e quella della VPN, es. <code>tun0</code>. Per maggiori informazioni si veda ad esempio la [http://guide.debianizzati.org/index.php/Debian_e_iptables#Uso_di_una_VPN_commerciale sezione apposita della guida di iptables].
 
Arrivati a questo punto il servizio prescelto dovrebbe essere normalmente raggiungibile attraverso la nostra interfaccia internet, tuttavia è importante sottolineare quanto segue:
* Le rotte e le regole create non sono permanenti, ovvero andranno perse al momento di un eventuale riavvio, quindi in tale caso l'utente dovrà nuovamente ripetere la procedura qui descritta. Il problema dovrebbe essere ovviabile dichiarando opportunamente i precedenti comandi nel file <code>/etc/network/interfaces</code>, come riportato nel seguente esempio che contiene una configurazione sia per l'interfaccia <code>ppp0</code> che <code>eth0</code>
<pre>
auto dsl-provider
iface dsl-provider inet ppp
pre-up /bin/ip link set eth1 up
provider dsl-provider
post-up /bin/ip route flush table 1
post-up /bin/ip route add default dev ppp0 table 1
post-up /bin/ip rule add from $(ip -f inet addr show ppp0 | grep -Po 'inet \K[\d.]+') table 1
 
auto eth0
iface eth0 inet static
        address 192.168.1.172
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        post-up /bin/ip route add 192.168.1.0/24 dev eth0 src 192.168.1.172 table 1
</pre>
* Se non si dispone di un IP pubblico statico, ma solo dinamico, sarà necessario eliminare e dichiarare nuovamente il comando descritto al punto 3 ogni volta che detto IP pubblico cambia. A tale fastidio si può ovviare sostituendo alla regola del punto 3 una dichiarazione basata sull'uso dell'opzione <code>fwmark</code> e del target <code>mark</code> di IPtables, oppure creando uno script che ad intervalli regolari verifica il proprio IP pubblico attuale ed eventualmente aggiorna rotte e regole come necessario. A puro titolo esemplificativo si mostra lo script usato da chi scrive (e quindi ritagliato sulla propria specifica configurazione macchina):
<pre>
#!/bin/bash
# CRON: */10 * * * * /percorso/script/nome_script.sh
PPP=$(ip addr | grep 'ppp0')
IPO=$(ip rule | grep '32765' | tr -d '[a-z ]' | sed 's/32765:\t//1')
TAB=$(ip route show table tab1)
DATA=$(date +'%b %d %T')" nome_host nome_script.sh: "
# Check first if secondary routing table is empty
if [ "$TAB" = '' ]
then
ip route add default dev ppp0 table tab1
# Next command is necessary to be able to connect to the web server using my fqdn, like "blabla.fornitore.net"
# from inside the LAN
ip route add 192.168.1.0/24 dev br0 src 192.168.1.172 table tab1
MSG1=$DATA"secondary routing table was empty, added ppp0 as default gateway."
else
MSG1=$DATA"secondary routing table was not empty, nothing to do."
fi
echo $MSG1 >> /var/log/syslog
# Check now if ppp0 inet ip has changed
if [ "$PPP" != '' ]
then
IPN=$(ip -f inet addr show ppp0 | grep -Po 'inet \K[\d.]+')
if [ "$IPN" != "$IPO" ] && [ "$IPN" != "" ]
then
if [ "$IPO" = '' ]
then
MSG0=" (missing secondary routing table rule)"
else
MSG0=" (secondary routing table rule found)"
ip rule del table tab1
fi
ip rule add from $IPN table tab1
MSG2=$DATA"IP changed from "$IPO" to "$IPN$MSG0". Rule updated."
else
MSG2=$DATA"IP ($IPO / $IPN) has not changed, nothing to do."
fi
else
MSG2=$DATA"failed to read inet address (is interface up?)."
fi
echo $MSG2 >> /var/log/syslog
</pre>
 
==== Streaming e VPN ====
 
Sfortunatamente alcuni servizi di streaming rendono impossibile la fruzione dei loro contenuti a chi usa una VPN per ragioni legate allo sfruttamento dei diritti commerciali (che nella stragrande maggioranza dei casi sono ripartiti per aree geografiche).
In tali situazioni c'è poco da fare, l'unica soluzione è non usare temporaneamente la VPN per il traffico web. Non è infatti è possibile, per la complessità di tali servizi, instradare il traffico semplicemente sulla base del dominio web.<br>
Un semplice palliativo, che richiede solo un minimo di disciplina personale, è quello di crearsi una seconda configurazione per l'interfaccia di rete in uso sul proprio PC (e '''NON''' sul gateway della LAN), in modo da poter specificare un diverso indirizzo privato. In questo modo a livello di gateway sarà possibile aggiungere una regola tale per cui si dichiara che il traffico dati proveniente da questo nuovo IP non dovrà essere gestito dalla tabella di routing principale, ma da una alternativa.<br>
La procedura per creare tale tabella è identica a quella descritta nella sezione precedente "''Scenario misto''", pertanto se già si sono seguite le relative istruzioni non è necessario configurare una terza tabella, viceversa andrà appunto creata. Il punto è che serve una tabella alternativa a quella principale in modo da ignorare le rotte imposte dal prioprio servizio VPN.<br>
In sintesi quando si vuole usare un servizio che blocca le VPN si cambia la configurazione di rete in uso.<br>
Ipotizzando che l'indirizzo IP della configurazione di rete alternativa sia <code>192.168.1.107</code> allora sarà sufficiente dare il seguente comando sul proprio PC gateway:
<pre># ip rule add from 192.168.1.107 table 1</pre>
Si ricorda che le regole di routing vengono perse ad ogni riavvio, pertanto l'utente dovrà aggiungere al file <code>/etc/network/interfaces</code> del proprio PC gateway, in corrispondenza dell'interfaccia cui si collegano tutti i PC della LAN, una direttiva di questo tipo:
<pre>post-up /bin/ip rule add from 192.168.1.107 table 1</pre>
La sezione relativa all'interfaccia <code>eth0</code> (o quello che è a seconda del setup del lettore) sarà quindi simile a quanto segue:
<pre>
auto eth0
iface eth0 inet static
        address 192.168.1.172
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        post-up /bin/ip route add 192.168.1.0/24 dev eth0 src 192.168.1.172 table 1
        post-up /bin/ip rule add from 192.168.1.107 table 1
</pre>
 
===== Script ausiliario =====
 
Poiché è scontato che prima o poi si finisca per dimenticarsi di ritornare alla configurazione di rete standard una volta finito di usare il servizio di streaming è possibile organizzarsi nel seguente modo per ridurre al minimo tale evenienza:
# usare un browser dedicato diverso da quello solito per usufruire dei servizi di streaming;
# evitare di avviare direttamente il suddetto browser, ma usare uno script apposito che si occupi anche di cambiare automaticamente il profilo di rete da usare.
Lo script indicato qui sotto, estremamente semplice, sfrutta il browser "Vivaldi" e <code>nmcli</code> (lo strumento a riga di comando per gestire network manager) per cambiare/ripristinare le configurazioni di rete:
<pre>
#!/bin/bash
# È necessario aver già creato entrambe le reti in Network Manager.
# Si suppone che l'IP di "NOVPN" sia 192.168.1.107
nmcli con down CONVPN
nmcli con up NOVPN
vivaldi indirizzo_web
nmcli con down NOVPN
nmcli con up CONVPN
</pre>
 
=== File di configurazione ===
 
Di seguito un paio di esempi presi da due differenti fornitori. Le opzioni che interessano l'utente sono essenzialmente tre:
* '''remote''': qui viene specificato l'indirizzo del server VPN e il numero di porta da usare.
* '''auth-user-pass''': questa direttiva definisce come avverrà l'autenticazione presso il server VPN, se infatti non viene specificato un file contenente i dati di accesso questi verranno semplicemente richiesti al primo tentativo di connessione, ovvero username e password. Viceversa se viene specificato questo dovrà essere un semplice file testuale composto da due righe, la prima dove viene indicato il nome utente e la seconda dove si specifica la password corrispondente al nome utente indicato nella prima riga. Generalmente il file di credenziali non viene mai specificato a meno di non voler automatizzare la connessione alla VPN usando systemctl.
* '''up''' e '''down''' <code>/etc/openvpn/update-resolv-conf</code>, usate per sostituire in automatico gli indirizzi dei server DNS con quelli del fornitore del servizio VPN. Quando il client VPN viene terminato vengono automaticamente ripristinati i DNS originali dell'utente. Se non si vuole usare i DNS del fornitore VPN è sufficiente commentare le suddette due direttive. Si noti che lo script </code>/etc/openvpn/update-resolv-conf</code> non è legato al fornitore VPN, ma è proprio uno strumento incluso con il client di openvpn (almeno in Debian). Per questo non tutti i fornitori di servizio includono le suddette direttive nei loro file di configurazione.
 
==== Esempio file credenziali ====
<pre>
Caio
La_mia_complicatissima_password
</pre>
 
==== Esempio 1 ====
 
<pre>
client
dev tun
proto udp
remote indirizzo_server_vpn numero_porta
auth-user-pass nome_file_credenziali_accesso
 
resolv-retry infinite
nobind
persist-tun
persist-key
persist-remote-ip
 
cipher AES-256-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-DSS-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA
remote-cert-tls server
verify-x509-name it name-prefix
key-direction 1
comp-lzo no
verb 3
 
;ca ca.crt
<ca>
-----BEGIN CERTIFICATE-----
 
stringa caratteri certificato
 
-----END CERTIFICATE-----
</ca>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
 
stringa caratteri chiave
 
-----END OpenVPN Static key V1-----
</tls-auth>
</pre>
 
==== Esempio 2 ====
<pre>
proto udp
tun-mtu 1500
fragment 1300
mssfix
cipher AES-256-CBC
ignore-unknown-option ncp-disable # ovpn 2.3 to 2.4 transition
ncp-disable
 
remote indirizzo_server_vpn1 numero_porta1
remote indirizzo_server_vpn2 numero_porta2
remote indirizzo_server_vpn3 numero_porta3
 
auth SHA512
auth-user-pass nome_file_credenziali_accesso
client
comp-lzo
dev tun
hand-window 120
inactive 604800
mute-replay-warnings
nobind
remote-cert-tls server
persist-key
persist-remote-ip
persist-tun
ping 5
ping-restart 120
redirect-gateway def1
remote-random
reneg-sec 3600
resolv-retry 60
route-delay 2
route-method exe
script-security 2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA
tls-timeout 5
verb 4
tun-ipv6
 
down /etc/openvpn/update-resolv-conf
up /etc/openvpn/update-resolv-conf
 
key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
 
Stringa caratteri certificato
 
-----END CERTIFICATE-----
 
</ca>
 
<cert>
-----BEGIN CERTIFICATE-----
 
Stringa caratteri certificato
 
-----END CERTIFICATE-----
 
</cert>
 
<key>
-----BEGIN PRIVATE KEY-----
 
Stringa chiave privata
 
-----END PRIVATE KEY-----
 
</key>
 
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
 
Stringa caratteri chiave
 
-----END OpenVPN Static key V1-----
</tls-auth>
</pre>
 
== Approfondimenti ==
 
=== Manpages ===
 
<pre>man openvpn</pre>
 
=== Sitografia ===
 
* [http://openvpn.net Openvpn.net], sito ufficiale OpenVPN
* [http://a2.pluto.it/a2/a258.htm#almlindex4169 sez. "IPTables per l'amministrazione del firewall" di Appunti di informatica libera];
* [http://www.mkssoftware.com/docs/man1/openssl_dhparam.1.asp OpenSSL dhparam]
* [http://www.openssl.org www.openssl.org]
<!-- [http://milano.linux.it/contributi/ValentinoSquilloni.pdf Openvpn e reti private virtuali]<br>
LINK ROTTO E AL MOMENTO IRRINTRACCIABILE -->
* [http://a2.pluto.it/a2/a263.htm#almltitle2684 Appunti Linux]
 
{{Autori
|Autore = [[Utente:Zmo.zmo|zmo]]
|Estesa_da = [[Utente:Wtf|Wtf]] 18:36, 20 gen 2019 (CET)
}}


Autore: [[Utente:Zmo.zmo|zmo]]
[[Categoria:VPN]]

Versione attuale delle 21:25, 23 feb 2020

Edit-clear-history.png Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.

Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione.


Debian-swirl.png Versioni Compatibili

Debian 7 "wheezy"
Debian 8 "jessie"
Gateway-Router

Sommario

Introduzione

Una VPN (Virtual Private Network) è un tipo di interconnessione tra computer che permette, sul piano logico, di comprendere in una LAN (Local Area Network) macchine residenti in qualsiasi parte del pianeta e soprattutto, di cifrare, il traffico scambiato tra le stesse.
Solitamente si considera una LAN come una rete di computer locali, identificati da un indirizzo e una classe di IP (es: 192.168.0.0/24, 10.0.0.0/24 etc.). Con un collegamento VPN, un computer che si trovi fisicamente al di fuori di tale LAN, può risultarne un perfetto membro.

Tre computer, quindi, che si trovassero rispettivamente a Madrid, Londra e Roma potrebbero, grazie ad una VPN, creare la seguente rete:

                                                   
______________                       _______________ 
|    LAN      | ----- INTERNET ----- |    LAN      |
|   Madrid    |          |           |    Roma     |
| 192.168.0.1 |          |           | 192.168.0.3 |
|_____________|    ______|_______    |_____________|
                  |     LAN     |         
                  |    Londra   |           
                  | 192.168.0.2 |            
                  |_____________|

La tecnica che permette di creare connessioni sicure attraverso reti insicure consiste nell'utilizzare un tunnel criptato attraverso il quale far transitare le nostre comunicazioni, rendendole di fatto indecifrabili all'esterno.

VPN commerciali per utenti comuni

Negli ultimi anni hanno cominciato a proliferare servizi di VPN commerciali indirizzati agli utenti comuni e non alle imprese. Tali servizi non mirano a creare una rete di computer in senso canonico, ma si propongono invece come nodi di uscita per il traffico generato da chi sottoscrive il servizio. In pratica in tale scenario l'utente crea una rete condivisa col proprietario del server VPN in modo che tutto il traffico generato dall'utente sia diretto al server VPN, il quale poi lo smisterà normalmente attraverso la rete internet. Questo significa che i destinatari del traffico dell'utente vedranno come IP sorgente quello del server VPN e non quello del router-gateway dell'utente. Usare una VPN conferisce quindi una certo grado di anonimato, almeno per gli utenti comuni che non passano il loro tempo a progettare attentati, minacciare politici e istituzioni, ecc. Inoltre permette di aggirare eventuali filtraggi del proprio traffico dati ad opera del proprio ISP, finalizzato per esempio ad impedire o semplicemente ostacolare l'uso di certi applicativi. A dispetto di quanto sostenuto da chi offre questo genere di servizi il vero fine di una VPN è la cifratura delle connessioni, non l'anonimato, quindi un ipotetico dissidente politico che vivesse in un regime autoritario non dovrebbe usare una VPN per garantirsi l'anonimato, ma dovrebbe usare TOR (o meglio dovrebbe usare una VPN insieme a TOR). La seconda cosa da tenere presente quando si sottoscrive un servizio di questo tipo è che si compie un atto di fiducia nei confronti di chi fornisce la VPN, infatti non esiste alcun modo per verificare indipendentemente che una certa azienda non registri o manipoli in alcun modo il traffico dati dei suoi utenti. Per questo è estremamente importante scegliere con cura il servizio, analizzando le faq, gli how-to, come sono scritti i termini di servizio, da quanto tempo è in attività, dove ha sede l'azienda e se il tale paese ha o meno leggi di "data retention". Affidarsi a aziende poco serie, o peggio truffatori, in questo caso potrebbe infatti risultare peggio che non usare proprio alcuna VPN.

Installazione

A prescindere da quello che si vuole fare il primo passo è installare OpenVPN:

# apt-get install openvpn

Creare una propria VPN

Info.png Nota
Questa guida è stata scritta anni prima ed è ragionevolmente valida fino a Jessie. Una guida più recente è questa: Debian come server VPN


Prima di cominciare

La prima cosa da fare è verificare in /dev la presenza della directory net contenente il device virtuale tun. Se tutto ciò non ci fosse, crearlo con:

# mkdir /dev/net && mknod /dev/net/tun c 10 200

tirare su il rispettivo modulo e far sì che al boot venga caricato:

# modprobe tun
# echo "tun" >> /etc/modules
Info.png Nota
La creazione del device virtuale /dev/net/tun permetterà sia a tun che a tap di funzionare e di poter essere richiamati dall'applicazione al momento della connessione (modo dinamico) ; ed è lo stesso device che permette ad Openvpn di crearsi quei device in modo permanente (modo statico).


Infine abilitare il forwarding:

# echo 1 > /proc/sys/net/ipv4/ip_forward

Openvpn e Iptables

Diamo le opportune regole al firewall:

iptables -A INPUT -p udp --dport 5000 -s 10.0.0.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT 
iptables -A INPUT -s 10.0.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT

Generazione delle chiavi

Se non l'abbiamo già fatto:

# apt-get update && apt-get install openvpn

Effettuiamo il collegamento fra due macchine, una chiamata in maniera molto originale server e una client.
Queste due macchine sono di due diversi utenti che possono risiedere ovunque nel mondo. La macchina server sarà quella in ascolto.
Spostiamoci sul server, esattamente in /etc/openvpn e creiamo la nostra chiave con:

# openvpn --genkey --secret zmo.key

Una volta creata dovremmo poterla copiare nella stessa directory del client. Questo passaggio dovrebbe essere fatto nel più sicuro dei modi ad esempio tramite mail crittografate, o utilizzando scp (dalla suite Openssh: vedi la guida OpenSSH: file di configurazione).
Utilizzando queste chiavi su tutti gli host (crittografia simmetrica) otteniamo una notevole cifratura del nostro canale in maniera davvero rapida.

Configurazione chiavi condivise

Spostiamoci sul server e creiamo in /etc/openvpn il file server.conf editandolo così:

dev tap
lport 5000
ifconfig 10.0.0.1 255.255.255.0
secret /etc/openvpn/zmo.key	
verb 9
dev
identifica il device utilizzato per il tunnel. I possibili device utilizzabili da openvpn sono tun e tap. La differenza tra i due device è fondamentale, in quanto tun si adopera per la trasmissione di pacchetti IP (una specie di ppp) e tap invece per la trasmissione di frame ethernet (una specie di eth). Per la creazione di LAN virtuali o per la condivisione di risorse come file-server, ftp-server, dobbiamo usare tap.
port
socket dell'applicazione, il default è la 5000, deve essere la stessa da ogni capo della VPN. È da sottolineare che sul server invece di port si scriverà lport (local) mentre sui client rport (remote).
ifconfig
determina l'IP dell'interfaccia virtuale (tun o tap).
secret
a questa stringa diamo il path della key creata in precedenza con openvpn.
verb
"verb" definisce il grado di verbose stampato a video in output durante l'esecuzione (da 0 a 11 sono spiegati dando openvpn --help).

Adesso sul client creiamo il file /etc/openvpn/client.conf così:

remote www.hostremoto.net (che ovviamente corrisponderà al server)
dev tap 
rport 5000shared-keys
ifconfig 10.0.0.2 255.255.255.0
secret /etc/openvpn/zmo.key	
verb 9
remote
a remote diamo l'IP pubblico della macchina alla quale ci connetteremo, oppure l'hostname come nell'esempio.

A questo punto lanciamo il collegamento su entrambe le macchine, indicando al programma di attenersi alle regole appena definite nei rispettivi server.conf e client.conf:

# openvpn --config /etc/openvpn/xxxx.conf

Tra le righe di output del client dovrebbero apparire tra le altre queste due stringhe:

Wed Sep  7 15:45:28 2005 Peer Connection Initiated with www.hostremoto.net:5000
Wed Sep  7 15:45:29 2005 Initialization Sequence Completed

Andiamo sul server e diamo:

# ifconfig tap
tap0   Link encap:Ethernet  HWaddr 01:F0:EF:27:41:4C
          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Nella riga inet addr vengono indicati IP, broadcast e netmask.
Proviamo a pingare l'host che sappiamo connesso:

# ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=258 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=135 ms

In questo modo disporremo rapidamente di un canale cifrato relativamente sicuro, per lo scambio di dati privati.

Configurazione SSL/TLS

Openvpn e Openssl

Adesso, avvalendoci di SSL/TLS, configureremo un CA (Certificate Authority) che servirà a firmare i certificati degli host e a rendere disponibile il proprio; creeremo le rispettive chiavi (una anche per il CA stesso) facendo in modo che ognuno detenga una chiave e un certificato firmato. Infine, per lo scambio sicuro di tali dati, creeremo un Diffie-Hellman.

# apt-get install openssl

Configurazione CA

Il CA risiederà sul server, ma distinguiamo le entità in questo modo: CA – Server – Client0 – Client1...
Occupiamoci del CA; facciamogli generare una sua chiave (ca.key), una sua richiesta di certificato (rich.ca), facciamogliela autofirmare (ca.cert) e depositare successivamente su ogni host. Dunque, sempre sul server, torniamo in /etc/openvpn.

# openssl genrsa -out ca.key
Generating RSA private key, 512 bit long modulus
...++++++++++++
........++++++++++++
e is 65537 (0x10001)

# openssl req -new -key ca.key -out rich.ca
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:

...questa sezione compilatela a discrezione vostra.

# openssl x509 -req -in rich.ca -signkey ca.key -out ca.cert
Signature ok
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
Getting Private key

Ricapitolando dovremmo aver creato ca.key rich.ca e ca.cert.

TLS-Server & TLS-Client

Occupiamoci ora di server e client, la loro configurazione è pressoché uguale.
Sul server:

# openssl genrsa -out server.key
# openssl req -new -key server.key -out rich.ser

Facciamo firmare al CA la richiesta di certificato del server:

# openssl x509 -req -in rich.ser -CA ca.cert -CAkey ca.key -CAcreateserial -out ser.cert

Sul server creiamo anche il Diffie-Hellman:

# openssl dhparam -out dh.pem 1024
Info.png Nota
Il format di default adottato da dhparam è PEM (adozione standard di Unix). Per una ulteriore consultazione del flag dhparam, fare riferimento a questa pagina: Openssl dhparam[1]


Sui client:

# openssl genrsa -out client.key
# openssl req -new -key client.key -out rich.cli

Spediamo il certificato al CA (che risiede sul server), facciamocelo firmare e rispedire in /etc/openvpn (stessa procedura del server per la firma).

Server.conf
Compilare così il file per il server:

dev tap
ifconfig 10.0.0.1 255.255.255.0
tls-server
dh dh.pem
ca ca.cert
cert ser.cert
key server.key
lport 5000
verb 4

Client.conf
Compilare così il file per il client:

remote www.hostremoto.net (che ovviamente corrisponderà al server)
dev tap
ifconfig 10.0.0.2 255.255.255.0
tls-client
ca ca.cert
cert cli.cert
key client.key
rport 5000
verb 4

Una volta compilati i file, lanciamo openvpn su entrambe le macchine come in precedenza:

openvpn –config xxxx.conf

Avviare Openvpn come servizio

Lo script /etc/init.d/openvpn

Questo script, che demonizza openvpn, una volta lanciato va a cercare nella dir /etc/openvpn il file con estensione .conf che dovrà corrispondere al file di configurazione. Dico questo poiché in varie documentazioni lo troverete con estensioni diverse (es: .ovpn etc..) che lo script non riconoscerebbe come valido.

# /etc/init.d/openvpn start

Una volta avviato lo script attiverà il demone. Per impostarlo al boot:

# update-rc.d openvpn defaults

Per rimuoverlo dal boot:

# update-rc.d -f openvpn remove

Openvpn & log

Per loggare l'output in un file qualunque (anche se non esiste verrà creato) aggiungere la riga al file .conf:

log /var/log/openvpn.log

Il file di log sarà più o meno forbito in base al valore che avremo dato al parametro verb.

Conclusioni

Openvpn[2] permette la creazione di VPN da applicativo ad applicativo, non necessitando quindi di modifiche nel kernel come nel caso di VPN che implementino IPSEC. Gira sulle principali piattaforme allacciando quindi OS diversi. Anche se lo standard IPSEC è una realtà nei dispositivi di rete hardware, il livello di sicurezza che openvpn può raggiungere è indiscutibile.

Usare una VPN commerciale

Molti fornitori di servizi VPN a pagamento supportano tra i diversi client anche e soprattutto OpenVPN. Se tutto quello che vuole fare l'utente è collegarsi direttamente dal proprio computer allora la questione è molto semplice, infatti chi scrive ha provato due differenti servizi ed in entrambi i casi la procedura è stata immediata e senza alcun tipo di problema. Se invece si vuole stabilire un unico tunnel per tutta la propria rete domestica la cosa diventa più complessa, ma in ogni caso è necessario scaricare in anticipo i file di configurazione che il fornitore mette a disposizione (si veda più sotto per un paio di esempi). Generalmente ogni fornitore mette a disposizione un file di configurazione per ogni località in cui ha un proprio server. Detti file hanno spesso estensione .ovpn e sono pressoché identici tra loro, fatto salvo l'indirizzo (o gli indirizzi) dei server cui connettersi.

Info.png Nota
Il client openvpn crea sempre un'interfaccia di rete aggiuntiva chiamata tun0 per gestire la connessione col server VPN. Tale interfaccia ha un suo indirizzo IP privato appartenenete ad una subnet diversa da quella già in uso sul computer client.
Warning.png ATTENZIONE
  • Il client OpenVPN apporterà delle modifiche alla tabella di routing del proprio computer in modo che tutte le connessioni dirette a subnet esterne alla propria LAN (cioè a internet) siano forzate ad usare l'interfaccia tun0, cioè a transitare attraverso il server VPN. Oltre a ciò verrà aggiunto anche un secondo gateway che avrà precedenza superiore a quello predefinito dell'utente. Alla chiusura della connessione VPN saranno automaticamente ripristinate le impostazioni originali.
  • I file di configurazione forniti dai fornitori della rete VPN non sono pensati per situazioni in cui un utente ha molteplici tunnel attivi, pertanto in tali situazioni l'utente dovrà necessariamente costruirsi dei file di configurazione personalizzati in modo che ogni tunnel non vada in conflitto con gli altri (questo caso non è trattato)


Uso singolo

Come già detto collegarsi ad un server VPN direttamente dal computer in uso è estremamente facile, è infatti possibile usare il client openvpn da terminale, oppure l'apposita funzionalità di network-manager (o altro client, ma qui si tratterà solo il caso di network-manager. In entrambi i casi è

Terminale

Aprire un terminale e digitare:

$ openvpn --config nome_file_configurazione.ovpn

Verranno richiesti nome utente e password, dopo di che a video compariranno i log di quello che succede e la connessione risulterà stabilita. La finestra del terminale deve restare aperta fintanto che si vuole rimanere collegati alla VPN, pertanto potrebbe fare comodo usare un applicativo come GNU/Screen per eseguire il predetto comando. Per terminare la connessione è sufficiente premere CTRL+C.
Volendo poi verificare che l'IP visibile dall'esterno sia effettivamente diverso da quello assegnato dal proprio provider internet è possibile digitare:

$ curl ipinfo.io/ip

Oppure caricare una delle tante pagine web che mostrano il proprio IP pubblico.

Network-Manager

  1. Aprire l'editor delle connessioni di network-manager e cliccare sulla voce Connessione
  2. Dal menù selezionare importa VPN e quindi aprire il file di configurazione scaricato dal proprio fornitore VPN
  3. Alla domanda Vuoi copiare i tuoi certificati in /home/kwisatzhaderach/.local/share/networkmanagement/certificates/? premere OK
  4. Nell'editor di connessioni dovrebbe ora comparire una nuova connessione, selezionarla e quindi premere Modifica dal menù in alto.
  5. Nella scheda VPN (openvpn) è necessario compilare i campi Nome utente e Password con i propri dati. Premere OK

A questo punto la connessione è pronta e sarà sufficiente selezionarla da Network-Manager per avviarla (esattamente come qualsiasi altra connessione).

Uso gateway

È generalmente conveniente effettuare il collegamento al server VPN dal router, in modo da avere un unico tunnel da cui far passare tutto il traffico in uscita invece che creare un tunnel per ogni dispositivo. Tale scelta è particolarmente conveniente se il proprio fornitore di VPN limita il massimo numero di connessioni che possono essere attive contemporaneamente (che è la prassi). Sebbene più ordinata come soluzione tale approccio potrebbe generare problemi nel caso si abbiano dei servizi che accettano nuove connessioni provenienti da internet, tipo un webserver, infatti in genere ogni fornitore configura i client della propria VPN in modo che tutto il traffico sia automaticamente dirottato attraverso il tunnel VPN. Il problema è che non è scontato che dia anche la possibilità di aprire le porte necessarie, o quanto meno un numero adeguato. In tal caso c'è poco da fare e si avranno due possibili scenari:

  • se si vuole far passare tutti i servizi attraverso il tunnel VPN allora non si potrà far altro che eseguire contemporaneamente solo un numero di servizi pari al numero di porte disponibili.
  • se si è disposti a non far passare uno o più servizi attraverso il tunnel VPN, tipo un web server, allora si tratta "solo" di configurare il computer che funge da router opportunamente.

A prescindere dal proprio scenario la configurazione di openvpn è la medesima e prevede l'utilizzo di openvpn come servizio. Digitando da terminale ls -hl /etc/openvpn/ apparirà quanto segue:

drwxr-xr-x 2 root root client
drwxr-xr-x 2 root root server
-rwxr-xr-x 1 root root update-resolv-conf

Il file update-resolv-conf è uno script che viene installato automaticamente insieme ad openvpn e serve per permettere al server vpn cui ci si collega di spingere al nostro computer gli indirizzi dei server DNS del fornitore VPN stesso, in modo che la nostra macchina usi tali DNS e non quelli normalmente usati. Si veda la sezione con gli esempi dei file di configurazione per maggiori informazioni in merito.
Le sottocartelle client e server permettono di separare i file di configurazione relativi al client VPN da quelli di un eventuale server (un computer potrebbe teoricamente essere usato sia per creare più tunnel verso altri server VPN che per fungere esso stesso da server VPN), ma il loro utilizzo non è obbligatorio, infatti si può semplicemente mettere tutto in /etc/openvpn/. È tuttavia fondamentale sapere che l'utilizzo di ciascuna cartella dipende strettamente da come viene avviato il servizio VPN, infatti openvpn può essere avviato con tre comandi diversi:

# systemctl start openvpn@nome_file_configurazione
# systemctl start openvpn-client@nome_file_configurazione
# systemctl start openvpn-server@nome_file_configurazione

Nel primo caso il file di configurazione nome_file_configurazione deve obbligatoriamente trovarsi in /etc/openvpn/, mentre negli altri due rispettivamente in /etc/openvpn/client/ e /etc/openvpn/server/. Si possono avere molteplici file di configurazione nella stessa cartella e tutti possono essere nominati come meglio si crede, tuttavia quando si avvia il servizio il nome specificato dopo il carattere @ dovrà necessariamente coincidere con quello effettivamente presente nella corrispondente cartella. È altresì necessario che ogni file di configurazione abbia estensione .conf, quindi se i file di configurazione scaricati hanno estensione .ovpn questi dovranno essere opportunamente rinominati. Oltre ai file di configurazione è anche necessario che nella stessa cartella siano presenti i relativi file contenenti la credenziali per accedere alle varie VPN (si veda la sezione sottostante con gli esempi di file di configurazione). Oltre al comando start sono supportati anche altri comandi, quali restart, stop, status, ecc.

A questo punto la connessione al proprio server VPN dovrebbe essere attiva, ma il traffico proveniente da altre macchine non sarà accettato se prima non si è abilitato il reindirizzamento a livello del kernel. Vedere questa guida per sapere come fare.

Normalmente i fornitori VPN non lasciano porte aperte, quindi in teoria non vi sarebbe alcun bisogno di configurare un firewall sulla propria macchina, tuttavia fidarsi bene e non fidarsi è meglio ed è dunque opportuno configurare delle regole anche per l'interfaccia tun0. Si veda per esempio questa guida.

Avvio automatico

Per avviare automaticamente la connessione VPN all'avvio del computer è sufficiente usare l'apposito comando di systemd:

# systemctl enable openvpn-client@nome_file_configurazione

dove nome_file_configurazione è il file di configurazione /etc/openvpn/client/nome_file_configurazione.conf del proprio client. Di converso per disabilartne l'avvio automatico è sufficiente impartire:

# systemctl disable openvpn-client@nome_file_configurazione

Scenario misto

Nel caso si abbia necessità di rendere un servizio, come un webserver, accessibile direttamente senza passare dal tunnel VPN è possibile procedere come segue.

Bulb.png Suggerimento
Prima di procedere si consiglia la lettura delle guide dedicate a Iproute2 e IPtables.


1 - Creare una nuova tabella di routing, che sarà chiamata per semplicità "tab1" (come descritto per esempio nella sezione Aggiungere tabelle di routing della guida di Iproute2).
2 - Aggiungere le rotte standard del proprio computer a "tab1", ovvero le rotte definite in automatico dalla propria macchina quando non è in esecuzione alcun servizio VPN. Per esempio nel caso di macchina che funge da gateway sfruttando pppoeconf potrebbero essere sufficienti i seguenti due comandi:

# ip route add default dev ppp0 table tab1
# ip route add 192.168.1.0/24 dev eth0 src 192.168.1.172 table tab1

Dove si suppone che la macchina su cui è in esecuzione il servizio abbia IP 192.168.1.172
3 - Aggiungere una regola per cui si dichiara che per i pacchetti provenienti dall'interfaccia con cui ci si connette ad internet, ad esempio ppp0, è necessario usare la tabella di routing "tab1" invece di quella principale

# ip rule add from AAA.BBB.CCC.DDDD table tab1

Dove con AAA.BBB.CCC.DDDD si intende l'IP associato all'interfaccia ppp0, cioè quello pubblico effettivamente attribuitoci dal nostro ISP (e non quindi quello del server VPN di uscita). Da notare che anche nel caso non si usasse pppoeconf l'ip da specificare sarebbe sempre quello dell'interfaccia attraverso cui transita il traffico internet (eth1 in questo esempio), anche se privato e non pubblico.
4 - Aggiungere delle regole al firewall per assicurarsi di non poter mischiare il traffico tra l'interfaccia internet, es. ppp0, e quella della VPN, es. tun0. Per maggiori informazioni si veda ad esempio la sezione apposita della guida di iptables.

Arrivati a questo punto il servizio prescelto dovrebbe essere normalmente raggiungibile attraverso la nostra interfaccia internet, tuttavia è importante sottolineare quanto segue:

  • Le rotte e le regole create non sono permanenti, ovvero andranno perse al momento di un eventuale riavvio, quindi in tale caso l'utente dovrà nuovamente ripetere la procedura qui descritta. Il problema dovrebbe essere ovviabile dichiarando opportunamente i precedenti comandi nel file /etc/network/interfaces, come riportato nel seguente esempio che contiene una configurazione sia per l'interfaccia ppp0 che eth0
auto dsl-provider
iface dsl-provider inet ppp
	pre-up /bin/ip link set eth1 up
	provider dsl-provider
	post-up /bin/ip route flush table 1
	post-up /bin/ip route add default dev ppp0 table 1
	post-up /bin/ip rule add from $(ip -f inet addr show ppp0 | grep -Po 'inet \K[\d.]+') table 1

auto eth0
iface eth0 inet static
        address 192.168.1.172
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        post-up /bin/ip route add 192.168.1.0/24 dev eth0 src 192.168.1.172 table 1
  • Se non si dispone di un IP pubblico statico, ma solo dinamico, sarà necessario eliminare e dichiarare nuovamente il comando descritto al punto 3 ogni volta che detto IP pubblico cambia. A tale fastidio si può ovviare sostituendo alla regola del punto 3 una dichiarazione basata sull'uso dell'opzione fwmark e del target mark di IPtables, oppure creando uno script che ad intervalli regolari verifica il proprio IP pubblico attuale ed eventualmente aggiorna rotte e regole come necessario. A puro titolo esemplificativo si mostra lo script usato da chi scrive (e quindi ritagliato sulla propria specifica configurazione macchina):
#!/bin/bash
# CRON: */10 * * * * /percorso/script/nome_script.sh
PPP=$(ip addr | grep 'ppp0')
IPO=$(ip rule | grep '32765' | tr -d '[a-z ]' | sed 's/32765:\t//1')
TAB=$(ip route show table tab1)
DATA=$(date +'%b %d %T')" nome_host nome_script.sh: "
# Check first if secondary routing table is empty
if [ "$TAB" = '' ]
then
	ip route add default dev ppp0 table tab1
	# Next command is necessary to be able to connect to the web server using my fqdn, like "blabla.fornitore.net"
	# from inside the LAN
	ip route add 192.168.1.0/24 dev br0 src 192.168.1.172 table tab1
	MSG1=$DATA"secondary routing table was empty, added ppp0 as default gateway."
else
	MSG1=$DATA"secondary routing table was not empty, nothing to do."
fi
echo $MSG1 >> /var/log/syslog
# Check now if ppp0 inet ip has changed
if [ "$PPP" != '' ]
then
	IPN=$(ip -f inet addr show ppp0 | grep -Po 'inet \K[\d.]+')
	if [ "$IPN" != "$IPO" ] && [ "$IPN" != "" ]
	then
		if [ "$IPO" = '' ]
		then
			MSG0=" (missing secondary routing table rule)"
		else
			MSG0=" (secondary routing table rule found)"
			ip rule del table tab1
		fi
		ip rule add from $IPN table tab1
		MSG2=$DATA"IP changed from "$IPO" to "$IPN$MSG0". Rule updated."
	else
		MSG2=$DATA"IP ($IPO / $IPN) has not changed, nothing to do."
	fi
else
	MSG2=$DATA"failed to read inet address (is interface up?)."
fi
echo $MSG2 >> /var/log/syslog

Streaming e VPN

Sfortunatamente alcuni servizi di streaming rendono impossibile la fruzione dei loro contenuti a chi usa una VPN per ragioni legate allo sfruttamento dei diritti commerciali (che nella stragrande maggioranza dei casi sono ripartiti per aree geografiche). In tali situazioni c'è poco da fare, l'unica soluzione è non usare temporaneamente la VPN per il traffico web. Non è infatti è possibile, per la complessità di tali servizi, instradare il traffico semplicemente sulla base del dominio web.
Un semplice palliativo, che richiede solo un minimo di disciplina personale, è quello di crearsi una seconda configurazione per l'interfaccia di rete in uso sul proprio PC (e NON sul gateway della LAN), in modo da poter specificare un diverso indirizzo privato. In questo modo a livello di gateway sarà possibile aggiungere una regola tale per cui si dichiara che il traffico dati proveniente da questo nuovo IP non dovrà essere gestito dalla tabella di routing principale, ma da una alternativa.
La procedura per creare tale tabella è identica a quella descritta nella sezione precedente "Scenario misto", pertanto se già si sono seguite le relative istruzioni non è necessario configurare una terza tabella, viceversa andrà appunto creata. Il punto è che serve una tabella alternativa a quella principale in modo da ignorare le rotte imposte dal prioprio servizio VPN.
In sintesi quando si vuole usare un servizio che blocca le VPN si cambia la configurazione di rete in uso.
Ipotizzando che l'indirizzo IP della configurazione di rete alternativa sia 192.168.1.107 allora sarà sufficiente dare il seguente comando sul proprio PC gateway:

# ip rule add from 192.168.1.107 table 1

Si ricorda che le regole di routing vengono perse ad ogni riavvio, pertanto l'utente dovrà aggiungere al file /etc/network/interfaces del proprio PC gateway, in corrispondenza dell'interfaccia cui si collegano tutti i PC della LAN, una direttiva di questo tipo:

post-up /bin/ip rule add from 192.168.1.107 table 1

La sezione relativa all'interfaccia eth0 (o quello che è a seconda del setup del lettore) sarà quindi simile a quanto segue:

auto eth0
iface eth0 inet static
        address 192.168.1.172
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        post-up /bin/ip route add 192.168.1.0/24 dev eth0 src 192.168.1.172 table 1
        post-up /bin/ip rule add from 192.168.1.107 table 1
Script ausiliario

Poiché è scontato che prima o poi si finisca per dimenticarsi di ritornare alla configurazione di rete standard una volta finito di usare il servizio di streaming è possibile organizzarsi nel seguente modo per ridurre al minimo tale evenienza:

  1. usare un browser dedicato diverso da quello solito per usufruire dei servizi di streaming;
  2. evitare di avviare direttamente il suddetto browser, ma usare uno script apposito che si occupi anche di cambiare automaticamente il profilo di rete da usare.

Lo script indicato qui sotto, estremamente semplice, sfrutta il browser "Vivaldi" e nmcli (lo strumento a riga di comando per gestire network manager) per cambiare/ripristinare le configurazioni di rete:

#!/bin/bash
# È necessario aver già creato entrambe le reti in Network Manager.
# Si suppone che l'IP di "NOVPN" sia 192.168.1.107
nmcli con down CONVPN
nmcli con up NOVPN
vivaldi indirizzo_web
nmcli con down NOVPN
nmcli con up CONVPN

File di configurazione

Di seguito un paio di esempi presi da due differenti fornitori. Le opzioni che interessano l'utente sono essenzialmente tre:

  • remote: qui viene specificato l'indirizzo del server VPN e il numero di porta da usare.
  • auth-user-pass: questa direttiva definisce come avverrà l'autenticazione presso il server VPN, se infatti non viene specificato un file contenente i dati di accesso questi verranno semplicemente richiesti al primo tentativo di connessione, ovvero username e password. Viceversa se viene specificato questo dovrà essere un semplice file testuale composto da due righe, la prima dove viene indicato il nome utente e la seconda dove si specifica la password corrispondente al nome utente indicato nella prima riga. Generalmente il file di credenziali non viene mai specificato a meno di non voler automatizzare la connessione alla VPN usando systemctl.
  • up e down /etc/openvpn/update-resolv-conf, usate per sostituire in automatico gli indirizzi dei server DNS con quelli del fornitore del servizio VPN. Quando il client VPN viene terminato vengono automaticamente ripristinati i DNS originali dell'utente. Se non si vuole usare i DNS del fornitore VPN è sufficiente commentare le suddette due direttive. Si noti che lo script /etc/openvpn/update-resolv-conf non è legato al fornitore VPN, ma è proprio uno strumento incluso con il client di openvpn (almeno in Debian). Per questo non tutti i fornitori di servizio includono le suddette direttive nei loro file di configurazione.

Esempio file credenziali

Caio
La_mia_complicatissima_password

Esempio 1

client
dev tun
proto udp 
remote indirizzo_server_vpn numero_porta
auth-user-pass nome_file_credenziali_accesso

resolv-retry infinite
nobind
persist-tun
persist-key
persist-remote-ip

cipher AES-256-CBC
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-DSS-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA
remote-cert-tls server
verify-x509-name it name-prefix
key-direction 1
comp-lzo no
verb 3

;ca ca.crt
<ca>
-----BEGIN CERTIFICATE-----

stringa caratteri certificato

-----END CERTIFICATE-----
</ca>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----

stringa caratteri chiave

-----END OpenVPN Static key V1-----
</tls-auth>

Esempio 2

proto udp
tun-mtu 1500
fragment 1300
mssfix
cipher AES-256-CBC
ignore-unknown-option ncp-disable # ovpn 2.3 to 2.4 transition
ncp-disable

remote indirizzo_server_vpn1 numero_porta1
remote indirizzo_server_vpn2 numero_porta2
remote indirizzo_server_vpn3 numero_porta3

auth SHA512
auth-user-pass nome_file_credenziali_accesso
client
comp-lzo
dev tun
hand-window 120
inactive 604800
mute-replay-warnings
nobind
remote-cert-tls server
persist-key
persist-remote-ip
persist-tun
ping 5
ping-restart 120
redirect-gateway def1
remote-random
reneg-sec 3600
resolv-retry 60
route-delay 2
route-method exe
script-security 2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-RSA-WITH-AES-256-CBC-SHA
tls-timeout 5
verb 4
tun-ipv6

down /etc/openvpn/update-resolv-conf
up /etc/openvpn/update-resolv-conf

key-direction 1
<ca>
-----BEGIN CERTIFICATE-----

Stringa caratteri certificato

-----END CERTIFICATE-----

</ca>

<cert>
-----BEGIN CERTIFICATE-----

Stringa caratteri certificato

-----END CERTIFICATE-----

</cert>

<key>
-----BEGIN PRIVATE KEY-----

Stringa chiave privata

-----END PRIVATE KEY-----

</key>

<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----

Stringa caratteri chiave

-----END OpenVPN Static key V1-----
</tls-auth>

Approfondimenti

Manpages

man openvpn

Sitografia




Guida scritta da: zmo Swirl-auth20.png Debianized 20%
Estesa da:

Wtf 18:36, 20 gen 2019 (CET)

Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized