12737
Comment:
|
26731
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
In Debian Sarge openvpn 2.0 e` gia` pacchettizzata, basta installare il pacchetto e creare le configurazioni. Se si crea un file {{{<nome>.conf}}} dentro a {{{/etc/openvpn}}} gli script standard di Debian lo lanciano al boot. |
|
Line 63: | Line 62: |
Line 75: | Line 75: |
replay-persist | replay-persist |
Line 79: | Line 79: |
In questo modo se uno dei due endpoint cambia indirizzo, dopo 300 secondi di disconnessione (causata dal cambio di indirizzo) openvpn riavvia l'handshake provvedendo anche a ri-risolvere dal dns l'ip del remoto (resolv-retry). | In questo modo se uno dei due endpoint cambia indirizzo, dopo 300 secondi di disconnessione (causata dal cambio di indirizzo) openvpn riavvia l'handshake provvedendo anche a ri-risolvere dal dns l'ip del remoto (resolv-retry). |
Line 83: | Line 84: |
=== Configurazione per connettere portatili con Windows a un concentratore Linux con chiavi asimmetriche === Questa dovrebbe essere la configurazione piu` sicura possibile per l'uso con tanti portatili che si connettono individualmente alla rete. Utilizzo chiavi asimmetriche per l'autenticazione e un pool di indirizzi dinamico. Questa configurazione, cosi` com'e` fatta, accetta fino a 64 client contemporaneamente. Uso tutti i mezzi di autenticazione possibili, ovvero chiavi diverse per ogni client e uno username/password. E` anche possibile richiedere l'inserimento di una password per usare le chiavi sui client. Questa configurazione crea un tunnel, non un bridge. |
=== Configurazione per connettere portatili con Windows (2000 o XP) a un concentratore Linux con chiavi asimmetriche === Questa dovrebbe essere la configurazione piu` sicura possibile per l'uso con tanti portatili che si connettono individualmente alla rete. Utilizzo chiavi asimmetriche per l'autenticazione e un pool di indirizzi dinamico. Questa configurazione, cosi` com'e` fatta, accetta fino a 64 client contemporaneamente. Uso tutti i mezzi di autenticazione possibili, ovvero chiavi diverse per ogni client e uno username/password. E` anche possibile richiedere l'inserimento di una password per usare le chiavi sui client. 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. Se si usa il metodo di autenticazione per username e password potrebbe essere sensato, per semplificare la vita a scapito di un pochino di sicurezza, usare una stessa chiave RSA per tutti i client e non proteggerla con password. Io comunque preferisco usare la soluzione senza username e password, fornendo una chiave RSA diversa ad ogni client, e proteggendo la stessa con una password. |
Line 91: | Line 94: |
* Se non e` gia` installato, occorre installare il pacchetto openssl che viene richiamato dagli script di easy-rsa. In Debian dovrebbe essere installato di default. * Se si vuole usare PAM per autenticare con username e password, occorre avere i seguenti pacchetti: libpam-pwdfile (per il file {{{/lib/security/pam_pwdfile.so}}}) e apache2-utils o qualsiasi altro pacchetto contenga il file {{{htpasswd}}} per generare le password. |
|
Line 92: | Line 97: |
* Se si usa Debian, copiarsi da qualche parte la directory {{{/usr/share/doc/openvpn/examples/easy-rsa}}}, anche sotto /etc/openvpn o su un'altra macchina, o nella propria home, o dove cavolo volete voi. Se usate i sorgenti, guardate dentro, troverete la stessa directory easy-rsa. | * Se si usa Debian, copiarsi da qualche parte la directory {{{/usr/share/doc/openvpn/examples/easy-rsa}}}, anche sotto /etc/openvpn o su un'altra macchina, o nella propria home, o dove cavolo volete voi. (Se siete molto paranoici la CA dovrebbe stare offline o su una macchina molto ben protetta) Se usate i sorgenti, guardate dentro, troverete la stessa directory easy-rsa. |
Line 112: | Line 117: |
* Creare una chiave statica per autenticare i pacchetti TLS, cosi`: {{{openvpn --genkey --secret tls-auth.key}}} * Copiare i files "ca.crt", "dh2048.pem", "tls-auth.key","<server>.crt" e "<server>.key" sul server in {{{/etc/openvpn}}} |
* Creare una chiave statica per autenticare i pacchetti TLS, cosi`: {{{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) * Copiare i files "ca.crt", "dh2048.pem", "<server>.crt" e "<server>.key" dalla directory delle chiavi della CA (dentro {{{keys}}} nel percorso della CA) sul server in {{{/etc/openvpn}}} * il file "tls-auth.key" dovrebbe essere gia` dentro a {{{/etc/openvpn}}} perche` e` stato generato da li` dentro. |
Line 121: | Line 127: |
local 62.123.161.1 | local 62.123.161.1 |
Line 154: | Line 160: |
# i clienti gli altri indirizzi di questa subnet. | # i clienti gli altri indirizzi di questa subnet. |
Line 164: | Line 170: |
# posso ripetere piu` righe con piu` reti/host, e verranno tutti impostati nel routing | |
Line 166: | Line 173: |
# configurazioni varie da insegnare ai client | # configurazioni varie da insegnare ai client Windows (non hanno effetto su linux, a quanto ne so) |
Line 169: | Line 176: |
push "dhcp-option DOMAIN pippo.it" | |
Line 196: | Line 204: |
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so openvpn | #### NOTA!!!!##### ## il file openvpn-auth-pam.so sembra che a seconda delle installazioni sia in due posti diversi. ## verificate qual'e` quello giusto per voi di questi due e scommentate la riga giusta: plugin /usr/lib/openvpn/openvpn-auth-pam.so # plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so openvpn |
Line 214: | Line 227: |
* Creare il file {{{/etc/openvpn/server-password}}} usando htpasswd, inserendo il nostro primo utente (come sopra, non serve se non si usa). | * Creare il file {{{/etc/openvpn/server-password}}} usando htpasswd, inserendo il nostro primo utente (come sopra, non serve se non si usa). NOTA: htpasswd, se non e` installato, puo` essere installato con il pacchetto Debian apache2-utils. |
Line 219: | Line 232: |
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. * Installare il client openvpn per windows * Creare il file di configurazione in (default) {{{c:\program files\openvpn\config}}}, con il nome che volete voi, purche` abbia estensione "ovpn". |
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) * Installare il client openvpn per windows. Si puo` usare quello solo testuale, oppure quello dotato di una minima interfaccia grafica (openvpn_gui) disponibile da http://www.openvpn.se (OBSOLETO). Le nuove versioni di openvpn grafico per windows si trovano oggi sul sito http://www.openvpn.net, nella sezione "Community software / downloads". Il link diretto, che non e` detto che funzioni sempre, e` questo: http://www.openvpn.net/index.php/open-source/downloads.html. L'installazione crea una directory che deve contenere le configurazioni, che di default ha nome {{{c:\programmi\openvpn\config}}} (per un windows italiano installato in C:) * Creare il file di configurazione nella directory {{{c:\programmi\openvpn\config}}} (o dove si trova nella vostra installazione di windows, a seconda della lingua oppure di dove avete installato openvpn), con il nome che volete voi, purche` abbia estensione "ovpn". Ad esempio, il file potrebbe essere {{{c:\programmi\openvpn\config\ufficio.ovpn}}} |
Line 227: | Line 240: |
nobind float |
|
Line 232: | Line 247: |
# il certificato del server deve essere di tipo "server" # questo evita che chi possiede un certificato client possa spacciarsi per server ns-cert-type server |
|
Line 240: | Line 258: |
* Copiare nella stessa directory i files delle chiavi menzionati nel file di configurazione | * Copiare nella stessa directory i files delle chiavi dalla CA (vedasi la parte server) e se necessario adattare i nomi degli stessi nel file di configurazione |
Line 243: | Line 261: |
* Usando openvpn_gui, nella tray in basso a destra si trova una icona che permette, mediante il tasto destro, di lanciare o disconnettere la VPN (o le vpn, se c'e` piu` di un file con estensione .ovpn nella directory delle configurazioni) * Ovviamente tutto questo ha vari problemi con quel cesso di Windows Vista, che io sicuramente non ho voglia di mettermi a risolvere. ---- === Configurazione LAN to LAN fra due Linux, usando le chiavi asimmetriche === Per la gestione delle chiavi, riferirsi alla sezione Linux-Windows, perche` e` identica. Per la configurazione dei due endpoint, queste sono due configurazioni di esempio. Uno dei due endpoint sara` sempre un "server" e l'altro un "client" per quanto riguarda l'autenticazione, ma non e` importante quale dei due lo sia. Configurazione "server". In questa configurazione non sono compresi i comandi per il keepalive che invece ha senso includere. Vedere prima per informazioni. {{{ # per usare un device tun dinamico, usa # "dev tun". qui ne uso uno statico. dev tun1 # Indirizzo IP pubblico del remoto remote xx.xx.xx.xx # Interfaccia locale a cui mi bindo (pubblica) local xx.xx.xx.xx # Definizione indirizzi IP privati del tunnel. # Questi saranno dati alle interfaccie "interne" (tunX) dei due endpoint. # ifconfig <locale> <remoto> ifconfig 10.0.0.254 172.16.0.253 # Definisco uno o piu` routing verso la lan remota (una o piu` righe) # Formato: route <netbase> <netmask> route 172.16.0.0 255.255.255.0 # questa parta e` il server TLS tls-server # il file con dentro il numero primo per l'algoritmo Diffie Helman # (serve solo per il server tls). dh dh2048.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 cert server.crt # il file con la chiave privata del mio endpoint key server.key # il file con la shared key per l'autenticazione dei pacchetti # di handshake # The tls-auth directive adds an additional HMAC signature to # all SSL/TLS handshake packets for integrity verification. # Any UDP packet not bearing the correct HMAC signature can # be dropped without further processing tls-auth tls-auth.key 0 # la porta che uso per i dati crittati verso/da il remoto. # se uso "port" intendo la stessa per tutti e due, # altrimenti uso "lport" e "rport" per locale e remoto. # ogni tunnel deve avere una porta diversa. port 9001 # dopo aver avviato il tunnel, posso usare questi uid e gid # per non restare root, oppure anche no. A scelta 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 # abilito la compressione (se voglio) comp-lzo # log level (da 0 per il minimo a 9 per il massimo) verb 3 }}} Configurazione lato client. Fondamentalmente uguale al server se si escludono sette piccoli particolari. Anche qui vale il discorso di includere le funzioni di keepalive. {{{ # per usare un device tun dinamico, usa # "dev tun". qui ne uso uno statico. dev tun1 # Indirizzo IP pubblico del remoto remote xx.xx.xx.xx # Interfaccia locale a cui mi bindo (pubblica) local xx.xx.xx.xx # Definizione indirizzi IP privati del tunnel. # Questi saranno dati alle interfaccie "interne" (tunX) dei due endpoint. # ifconfig <locale> <remoto> ifconfig 172.16.0.253 10.0.0.254 # Definisco uno o piu` routing verso la lan remota (una o piu` righe) # Formato: route <netbase> <netmask> route 10.0.0.0 255.255.255.0 # questa parta e` il client TLS tls-client # 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 cert client.crt # il file con la chiave privata del mio endpoint key client.key # il file con la shared key per l'autenticazione dei pacchetti # di handshake # The tls-auth directive adds an additional HMAC signature to # all SSL/TLS handshake packets for integrity verification. # Any UDP packet not bearing the correct HMAC signature can # be dropped without further processing tls-auth tls-auth.key 1 # la porta che uso per i dati crittati verso/da il remoto. # se uso "port" intendo la stessa per tutti e due, # altrimenti uso "lport" e "rport" per locale e remoto. # ogni tunnel deve avere una porta diversa. port 9001 # dopo aver avviato il tunnel, posso usare questi uid e gid # per non restare root, oppure anche no. A scelta 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 # abilito la compressione (se voglio) comp-lzo # log level (da 0 per il minimo a 9 per il massimo) verb 3 }}} ---- === Configurazione con un server e tanti client ognuno dei quali ha una LAN dietro === Questa e` una configurazione che ho fatto per un cliente, ma vale la pena di conservarla qui. In questa configurazione c'e` un server centrale al quale si connettono tanti client (tutti linux) ognuno dei quali client e` un firewall che ha sotto di se` una rete locale. Le macchina delle varie reti dei vari client vedono quella dietro al server, e viceversa. Volendo e` possibile far vedere anche le reti client l'una con l'altra. Questa configurazione usa tutta la subnet 10.64.0.0/16, dividendola cosi`: 10.64.0.0/24 viene usata per le interfacce "tun" di tutti i partecipanti (server e clients della vpn), e poi le reti 10.64.x.0/24 vengono usate per le LAN dietro ogni rispettivo client della VPN, assegnandole arbitrariamente con X che va da 1 a 255 alle varie reti. Il limite di questa configurazione dovrebbe essere di 248 client con le relative reti, limite dato da come openvpn usa gli indirizzi della 10.64.0.0/24 per i vari client (10.64.0.1 va al server, e dal 4 al 254 vanno ai client). Il sistema generale e` quello della rete per portatili con un concentratore descritto prima, con alcune modifiche. Specificamente, faccio uso di una CCD (client config directory) per assegnare a mia discrezione le varie subnet alle LAN dei client, basandomi sul common name per distinguerli l'uno dall'altro. Inoltre, uso la direttiva "ifconfig-pool-linear" (che dalla openvpn 2.10 cambia nome) sul server per assegnare un solo IP ad ogni client remoto anziche` una rete /30 dal pool 10.64.0.0/24. Questo mi permette di gestire 248 reti remote anziche` 32, pero` mi limita a non usare client (intesi come client della vpn, quindi i firewall remoti) con windows. Ovviamente i client veri e propri nelle varie LAN remote possono benissimo essere Windows. Usando openvpn 2.10 probabilmente potrei fare tutto questo anche con windows sui firewall, ma perche` mai provarci? Configurazione lato server centrale: {{{ # interfaccia pubblica, porta e protocollo local 62.94.137.138 port 9000 proto udp # device usato dalla vpn 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). dh dh2048.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-impianti-remoti.crt # il file con la chiave privata del mio endpoint (il server) key server-impianti-remoti.key # il file con la shared key per l'autenticazione dei pacchetti # di handshake # The tls-auth directive adds an additional HMAC signature to # all SSL/TLS handshake packets for integrity verification. # Any UDP packet not bearing the correct HMAC signature can # be dropped without further processing tls-auth tls-auth.key 0 # indirizzi ip delle interfacce tun dei firewll # (questo e` il classico setup da "road warrior" pero` con un solo ip per client) # notare che in openvpn 2.1 la direttiva ifconfig-pool-linear va cambiata in "topolgy p2p" server 10.64.0.0 255.255.255.0 ifconfig-pool-linear # route dal kernel (locale, del server) a openvpn: tutte le 10.64.x.x ci vanno dentro # quindi anziche` indicarle una per una, le indico tutte assieme con una /16 # i singoli firewall remoti avranno una loro configurazione "speciale" dentro alla # directory "ccd", nel file chiamato con il loro common name, che indica quale rete # routare a quale firewall remoto. route 10.64.0.0 255.255.0.0 # client config dir client-config-dir ccd # configurazioni di routing da insegnare ai client che si collegano. # non voglio che i client si vedano fra loro, quindi non includo # nulla a riguardo. # qui vanno indicate le reti LAN dietro al firewall "centrale" push "route 10.0.0.0 255.255.0.0" push "route 192.168.2.0 255.255.255.0" # keepalive e timeout: ping ogni 60 secondi e timeout di 240 secondi. keepalive 60 240 # Compressione sul link comp-lzo # downgrade dei privilegi utente dopo l'avvio: 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 impianti-remoti/server-status.log # verboso verb 3 (END) }}} Configurazione lato client (firewall remoto): {{{ client dev tun proto udp nobind float remote <firewall sede centrale> 9000 # 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 ns-cert-type server tls-auth tls-auth.key 1 # compressione comp-lzo #loglevel 3 verb 3 }}} Esempio del file che va dentro alla client config directory (ccd) per un client. questo file deve avere come nome il common name del client stesso (ad esempio, client1) {{{ # indico al server openvpn quale subnet remota (10.64.x.0/24) va a questo client: # In questo caso la 10.64.1.0/24. # Ovviamente sul firewall remoto dovro` usare questa subnet per la LAN. iroute 10.64.1.0 255.255.255.0 }}} ---- |
|
Line 246: | Line 538: |
* La configurazione della parte di autenticazione via PAM puo` essere agilmente saltata, in questo caso possedere la chiave privata di un client e` credenziale sufficiente ad autenticarsi. In questo caso forse e` meglio proteggere con password il certificato. | * La configurazione della parte di autenticazione via PAM puo` essere agilmente saltata, in questo caso possedere la chiave privata di un client e` credenziale sufficiente ad autenticarsi. In questo caso e` meglio proteggere con password la chiave privata di ogni client. |
Line 248: | Line 540: |
* I nomi dei files delle chiavi secondo me e` comodo che siano uguali (o molto simili) ai "Common Name" che si impostano all'interno delle chiavi stesse al momento della generazione. Questo facilita la gestione perche` mette ordine e rende evidente che un client che ha common name "Mario Rossi" appartiene (si spera) a Mario Rossi e ha come chiavi dei files che avranno nome tipo "mario_rossi.key", "mario_rossi.crt", eccetera. * E` ovvio che nei files di configurazione di openvpn andranno indicati i nomi corretti delle chiavi che usate. Nei files di esempio ci sono nomi tipo "ca.crt" o "server.key" che vanno adattati ai nomi che avete scelto. * il file {{{openvpn-auth-pam.so}}} potrebbe non essere installato dove me lo aspetto. Verificare dove si trova e correggere la configurazione del server in modo congruente se si usa PAM. |
Configurazione di un link fra due reti con chiave preshared
Questa e` la configurazione piu` semplice del mondo, non la piu` sicura. Tuttavia per macchine con poca CPU puo` essere una soluzione valida. Questa configurazione crea un tunnel, non un bridge.
Su una delle due macchine, creare la pre-shared key con openvpn --genkey --secret <nome del file della chiave>
- Creare un file di configurazione minimale come questo:
# device per il tunnel dev tun0 # indirizzi ip pubblici locale e remoto remote 62.123.191.1 local 82.88.19.1 # porta udp esterna (se non uso il default) port 4242 # indirizzi ip privati locale e remoto (uso quelli delle eth locali, ma # potrei anche usarne altri due a caso non usati nelle reti) ifconfig 192.168.1.254 192.168.2.1 # routing (indico che la rete remota va routata per la vpn) # qui metto indirizzo e netmask della rete REMOTA. route 192.168.2.0 255.255.255.0 # pre shared key secret <nome del file della chiave> # dropppo i privilegi user nobody group nogroup # Compressione comp-lzo # log level 3 verb 3
- Copiare tutto sulla macchina remota, ed editare il file sulla macchina remota per ribaltare local con remote, modificare il routing per indicare la rete remota.
Lanciare openvpn su tutte due le macchine con /etc/init.d/openvpn start
Keepalive per link rognosi
Se ci sono dei nat in mezzo, e il link non resta su quando non c'e` traffico, si possono aggiungere nei file di configurazione di tutti e due gli endpoint un paio di righe per il keepalive.
# Ogni 60 secondi manda un keepalive, e se non hai risposta in 120 secondi, resetta il link keepalive 60 120 # Quanto sopra vale SOLO quando sei in connessione stabilita ping-timer-rem # tieni "buono" il tunnel anche se ci sono interruzioni sull' UDP persist-tun # se devi resettare il tunnel, non rileggere la chiave ma usa quella che hai in ram persist-key
Link fra due ip dinamici con dns dinamico
Per una vpn fra due endpoint (non in stile client/server) con ip e dns dinamico, si puo` cercare di ovviare ai problemi di cambio di indirizzo ip di uno dei due endpoint (anche di tutti e due, nel caso) cosi`:
ping 60 ping-restart 300 # 5 minutes resolv-retry 300 # 5 minutes persist-tun persist-key replay-persist replay-persist-file
In questo modo se uno dei due endpoint cambia indirizzo, dopo 300 secondi di disconnessione (causata dal cambio di indirizzo) openvpn riavvia l'handshake provvedendo anche a ri-risolvere dal dns l'ip del remoto (resolv-retry).
Configurazione per connettere portatili con Windows (2000 o XP) a un concentratore Linux con chiavi asimmetriche
Questa dovrebbe essere la configurazione piu` sicura possibile per l'uso con tanti portatili che si connettono individualmente alla rete. Utilizzo chiavi asimmetriche per l'autenticazione e un pool di indirizzi dinamico. Questa configurazione, cosi` com'e` fatta, accetta fino a 64 client contemporaneamente. Uso tutti i mezzi di autenticazione possibili, ovvero chiavi diverse per ogni client e uno username/password. E` anche possibile richiedere l'inserimento di una password per usare le chiavi sui client. 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.
Se si usa il metodo di autenticazione per username e password potrebbe essere sensato, per semplificare la vita a scapito di un pochino di sicurezza, usare una stessa chiave RSA per tutti i client e non proteggerla con password. Io comunque preferisco usare la soluzione senza username e password, fornendo una chiave RSA diversa ad ogni client, e proteggendo la stessa con una password.
Impostazione server Linux
- Prima di tutto, installare il pacchetto openvpn 2.0 (o compilarsi la 2.0 dai sorgenti)
- Se non e` gia` installato, occorre installare il pacchetto openssl che viene richiamato dagli script di easy-rsa. In Debian dovrebbe essere installato di default.
Se si vuole usare PAM per autenticare con username e password, occorre avere i seguenti pacchetti: libpam-pwdfile (per il file /lib/security/pam_pwdfile.so) e apache2-utils o qualsiasi altro pacchetto contenga il file htpasswd per generare le password.
- Occorre crearsi una propria CA interna per generare le chiavi asimmetriche per i vari link. Per fare questo, seguire questa procedura.
Se si usa Debian, copiarsi da qualche parte la directory /usr/share/doc/openvpn/examples/easy-rsa, anche sotto /etc/openvpn o su un'altra macchina, o nella propria home, o dove cavolo volete voi. (Se siete molto paranoici la CA dovrebbe stare offline o su una macchina molto ben protetta) Se usate i sorgenti, guardate dentro, troverete la stessa directory easy-rsa.
Editare il file vars che si trova sotto easy-rsa e configurare in modo credibile i seguenti parametri: KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG e KEY_EMAIL. Nessuno di questi deve essere vuoto. Vale anche la pena di impostare KEY_SIZE a 2048, perche` siamo paranoici.
Se il file openssl.cnf e` gzippato (openssl.cnf.gz) occorre gunzipparlo.
Editare il file openssl.cnf e mettere il parametro "default_days" a un valore accettabile. Un anno e` troppo poco, io ho messo 10 anni. (3650 giorni)
- Creare i certificati della root CA privata, con i seguenti comandi:
. ./vars ./clean-all ./build-ca
Attenzione a come viene invocato "vars" nella prima riga, "punto spazio punto barra"... e` un po` molesto. Alle domande che verranno poste da "build-ca", e` necessario inserire dei valori dove manca il default, e NON MODIFICARE nulla dove il default e` presente. Ora la CA e` configurata. La chiave privata della CA dovrebbe essere supersegreta, da tenere in un floppy in una cassaforte in cantina con davanti un cartello "attenti al leopardo".
- Creare una coppia di chiavi per il server, come segue:
eseguire il comando ./build-key-server <nome file della chiave> (usare un nome tipo "server" puo` andare bene)
- Alle domande con un default, NON modificarlo. Dove non c'e` default, rispondere a senso.
- Alla fine, rispondere di si` alle domande "Sign the certificate?" e "1 out of 1 certificate requests certified, commit?".
- Creare una coppia di chiavi per il primo client. Ovviamente se ne possono creare quante se ne vogliono, ripetendo questa procedura in futuro.
eseguire il comando ./build-key <nome file della chiave> (usare un nome tipo "client1" puo` andare bene). Se si vuole che l'utente del client debba inserire una password per usare la chiave, usare build-key-pass al posto di build-key.
- Come per il server, rispondere alle domande che non hanno default con delle risposte sensate. Attenzione che il "Common Name" deve essere DIVERSO per ogni chiave generata.
- Alla fine, rispondere di si` alle domande "Sign the certificate?" e "1 out of 1 certificate requests certified, commit?".
Generare, per il server, il file contenente i parametri DH, con il comando ./build-dh. (roba da matematti). E` lentissimo, bersi una coca in attesa.
Creare una chiave statica per autenticare i pacchetti TLS, cosi`: 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)
Copiare i files "ca.crt", "dh2048.pem", "<server>.crt" e "<server>.key" dalla directory delle chiavi della CA (dentro keys nel percorso della CA) sul server in /etc/openvpn
il file "tls-auth.key" dovrebbe essere gia` dentro a /etc/openvpn perche` e` stato generato da li` dentro.
Copiare i files "ca.crt", "tls-auth.key", "<client1>.crt" e "client1.key" sul client (su windows, vedremo dopo dove esattamente vanno messi)
Creare un file di configurazione in /etc/openvpn con un nome tipo "server.conf", cosi` fatto:
# configurazione per openvpn 2.0 # per gestire un server per molti client # interfaccia pubblica, porta e protocollo local 62.123.161.1 port 1194 proto udp # device usato dalla vpn 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). dh dh2048.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 # il file con la shared key per l'autenticazione dei pacchetti # di handshake # The tls-auth directive adds an additional HMAC signature to # all SSL/TLS handshake packets for integrity verification. # Any UDP packet not bearing the correct HMAC signature can # be dropped without further processing 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 # 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 qui devo dire 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 push "route 192.168.0.0 255.255.255.0" # configurazioni varie da insegnare ai client Windows (non hanno effetto su linux, a quanto ne so) push "dhcp-option DNS 192.168.0.1" push "dhcp-option WINS 192.168.0.2" push "dhcp-option DOMAIN pippo.it" # consento ai clients di vedersi fra di loro # client-to-client # uso il nome utente come "nome" del client. Togliere se non si usa l'autenticazione username/password con PAM username-as-common-name # keepalive e timeout: ping ogni 30 secondi e timeout di 120 secondi. keepalive 30 120 # Compressione sul link comp-lzo # downgrade dei privilegi utente dopo l'avvio: 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 # autenticazione deli utenti tramite PAM. Non solo gli utenti devono avere una # chiave valida per la vpn, ma devono anche essere in server-passwords e devono # inserire la password quando si collegano. Vedere /etc/pam.d/openvpn. #### NOTA!!!!##### ## il file openvpn-auth-pam.so sembra che a seconda delle installazioni sia in due posti diversi. ## verificate qual'e` quello giusto per voi di questi due e scommentate la riga giusta: plugin /usr/lib/openvpn/openvpn-auth-pam.so # plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so openvpn # verboso verb 3
Creare il file /etc/pam.d/openvpn cosi` fatto (non necessario se non si usa l'autenticazione user/password):
# configurazione per openvpn 2.0, per autenticare gli utenti su un file di testo # e non su /etc/passwd # il file delle password deve essere generato con htpasswd. # ho dovuto inserire la riga "account" per evitare che gli utenti debbano esistere anche in # passwd. auth required /lib/security/pam_pwdfile.so pwdfile /etc/openvpn/server-passwords account sufficient /lib/security/pam_permit.so
Creare il file /etc/openvpn/server-password usando htpasswd, inserendo il nostro primo utente (come sopra, non serve se non si usa). NOTA: htpasswd, se non e` installato, puo` essere installato con il pacchetto Debian apache2-utils.
Lanciare /etc/init.d/openvpn start sul server.
Configurazione per i client Windows
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)
Installare il client openvpn per windows. Si puo` usare quello solo testuale, oppure quello dotato di una minima interfaccia grafica (openvpn_gui) disponibile da http://www.openvpn.se (OBSOLETO). Le nuove versioni di openvpn grafico per windows si trovano oggi sul sito http://www.openvpn.net, nella sezione "Community software / downloads". Il link diretto, che non e` detto che funzioni sempre, e` questo: http://www.openvpn.net/index.php/open-source/downloads.html. L'installazione crea una directory che deve contenere le configurazioni, che di default ha nome c:\programmi\openvpn\config (per un windows italiano installato in C:)
Creare il file di configurazione nella directory c:\programmi\openvpn\config (o dove si trova nella vostra installazione di windows, a seconda della lingua oppure di dove avete installato openvpn), con il nome che volete voi, purche` abbia estensione "ovpn". Ad esempio, il file potrebbe essere c:\programmi\openvpn\config\ufficio.ovpn
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 ns-cert-type server tls-auth tls-auth.key 1 # autenticazione con user e password da PAM (togliere se non si usa) auth-user-pass # compressione comp-lzo #loglevel 3 verb 3
- Copiare nella stessa directory i files delle chiavi dalla CA (vedasi la parte server) e se necessario adattare i nomi degli stessi nel file di configurazione
- Cliccare col tasto destro sul file di configurazione (estensione .ovpn) e scegliere dal menu` la voce "Start openvpn with this config"
- nella finestra DOS che compare, inserire username e password (se richiesto)
- Usando openvpn_gui, nella tray in basso a destra si trova una icona che permette, mediante il tasto destro, di lanciare o disconnettere la VPN (o le vpn, se c'e` piu` di un file con estensione .ovpn nella directory delle configurazioni)
- Ovviamente tutto questo ha vari problemi con quel cesso di Windows Vista, che io sicuramente non ho voglia di mettermi a risolvere.
Configurazione LAN to LAN fra due Linux, usando le chiavi asimmetriche
Per la gestione delle chiavi, riferirsi alla sezione Linux-Windows, perche` e` identica.
Per la configurazione dei due endpoint, queste sono due configurazioni di esempio. Uno dei due endpoint sara` sempre un "server" e l'altro un "client" per quanto riguarda l'autenticazione, ma non e` importante quale dei due lo sia.
Configurazione "server". In questa configurazione non sono compresi i comandi per il keepalive che invece ha senso includere. Vedere prima per informazioni.
# per usare un device tun dinamico, usa # "dev tun". qui ne uso uno statico. dev tun1 # Indirizzo IP pubblico del remoto remote xx.xx.xx.xx # Interfaccia locale a cui mi bindo (pubblica) local xx.xx.xx.xx # Definizione indirizzi IP privati del tunnel. # Questi saranno dati alle interfaccie "interne" (tunX) dei due endpoint. # ifconfig <locale> <remoto> ifconfig 10.0.0.254 172.16.0.253 # Definisco uno o piu` routing verso la lan remota (una o piu` righe) # Formato: route <netbase> <netmask> route 172.16.0.0 255.255.255.0 # questa parta e` il server TLS tls-server # il file con dentro il numero primo per l'algoritmo Diffie Helman # (serve solo per il server tls). dh dh2048.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 cert server.crt # il file con la chiave privata del mio endpoint key server.key # il file con la shared key per l'autenticazione dei pacchetti # di handshake # The tls-auth directive adds an additional HMAC signature to # all SSL/TLS handshake packets for integrity verification. # Any UDP packet not bearing the correct HMAC signature can # be dropped without further processing tls-auth tls-auth.key 0 # la porta che uso per i dati crittati verso/da il remoto. # se uso "port" intendo la stessa per tutti e due, # altrimenti uso "lport" e "rport" per locale e remoto. # ogni tunnel deve avere una porta diversa. port 9001 # dopo aver avviato il tunnel, posso usare questi uid e gid # per non restare root, oppure anche no. A scelta 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 # abilito la compressione (se voglio) comp-lzo # log level (da 0 per il minimo a 9 per il massimo) verb 3
Configurazione lato client. Fondamentalmente uguale al server se si escludono sette piccoli particolari. Anche qui vale il discorso di includere le funzioni di keepalive.
# per usare un device tun dinamico, usa # "dev tun". qui ne uso uno statico. dev tun1 # Indirizzo IP pubblico del remoto remote xx.xx.xx.xx # Interfaccia locale a cui mi bindo (pubblica) local xx.xx.xx.xx # Definizione indirizzi IP privati del tunnel. # Questi saranno dati alle interfaccie "interne" (tunX) dei due endpoint. # ifconfig <locale> <remoto> ifconfig 172.16.0.253 10.0.0.254 # Definisco uno o piu` routing verso la lan remota (una o piu` righe) # Formato: route <netbase> <netmask> route 10.0.0.0 255.255.255.0 # questa parta e` il client TLS tls-client # 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 cert client.crt # il file con la chiave privata del mio endpoint key client.key # il file con la shared key per l'autenticazione dei pacchetti # di handshake # The tls-auth directive adds an additional HMAC signature to # all SSL/TLS handshake packets for integrity verification. # Any UDP packet not bearing the correct HMAC signature can # be dropped without further processing tls-auth tls-auth.key 1 # la porta che uso per i dati crittati verso/da il remoto. # se uso "port" intendo la stessa per tutti e due, # altrimenti uso "lport" e "rport" per locale e remoto. # ogni tunnel deve avere una porta diversa. port 9001 # dopo aver avviato il tunnel, posso usare questi uid e gid # per non restare root, oppure anche no. A scelta 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 # abilito la compressione (se voglio) comp-lzo # log level (da 0 per il minimo a 9 per il massimo) verb 3
Configurazione con un server e tanti client ognuno dei quali ha una LAN dietro
Questa e` una configurazione che ho fatto per un cliente, ma vale la pena di conservarla qui. In questa configurazione c'e` un server centrale al quale si connettono tanti client (tutti linux) ognuno dei quali client e` un firewall che ha sotto di se` una rete locale. Le macchina delle varie reti dei vari client vedono quella dietro al server, e viceversa. Volendo e` possibile far vedere anche le reti client l'una con l'altra.
Questa configurazione usa tutta la subnet 10.64.0.0/16, dividendola cosi`: 10.64.0.0/24 viene usata per le interfacce "tun" di tutti i partecipanti (server e clients della vpn), e poi le reti 10.64.x.0/24 vengono usate per le LAN dietro ogni rispettivo client della VPN, assegnandole arbitrariamente con X che va da 1 a 255 alle varie reti.
Il limite di questa configurazione dovrebbe essere di 248 client con le relative reti, limite dato da come openvpn usa gli indirizzi della 10.64.0.0/24 per i vari client (10.64.0.1 va al server, e dal 4 al 254 vanno ai client).
Il sistema generale e` quello della rete per portatili con un concentratore descritto prima, con alcune modifiche. Specificamente, faccio uso di una CCD (client config directory) per assegnare a mia discrezione le varie subnet alle LAN dei client, basandomi sul common name per distinguerli l'uno dall'altro. Inoltre, uso la direttiva "ifconfig-pool-linear" (che dalla openvpn 2.10 cambia nome) sul server per assegnare un solo IP ad ogni client remoto anziche` una rete /30 dal pool 10.64.0.0/24. Questo mi permette di gestire 248 reti remote anziche` 32, pero` mi limita a non usare client (intesi come client della vpn, quindi i firewall remoti) con windows. Ovviamente i client veri e propri nelle varie LAN remote possono benissimo essere Windows. Usando openvpn 2.10 probabilmente potrei fare tutto questo anche con windows sui firewall, ma perche` mai provarci?
Configurazione lato server centrale:
# interfaccia pubblica, porta e protocollo local 62.94.137.138 port 9000 proto udp # device usato dalla vpn 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). dh dh2048.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-impianti-remoti.crt # il file con la chiave privata del mio endpoint (il server) key server-impianti-remoti.key # il file con la shared key per l'autenticazione dei pacchetti # di handshake # The tls-auth directive adds an additional HMAC signature to # all SSL/TLS handshake packets for integrity verification. # Any UDP packet not bearing the correct HMAC signature can # be dropped without further processing tls-auth tls-auth.key 0 # indirizzi ip delle interfacce tun dei firewll # (questo e` il classico setup da "road warrior" pero` con un solo ip per client) # notare che in openvpn 2.1 la direttiva ifconfig-pool-linear va cambiata in "topolgy p2p" server 10.64.0.0 255.255.255.0 ifconfig-pool-linear # route dal kernel (locale, del server) a openvpn: tutte le 10.64.x.x ci vanno dentro # quindi anziche` indicarle una per una, le indico tutte assieme con una /16 # i singoli firewall remoti avranno una loro configurazione "speciale" dentro alla # directory "ccd", nel file chiamato con il loro common name, che indica quale rete # routare a quale firewall remoto. route 10.64.0.0 255.255.0.0 # client config dir client-config-dir ccd # configurazioni di routing da insegnare ai client che si collegano. # non voglio che i client si vedano fra loro, quindi non includo # nulla a riguardo. # qui vanno indicate le reti LAN dietro al firewall "centrale" push "route 10.0.0.0 255.255.0.0" push "route 192.168.2.0 255.255.255.0" # keepalive e timeout: ping ogni 60 secondi e timeout di 240 secondi. keepalive 60 240 # Compressione sul link comp-lzo # downgrade dei privilegi utente dopo l'avvio: 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 impianti-remoti/server-status.log # verboso verb 3 (END)
Configurazione lato client (firewall remoto):
client dev tun proto udp nobind float remote <firewall sede centrale> 9000 # 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 ns-cert-type server tls-auth tls-auth.key 1 # compressione comp-lzo #loglevel 3 verb 3
Esempio del file che va dentro alla client config directory (ccd) per un client. questo file deve avere come nome il common name del client stesso (ad esempio, client1)
# indico al server openvpn quale subnet remota (10.64.x.0/24) va a questo client: # In questo caso la 10.64.1.0/24. # Ovviamente sul firewall remoto dovro` usare questa subnet per la LAN. iroute 10.64.1.0 255.255.255.0
Note
- La configurazione della parte di autenticazione via PAM puo` essere agilmente saltata, in questo caso possedere la chiave privata di un client e` credenziale sufficiente ad autenticarsi. In questo caso e` meglio proteggere con password la chiave privata di ogni client.
- Usando la direttiva "duplicate-cn" nella config del server si puo` usare lo stesso certificato per tutti i client. In questo caso e` BENE usare l'autenticazione username/password perche` altrimenti non si possono nemmeno distinguere gli utenti collegati l'uno dall'altro, visto che hanno tutti lo stesso certificato.
- I nomi dei files delle chiavi secondo me e` comodo che siano uguali (o molto simili) ai "Common Name" che si impostano all'interno delle chiavi stesse al momento della generazione. Questo facilita la gestione perche` mette ordine e rende evidente che un client che ha common name "Mario Rossi" appartiene (si spera) a Mario Rossi e ha come chiavi dei files che avranno nome tipo "mario_rossi.key", "mario_rossi.crt", eccetera.
- E` ovvio che nei files di configurazione di openvpn andranno indicati i nomi corretti delle chiavi che usate. Nei files di esempio ci sono nomi tipo "ca.crt" o "server.key" che vanno adattati ai nomi che avete scelto.
il file openvpn-auth-pam.so potrebbe non essere installato dove me lo aspetto. Verificare dove si trova e correggere la configurazione del server in modo congruente se si usa PAM.
- Se si vuole usare Samba attraverso la VPN, occorre collegare i dischi del server remoto usando l' IP e non il nome netbios, altrimenti questi si disconnettono quando lasciati idle per piu` di 6 minuti. Non so perche` ma lo fa ed e` odioso.
- E` possibile usare configurazioni diverse per ogni client, piu` una generica per i client che non ricadono nella lista di quelli "diversi", dando diverse subnet e poi firewallandole in modo diverso per avere diversi "livelli di accesso" alla LAN a seconda di che client si collega. Qui questa configurazione non e` prevista.