Archivi tag: openvpn

OpenVPN e client multipli

In questo post ho discusso della configurazione di OpenVPN (sia client che server). Tale configurazione si basa su una rete privata punto-punto, consentendo quindi la connessione in VPN ad un solo client per volta (solitamente quello dell’amministratore di rete per eventuali attività da remoto).

openvpn

Nel caso in cui, invece, si voglia consentire a più utenti di connettersi contemporaneamente al nostro VPN concentrator, è necessario apportare delle modifiche alla configurazione del server.

Di seguito gli step da seguire.

Configurazione del server

Per prima cosa, è necessario sostituire la direttiva:

ifconfig 192.168.110.1 192.168.110.2

con

server 192.168.110.0 255.255.255.0

Inoltre, mediante l’opzione:

 ifconfig-pool-persist ipp.txt

imporremo ad OpenVPN di mantenere una lista persistente di IP associati ai client, affinchè ad ogni nuova connessione venga loro assegnato sempre il medesimo indirizzo.

Per ragioni di sicurezza è meglio non far comunicare tra loro i client connessi in VPN ma, nel caso in cui si voglia consentire tale tipologia di traffico, è sufficiente aggiuntere questa opzione al file di configurazione del server:

client-to-client

Infine, se volessimo fare in modo che i client vegano nattati su Internet utilizzando l’IP pubblico del server VPN, è sufficiente aggiungere tali direttive al file di configurazione del demone in oggetto:

push "redirect-gateway def1"

impostando il nostro VPN concentrator come default gateway e:

push "dhcp-option DNS 8.8.8.8"

per forzare il nameserver da utilizzare durante la risoluzione degli FQDN in indirizzi IP.

E’ bene notare che, qualora fosse necessario, si dovrà operare anche sulla configurazione di netfilter del server VPN, impostando una regola di NAT simile alla seguente:

iptables -t nat -A POSTROUTING -s 192.168.110.0/24 -o eth1 -j MASQUERADE

e, nel caso in cui fosse abilitato lo steteful inspection, sarà necessario creare una regola del tipo:

iptables -A FORWARD -i eth1 -o tun0 -m state --state ESTABLISHED,RELATED -j ACCEPT

dove eth1 è l’interfaccia esposta su Internet e tun0 è l’interfaccia associata alla VPN.

Configurazione del client

Per il client, occorre semplicemente rimuovere la direttiva:

ifconfig 192.168.110.2 192.168.110.1

ed abbiamo finito.

Il post termina qui, alla prossima.

 

 

 

 

 

 

OpenVPN e WOL: accendere un PC da remoto attraverso un tunnel VPN

Recentemente mi è stato chiesto se fosse possibile inoltrare un magic packet mediante un tunnel VPN, in modo da accendere un PC da remoto senza forwardare porte aggiuntive sul router di destinazione. Ho quindi scaricato questo programma (free) ed ho subito iniziato i test.

La configurazione del suddetto programma è la seguente:

wol

In particolare, l’IP della workstation che voglio avviare da remoto è 192.168.1.5 e la subnet mask scelta è 255.255.255.255 (questo perchè la subnet della workstation è differente da quella del mio PC, quindi il traffico broadcast di livello 3 viene banalmente droppato dal mio router).

Tirando su uno sniffer sul VPN concentrator remoto:

user@vpn-concentrator:~$ sudo tcpdump -nn -i tun0

ho ottenuto il seguente output (dopo l’invio del magic packet):

17:17:52.386074 IP 192.168.114.2.61234 > 192.168.1.5.9: UDP, length 102
17:17:55.383997 IP 192.168.114.1 > 192.168.114.2: ICMP host 192.168.1.5 unreachable, length 138

ovvero l’interfaccia locale del suddetto VPN concentrator mi ha risposto con un pacchetto ICMP host unreachable.

Dando un’occhiata alla tabella ARP del server in questione ho notato che, essendo la workstation spenta ormai da tempo, non era presente nessuna entry ad essa correlata:

user@vpn-concentrator:~$ arp -a
? (192.168.1.7) associato a <incompleto> su eth0
? (192.168.1.14) associato a <incompleto> su eth0
? (192.168.1.5) associato a <incompleto> su eth0

Ho quindi creato una entry statica mediante il comando:

user@vpn-concentrator:~$ sudo arp -s 192.168.1.5 50:46:5d:54:07:76

ed il successivo invio di un magic packet ha finalmente avuto esito positivo (la macchina si è avviata ed ha iniziato a rispondere ai ping, come si evince dal tracciato tcpdump sottostante):

17:20:23.253400 IP 192.168.114.2.60731 > 192.168.1.5.9: UDP, length 102
17:20:39.211323 IP 192.168.114.2 > 192.168.1.5: ICMP echo request, id 1, seq 34, length 40
17:20:43.815485 IP 192.168.114.2 > 192.168.1.5: ICMP echo request, id 1, seq 35, length 40
17:20:43.815819 IP 192.168.1.5 > 192.168.114.2: ICMP echo reply, id 1, seq 35, length 40

Naturalmente tale settaggio non è più attivo dopo un eventuale riavvio del server. Per renderlo quindi “permanente” occorre modificare il file /etc/rc.local aggiungendo la seguente direttiva:

arp -s 192.168.1.5 50:46:5d:54:07:76

Alla prossima.

Creare una VPN SSL/TLS con OpenVPN

Lo standard de facto per realizzare i tunnel VPN è sicuramente IPSec. Tale protocollo è compatibile con dispositivi di vendor diversi (interoperabilità) e permette di creare dei tunnel altamente affidabili e robusti in termini di sicurezza. Per contro, però, esso risulta essere piuttosto complesso da configurare e proprio per questo motivo, soprattutto in ambito SOHO, si opta per soluzioni alternative. Una di queste è sicuramente OpenVPN, in grado di realizzare dei tunnel cifrati mediante i protocolli SSL/TLS.

Di seguito un breve howto in cui viene descritta la configurazione di OpenVPN per un bastion host dual-homed Linux.

Nello specifico, la rete locale è così definita:

Internet - Screened router - interfaccia UNTRUST del bastion - FW IPTABLES - interfaccia TRUST del bastion - LAN

Configurazione del server

Per prima cosa occorre installare l’applicativo in questione digitando il comando:

nightfly@nightbox:~$ sudo apt-get install openvpn

ad installazione completata, posizioniamoci nella directory /etc/openvpn e creiamo le subdir certificati e log:

 nightfly@nightbox:/etc/openvpn$ sudo mkdir log
 nightfly@nightbox:/etc/openvpn$ sudo mkdir certificati

Successivamente, creiamo i due file in cui verranno salvati i log:

 nightfly@nightbox:/etc/openvpn$ cd log
 nightfly@nightbox:/etc/openvpn/log$ sudo touch openvpn.log openvpn-status.log

A questo punto possiamo creare il file di configurazione:

nightfly@nightbox:/etc/openvpn$ sudo nano server.conf

il cui contenuto dovrà essere simile al seguente:

tls-server

port 5002

dev tun
ifconfig 192.168.110.1 192.168.110.2

persist-key
persist-tun

push "route 192.168.1.0 255.255.255.0"

#Percorsi dei certificati
ca certificati/ca.crt
cert certificati/server.crt
key certificati/server.key 
dh certificati/dh1024.pem
tls-auth certificati/ta.key 0 # 0 per il server ed 1 per il client, essenziale per la generazione dell'hash HMAC nell'header TLS

cipher BF-CBC
comp-lzo

keepalive 10 120

#log and security
user nobody
group nogroup
status log/openvpn-status.log
log-append log/openvpn.log
verb 3
scrip-security 2

Mediante la direttiva tls-server sto imponendo al mio bastion host di fungere da server per le sessioni TLS.

Con port specifico su quale porta OpenVPN deve rimanere in ascolto, mentre con dev tun sto scegliendo la tipologia di interfaccia da realizzare. A tal proposito, occorre precisare che i tipi di interfaccia che può tirar su OpenVPN sono 2, ovvero:

1) tun, per le VPN routed (livello 3);

2) tap, per le VPN bridged (livello 2).

Con ifconfig specifico l’indirizzo IP del tunnel VPN lato server (192.168.110.1) e lato client (192.168.110.2). Per la natura delle interfacce tun, trattasi di un collegamento point-to-point (/30).

con push “route 192.168.1.0 255.255.255.0” sto iniettando la rotta per raggiungere la mia LAN (interfaccia TRUST del bastion-host) sul client VPN.

Con le direttive:

 cipher BF-CBC
 comp-lzo

sto definendo il tipo di cifratura (BlowFish) ed il tipo di compressione (LZO – Lempel-Ziv-Oberhumer) messe in atto nel tunnel VPN.

Con keeplive faccio in modo che il tunnel rimanga attivo anche in assenza di traffico, mentre nella sezione #log and security definisco (in quest’ordine) i permessi, i file di log, il verbosity (accuratezza dei log) ed il livello di sicurezza di questo file di configurazione.

Salviamo il file in questione e procediamo con la generazione delle chiavi e dei certificati. Lato server i comandi da lanciare sono i seguenti:

nightfly@nightbox:~$ cd /usr/share/doc/openvpn/examples/easy-rsa/2.0/

nightfly@nightbox:~$ sudo nano vars

che andrà editato customizzando i campi indicati

nightfly@nightbox:~$ source ./vars

nightfly@nightbox:~$ ./clean-all

nightfly@nightbox:~$ ./build-ca

per la generazione del certificato relativo alla CA

nightfly@nightbox:~$ ./build-dh 

per lo scambio delle chiavi mediante l’algoritmo Diffie-Helman (leggasi premaster-key)

nightfly@nightbox:~$ ./build-key-server server

per la generazione della chiave privata associata al server, con relativa richiesta *.crt

nightfly@nightbox:~$ openvpn --genkey --secret ta.key

per la generazione della chiave segreta.

Una volta generate le chiavi ed i certificati copiamoli nella directory /etc/openvpn/certificati:

nightfly@nightbox:~$ sudo cp ca.crt server.crt server.key dh1024.pem ta.key /etc/openvpn/certificati

A questo punto possiamo avviare il demone OpenVPN:

nightfly@nightbox:~$ sudo service openvpn start

Verifichiamo che l’interfaccia tun0 sia attiva mediante il comando ifconfig:

nightfly@nightbox:~$ ifconfig

tun0     Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
indirizzo inet:192.168.110.1  P-t-P:192.168.110.2  Maschera:255.255.255.255
UP POINTOPOINT RUNNING NOARP 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
collisioni:0 txqueuelen:100
Byte RX:0 (0.0 B)  Byte TX:0 (0.0 B)

Configurazione di IPTABLES

Il bastion host ha DROP come azione di default per la chain FORWARD. Proprio per questo motivo, occorre consentire il transito del traffico dall’interfaccia tun0 a quella TRUST (eth0) e viceversa. Le regole da definire sono le seguenti:

 iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
 iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT

Configurazione del client

A questo punto è possibile installare e configurare il client, che però dovrà utilizzare lo stesso file ca.crt del server, la medesima chiave ta.key del server ma una propria chiave privata (client.key) ed un proprio certificato (client.crt).

Per ambienti Windows vi consiglio questo client Openvpn (se utilizzate Windows 7 fate riferimento a questa pagina per la procedura di installazione).

Quest’altro client, invece, evitatelo come la peste (in quanto bacatissimo, d’altronde è una versione alpha).

Ad installazione completata potrete utilizzare il seguente file di configurazione:

remote <indirizzo IP pubblico del server OpenVPN> 5002
client
tls-client
nobind
dev tun
ifconfig 192.168.110.2 192.168.110.1
pull

ca key/ca.crt
cert key/client.crt
key key/client.key
tls-auth key/ta.key 1

persist-key
persist-tun

cipher BF-CBC

comp-lzo

keepalive 10 120

scrip-security 2

verb 3

Da notare che gli algoritmi di compressione e cifratura devono essere i medesimi di quelli utilizzati dal server, pena l’impossibilità di connettersi allo stesso.

Diagnostica

A connessione VPN avvenuta, potete verificare la raggiungibilità attraverso il tunnel degli host della LAN mediante un seplice ping, ad esempio:

ping 192.168.1.2

Se il ping dovesse andare in timeout, provate a mettere in ascolto tcpdump sulle interfacce tun0 ed eth0 e controllate la tabella di routing del vostro bastion host (attraverso il comando route).

Verificate inoltre che la rotta verso la LAN sia stata correttamente iniettata sul client (Windows), digitando:

route print

Fine del post, bye.

Bypassare il firewall della rete aziendale mediante OpenVPN

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.

 

schema1.png

 

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…

 

schema2.png

 

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.