Openvpn: differenze tra le versioni

Vai alla navigazione Vai alla ricerca

Openvpn (visualizza wikitesto)

Versione delle 21:25, 23 feb 2020

12 828 byte aggiunti ,  23 feb 2020
m
→‎Avvio automatico
 
(43 versioni intermedie di uno stesso utente non sono mostrate)
Riga 1: Riga 1:
{{Versioni compatibili|Wheezy|Jessie}}
{{Versioni compatibili|Wheezy|Jessie}}{{Gateway-Router}}
== Introduzione ==
== 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.<br/>
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/>
Riga 263: Riga 263:
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.
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.
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. Alla chiusura della connessione VPN saranno automaticamente ripristinate le impostazioni originali.
}}
}}
{{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 base ===
=== 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.
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.
Riga 295: Riga 297:


A questo punto la connessione è pronta e sarà sufficiente selezionarla da Network-Manager per avviarla (esattamente come qualsiasi altra connessione).
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.
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.
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 ===
=== File di configurazione ===
Riga 433: Riga 592:
</pre>
</pre>


== Approfondimenti ==


=== Uso gateway ===
=== Manpages ===


È 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).
<pre>man openvpn</pre>
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:
=== Sitografia ===
<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.
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>.


== Riferimenti ==
* [http://openvpn.net Openvpn.net], sito ufficiale OpenVPN
[1] [http://www.mkssoftware.com/docs/man1/openssl_dhparam.1.asp OpenSSL dhparam]<br/>
* [http://a2.pluto.it/a2/a258.htm#almlindex4169 sez. "IPTables per l'amministrazione del firewall" di Appunti di informatica libera];
[2] [http://openvpn.net Openvpn.net]<br>
* [http://www.mkssoftware.com/docs/man1/openssl_dhparam.1.asp OpenSSL dhparam]
[http://www.openssl.org www.openssl.org]<br>
* [http://www.openssl.org www.openssl.org]
<!-- [http://milano.linux.it/contributi/ValentinoSquilloni.pdf Openvpn e reti private virtuali]<br>
<!-- [http://milano.linux.it/contributi/ValentinoSquilloni.pdf Openvpn e reti private virtuali]<br>
LINK ROTTO E AL MOMENTO IRRINTRACCIABILE -->
LINK ROTTO E AL MOMENTO IRRINTRACCIABILE -->
[http://a2.pluto.it/a2/a263.htm#almltitle2684 Appunti Linux]
* [http://a2.pluto.it/a2/a263.htm#almltitle2684 Appunti Linux]


{{Autori
{{Autori
|Autore = [[Utente:Zmo.zmo|zmo]]
|Autore = [[Utente:Zmo.zmo|zmo]]
|Estesa_da = [[Utente:Wtf|Wtf]] 18:36, 20 gen 2019 (CET)
}}
}}


[[Categoria:VPN]]
[[Categoria:VPN]]
Wtf
2 853

contributi

Estratto da "https://guide.debianizzati.org/index.php/Speciale:DiffMobile/42553...43923"

Menu di navigazione