Quest’articolo, per fruibilità, l’ho diviso nelle seguenti parti:
- Installazione dei pacchetti
- Creazione dei certificati
- Configurazione del server
- Configurazione di un client
- chroot
L’intera guida è orientata verso un S.O. Debian e Debian-like.
Ho impiegato tre giorni per scrivere questa guida, il motivo per cui l’ho scritta e che in internet si trovano tantissime guide sull’argomento, ma nessuna specifica che spiega per bene come integrare il servizio openvpn, configurato come bridge, con il demone dhcp.
Inoltre molte guide sono obsolete o con informazioni alle volte contraddittorie, per cui spero che possa essere utile a qualcuno. 🙂
Installiamo dei pacchetti necessari
sudo su apt-get install openvpn bridge-utils
Creare i certificati usando il tool easy-rsa
Eseguite una copia dei file del tool easy-rsa:
mkdir /etc/openvpn/easy-rsa/ cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa/
Settiamo il tool modificando il file vars:
nano /etc/openvpn/easy-rsa/vars
Modificare i campi:
export KEY_COUNTRY="" # il vostro STATO export KEY_PROVINCE="" # la vostra PROVINCIA export KEY_CITY="" # la vostra città export KEY_ORG="" # la vostra organizzazione export KEY_EMAIL="" # il vostro indirizzo di posta elettronica export KEY_SIZE=2048 # Diffie-Hellman export KEY_NAME="server" # X509 Subject Field
Certificati del Server
cd /etc/openvpn/easy-rsa/ source vars ./clean-all # Cancella tutti i certificati e le chiavi presenti nella cartella /etc/openvpn/easy-rsa/keys ./build-ca # Crea il certificato di ROOT della Certification Authority ./build-key-server server # Crea il certificato e la chiave privata del server
Cambiate “server” con il nome che ritenete più opportuno.
All’esecuzione dell’ultimo comando vi verrà chiesto di inserire una password.
1. Inserite una password sicura e accertatevi di non perderla.
2. Alla richiesta di firmare il certificato rispondete di si.
3. Alla richiesta di eseguire il commit rispondete si.
Creiamo i parametri DIFFIE-HELLMAN necessari per il server per la connessione SSL/TSL
./build-dh
Tutti i certificati e le chiavi sono stati generati nella sottocartella “/etc/openvpn/vars/keys”
Se volete attivare il protocollo TSL dovete generare la key corrispondente:
openvpn --genkey --secret keys/ta.key
Wiki: http://it.wikipedia.org/wiki/Transport_Layer_Security
Mettiamo i file creati nella cartella del programma:
cp server.crt server.key ca.crt dh2048.pem ta.key /etc/openvpn/
Certificati del Client
sudo su cd /etc/openvpn/vars source vars ./build-key nome_del_pc_client
I certificati e le chiavi del client vengono sempre creati nella cartella “/etc/openvpn/easy-rsa/keys”
Il file che il client ha bisogno per effettuare la connessione con il server sono:
ca.crt # Certificato di Root della CA nome_del_pc_client.crt # Certificato del client nome_del_pc_client.key # Chiave privata del client ta.key # TSL key
Copiate questi file all’interno della cartella /etc/openvpn/ del client.
Configurazione del server
tun (routing) o tap (bridging) ?
Il device TAP è una scheda di rete virtuale, mentre il dispositivo TUN è un collegamento IP virtuale da punto a punto (point-to-point).
Vantaggi e svantaggi: http://openvpn.net/index.php/open-source/faq/community-software-general/309-what-is-the-difference-between-bridging-and-routing.html
Se si utilizza bridging Ethernet (tap), è necessario utilizzare i parametri dev tap e server-bridge invece dei parametri dev tun e server.
Gli indirizzi utilizzati nella rete del server e nella rete locale del client non devono fare parte della stessa sottorete, altrimenti vi ritroverete con un loop nel routing dei pacchetti.
Es:
dev tap0 server-bridge
Altrimenti:
dev tun server
L’istruzione server-bridge senza parametri, implica che il rilascio degli indirizzi ip per i client venga fornito dal demone dhcpd (isc-dhcp-server o dnsmasq) e non da openvpn.
Un motivo valido per cui si vuole usare dhcpd del proprio server piuttosto che openvpn e la possibilità che il proprio server abbia un dns (bind) installato e che il demone dhcp annunci i nuovi pc che si collegano alla rete al dns.
Questo aspetto è poco documentato e le informazioni al riguardo sono contraddittorie:
ATTENZIONE: La direttiva “server” con “dev tap” non deve essere usata come è suggerito dalla faq del sito openvpn, usate “server-bridge”:
- senza parametri se volete che sia il vostro server dhcp a rilasciare gli indirizzi
- con parametri opportunamente settati se volete che la gestione degli indirizzi ip sia lasciata al server openvpn.
In questo caso c’è molta documentazione valida a riguardo.
Tuttavia è importante fare notare che il server dhcp non deve fornire ai client vpn il gateway di default della rete in cui è presente il server openvpn, pena la perdita di connessione da parte dei client remoti ad internet.
1. Creare un bridge su server
Configurazione di esempio della mia macchina (file: /etc/network/interfaces)
iface eth0 inet manual iface eth1 inet manual iface eth2 inet manual iface eth3 inet manual iface eth4 inet manual iface wlan0 inet manual auto br0 iface br0 inet static bridge_ports eth0 eth1 eth2 eth3 eth4 wlan0 tap0 address 172.16.0.10 netmask 255.255.0.0 network 172.16.0.0 broadcast 172.16.255.255 gateway 172.16.0.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 172.16.0.10 172.16.0.1 8.8.8.8 dns-search example.org
Le istruzioni:
iface br0 inet static bridge_ports eth0 eth1 eth2 eth3 eth4 wlan0 tap0
permettono la creazione di un bridge di rete di nome br0, con configurazione di rete statica, di cui fanno parte le periferiche fisiche:
eth0 eth1 eth2 eth3 eth4 wlan0
e la periferica virtuale
tap0
L’indirizzo di rete del bridge e le varie altre impostazioni vengono settate dalle istruzioni successive.
Una volta modificata la vostra configurazione di rete in relazione alle vostre esigenze potete riavviare il servizio di networking col comando:
sudo /etc/init.d/networking restart
2. Configurare il demone dhcpd, nel caso specifico “isc-dhcp-server”.
Questo è un cat parziale del mio file del mio file di configurazione /etc/dhcp/dhcpd.conf del mio server:
...
# Definizioni delle classi
class "local" {
match pick-first-value (option dhcp-client-identifier, hardware);
}
class "ospiti" {
match pick-first-value (option dhcp-client-identifier, hardware);
}
class "vpn" {
match if (substring(hardware, 1, 2) = 00:FF );
}
# MAC address delle macchine
subclass "ospiti" 1:00:01:AA:BB:CC:DD;
subclass "ospiti" 1:00:02:AA:BB:CC:DD;
subclass "local" 1:00:03:AA:BB:CC:DD;
subclass "local" 1:00:04:AA:BB:CC:DD;
# Definizione della subnet
subnet 172.16.0.0 netmask 255.255.0.0 {
allow duplicates;
default-lease-time 86400;
max-lease-time 86400; # 24h
option domain-name "example.org";
option subnet-mask 255.255.0.0;
option broadcast-address 172.16.255.255;
option domain-name-servers 172.16.0.10;
option ntp-servers 172.16.0.10;
# Local 172.16.0.50-89
pool {
allow members of "local";
range 172.16.0.50 172.16.0.89;
option routers 172.16.0.1; # gateway della rete locale
ddns-updates on;
}
# Ospiti 172.16.10.0/24
pool {
allow members of "ospiti";
range 172.16.10.1 172.16.10.254;
default-lease-time 43200;
max-lease-time 43200; # 12h
option routers 172.16.0.1; # gateway della rete locale
ddns-updates on;
}
# VPN 172.16.20.0/24
pool {
allow members of "vpn";
range 172.16.20.1 172.16.20.254;
ddns-updates on;
}
}
Questa è la definizione del mio pool di indirizzi nel mio server.
Per la sottoclasse VPN l’opzione “option routers 172.16.0.10;” è mancante ne è presente nella definizione generale del range:
subnet 172.16.0.0 netmask 255.255.0.0 {
...
Tanto basta per evitare che venga fornito ai client vpn un gateway che incasini l’instradamento di default dei client vpn verso internet.
Tuttavia è d’obbligo indicare l’opzione “option routers 172.16.0.10;” in tutti gli altri pool della subnet.
Per assicurarsi che tutti i client vpn finiscano nel pool corretto bisogna indicare come regola “allow members of “vpn”;” nel pool e creare una classe con questa regola qui:
class "vpn" {
match if (substring(hardware, 1, 2) = 00:FF );
}
La regola funziona perché ogni client che si collega tramite openvpn avrà sempre come MAC address iniziale i valori: 00:FF
Tutti gli altri pool definiti nella subnet hanno regole differenti che non coincidono con la regola della classe vpn.
E’ importante accertarsi che nessuno dei client vpn possa finire in un pool di indirizzi in cui è definita la regola “option routers”, sopratutto se in quest’ultima regola è definito il gateway della rete del server vpn.
E’ possibile instradare tutto il traffico del client vpn verso la rete del server, ma in quel caso bisogna specificare come indirizzo ip quello del server vpn. Es:
option routers 172.16.0.10
Gli altri valori del MAC Address dei client vpn varieranno casualmente ad ogni connessione a meno che non si specificano esplicitamente tramite l’istruzione:
lladdr 00:ff:00:00:00:0d
per le macchine linux e nelle proprietà del device tap0 per le macchine windows.
Nelle macchine windows l’istruzione “lladdr 00:ff:00:00:00:0d” non è riconosciuta.
3. Configurazione del servizio OpenVpn
Nella cartella di configurazione del demone openvpn non sono presenti i file di configurazione per cui bisogna metterceli a mano:
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/ gzip -d /etc/openvpn/server.conf.gz rm /etc/openvpn/server.conf.gz
Una configurazione di esempio del file del server.conf è la seguente:
# Quale indirizzo ip dovrebbe rimanere in ascolto OpenVPN? local 172.16.0.10 # Indirizzo ip del bridge br0 port 1194 # Porta proto udp # Protocollo dev tap0 server-bridge ca ca.crt # Certificato di Root della CA cert server.crt # Certificato del Server key server.key # Chiave privata del Server dh dh2048.pem # Diffie Hellman parameters tls-auth ta.key 0 # This file is secret (0 = server) comp-lzo # algoritmo di compressione per la connessione client-to-client keepalive 10 120 user nobody group nogroup persist-key persist-tun status openvpn-status.log daemon verb 3 chroot jail
Anche qui ho omesso i commenti presenti nel file di configurazione di esempio.
Configurazione di un client
Il client ha anche lui bisogno del suo file di configurazione per cui, se non ne avete uno già pronto potete copiare quello di default:
cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/
Esempio di configurazione per un client linux.
E’ stata omessa la documentazione presente nel file di configurazione di esempio.
script-security 2 client dev tap proto tcp remote vpn.example.org 1194 # Indirizzo del vostro server vpn lladdr 00:ff:00:00:00:0d # Indirizzo MAC del client resolv-retry infinite nobind user nobody group nogroup persist-key persist-tun ca ca.crt # Certificato radice della CA cert client.crt # certificato del client key client.key # chiave privata del client ns-cert-type server tls-auth ta.key 1 # File condiviso con il server (1 = client) comp-lzo verb 3
chroot
Per maggiorni informazioni in merito al chroot si può controllare questa pagina della wiki http://it.wikipedia.org/wiki/Chroot
mkdir /etc/openvpn/jail nano /etc/openvpn/server.conf
Alla fine del file aggiungere l’istruzione:
chroot jail
e salvare.
chroot jail e syslog
Il problema è semplice, alla rotazione giornaliera dei log del sistema il servizio rsyslog viene riavviato dalla macchina facendo perdere la connessione alla socket “/dev/log” da parte del servizio openvpn.
Infatti la socket AF_UNIX “/dev/log” viene terminata e ricreata al riavvio del servizio rsyslog.
Il servizio openvnp, essendo bloccato dentro la cartella “/etc/openvpn/jail” non può più accedere alla socket del demone rsyslog che si torva fuori dalla cartella “jail” (ovvero “/dev/log”).
Per ovviare al problema bisogna creare la cartella dev dentro jail:
mkdir /etc/openvpn/jail/dev
e modificare la configurazione del demone rsyslog creando un nuovo file dentro la cartella “/etc/rsyslog.d” e aggiungere lì la configurazione del nuovo socket per il demone openvpn. Ovvero:
nano /etc/rsyslog.d/openvpn.conf
E aggiungere la seguente istruzione:
$AddUnixListenSocket /etc/openvpn/jail/dev/log
e salvare e riavviare il servizio.
service rsyslog restart
La politica di ogni provider adsl che si rispetti è di lasciare fuori i propri clienti dall’amministrazione del router. Va da se che questo modo di fare cozza, completamente, con i miei ideali. Ovvero, io ho acquistato il modem, dunque, penso di avere il diritto di gestirlo come amministratore.
Segnalo l’evento speciale “Palermo a Venezia” dell’artista Alessandro Librio che avrà luogo il 4 Giugno, giornata di apertura della 54° edizione della Biennale di Venezia.