Un Gateway VPN con RaspberryPi (e un po’ di DNS cache con Dnsmasq)

Raspberry Pi Logo
ATTENZIONE: ALCUNE INFORMAZIONI RIPORTATE IN QUESTO ARTICOLO SONO DA CONSIDERARSI OBSOLETE E NON NE È RACCOMANDATA L’ESECUZIONE SULLE NUOVE VERSIONI DI RASPBIAN JESSIE E DERIVATE.

Una VPN (Virtual Private Network) è una rete che permette a computer che si trovano in sedi fisiche diverse di stabilire un collegamento privato e criptato tramite Internet. Un tempo erano necessarie costose linee dedicate per ottenere tutto questo. Le VPN hanno permesso di abbattere i costi. Una rete VPN, soprattutto in ambito domestico, può risultare utile per rendere le connessioni sicure, navigare in modo anonimo e sbloccare le censure o i contenuti region locked di alcuni servizi tipo Netflix. In sostanza una VPN ci garantisce una navigazione anonima e sicura verso qualsiasi fonte di dati, criptando le nostre comunicazioni e permettendoci di emulare l’indirizzo di provenienza con quello di un server di una nazione a nostra scelta.

Un Gateway VPN consente di collegare facilmente più dispositivi alla stessa rete VPN, aggirando i limiti spesso imposti dai provider VPN che permettono una o al massimo due connessioni simultanee per ogni sottoscrizione.

Note sulla guida

Questa guida non è altro che la raccolta (ri)ordinata (circa…) e rivista di alcuni appunti che ho preso per realizzare la mia prima versione del gateway VPN con Raspberry Pi. Sono sicuramente presenti errori e omissioni in quanto non sono (e non mi ritengo) un esperto in materia, quindi prendete il tutto per quello che è: una (piuttosto lunga) seri di appunti.

Inoltre vi prego di notare che alcune parti della guida sono opzionali e non sono indispensabili ai fini del funzionamento del gateway VPN, ma possono tornare utili per configurazioni particolari.

Prerequisiti

  • Una scheda Raspberry Pi (completa di SD/microSD) con porta ethernet da utilizzare come Gateway VPN.
  • HideMyAss.comUn abbonamento ad un qualche provider che fornisca un servizio VPN. In questa guida farò riferimento a HideMyAss, ma siete liberi di utilizzare qualsiasi altro provider: in questo caso dovrete adattare le istruzioni per la preparazione dei file di configurazione forniti del provider stesso. I link a HideMyAss presenti in questo articolo sono “sponsorizzati” (partecipo al programma di affiliazione di HMA).
  • Per questa guida ho scelto come distribuzione di riferimento RaspBian, ma esistono molte altre distribuzioni adatte allo scopo, una su tutte MiniBian, una derivata di RaspBian molto più leggera e ideata per progetti embedded.
  • Il vostro IP Range deve essere del tipo 192.168.0.0/24 – Se così non fosse dovrete riadattare ogni comando/parametro che fa riferimento alla LAN presente nella guida.
  • Un minimo di dimestichezza con la shell di Linux.
  • Un po’ di pazienza.

Parte 1: Installare il Sistema Operativo

Scarichiamo l’ultima versione della distribuzione da Raspberry.org e procediamo con l’installazione nel solito modo. Inseriamo la sd/microsd nella RPi collegata via Ethernet alla LAN ed avviamo il tutto attaccando l’alimentazione.

Ora dobbiamo recuperare l’indirizzo IP assegnato automaticamente alla scheda. Se avete collegato la RPi ad un monitor, l’IP dovrebbe apparire alla fine del processo di boot, altrimenti è possibile utilizzare nmap  (se nmap non risulta installato: sudo apt-get install nmap):

nmap -sP 192.168.0.0/24

L’output sarà qualcosa del genere:

Starting Nmap 6.46 ( http://nmap.org ) at 2015-04-13 11:04 CEST
Nmap scan report for 192.168.0.1
Host is up (0.0035s latency).
Nmap scan report for 192.168.0.58
Host is up (0.000079s latency).
Nmap scan report for 192.168.0.130
Host is up (0.0099s latency).

In questo caso l’IP della mia RPi è 192.168.0.130 in quanto gli altri due sono rispettivamente del router e del Notebook.

Colleghiamoci quindi via SSH alla RPi (user “pi“, password “raspberry“) e come prima cosa cambiamo immediatamente la password di default dell’utente “pi” con qualcosa di più robusto tramite raspi-config (per avviarlo: sudo raspi-config). Sempre tramite raspi-config, procediamo a rinominare l’hostname ed espandiamo il filesystem per occupare tutto lo spazio disponibile. Infine riavviamo con sudo reboot.

Ricolleghiamoci tramite ssh e modifichiamo il file /etc/network/interfaces per fare in modo che la nostra RPi abbia un’indirizzo IP statico e non utilizzi eventuali server DHCP presenti nella nostra rete:

sudo nano /etc/network/interfaces

e modifichiamo

iface eth0 inet dhcp

in

iface eth0 inet static

ed aggiungiamo le seguenti voci:

address 192.168.0.130
broadcast 192.168.0.255
netmask 255.255.255.0
network 192.168.0.0
gateway 192.168.0.1

(ovviamente dovrete adattare i vari parametri a quelli della vostra rete: per maggiori info consultare questa guida.)

Salviamo (CTRL+o) ed usciamo da nano.

Ora effettuiamo un reboot del sistema (sudo reboot) e colleghiamoci nuovamente tramite SSH; ricordatevi che il device avrà cambiato IP, prendendo quello che avete indicato precedentemente in /etc/network/interfaces.

Alleggerire Raspbian (opzionale - clicca per espandere)

Se avete optato per l’installazione di RaspBian, vi sarete tirati dietro un mucchio di pacchetti inutili che non verranno mai utilizzati, ovvero tutti quelli relativi all’interfaccia grafica. Con un po’ di pazienza è però possibile rimuovere gran parte delle librerie e dei programmi in questione, vediamo come.

Con il comando che segue disinstalleremo (quasi) tutto quello che riguarda l’interfaccia grafica. L’operazione durerà abbastanza a lungo:

apt-get remove --auto-remove --purge libx11-.*

Ora installiamo deborphan. Tramite questo programma, lanciato con i parametri di default, identificheremo tutte le librerie rimaste nel sistema che non hanno programmi da esse dipendenti (ovvero librerie inutili):

sudo apt-get install deborphan

Diamo un’occhiata alle librerie che stiamo per eliminare:

deborphan -sz

Ed ora cancelliamole definitivamente:

sudo apt-get remove --purge $(deborphan)

Infine utilizziamo l’opzione autoremove di apt-get per (cito testualmente dal man) “…rimuovere i pacchetti che sono stati installati automaticamente per soddisfare delle dipendenze per altri pacchetti e che non sono più necessari.

sudo apt-get autoremove

A questo punto dovreste ritrovarvi Raspbian di circa 1GB e rotti più leggera ed un poco più adatta ai nostri scopi.

Aggiorniamo infine il sistema:

sudo apt-get update && sudo apt-get upgrade

Parte 2 – Installare e configurare dnsmasq

Dnsmasq fornisce un servizio di cache DNS e di server DHCP. Come DNS (Domani Main Server) può conservare in cache i risultati delle richieste di risoluzione per migliorare la velocità di connessione ai siti già visitati mentre, come server DHCP, può essere usato per fornire indirizzi IP interni ed instradare i dati in una LAN. I servizi possono essere abilitati singolarmente oppure insieme. In questa parte vedremo come abilitare il servizio DNS.

Installiamo dnsmasq:

sudo apt-get install dnsmasq

Fermiamo il servizio che dovrebbe essersi avviato in automatico al termine dell’installazione:

sudo service dnsmasq stop

Per sicurezza rinominiamo il file originale:

sudo cp /etc/dnsmasq.conf /etc/dnsmasq.conf.orig

e creiamo una nuova copia vuota del file di configurazione principale:

sudo nano /etc/dnsmasq.conf

Copiamo nel file appena creato quanto segue (adattando dove opportuno i parametri alle nostre esigenze):

##### dns #####
# Non passare al DNS le richieste per nomi di dominio incompleti
# (es. senza il punto oppure senza il nome di dominio).
# Questo significa  che le richieste di risoluzione per nomi incompleti,
# tipo "google" invece di "google.com", # vengono eliminate prima
# che lascino la LAN
domain-needed

# Qualsiasi richiesta di risoluzione inversa di intervalli di indirizzi
# IP privati (es: 192.168.x.x) non viene passata al server DNS
bogus-priv

# Indica a dnsmaq su quale indirizzo IP rimanere in ascolto e
# quindi erogare i servizi. In questo caso l'opzione è impostata
# sull'indirizzo IP statico che abbiamo assegnato in /etc/network/interfaces
# all'unica interfaccia di rete presente nella nostra RPi
listen-address=192.168.0.130

# Decommentare per forzare dnsmasq ad utilizzare le porte
# sopra quella specificata. Utile se ci si trova dietro un firewall.
# min-port=4096

# Cache DNS
cache-size=10000

# Il servizio dnsmasq non si appoggia al contenuto del file /etc/resolv.conf,
# ma utilizza i server indicati sotto
no-resolv

# localhost
server=127.0.0.1

# Server DNS 1 (per Google utilizzare 8.8.8.8)
server=208.67.222.222

# Server DNS 2 (per Google utilizzare 8.8.4.4)
server=208.67.220.220

# Logging
# Decommentando log-queries, i log del di dnsmaq verranno
# registarti in /var/log/daemon.log
# decommentando log-facility, i log verranno registrati nel file specificato
#log-facility=/var/log/dnsmasq.log
#log-queries

Controlliamo che dnsmasq funzioni a dovere riattivando il servizio:

sudo service dnsmasq start

Ora impostiamo un qualsiasi computer della nostra LAN per utilizzare dnsmasq, impostandone la connessione in modo che l’opzione Server DNS punti all’indirizzo IP della RPi (schermata di esempio tratta da Lubuntu):

Schermata Impostazioni IP4 su Lubuntu
Impostare il server DNS su Lubuntu

Riavviamo la connessione per essere sicuri che le nuove impostazioni vengano caricate. Dalla shell dello stesso computer effettuiamo un dig ad un qualsiasi dominio (se non avete dig nel vostro sistema installarlo con sudo apt-get install dnsutils):

dig nasa.com

Analizziamo il tempo della query (è la voce ;; Query time: 400 msec):

Query DNS no cached
Query DNS no cached

Eseguiamo di nuovo il comando e controlliamone l’output:

Query DNS cached
Query DNS cached

E’ un poco più veloce, no?

Ora controlleremo che effettivamente le query DNS vengano gestite correttamente da dnsmasq. Sulla RPI fermiamo il servizio dnsmasq:

sudo service dnsmasq stop

Abilitiamo il log decommentando le righe opportune in dnsmasq (sezione “Logging” del file di configurazione) e riavviamo il demone:

sudo service dnsmasq start

Controlliamo l’output del programma con tail -f /var/log/dnsmasq.log

Ora effettuiamo di nuovo i due dig precedenti: possiamo vedere come la prima volta il dominio nasa.com non sia nella cache e la query venga passata ai DNS impostati in dnsmasq.conf, mentre la seconda volta la risposta arriverà direttamente dalla cache di dnsmasq:

dig nasa.com
...
Apr 11 08:24:39 dnsmasq[17845]: query[A] nasa.com from 192.168.0.58
Apr 11 08:24:39 dnsmasq[17845]: forwarded nasa.com to 127.0.0.1
Apr 11 08:24:39 dnsmasq[17845]: forwarded nasa.com to 208.67.222.222
Apr 11 08:24:39 dnsmasq[17845]: forwarded nasa.com to 208.67.220.220
Apr 11 08:24:39 dnsmasq[17845]: reply nasa.com is 173.244.177.114

dig nasa.com
....
Apr 11 08:24:41 dnsmasq[17845]: query[A] nasa.com from 192.168.0.58
Apr 11 08:24:41 dnsmasq[17845]: cached nasa.com is 173.244.177.114

Ok, dnmasq è bello e funzionante ma prima di continuare, per evitare problemi di saturazione repentina dello spazio della nostra scheda SD, disabilitiamo nuovamente i log di dnsmasq (ricordatevi di fermare il servizio prima delle modifiche!). Se si vuole continuare ad utilizzare la possibilità di loggin di dnsmasq, fare riferimento alla parte opzionale della guida: Dnsmasq logging con logrotate.

Dnsmasq logging con logrotate (opzionale - clicca per espandere)

Come abbiamo già visto, affinché dnsmasq possa registrare i suoi messaggi su un logfile custom, è necessario decommentare le direttive log-queries e log-facility in /etc/dnmasq.conf ed indicare correttamente la patch al file di log nella direttiva log-facility.

Per assicurarci che il log venga propriamente gestito è necessario utilizzare questa file di configurazione per logrotate:

/var/log/dnsmasq.log {
monthly
missingok
notifempty
delaycompress
sharedscripts
postrotate
[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 `cat /var/run/dnsmasq.pid`
endscript
create 0640 dnsmasq dnsmasq
}

Salvare il file sopra riportato come /etc/logrotate.d/dnsmasq. Correggere, se necessario, il nome del file di log o la path al PID file, ma non modificare il segnale USR2 che viene inviato all’interno della routine postrotate.

Parte 3 – Installare e configurare OpenVPN

Iniziamo con l’installazione del pacchetto OpenVPN. Sempre collegati via ssh, impartiamo il seguente comando:

sudo apt-get install openvpn

Entro pochi secondi dovreste ritrovarvi con OpenVPN installato. Fermiamo subito il servizio e creiamo in /etc/openvpn/ un paio di directory per facilitarci il lavoro:

sudo service openvpn stop
sudo mkdir -p /etc/openvpn/HMA/disabled

Utilizzeremo la directory /etc/openvpn/HMA/ per inserire i file di configurazione dei server di HideMyAss, mentre la directory /etc/openvpn/HMA/disabled/ potrà essere utilizzate come dir di servizio dove spostare eventuali file di configurazione non utilizzati.

A questo punto dobbiamo scaricare i file di configurazione per i vari server messi a disposizione dal provider VPN. Nel caso di HideMyAss i server disponibili sono più di 800: è possibile scaricarli tutti, anche se io non lo consiglio. I file di configurazione sono forniti sia per l’utilizzo del protocollo TCP sia per il protocollo UDP: dal punto di vista dell’utente finale la differenza tra l’utilizo dei due protocoli si può ridurre al fatto che con UDP si possono ottenere velocità maggiori rispetto all’utilizzo del protocollo TCP, ma questo dipende da moltissimi elementi. Solitamente i provider VPN lasciano all’utente la scelta del protocollo da utilizzare limitandosi ad indicare di cambiarlo se si lamentano problemi di disconnessioni o altri errori di rete. Per questa guida utilizzeremo il protocollo UDP che, almeno nel mio caso, mi ha dato ottimi risultati con moltisimi server europei. Il mio consiglio è di fare alcune prove sia con i file conf TCP che UDP e infine utilizzare quelli che si ritengono più idonei alle proprie esigenze.

Spostiamoci quindi nella directory /etc/openvpn/HMA/ e scarichiamo alcuni file di configurazione UDP utilizzando wget:

cd /etc/openvpn/HMA/
sudo wget https://www.hidemyass.com/vpn-config/UDP/Netherlands.Amsterdam_LOC2S9.UDP.ovpn https://www.hidemyass.com/vpn-config/UDP/Sweden.Stockholm.Nacka_LOC1S9.UDP.ovpn https://www.hidemyass.com/vpn-config/UDP/Netherlands.Dronten_LOC1S4.UDP.ovpn https://www.hidemyass.com/vpn-config/UDP/Germany.Frankfurt-VirtualUSA_LOC1S1.UDP.ovpn

Scaricare tutti i file di configurazione TCP e UDP (opzionale - clicca per espandere)

Se desiderate scaricare tutti i file siano essi TCP che UDP:

sudo wget https://www.hidemyass.com/vpn-config/vpn-configs.zip
sudo unzip vpn-configs.zip && sudo rm openvpn.zip

Vi ritroverete con due ulteriori directory, UDP e TCP contenenti i relativi file di configurazione.

Se volete solo i file di configurazione TCP:

wget -r -A.ovpn -nd --no-parent https://www.hidemyass.com/vpn-config/TCP/

Per i soli file di configurazione UDP:

wget -r -A.ovpn -nd --no-parent https://www.hidemyass.com/vpn-config/TCP/

Negli ultimi due casi mettetevi comodi perché l’operazione durerà qualche buon minuto.

Qualsiasi sia il metodo scelto per scaricare i file, ricordatevi che dovranno essere posizionati nella directory /etc/openvpn/HMA.

Scaricare le chiavi di HMA (opzionale - clicca per espandere)

Anche se ai fini di questa guida non sono necessari, in quanto già integrate nei file di configurazione dei vari server, è possibile scaricare le chiavi di HideMyAss:

sudo wget http://hidemyass.com/vpn-config/keys/ca.crt http://hidemyass.com/vpn-config/keys/hmauser.crt http://hidemyass.com/vpn-config/keys/hmauser.key -P /etc/openvpn/HMA/

Creiamo un file contenente lo username e la nostra password dell’account che abbiamo su HideMyAss:

sudo nano hmauser.pass

Inserite username e password in questo modo (sostituite ovviamente username e password con i dati di accesso del vostro account HMA):

username
password

Salviamo ed usciamo da nano.

Modifichiamo i file di configurazione precedentemente scaricati cambiando la direttiva auth-user-pass in auth-user-pass hmauser.pass ed aggiungendo l’opzione redirect-gateway; senza queste modifiche il gateway VPN non potrà funzionare. Utilizziamo sed per una modifica di massa (ricordatevi che siamo sempre in /etc/openvpn/HMA/):

sudo sed -i 's/auth-user-pass/auth-user-pass hmauser.pass\nredirect-gateway/g' *.ovpn

Ora abbiamo due possibilità:

  • Impostare OpenVPN per collegarsi sempre e solo ad uno dei server scelti (metodo raccomandato; ovviamente avremo sempre la possibilità di modificare il server scelto, ma lo potremo fare solo manualmente)
  • Fare in modo che OpenVPN scelga uno dei server disponibili in maniera random ad ogni suo avvio

Metodo 1 - Collegamento ad un server singolo

In /etc/openvpn/ creiamo un symbolic link chiamato server.conf che punti al file di configurazione del server scelto (in questo esempio Sweden.Stockholm.Nacka_LOC1S9.UDP.ovpn):

sudo ln -s /etc/openvpn/HMA/Sweden.Stockholm.Nacka_LOC1S9.UDP.ovpn server.conf

Proviamo quindi ad avviare e fermare immediatamente OpenVPN:

sudo service openvpn start && sudo service openvpn stop

Dovremmo ricevere un output come il seguente:

[ ok ] Starting virtual private network daemon: server.
[ ok ] Stopping virtual private network daemon: server.

Ok, il servizio si avvia (e finisce) correttamente: la nostra VPN funziona correttamente, ma necessita ancora di piccole modifiche.

Metodo 2 - Scelta random automatica del server VPN all'avvio di OpenVPN

Questo metodo richiede un po’ di modifiche, ma ci permette maggiore flessibilità. Per prima cosa, se precedentemente utilizzavamo il metodo di collegamento ad un server singolo sopra esposto, eliminate il symbolic link /etc/openvpn/server.conf precedentemente creato.

Ora modifichiamo l’estensione dei file di configurazione da .ovpn a .conf, così da poter utilizzare lo script di autostart, che vedremo dopo, per scegliere in automatico un server random tra quelli disponibili:

cd /etc/openvpn/HMA/
sudo rename 's/ovpn/conf/' *.ovpn

(In minibian potete utilizzare rename.ul .ovpn .conf *.ovpn)

Modifichiamo quindi lo script di init di OpenVPN; attenzione a ricopiare esattamente quanto sotto riportato, pena l’impossibilità di far partire il servizio stesso.

Apriamo il file di init con l’editor nano:

sudo nano /etc/init.d/openvpn

modifichiamo la riga

CONFIG_DIR=/etc/openvpn

in questo modo:

#CONFIG_DIR=/etc/openvpn
CONFIG_DIR=/etc/openvpn/HMA

Subito sotto la riga:

test -d $CONFIG_DIR || exit 0

Aggiungiamo le seguenti istruzioni:

# Helper array and selector variable to pick random element
returnRandomVPN (){
# set Interna File Separator to NewLine
IFS='
'
CHOSEN="$(ls $CONFIG_DIR/*.conf | shuf -n1)"
CHOSEN=`basename $CHOSEN .conf`
# set IFS @default
unset IFS
if [ -z "$CHOSEN" ]; then
returnRandomVPN
else
echo $CHOSEN
fi
}

Ancora poco più sotto modifichiamo la riga:

AUTOSTART="all"

in questo modo:

#AUTOSTART="all"
AUTOSTART=`returnRandomVPN`

Salviamo ed usciamo da nano.

Proviamo lo script di avvio modificato avviando e fermando immediatamente il servizio:

service openvpn start && service openvpn stop

Se è andato tutto liscio doveste ritrovarvi con un output simile al seguente:

...
[ ok ] Starting virtual private network daemon: Netherlands.Amsterdam_LOC2S9.UDP.
...

Proviamo ancora una volta ad avviare e fermare il servizio: ora l’output dovrebbe essere cambiato e il demone dovrebbe riportare la scelta di un nuovo file di configurazione. Se così non fosse, ricontrollate le modifiche fatte allo script di init fino a quando il tutto non funzionerà in maniera corretta.

Parte 4 – Impostare iptable ed il kernel per gestire il traffico attraverso la VPN

Per fare funzionare correttamente il nostro gateway VPN, dobbiamo abilitare l’IP forwarding del kernel della nostra Raspbian.Come primo passo testiamo se il forwarding è abilitato o meno:

cat /proc/sys/net/ipv4/ip_forward

se il risultato del comando sopra riportato è 0, dobbiamo abilitare l’IP Forwarding. Per farlo in maniera permanente dobbiamo modificare il file di configurazione /etc/sysctl.conf. Apriamolo con nano, identifichiamo questa riga:

#net.ipv4.ip_forward=1

e decommentiamola in questo modo

net.ipv4.ip_forward=1

Salviamo, usciamo da nano e abilitiamo la modifica appena effettuata:

sysctl -p /etc/sysctl.conf

Impostiamo iptables per fare in modo che il nostro gateway non sia esposto troppo esplicitamente lato VPN. Infatti, benché i nostri dati attraverso la VPN viaggino in maniera criptata, la macchina è esposta nel punto di uscita della VPN. Come prima cosa, per facilitare la gestione, installiamo il pacchetto iptables-persistent:

sudo apt-get install iptables-persistent

Scegliete di non salvare le regole di iptables attuali e completate l’installazione. Fermiamo iptable-persistent:

service iptables-persistent stop

Creiamo il file che conterrà le regole per iptables:

sudo nano /etc/iptables/rules.v4

Copiate all’interno del file appena aperto il seguente contenuto:

*nat
:PREROUTING ACCEPT [1:148]
:INPUT ACCEPT [1:148]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]

#### NAT Amule
#-A PREROUTING -i tun0 -p tcp -m tcp --dport 4662 -j DNAT --to ip.server.emule:4662
#-A PREROUTING -i tun0 -p udp -m udp --dport 4672 -j DNAT --to ip.server.emule:4672
#-A PREROUTING -i tun0 -p tcp -m tcp --dport 4665 -j DNAT --to ip.server.emule:4665
#-A PREROUTING -i tun0 -p udp -m udp --dport 4665 -j DNAT --to ip.server.emule:4665
#### NAT Transmission
#-A PREROUTING -i tun0 -p tcp -m tcp --dport 56413 -j DNAT --to ip.client.torrent:porta_transmission

-A POSTROUTING -o tun0 -j MASQUERADE

COMMIT

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# full loopback access su lo0 e blocca chi non usa lo0 verso 127/8
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable

# permetti traffico in entrata su tutte le connessioni stabilte
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# permetti traffico in entrata da eth0
-A INPUT -i eth0 -j ACCEPT

#### Amule
#-A INPUT -i tun0 -p udp --dport 4672 -j ACCEPT
#-A INPUT -i tun0 -p tcp --dport 4665 -j ACCEPT
#-A INPUT -i tun0 -p udp --dport 4665 -j ACCEPT
#-A INPUT -i tun0 -p tcp --dport 4662 -j ACCEPT
### Transmission
#-A INPUT -i tun0 -p tcp --dport porta_transmission -j ACCEPT

# blocca ping su tun0 (VPN)
-A INPUT -i tun0 -p icmp -m icmp --icmp-type 8 -j REJECT

-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log dropped packets
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

-A INPUT -j REJECT --reject-with icmp-port-unreachable

### Amule
#-A FORWARD -i tun0 -o eth0 -p tcp --dport 4662 -j ACCEPT
#-A FORWARD -i tun0 -o eth0 -p udp --dport 4672 -j ACCEPT
# Transmission
#-A FORWARD -i tun0 -o eth0 -p tcp --dport porta_transmission -j ACCEPT

-A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun0 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -j ACCEPT

COMMIT

Queste regole fanno in modo che il nosto gateway accetti tutto il traffico in uscita dalla LAN verso la VPN, ma consenta l’inverso solo per le connessioni già stabilite. E’ un approccio che impedisce l’utilizzo di molti servizi, quindi se vorrete utilizzare programmi quali ssh/transmission/amule/ecc dovrete per forza di cose adattare queste regole alla vostra configurazione (nelle regole ho mantenuto quelle che utilizzo per il mio serverino emule che garantiscono ID alto e KAD non firewalled, basta decommentarle e inserire gli IP e le porte corrette del vostro server emule).

Salvate il file e riavviate iptables-persistent per rendere effettive le modifiche;

sudo service iptables-persistent restart

Controlli finali

Ora il gateway VPN è praticamente completo e non rimane che testare il tutto.

Per sicurezza riavviamo la RPi, ricolleghiamoci tramite SSH e testiamo i vari servizi:

Openvpn:

sudo service openvpn status
[ ok ] VPN 'server' is running.

DNSMasq:

sudo service dnsmasq status
[ ok ] Checking DNS forwarder and DHCP server: dnsmasq[....] (running).

Assicuratevi che l’IP pubblico sia compatibile con quello del server VPN scelto:

dig +short myip.opendns.com @resolver1.opendns.com
185.7.xx.xxx

(per maggiori info su questo metodo: http://unix.stackexchange.com/a/81699)

Se avete optato per la scelta che openvn utilizzi un server random ad ogni suo riavvio, provate a riavviare il servizio e controllate nuovamente che il vostro indirizzo IP pubblico sia cambiato:

sudo service openvpn stop && sudo service openvpn start
dig +short myip.opendns.com @resolver1.opendns.com

Se tutto funziona come deve, non resta da fare altro che puntare l’opzione Gateway Internet dei vari dispositivi della vostra LAN all’IP che avete assegnato alla vostra RPi. Ricordatevi inoltre di inserire lo stesso IP per l’opzione Server DNS, così da poter far gestire a DNSMasq la risoluzione dei domini DNS.

Impostazione DNS e IP su Lubuntu
Impostazione DNS e IP su Lubuntu

Infine puntiamo il browser del PC che abbiamo appena collegato alla VPN a http://ipleak.net/. Controlliamo i dati che ci restituirà il sito (ricordatevi che la geo-localizzazione dipende dalle impostazioni del browser e non del vostro server VPN). Se tutto ci sembra ok, possiamo dire di aver finito la configurazione del gateway.

Buon divertimeno con la vostra VPN 🙂

Fonti consultate e altri link utili

Informazioni su Roberto 349 Articoli

Roberto “rbnet” Bolli, (ri)fondatore di rbnet.it con la passione per la tecnologia, Linux ed i meme Internet. La notte giocatore incallito di The Last of US su Playstation 4, di giorno “lavoricchiatore” in Francia, nazione dove cerca di sopravvivere non conoscendone la lingua.

16 Commenti

  1. Salve, mi chiedevo se con un po’ di pazienza e’ possibile adattare questa guida per l’utilizzo con il fornitore di vpn “purevpn” saluti.

    • Premesso che non utilizzo più lo script in questione è quindi non posso garantire che funzioni attualmente con le ultime versioni di raspbian/minibian, per aiutarti servirebbe di capire che tipo di errore hai.

      • semplicemente non funziona, ho creato la cartella con i file.conf ma non vengono selezionati in maniera random. Si collega sempre allo stesso e a volte non si collega proprio

        • Lucio, ho provato a riconfigurare la mia RPi con lo script in questione e tutto è andato liscio al primo tentativo:

          # service openvpn start && service openvpn stop
          [ ok ] Starting virtual private network daemon: Norway.Oslo_LOC1S1.TCP.
          [ ok ] Stopping virtual private network daemon: Norway.Oslo_LOC1S1.TCP.
          
          # service openvpn start && service openvpn stop
          [ ok ] Starting virtual private network daemon: Sweden.Stockholm.Nacka_LOC1S14.UDP.
          [ ok ] Stopping virtual private network daemon: Sweden.Stockholm.Nacka_LOC1S14.UDP.
          
          # service openvpn start && service openvpn stop
          [ ok ] Starting virtual private network daemon: Italy.Lombardy.Milan_LOC3S1.UDP.
          [ ok ] Stopping virtual private network daemon: Italy.Lombardy.Milan_LOC3S1.UDP.
          

          Accertati di effettuare le giuste modifiche nel file di init: assicurati che l’IFS sia impostato su NewLine e che nella riga modificata in AUTOSTART=`returnRandomVPN` ci siano i backtick e non le semplici virgolette (singole ” o doppie “”).

          • ok
            ma precisamente lo script in sudo nano /etc/init.d/openvpn
            dove va posizionato?in qualsiasi punto?

          • Assolutamente no. Lo script in questione è uno script di init. Anche nella guida ho riportato più volte di fare molta attenzione quando si modifica tale script: basta un carattere errato per mandare tutto all’aria. In ogni caso la guida inizia ad essere un po’ vecchiotta: sicuramente esistono altri metodi più corretti/facili per effettuare il medesimo lavoro. Io stesso non utilizzo più questo sistema per modificare in maniera random il server vpn al quale connettersi, ma mi affido ad un semplice programmino esterno che ho realizzato per android con il quale posso cambiare al volo il server VPN a cui la raspberry si connette (in effetti lo stesso risultato è possibile ottenerlo molto facilmente tramite un client SSH come JuiceSSH ed i sui script automatici).

          • Lo script è già presente in /etc/init.d/openvpn (è lo script di init di openvpn) tu lo devi modificare seguendo esattamente quanto riportato nella sezione “Metodo 2 – Scelta random automatica del server VPN all’avvio di OpenVPN”. Attenzione al copia incolla dal browser all’editor che utilizzi per modificare lo script: ci sono alcuni caratteri che potrebbero venire male interpretati dall’editor che utilizzi per modificare lo script, in particolare i caratteri backtick (“ <- che non sono virgolette singole!) Inoltre attenzione al carattere New Line della riga che inizia con IFS=... (è un semplice "a capo", senza spazi aggiuntivi).

1 Trackback / Pingback

  1. amuled, aMuleGUI, amulecmd e Raspberry Pi - rbnet.it

Lascia un commento

L'indirizzo email non sarà pubblicato.


*