VPN Road Warrior (client-to-gateway)

Ultima modifica: 16 Marzo 2018

Valutazione attuale: 5 / 5

Oggi è sabato e domani non si lavora, parafrasando il grande Pino Daniele, anche se è tardi ed andare a dormire non sarebbe una cattiva idea. Ma il pensiero della VPN mi ronza in testa. Decido di continuare il lavoro iniziato qualche domenica fa, una VPN con OpenVPN e Raspberry Pi. Lo slate è già operativo, in genere è sempre operativo, ah se potesse parlare. Faccio partire un po’ di musica dance di sottofondo, una stazione radio vale l’altra, tanto a quest’ora gli speaker parlano poco. Spengo il WiFi sullo Slate, accendo la connessione cellulare, e si parte. Avvio OpenVPN. Come previsto tutto liscio, si collega al primo colpo.

Parto con la verifica di raggiungibilità di una macchina interna alla rete.

> ping 192.168.0.1

Pinging 192.168.0.1 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 192.168.0.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

VPN Road Warrior

Naturalmente non riesco a raggiungere le macchine interne. Lo sospettavo, infatti la VPN è di tipo point-to-point, e permette la connessione di due macchine. Adesso devo trasformare la configurazione in client-to-gateway.

Una VPN in modalità client-to-gateway permette ad un client di accedere alla rete LAN posta all’altro capo della VPN. L’altro capo funge appunto da gateway. Questa modalità è usata in genere per permettere ad utenti mobile di accedere alle risorse interne alla rete. Per questo motivo questa configurazione è detta anche road warrior.

Inizio la fase di analisi del problema per verificare cos’è che non va. Perché, nonostante la VPN funzioni, non riesco a collegarmi alle macchine della rete?

> tracert 192.168.0.1

Tracing route to 192.168.0.1 over a maximum of 30 hops: 1 1 ms 2 42 ms 39 ms 63 ms 172.4.5.6 3 40 ms 40 ms 41 ms 172.7.8.9 4 * * * Request timed out.

Sembra proprio che la richiesta si perda su Internet, mi sa che è un problema di routing. Il routing, o instradamento, è quel processo che permette ai dati di transitare da una rete ad all’altra. In questo caso mi sa che manca la route per accedere alla rete di casa, ed infatti i dati si perdono su Internet.

Per verificare la mia teoria aggiungo una route a mano, in pratica istruisco il client a trasmettere i dati verso la rete di casa (192.168.0.0/24) passando attraverso il gateway VPN (10.8.0.1). Per fare ciò eseguo il seguente comando da una shell dos avviata come amministratore:

> route add 192.168.0.0 mask 255.255.255.0 10.8.0.1

Bene adesso la macchina interna alla rete all’altro capo della VPN dovrebbe essere raggiungibile.

> ping 192.168.0.1

Male, la macchina ancora non è raggiungibile. Un dubbio mi assale, vuoi vedere che è spenta? Verifico, ma no, il pc è acceso. È tardi, ma non così tardi da fare le prove con la macchina di test spenta, sono ancora sveglio, anche se molto stanco. Magari c’è il firewall attivo sulla macchina? Neanche, tutto configurato bene. Ed infatti, se provo il ping dal client connesso alla rete WiFi non ho problemi. Il problema deve essere un po’ più serio.

Riprovo con il trace route per vedere dove si perdono i pacchetti:

> tracert 192.168.0.1

Tracing route to 192.168.0.1 over a maximum of 30 hops: 1 * * * Request timed out.

Niente da fare, forse è meglio andare a dormire. Sto per spegnere tutto quando ho un tuffo al cuore. Le note che escono dalla radio sono quelle di Children, di Robert Miles. Quanti ricordi. Come si fa ad abbandonare con una colonna sonora del genere? È deciso, continuo, questa notte devo avere la mia VPN Road Warrior.

Potrebbe sembrare che la route non sia servita a nulla, ma non è così. Infatti a differenza di prima il trace route mostra che il pacchetto continua a perdersi, ma non su Internet. Sembra più un problema del gateway.

Fortunatamente riesco ancora a raggiungere il gateway, per cui posso configurarlo via SSH. Provo ad aggiungere una NAT (network address translation) al gateway e a modificare il firewall affinché lasci passare il traffico proveniente dalla VPN verso la rete interna. Di fatto configuro la macchina all’altro capo della VPN come gateway.

$ sudo su
$ echo 1 > /proc/sys/net/ipv4/ip_forward
$ iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

I tre comandi servono rispettivamente ad acquisire i privilegi di amministratore, abilitare l’IP forwarding e la NAT.

Il ping eseguito dal client non lascia dubbi; la configurazione del gateway è completa, riesco a raggiungere le macchine interne alla rete. Beh, proprio completa no. Intanto ci sono un paio di configurazioni che al prossimo riavvio andranno perse, e poi c’è da migliorare un po’ la sicurezza della VPN.

Ma andiamo con ordine. Il primo problema di questa configurazione è che al prossimo riavvio del client non riuscirò a raggiungere le macchine interne, causa la cancellazione della route.

Una prima soluzione potrebbe essere quella di creare una route persistente, basta aggiungere il parametro –p al comando di creazione della route. Sicuramente la cosa funzionerebbe, ma avrei la route anche senza VPN attiva, e questo potrebbe creare non pochi problemi nel caso mi collegassi ad una lan con subnet 192.168.0.0/24. Meglio allora fare in modo che sia OpenVPN ad impostare la route quando viene attivata la VPN. Dopo aver eliminato la route appena creata manualmente, mi disconnetto dalla VPN e aggiungo quindi la seguente riga nel file client.conf:

route 192.168.0.0 255.255.255.0

Adesso la route verrà caricata solo quando verrà attivata la VPN. Per verificare che la route venga creata correttamente, avvio la VPN e lancio da shell dos il seguente comando:

> route print -4 | find "192.168.0.0"

192.168.0.0 255.255.255.0 10.8.0.1 10.8.0.2 30

Bene, la route c’è ed il ping funziona. Posso passare oltre. Adesso mi tocca rendere permanente la parte gateway. Anche in questo caso ho più opzioni, ma mi collego al Raspberry Pi via SSH ed inizio con il port forwardning nel seguente modo:

$ sudo su
$ echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
$ sysctl -p

Anche la configurazione del firewall è abbastanza semplice. Creo prima il file /usr/local/bin/iptables-openvpn.sh:

#!/bin/sh iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE chmod +x /usr/local/bin/iptables-openvpn.sh

E poi aggiungo la seguente linea al file /etc/rc.local, in modo da lanciare il file ad ogni riavvio del gateway, facendo attenzione a posizionarla prima del comando exit 0:

/usr/local/bin/iptables-openvpn.sh

Ottimizzazione e messa in sicurezza della VPN

Adesso non mi resta che riavviare il gateway per vedere se tutto va come dovrebbe. Va, per fortuna. Solo un paio di ottimizzazioni e poi chiudo per oggi. La prima riguarda la compressione dei dati. Infatti, OpenVPN è in grado di eseguire la compressione dei dati che transitano all'interno del tunnel VPN permettendo così di ridurre il carico sulla rete WAN. Mi basta aggiungere la seguente riga al file server.conf:

comp-lzo

Per aumentare ulteriormente la sicurezza mi preoccupo di eseguire OpenVPN senza i privilegi dell’utente root. Per fare questo basta aggiungere le seguenti righe al file server.conf:

user nobody group nogroup

Faccio le modifiche, mi sincero che tutto funzioni e spengo. O almeno questi sono i programmi. Perché c’è qualcosa che non va. Ho modificato il file server.conf e ho riavviato OpenVPN sul gateway, ma quando ho cercato di ripristinare la connessione ho avuto una brutta sorpresa.

Troubleshooting

Poco male, ne approfitto per attivare il logging in OpenVPN, così vedo cosa non va. Aggiungo le seguenti due righe al file server.conf.

log /var/log/openvpn verb 3

La prima attiva i log mentre la seconda dice che tipo di messaggi devono essere tracciati. Il livello 3 dovrebbe essere sufficiente allo scopo.

Collego tastiera e monitor al Raspberry Pi e con il seguente comando inizio a monitorare i log di OpenVPN:

sudo tail -f /var/log/openvpn

Bad LZO decompression header byte: 40

Il messaggio che compare a video appena cerco di connettermi alla VPN mi fa sorridere. La solita fretta, questa volta mista a stanchezza, vista l’ora tarda. Ho abilitato la compressione dei dati lato server, ma ho dimenticato di farlo sul client. Basta aggiungere la direttiva comp-lzo al file client.conf ed il gioco è fatto. Adesso ho di nuovo accesso alla rete di casa tramite tunnel VPN.

Un altro mattoncino della mia VPN è stato posato. La configurazione road warrior è completata.

continua...

Menu di navigazione