Quanto di seguito, è il racconto di una mattina in ufficio, passata a dare una mano ad un amico. Non vuole essere assolutamente un how-to su OpenVPN, per il quale si trova dell’ottima documentazione su internet, a partire da quella presente sul sito ufficiale.
Poniamo il caso che un giorno un vostro amico vi telefoni e vi dica qualcosa del genere: “Ti prego, aiutami!!! Devo assolutamente entrare su LogmeIn per fare un’assistenza urgente, ma questa rete è completamente chiusa. Non so proprio come fare!!!”.
Ovviamente voi, spinti da irrefrenabile spirito di altruismo, non potrete rimanere indifferenti. L’unico abbozzo di soluzione che vi verrà in mente sarà quello di dirottare il traffico del vostro amico attraverso di voi, visto che, casualmente, avete una macchina Linux proprio lì sulla vostra scrivania.
LogMeIn rappresenta un esempio abbastanza interessante, non permettendo il passaggio attraverso Socks di nessun tipo. Pertanto, per risolvere il problema, la cosa migliore venutaci in mente è quella di bypassare e non utilizzare nessun tipo di proxy.
Armati di santa pazienza e di un buon auricolare, iniziate ad investigare. In primis perché il vostro amico non riesce ad accedere a LogMeIn, oltre che a tutta una serie di altri siti? Poi, quanta intelligenza ha l’attrezzo che gli tarpa le ali?
Rispondere alla prima domanda è piuttosto semplice: c’è un firewall, piuttosto che un proxy, piuttosto che qualche genere di apparato che in base ad una lista o ad un servizio, decide se l’URL che volete visitare è da considerarsi legittima oppure no.
Per quanto riguarda la seconda domanda, la riscrivo in maniera meno criptica: l’apparato che blocca, è un semplice firewall? Si limita a fare firewalling oppure fa anche content inspection? Cioè, se sulla porta 80 faccio viaggiare qualunque altra cosa che non sia HTTP, lui se ne accorge oppure no?
Boh, non rimane che provare. Per fare una prova veloce e “senza impegno” usiamo netcat (grazie di esistere!!):

netcat –l 80

ossia lo mettiamo in listening sulla porta 80 della nostra macchina, pronto ad accettare qualunque connessione da chicchessia. Ovviamente se siete anche voi, a vostra volta, dietro un firewall, dovete fare in modo che questi consenta che voi accettiate connessioni dall’esterno, o con port-forwarding o con un DNAT e relativa policy.
Fatto questo, fate un fischio al vostro amico che sta all’interno della rete protetta e ditegli di fare un bel:

telnet il.vostro.indirizzo.ip 80

Se tutto funziona a dovere, avete realizzato un piccolo tubo, di cui il vostro amico sta ad un’estremità e voi all’estremità opposta. A questo punto ogni carattere che lui inserirà sulla console, voi ve lo vedrete rispuntare dalla vostra parte del tubo. Quello che sta succedendo, ai fini del nostro test, è che l’apparato che sta ai bordi della rete non si accorge che la nostra comunicazione, benché sia sulla porta TCP 80, non è affatto HTTP. Questo ci suggerisce che l’attrezzo non è così cattivo come sembra, ed è disposto a far passare qualunque cosa purché sia sulla porta www e l’IP o il dominio non siano stato inseriti fra i suoi filtri.

A questo punto siamo pronti a mettere in piedi il resto della baracca: lato nostro installeremo OpenVPN e lo configureremo come server. Il nostro amico (che per ipotesi ha una macchina Windows) dovrà installare la versione client. Non entro nei dettagli di installazione del client che si trovano un po’ ovunque.
Per mettere a punto la configurazione sul server dovremo fare, più o meno tre macro passaggi:

1. abilitare il server sulla porta 80, pronto a ricevere connessioni con una chiave condivisa col nostro amico;

2. abilitare la nostra macchina a fare del routing;

3. nattare la macchina del nostro amico, in modo che sulla rete abbia lo stesso IP della nostra;

In merito al primo punto e all’utilizzo di una chiave condivisa, certo non è il modo migliore e più sicuro di utilizzare OpenVPN. Per una infrastruttura stabile e seria è assolutamente consigliato utilizzare i certificati. Ma questa non è né un’infrastruttura stabile, né tanto meno seria…

Per prima cosa, genereremo la chiave condivisa:

openvpn --genkey --secret key.txt

Io ho messo questo file nella directory

/etc/openvpn

Adesso configureremo il server OpenVPN:

 dev tun
 secret /etc/openvpn/key.txt
 ping 10
 verb 1
 mute 10
 ifconfig 10.0.1.1 10.0.1.2
 proto tcp-server
 lport 80

Di questa configurazione, ci interessano in particolare questi dettagli:

• dev tun: questo è il tipo di device che intendiamo utilizzare. Le scelte possibili sono tap e tun. Il device tun creerà un device di livello 3, creando delle interfacce punto-punto. Da manuale, è sempre consigliabile utilizzare questo tipo di device, a meno di situazioni in cui sia richiesto l’utilizzo di protocolli particolari o si faccia grande utilizzo di broadcast.
• ifconfig 10.0.1.1 10.0.1.2: queste sono le impostazioni della vostra interfaccia tun. Se date un’occhiata al manuale di OpenVPN, vi renderete conto di come, questa opzione, abbia due significati differenti a seconda che il device sia tun o tap. Nel nostro caso stiamo dicendo al server che la nostra interfaccia avrà indirizzo 10.0.1.1 mentre quella del nostro amico, sulla quale termineremo questo collegamento punto-punto, avrà indirizzo 10.0.1.2
• tcp-server e lport 80: questa sono un po’ il cuore di tutto il nostro discorso, infatti metteno in ascolto il server OpenVPN sulla porta TCP 80, piuttosto che su quella di default, alla stregua, quindi, di qualunque web-server.
La configurazione che dovrete inviare al vostro amico sarà speculare alla vostra, e, soprattutto, avrà la stessa chiave, che dovrete provvedere a passargli.

 remote il.vostro.ip.pubblico
 proto tcp-client
 rport 80
 dev tun
 ifconfig 10.0.1.2 10.0.1.1
 secret key.txt
 route-gateway 10.0.1.1
 redirect-gateway
 ping 10
 verb 1
 mute 10

Anche per questa configurazione, facciamo un paio di considerazioni:
• route-gateway e redirect-gateway: affinché il tutto funzioni, queste opzioni sono fondamentali, in quanto impongono al client di utilizzare come default gateway l’interfaccia tun appena creata. Pertanto, tutto il traffico in uscita dal client, non diretto alla sua sottorete, verrà instradato verso il server OpenVPN. A questo proposito va fatta una sottolineatura: quando si parla di tutto il traffico, si intende TUTTO il traffico, per cui, ad esempio, anche quello DNS. Se quindi, il vostro amico ha impostato come DNS uno interno alla sua rete, visto che passerà per voi, non riuscirà mai a raggiungerlo. Quindi o cambia DNS o potete fare in modo di mandargliene uno voi tramite il push. Per questo vi rimando al manuale.
• proto tcp-client e rport 80: protocollo e porta verso la quale il vostro amico dovrà connettersi.
Non rimane che tirare su il tutto, voi il server ed il vostro amico il client. Se tutto va come
dovrebbe, facendovi dei rispettivi ping dovrete avere delle risposte:

Lato server: ping 10.0.1.2
Lato client: ping 10.0.1.1

Rimangono da completare altri due task lato server: il routing ed il NAT.
Per quanto riguarda il routing, io solitamente faccio così:

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

Questa impostazione trasformerà il vostro computer in un router, permettendo, di fatto, il
fowarding dei pacchetti fra le vostre schede di rete.

Anche per quanto riguarda il nat, o meglio, il MASQUERADE ce la sbrigheremo
facilmente:

iptables -t nat -A POSTROUTING -s 10.0.1.2/32 -o eth0 -j MASQUERADE

Probabilmente, quella messa sopra, è la stringa di iptables più famosa del web, nonché una delle meravigliose “magie” di Linux e IPTABLES. In sostanza fa in modo che tutto il traffico che attraverserà in uscita l’interfaccia eth0 del server (nell’ipotesi che la eth0 sia l’interfaccia utilizzata dal server per connettersi alla LAN) dovrà essere mascherato con l’indirizzo dell’interfaccia stessa.
A questo punto tutta l’infrastruttura dovrebbe essere ok, e non rimane altro che provare. Un traceroute (o tracert su Windows) o un sito come www.myip.dk, potrebbero essere gli strumenti giusti per fare qualche test.
In bocca al lupo.