Questa dovrebbe essere la configurazione piu` sicura possibile per l'uso con tanti portatili che si connettono individualmente alla rete. Utilizzo certificati e chiavi per l'autenticazione e un pool di indirizzi dinamico. Questa configurazione, cosi` com'e` fatta, accetta fino a 64 client contemporaneamente in quanto usa 4 indirizzi ip (di una subnet privata da 256 indirizzi) per ogni pc linkato. Le chiavi identificano il client, il che significa che è necessario creare una chiave diversa per ogni client, e che se due client che usano la stessa chiave si connettono nello stesso momento, le loro connessioni continueranno a flappare (andare e venire) in quanto si "ammazzano" a vicenda l'una con l'altra. L'uso di una stessa chiave su piu` client è consentito, ma solo se sono connessi uno alla volta. Peraltro siccome la chiave identifica l'utente, non è una buona idea farlo.
Questa configurazione crea un tunnel con routing IP fra subnet diverse (una per la LAN, una dedicata ai clienti in VPN) e non un bridge ethernet.
Per generare i certificati per l'autenticazione uso Easy-RSA, ma potrei usare qualsiasi sistema che mi permetta di mettere in piedi una CA privata.
openvpn --genkey --secret tls-auth.key
(Suggerimento: stando in /etc/openvpn
quando si da` il comando, la chiave, con nome tls-auth.key
, viene generata gia` nel posto giusto). Questa chiave ha lo scopo di fornire una ulteriore protezione soprattutto contro attacchi di denial of service. Non è necessaria, e certi clienti OpenVPN (per esempio quelli integrati nei telefoni voip Grandstream) non la supportano. In questo caso, sarete costretti a non usarla nemmeno sul server.pki/private
e pki/issued
nel percorso della CA) sul server in /etc/openvpn
/etc/openvpn
con un nome tipo "server.conf", cosi` fatto:# configurazione per openvpn 2.5 # per gestire un server per molti client # interfaccia pubblica, porta e protocollo # Non è obbligatorio specificare l' ip della interfaccia. Se lo si omette # openvpn ascolta su tutte le interfacce. In quel caso omettete totalmente la riga # "local x.x.x.x" local 62.123.161.1 port 1194 proto udp # se voglio usare piu` interfacce pubbliche, devo: # togliere la definizione "local" # aggiungere la voce "multihome" # usare "nobind" sui client e piu` righe di "remote" sui client. # Management via telnet solo in locale management localhost 7505 # device usato dalla vpn (univoco per ogni istanza di openvpn) dev tun0 # io sono il server TLS (sempre vero per una conf a un server e molti client) tls-server # il file con dentro il numero primo per l'algoritmo Diffie Helman # (serve solo per il server tls). # il nome deve essere ovviamente uguale a quello del file che avete generato prima. dh dh.pem # il file con la chiave pubblica # della CA che ha firmato i certificati per tutti gli endpoint. ca ca.crt # il file con la chiave pubblica del mio endpoint (il server) cert server.crt # il file con la chiave privata del mio endpoint (il server) key server.key # certificate revocation list. Questo file viene generato dalla CA # quando si revoca un certificato, e va passato a openvpn perche` la revoca # abbia effetto. # essendo che fino a che non revocate il primo cert questo file non esiste, # ho commentato la riga. # crl-verify /etc/openvpn/crl.pem # il file con la shared key per l'autenticazione dei pacchetti # di handshake. A seconda se volete o meno usarlo, questa riga # può essere omessa. tls-auth tls-auth.key 0 # rete per l'interfaccia privata. il server si prende il .1 e # i clienti gli altri indirizzi di questa subnet. # Qui si usa una rete che non sia quella locale del server. server 192.168.99.0 255.255.255.0 # nuova logica di assegnazione degli ip e subnet ai client: # funziona SOLO con openvpn 2.5 in avanti topology subnet # tengo traccia degli indirizzi assegnati ai server e riassegno sempre # quelli usando questo file. (facoltativo) ifconfig-pool-persist server-pool-cache.txt # configurazioni di routing da insegnare ai client che si collegano. # in pratica questo comando dice al client che 192.168.0.0/24 (la mia LAN) va mandato alla vpn # posso ripetere piu` righe con piu` reti/host, e verranno tutti impostati nel routing del client # nel momento in cui questo si collega. push "route 192.168.0.0 255.255.255.0" # configurazioni varie da insegnare ai client. Anche in questo caso, insegno al client # che deve usare il mio DNS mentre è connesso alla VPN, che il dominio interno è "pippo.locale" # e che c'e` un server WINS. Ovviamente il WINS e` facoltativo, così come anche gli altri parametri, # però se vogliamo che il client risolva i nomi interni, sarà il caso di metterli. push "dhcp-option DNS 192.168.0.1" push "dhcp-option WINS 192.168.0.2" push "dhcp-option DOMAIN pippo.locale" # workaround per i provider stronzi che rispondono con un loro ip interno alle richieste dns # che dovrebbero dare nxdomain. Inoltre, evita anche il leak di richieste DNS. # si applica SOLO a client da windows da 7 in poi. Non dovrebbe rompere comunque i client diversi. push "block-outside-dns" # consento ai clients di vedersi fra di loro (se non volete, togliete la riga) client-to-client # keepalive e timeout: ping ogni 30 secondi e timeout di 120 secondi. keepalive 30 120 # downgrade dei privilegi dopo l'avvio del server: user nobody group nogroup # in caso di reload, tieni in memoria i dati che non potresti piu` rileggere a causa del privilegio insufficiente persist-key persist-tun # file che indica lo stato delle connessioni, ad uso di chi lo vuole leggere status server-status.log # log verboso per debug verb 3
/etc/init.d/openvpn start
sul server.La configurazione per i client windows e linux e` praticamente identica. Qui descrivo quella per windows, ma per Linux basta prendere i files di configurazione e metterli in /etc/openvpn (in linux il file di confiugurazione non ha estensione .ovpn ma .conf).
ufficio.ovpn
. Il contenuto sarà questo:client dev tun proto udp nobind float remote <hostname o ip pubblico del server> # file con le chiavi che abbiamo copiato prima dalla directory di easy-rsa: ca ca.crt cert client1.crt key client1.key # il certificato del server deve essere di tipo "server" # questo evita che chi possiede un certificato client possa spacciarsi per server remote-cert-tls server # il file con la shared key per l'autenticazione dei pacchetti # di handshake. Se sul server l'abbiamo usato, dobbiamo usarlo sul client, # altrimenti non dobbiamo. tls-auth tls-auth.key 1 #loglevel 3 verb 3
c:\Program Files\OpenVPN\config
oppure c:\Users\$USERNAME\OpenVPN\config
Volendo, è possibile creare un unico file di configurazione, che contiene anche i vari certificati, chiavi, e files "accessori". Questo file può essere usato da tutti i client a me noti ad oggi (windows, android, ios, linux) ed è più comodo da gestire rispetto al gruppo di files che abbiamo visto in precedenza.
Per farlo, in pratica si copia e incolla il contenuto dei vari files di certificato (ca.crt, client.crt, client.key, tls-auth.key) dentro al file di configurazione, all'interno dei vari blocchi <xxx> </xxx>. E` sufficiente seguire lo schema qui sotto. Notare il comando key-direction 1
che sostituisce il parametro 1
della voce tls-auth tls-auth.key 1
dell'esempio precedente.
Qui trovate uno script che genera queste configurazioni partendo dai files singoli: unifier.sh
Tutte le voci di configurazione che non fanno riferimento a dei files vanno lasciate esattamente come prima.
Nota bene: se la chiave e` crittata, anziche` la voce -----BEGIN RSA PRIVATE KEY-----
e relativo end, occorre usare la voce -----BEGIN ENCRYPTED PRIVATE KEY-----
e relativo end.
# qui vanno tutte le voci di config # che non fanno riferimento a dei files key-direction 1 <ca> -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- </ca> <cert> -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- </cert> <key> -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- </key> <tls-auth> -----BEGIN OpenVPN Static key V1----- ... -----END OpenVPN Static key V1----- </tls-auth>