Openvpn: differenze tra le versioni
Wtf (discussione | contributi) |
Wtf (discussione | contributi) |
||
Riga 262: | Riga 262: | ||
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. 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. | ||
{{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. Alla chiusura della connessione VPN saranno automaticamente ripristinate le impostazioni originali. | ||
Riga 432: | Riga 432: | ||
</tls-auth> | </tls-auth> | ||
</pre> | </pre> | ||
=== 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. | |||
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 == | == Riferimenti == |
Versione delle 16:13, 20 gen 2019
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. |
Versioni Compatibili Debian 7 "wheezy" Debian 8 "jessie" |
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
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
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
etap
. La differenza tra i due device è fondamentale, in quantotun
si adopera per la trasmissione di pacchetti IP (una specie dippp
) etap
invece per la trasmissione di frame ethernet (una specie dieth
). Per la creazione di LAN virtuali o per la condivisione di risorse come file-server, ftp-server, dobbiamo usaretap
. 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 clientrport
(remote). ifconfig
- determina l'IP dell'interfaccia virtuale (
tun
otap
). 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
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.
Uso base
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
- 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).
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>
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/
.
Riferimenti
[1] OpenSSL dhparam
[2] Openvpn.net
www.openssl.org
Appunti Linux
Guida scritta da: zmo | Debianized 20% |
Estesa da: | |
Verificata da: | |
Verificare ed estendere la guida | Cos'è una guida Debianized |