20 dicembre 2013

OpenVPN, una risorsa per aumentare la produttività

Questo strumento, tanto complicato da configurare quanto utile rappresenta un'ottima opportunità per tutti coloro che per varie e diverse esigenze desidererebbero accedere da un loro PC (o smarphone e tablet) ad un altro fisicamente distante, come se fosse collegato alla stessa rete LAN, quindi avente IP della stessa classe e quindi può connettersi a tutti gli altri host localmente senza limiti di porta e senza ricorrere a varie pratiche tipo NAT o Port Forwarding.

Questo strumento è chiamato VPN (Virtual Private Network), ci sono molte varianti, alcune a pagamento tramite un server gestito da terzi, altre molto performanti ma che richiedono caratteristiche non sempre disponibili dalla rete internet tramite la quale ci stiamo connettendo, altre che utilizzano un protocollo proprietario a pagamento.

Oggi vi propongo una soluzione forse non semplicissima ed immediata dal punto di vista della realizzazione, ma di sicuro molto scalabile, personalizzabile, performante ma soprattutto, libera e gratuita.

Prima di addentrarmi vi specifico che questa configurazione è orientata verso chi possiede un Computer da adibire a Server, che stia acceso per consentire agli altri di connettersi e comunicare, e che disponga di una connessione a banda larga, altrimenti potrebbe risultare lento e quindi inutile.

Scarichiamo l'unico software che ci serve da qui.
Ci sono due versioni per Windows, (32 o 64bit).



http://openvpn.net/index.php/open-source/downloads.html


Procediamo con l'istallazione molto semplice ed intuitiva.


Chiaramente esiste la versione per Linux e Mac OS X, su "Debian Linux" per esempio basta eseguire con permessi di root il comando:

apt-get install openvpn

Questo software dovrà essere installato su ogni Computer che vorrà prendere parte alla rete virtuale.

Primo passo:



Generazione Certificati


Premessa: per questo step vi indicherò 2 metodi, che produrranno lo stesso risultato ma con versatilità ed ambiti diversi, la prima, orientata alla estrema sicurezza, offre appunto possibilità di configurare in piena sicurezza VPN formata da host lontani tra loro, e consente ad ogni client di essere gli unici in possesso della chiave privata. La seconda invece, prevede una fase di configurazione più sensibile, in quanto tutto il set delle chiavi viene creato sul server, e poi le chiavi viengono distribuite ai client, rendendo quindi la fase di distribuzione delle chiavi, se questa fatta via internet, più vulnerabile.

Ma comunque le chiavi finali saranno esattamente le stesse.
Se non avete particolari esigienze di estrema sicurezza o se avete un canale sicuro di distribuzione delle chiavi, tunnel SSH, oppure avete possibilità di distribuirle di persona e non vi interessa che i client non siano gli unici in possesso delle loro chiavi private, potete scegliere la seconda opzione, molto più rapida della prima.

La prima cosa da fare subito dopo aver installato il software è generare le chiavi che consentiranno l'identificazione e la cifratura della VPN da parte di ogni client.

La cifratura a chiave asimmetrica è formata principalmente da una coppia di chiavi (file) per ogni host, una chiave "privata" che serve a decifrare il contenuto informativo di un flusso di dati cifrato con una chiave "pubblica".

Oltre a criptare, una chiave può servire anche ad autenticare, ossia a stabilire se l'entità che fa la richiesta è autorizzata all'accesso.

Nella nostra configurazione avremo 3 entità, ognuna delle quali con la propria coppia di chiavi. La prima entità si chiama "Certificate Authority" (CA) che si occupa di verificare se un'entità è davvero chi dice di essere.

La seconda entità invece è il nostro server OpenVPN, le successive invece saranno tutti i nostri client.

Quindi sia il server che i client dovranno prima farsi firmare le loro chiavi private dalla CA che ne certificherà la paternità e l'accesso.

Generalmente nelle grosse realtà telematiche, il CA risiede su una macchina fisica a parte, con delicate e soffisticate politiche di sicurezza e controllo, invece nel nostro caso possiamo tranquillamente assegnare questo compito alla stessa macchina che fa da server OpenVPN.


In sintesi i passaggi di cui è composto il procedimento sono i seguenti:
  • Generazione di una coppia di chiavi per il CA e la autofirma.
  • Invio chiave privata di ogni entità (o il rispettivo file request) al CA che provvederà a firmarla ed a generare una chiave pubblica relativa.
  • Invio chiavi pubbliche appena generate alle rispettive entità.
  • Invio chiave pubblica del CA ad ogni entità.
la generazione delle chiavi e la firma si fanno attraverso vari passaggi con dei tool a linea di comando che richiedono una sintassi ed articolazione complessa, ma per semplificare il tutto, ci viene incontro una suite gratuita complementare al software OpenVPN che ci semplificherà in maniera estrema il nostro lavoro, riducendolo ad una piccola sequenza di brevi comandi.

questo tool si chiama "EasyRSA" attualmente alla versione 3 (ogni versione ha una sintassi completamente diversa)

lo possiamo scaricare dal seguente link

supponendo di aver scaricato la versione per Windows e di essere posizionati sul nostro Server VPN/CA, scompattiamo l'archivio in una directory qualsiasi, eseguiamo il file al suo interno denominato "EasyRSA Start.bat"


ci ritroveremo davanti ad un prompt di comandi in cui dovremo inserire la sequenza dei comandi.

NOTA: la versione per Linux prevede la stessa sintassi con l'unica differenza di anteporre "./" ad ogni comando dopo esserci posizionati nella directory dell'archivio scompattato, (es: "./easyrsa init-pki" invece che "easyrsa init-pki").

easyrsa init-pki

questo comando ci crea l'ambiente, quindi la directory in cui inserire i nostri file.

seguiamo con:

easyrsa build-ca

questo provvede alla creazione della coppia di chiavi della CA (generazione chiave privata più autofirma), a questo punto ci verrà chiesto di impostare una password, ed un Common Name, ossia un nome che identifica la chiave, facciamolo. Così troveremo una coppia di file.


Primo metodo:


proseguiamo con:
 

easyrsa gen-req <server_file_name> nopass

sostituire <server_file_name> con il nome che si vuole dare al file del server, ipotizziamo "server".
questo comando genererà una chiave privata sottoforma di file .key ed un file "request" che useremo in seguito.

NOTA: considerando che abbiamo usato la direttiva "nopass" dovremo avere estrema cura nel custodire il file .key

terminata questa operazione, ci servirà creare l'ultima chiave per il client.
possiamo decidere di creare anche quest'ultima sul server e poi trasportarla sul client oppure, crearla direttamente sul client.

questo metodo è orientato a massimizzare la sicurezza, quindi su internet non dovranno essere trasferite chiavi private che, nel caso della generazione delle chiavi client sul server, sarà necessario spostare, anche se spostandole tramite un mezzo fisico come una pen drive avremmo comunque evitato di far transitare le chiavi private su internet.

è buona norma comunque, non far uscire le chiavi private dalle macchine a cui appartengono, ma questa è una politica che dipende anche dal livello di sicurezza che intendiamo raggiungere.

decidiamo quindi di spostarci sui client per creare le chiavi ad essi relative, scarichiamo il zip di EasyRSA e decomprimiamolo avviando EasyRSA.

easyrsa init-pki

seguito da

easyrsa gen-req <client_file_name>


sostituire <client_file_name> con il nome che si vuole dare al file del client, ipotizziamo "client1".

questo comando genera la chiave privata ed il corrispondente file request

in questo caso si consiglia vivamente di NON utilizzare la direttiva "nopass" in modo tale che se qualche individuo non autorizzato prenda possesso del vostro laptop, qualora dovesse cercare di connettersi alla VPN, gli verrà richiesta la password, se questo problema non vi preoccupa, sentitevi liberi di aggiungere la direttiva "nopass".
anche qui ci verrà chiesto il "Common Name" durante la fase di generazione.
ora diamo uno sguardo nella directory "pki" del client contenuta in quella di EasyRSA, entriamo a sua volta nella directory "reqs", troveremo il file requestche abbiamo appena generato (client1.req).
il passo successivo sarà inviare al CA la chiave request ossia un file che rappresenta la richiesta di certificato (tramite email, pendrive)

ricordo che il file request non è sensibile a problemi di sicurezza.

torniamo sul nostro server/CA, ed importiamo la request del nostro client col seguente comando:

easyrsa import-req /path/to/client1.req <client_file_name>


sostituire <client_file_name> con il nome che si vuole dare al file del client, ipotizziamo "client1".

dovremmo anche importare il request file relativo al server che in questo caso è sulla stessa macchina del CA, quindi ripetiamo il precedente comando:

easyrsa import-req /path/to/server.req <server_file_name>


anche qui <server_file_name>=server

ora procediamo alla firma di tipo Client o Server di entrambi i certificati appena importati:

per il Server:

easyrsa sign client <client_file_name>


per il Client:

easyrsa sign server <server_file_name>


dove <server_file_name> e <client_file_name> sono sempre quelli scelti in precedenza.

NOTA: per generare la firma ci verrà richiesta la password della CA che abbiamo inserito nel momento della sua generazione.

procediamo quindi al bilancio dei file che ci interessano:

apriamo la directory "pki" sul server, ci troveremo:

ca.crt

spostiamoci nella directory private/

ci troveremo

ca.key

server.key

invece nella directory issued/

server.crt

client1.crt

sul client invece troveremo nella directory private/ 


client1.key

come è stato spiegato in precedenza, ogni entità ha associata una coppia di file, uno corrisponde alla chiave pubblica, l'altro è quella privata, considerato che la chiave privata del client risiede già sul client, dobbiamo solamente inviargli quella pubblica appena generata dal CA, ossia client1.crt assieme al certificato pubblico della CA ca.crt

una volta fatto ciò, ci manca solo la chiave Diffie-Hellman (solo sul server)

quindi eseguiamo:

easyrsa gen-dh


NOTA: questo comando potrebbe richiedere del tempo in quanto deve acquisire entropia sufficiente.

sul server quindi creaiamo una directory chiamata "certs-server" e copiamoci i file:

ca.crt

server.crt
server.key
dh.pem

facciamo lo stesso sul client, quindi "certs-client1" in cui inseriremo

ca.crt

client1.crt
client1.key

dunque copiamo le rispettive dicertory in quella in cui è stato installato OpenVPN sotto la directory "config"


Secondo metodo:


easyrsa build-server-full
<server_common_name> nopass

sostituire <server_common_name> con il nome che si vuole dare al "Common Name" e al file del server, decidetene uno significativo e segnatevelo in quanto dopo vi servirà, ipotizziamo "server".

questo comando genererà la chiave privata del server e la firmerà col CA,
generando quindi anche la chiave pubblica del server.

la direttiva "nopass" evita la creazione della password relativa alla chiave privata.


ci verrà richiesta la password della CA che abbiamo inserito nel momento della sua generazione.

easyrsa build-client-full
<client_common_name>

sostituire
<client_common_name> con il nome che si vuole dare al "Common Name" d al file del client, ipotizziamo "client1". 


anche questo farà lo stesso, ossia genererà una chiave privata e la firmerà col CA per il client1.

è possibile anche specificare la direttiva "nopass", ma ogni volta che qualcuno tenterà di connettersi alla VPN mentre utilizza il vostro laptop, potrà farlo senza che gli venga chiesta una password.

chiaramente reiterate il comando cambiando nome del client (client2, client3, clientN...)

infine generate il file Diffie-Hellman con:

easyrsa gen-dh


NOTA: questo comando potrebbe richiedere del tempo in quanto deve acquisire entropia sufficiente.

ora accedete alla directory di easyRSA, entrate in "pki", qui troverete i files che ci serviranno:

private/ca.key

ca.crt
private/server.key
issued/server.crt
private/client1.key
issued/client1.crt
dh.pem

copiamo ca.crt, server.key, server.crt, dh.pem in una directory chiamata "certs-server" che andremo a posizionare nella directory config/ in quella di installazione di OpenVPN

copiamo invece ca.crt, client1.key, client1.crt in una directory chiamata "certs-client" che andremo a mettere nella directory config/ di OpenVPN sulla macchina client1.

------------------------------------------------------------------------------------

NOTA: dopo aver terminato la fase della creazione dei certificati, è altamente consigliabile che vi salviate la directory "pki" conservandola in un lugoo sicuro assieme alle password delle chiavi in modo da poter successivamente creare successivi certificati o poter effettuare la revoca dei certificati.
Abbiamo quindi terminato la fase relativa alla generazione delle chiavi
avviamo "OpenVPN GUI" dal menù programmi e ci ritroveremo un'icona sulla tray-bar, clicchiamo col tasto destro ed andiamo su "Modifica Configurazione"
ci troveremo davanti ad un file di testo di blocco note, qui dovremmo iniziare ad inserire i vari parametri di configurazione della nostra VPN.

Configurazione Server:


Installiamo il software OpenVPN sulla macchina Windows che designamo come server ed editiamo il relativo file configurazione spostandoci in /Programmi/OpenVPN/config quindi creiamo un file con estensione ".ovpn".
per quanto riguarda Linux basta spostarci in "/etc/openvpn/" quindi editiamo il file di testo con estensione "server.conf".

port 1194

imposta la porta sulla quale il server si metterà in ascolto.

proto udp


imposta il relativo protocollo di connessione, è fortemente consigliato udp, chiaramente client e server devono adottare stessa porta e protocollo.

server 10.0.0.0 255.255.255.0

imposta la maschera di rete che assumera la nostra VPN, in questo caso
gli IP disponibili andranno da 10.0.0.1 a 10.0.0.254. dove il primo,

10.0.0.1 sarà l'IP assegnato al server.

dev tun
 

OpenVPN per funzionare ha bisogno di delle interfacce di rete virtuali, possono essere di 2 tipi: TUN e TAP, quella TUN astrae solo il livello di rete (layer 3 ISO/OSI) trascurando i livelli sottostanti, invece TAP astrae il livello fisico Ethernet 802.3 (layer 2 ISO/OSI) e quindi permette l'invio e la ricezione di trame ethernet, generalmente consiglio l'interfaccia TUN, in quanto è meglio compatibile sui sistemi Windows e consente anche una latenza migliore, in caso di esigenze specifiche chiaramente basta settare il parametro su "TAP".
NOTA: in alcuni casi, come il bridge con un'altra interfaccia, di rete, è obbligatorio usare TAP.

topology subnet

ne consiglio vivamente l'utilizzo. 

questa direttiva permette di utilizzare una topologia subnet invece che net30 (che è di default). Se usata sul server, come in questo caso, verrà impostata tramite la modalità push su tutti i client. Poichè l'interfaccia virtuale TAP utilizza già di default la topologia subnet, questa opzione ha senso solo se usata con --dev tun. Quindi qualora dovessimo usare l'interfaccia TAP, ignoriamola.


NOTA: net30 è una topologia utilizzata sopra le architetture Windows per consentire l'utilizzo di semantiche point-to-point, non supportate nativamente dal driver TAP-WIN32 su Windows. 
qualora decidessimo di non utilizzare questa direttiva e quindi adottare una net30 e volessimo impostare l'indirizzamento statico degli host tramite la configurazione client-config-dir (spiegato successivamente), nell'assegnazione degli IP a client Windows, dovremmo scegliere una subnet valida per assegnare un indirizzo IP, ossia gli IP centrali di una /30 (esempio: supponendo di usare 10.0.0.4/30 avremmo a disposizione 4 IP per subnet (la prima subnet 10.0.0.0/30 è riservata al server), 10.0.0.4 per la rete, 10.0.0.7 per il broadcast, per l'host sono i 2 centrali, 10.0.0.6 e 10.0.0.5, uno per indirizzare il client e l'altro per indirizzare il server quindi la nostra direttiva sarà "ifconfig-push 10.0.0.6 10.0.0.5" , anche se in realtà l'IP che identifica il server verra routato sull'IP principale, ossia 10.0.0.1) se scegliamo un IP non centrale rispetto alla subnet, Windows ci restituirà un errore, mentre un sistema operativo diverso lo accetterà comunque, questo dipende dal fatto che gli altri sistemi operativi supportano la modalità p2p e quindi verrà configurato come tale, che non necessita di IP appartenenti alla stessa subnet per funzionare, mentre Windows non è abilitato al supporto di p2p, quindi per emulare questa modalità utilizza net30, falsificando di fatto p2p.
per consultare la tabella degli indirizzamenti validi net30, basterebbe eseguire il comando: "openvpn --show-valid-subnets"
La modalità net30 è ormai deprecata, continuano a mantenerla come impostazione di default solo per evitare di creare problemi alle vecchie infrastrutture già configurate in questo modo. é fortemente consigliato quindi utilizzare la direttiva "topology subnet" che probabilmente diventerà di default nelle successive release di OpenVPN.

ca cert-server1/ca.crt
cert cert-server1/server1.crt
key cert-server1/server1.key
dh cert-server1/dh1024.pem


specificano i path dei vari certificati

comp-lzo

abilita la compressione dati LZO.


persist-key

evita di ricaricare le chiavi in caso di disconnessione.


persist-tun

evita di chiudere l'interfaccia virtuale TUN/TAP quando la connessione si riavvia.


verb 3

imposta il livello di verbosity, ossia il dettaglio di informazioni che il log deve contenere, possiamo anche incrementarla, ma in quel caso avremmo un log che comprende ogni singolo pacchetto ricevuto, quindi potrebbe diventare molto grosso.


remote-cert-tls client

incrementa la sicurezza evitando attacchi di tipo man-in-the-middle
certificando che il client stia usando realmente un certificato
di tipo client.

status openvpn-status-log

questa direttiva permette di monitorare lo stato della vpn semplicemente visualizzando il file presente nella directory.


log /etc/openvpn/log.log

abilita il log dell'attività del server nel file specificato.


NOTA: la modalità "log" prevede che il file venga sovrascritto ad ogni nuova connessione, se volete la modalità append, basta sostituire la direttiva "log" con "log-append".

duplicate-cn

permette di utilizzare lo stesso certificato su più client contemporanamente, ne sconsiglio assolutamente l'utilizzo.

max-clients 5

imposta il numero massimo di client connessi contemporaneamente.

keepalive 10 120

quest'opzione è determinante nei casi in cui la connessione sulla quale viene stabilito il link VPN, in caso di idle, scada, interrompendo così la comunicazione, da notare che è in modalità push, quindi verrà impostata anche sui client.

precisamente significa questo: invia dei messaggi di keepalive ogni 10 secondi e disconnettili se non ricevi risposta entro 120 secondi.

client-to-client

abilita la connessione client to client, ossia permette ai client che si collegano al server di comunicare tra di loro.

client-config-dir nome_dir/


ci permette di specificare la directory in cui sono contenute le impostazioni sulla configurazione statica degli IP.

può capitare che un IP che dovrebbe essere assegnato staticamente alla macchina designata, possa essere assegnato dinamicamente ad un altro host, creando quindi dei conflitti, per evitare ciò,
prima di tutto bisogna effettuare una piccola modifica, ossia esplicitare la direttiva --server che in realtà è uno script formato da un'insieme di direttive che valgono a seconda dello scenario, ossia delle condizioni di configurazione, precisamente nel nostro caso corrisponde alle seguenti direttive:

mode server
tls-server
push "topology subnet"
ifconfig 10.0.0.1 255.255.255.0
push "route-gateway 10.0.0.1"
ifconfig-pool 10.0.0.2 10.0.0.199 255.255.255.0


in questo modo gli IP che vanno da 10.0.0.200 a 10.0.0.254 sono riservati all'assegnazione statica quindi non possono essere utilizzati da altri host, ricordiamoci di eliminare la direttiva --server dalla configurazione.


per definire ogni IP che deve avere un client bisogna creare una sottodirectory nella directory config/ con lo stesso nome definito nel parametro, al suo interno ci basta creare un file di testo senza estensione (.txt, .conf) e nominarlo come quel famoso "Common Name" che abbiamo definito durante la generazione dei certificati, quindi, usando il Common Name relativo al client1, si decidera quale IP dovrà ricevere quel determinato host che sta usando quel certificato.

qualora ci fossimo dimenticati il Common Name del certificato, assumendo che il certificato sia ancora presente nella directory "issued/" di EasyRSA, basterà eseguire il comando:

easyrsa show-cert <shortname>

<shortname> equivale semplicemente al nome del file senza estensione, quindi se il file è chiamato "client1.crt", lo shortname sarà semplicemente "client1".

quindi editiamo il file ed inseriamogli la riga:

ifconfig-push 10.0.0.200 255.255.255.0


in questo modo avremo definito l'IP per quel client.



Configurazione Client:


remote <indirizzo-ip> <porta>

come è facilmente intuibile, questi parametri sono l'indirizzo IP del server e la relativa porta, nel nostro caso la porta che abbiamo configurato sul server è quella standard, ossia 1194.

NOTA: ricordatevi di utilizzare l'indirizzo IP pubblico e qualora foste sotto nat/firewall, aprite la porta che avete scelto.


proto udp

deve essere lo stesso adottato per il server.


client

questa direttiva, come si evince dal nome, dice all'applicazione di comportarsi da client utilizzando autenticazione tls, in più abilita la modalità che permette di ricevere configurazioni dal server. è perfettamente equivalente alle "tls-client" "pull" messe assieme.

dev tun


(Come nel Server) deve essere coerente con l'impostazione nel server.

ca certs-client1/ca.crt
cert certs-client1/client1.crt
key certs-client1/client1.key


sono i certificati che abbiamo generato nella sezione precedente.


resolv-retry infinite

è opzionale, obbliga a ritentare la risoluzione dell'hostname qualora dovesse fallire.


nobind 

permetterà al sistema operativo di assegnare la source port.
 


comp-lzo

(Come nel Server)

persist-key

(Come nel Server)


persist-tun

(Come nel Server)


remote-cert-tls server

incrementa la sicurezza evitando attacchi di tipo man-in-the-middle
certificando che il server stia usando realmente un certificato
di tipo server. 

verb 3

imposta il livello di verbosity, ossia il dettaglio di informazioni che il log deve contenere.

------------------------------------------------------------------------------------

possiamo salvare i file ed avviare le VPN semplicemente premendo su "CONNECT" dal menu di OpenVPN sulla tray bar.

NOTA: affinchè l'applicazione possa modificare le tabelle di routing e quindi consentire il corretto funzionamento è importante ricordarsi di avviare OpenVPN su sistemi operativi Windows Vista/7/8 con i permessi di amministratore cliccando col tasto destro sull'icona, quindi "esegui come amministratore".

per Debian Linux invece il file dovrà essere salvato in /etc/openvpn/ sotto il nome di "server.conf" o "client.conf" e comando di avvio sarà "
/etc/init.d/openvpn start".
dualmente useremo "/etc/init.d/openvpn stop" per chiudere "/etc/init.d/openvpn restart" per riavviare (operazione necessaria ad ogni modifica della configurazione).

NOTA: si ricorda che le modalità di caricamento del file di configurazione o i comandi di gestione appena descritti dipendono dall'init script ed ogni distibuzione ne ha uno suo, ad esempio OpenVPN su "Debian Linux" avvia una istanza per ogni file .conf che trova nella directory "/etc/openvpn/", quindi se avete doppia configurazione, rinominate quella non utilizzata rimuovendo il ".conf" finale.

testiamo la nostra rete VPN con un semplice ping test dal terminale:

ping <host_remoto>

dove l'host remoto sarà l'IP dell'host che vogliamo raggiungere.
se ci risponderà, significa che la VPN funziona.


OpenVPN come gateway internet


Opzionalmente potete decidere di utilizzare il vostro server VPN come gateway di uscita per internet, ossia accedere ad internet tramite la VPN, utile talvolta per aggirare limiti e restrizioni imposti da alcuni provider internet rispetto all'IP che la nostra connessione ha assegnato.

I passi sono semplici

sul nostro Host che fa da server VPN è necessario:

  • Abilitare IP forward
  • Abilitare il NAT (Network Address Translation)
Ognuno di questi passaggi va eseguito sul Sistema Operativo e si differenzia totalmente in base a su queale di questi abbiamo impostato il nostro server.
- Linux

per prima cosa abilitiamo il forward semplicemente scrivendo sul terminale con permessi di root questa stringa:


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


successivamente abilitiamo il NAT:

quindi installiamo iptables ("apt-get install iptables" su Debian)

e dopo scriviamo questi comandi sul terminale:

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
iptables -P FORWARD DROP
iptables -A FORWARD -s 10.0.0.0/24 -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT


alla fine dobbiamo ricordarci di rendere permanenti le modifiche altrimenti al successivo riavvio della macchina le perderemo, quindi procediamo a salvare le regole iptables:

iptables-save > /ipt-NAT

poi editiamo il file /etc/rc.local ed inseriamo in coda:

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables-restore < /ipt-NAT

- Windows

NOTA: ci sono diverse procedure in base alla versione di Windows, io vi scrivo quella per Windows XP.

abilitiamo il forward:

digitiamo "regedit" da "esegui" e spostiamoci nella seguente chiave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Impostiamo il seguente valore di registro:

Nome valore: IPEnableRouter
Tipo valore: REG_DWORD
Dati valore: 1

impostando il valore ad "1", abilitiamo l'inoltro dei pacchetti IP per tutte le connessioni.

chiudiamo il registro.

Ora non ci resta che abilitare il NAT:

ora da "esegui" digitiamo "services.msc" e disabilitiamo "Routing ed Accesso remoto" e "Windows Firewall / Condivisione connessione Internet (ICS)"

spostiamoci in "Connessioni di rete" dal pannello di controllo, quì troveremo l'interfaccia connessa ad internet e quella che rappresenta la VPN, bene, segnamoci il nome di entrambe.

adesso da "esegui" digitiamo "netsh". ci apparirà una finestra in cui dovremmo inserire in sequenza i comandi dove:

pushd routing ip nat

uninstall

install

set global tcptimeoutmins=1440 udptimeoutmins=1 loglevel=ERROR

add interface name="<nome_interfaccia_internet>" mode=FULL

add interface name="<nome_interfaccia_VPN>" mode=PRIVATE

popd

------------------------------------------------------------------------------------

Per quanto riguarda la configurazione del client OpenVPN, basta inserire la seguenti direttive nel file di configurazione e riavviare il client

redirect-gateway def1

dhcp-option DNS 8.8.8.8

------------------------------------------------------------------------------------

Revoca dei certificati


è possibile che in un secondo momento si voglia impedire ad un host di connettersi alla VPN, oppure avete fornito quel certificato alla persona sbagliata, per fare ciò bisogna effettuare una revoca del certificato dello specifico host, procediamo nel farlo:

andiamo sul server e posizioniamoci nella directory
EasyRSA, quindi eseguiamo "EasyRSA Start.bat" o qualora fossimo su Linux, digitiamo i comandi nella shell preceduti da "./" (come già spiegato nel paragrafo della generazione dei certificati).
  
successivamente digitiamo il seguente comando seguito dal nome del file del certificato che vogliamo revocare:

easyrsa revoke
<client_file_name>

poi generiamo il file:

easyrsa gen-crl


NOTA: in entrambi i passaggi ci verrà chiesta la password del CA.
 

ci verrà mostrato un messaggio di successo.

succesivamente copiamo il file crl.pem contenuto nella sottodirectory pki/ nella directory principale di OpenVPN.

successivamente dobbiamo inserire la seguente direttiva nel file di configurazione server.conf

crl-verify crl.pem


infine riavviamo OpenVPN.

questa opzione consulterà automaticamente il file crl.pem ad ogni richiesta di connessione da parte di un client, quindi non c'è bisogno di riavviare il server e di conseguenza disturbare altri client non coinvolti.

in questo modo tutti i certificati saranno verificati nel file CRL, ed in caso di una verifica positiva, la connessione sarà automaticamente negata.