Differences between revisions 37 and 38
Revision 37 as of 2019-06-21 09:08:33
Size: 37463
Editor: Kurgan
Comment:
Revision 38 as of 2019-06-21 20:20:49
Size: 34533
Editor: Kurgan
Comment: Rimodernate diverse sezioni.
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
{{{  {{{
Line 58: Line 58:
{{{  {{{
Line 73: Line 73:
{{{  {{{
Line 91: Line 91:
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 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 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.
Line 101: Line 101:
 * 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.
 * 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)
 * Occorre crearsi una propria CA interna per generare i certificati che useremo per identificare il server e i client. Per fare questo usiamo Easy RSA [[../EasyRSA]]
 * Attenzione: la CA va conservata in una macchina sicura. Se qualcuno si impossessa delle chiavi della CA puo` generare certificati validi!
 * Seguendo quanto indicato qui [[../EasyRSA]] dovrete di fatto fare 4 passi:
  * Creare la CA stessa
  * Creare una chiave per il vostro server che sia di tipo server
  * Creare una chiave per il vostro primo client (che non sia di tipo server)
  * Creare il file contenente i parametri DH, per il server. (procedura molto lenta)
 * Eventualmente (non è obbligatorio) possiamo 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). 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.
 * Copiare i files "ca.crt", "dh.pem" (o altro nome del file dh, a seconda di come l'avete chiamato), "server.crt" e "server.key" dalla directory delle chiavi della CA (dentro {{{pki/private}}} e {{{pki/issued}}} nel percorso della CA) sul server in {{{/etc/openvpn}}}
 * Copiare i files "ca.crt", "tls-auth.key" (se lo volete usare), "client1.crt" e "client1.key" sul client (la posizione di questi files dipende dal client, in ogni caso tenete conto che servono questi files sul client)
Line 128: Line 112:
{{{  {{{
Line 132: Line 116:
# interfaccia pubblica, porta e protocollo # 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"
Line 143: Line 130:
# device usato dalla vpn # device usato dalla vpn (univoco per ogni istanza di openvpn)
Line 146: Line 133:
# algoritmi crittografici piu` sicuri # algoritmi crittografici piu` sicuri del vecchio default
Line 150: Line 137:
Line 156: Line 142:
dh dh2048.pem # il nome deve essere ovviamente uguale a quello del file che avete generato prima.
dh dh.pem
Line 171: Line 158:
# essendo che fino a che non revocate il primo cert questo file non esiste,
# ho commentato la riga.
Line 173: Line 162:
Line 175: Line 163:
# 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
# di handshake. A seconda se volete o meno usarlo, questa riga
# può essere omessa.
Line 192: Line 177:
# 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
# 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.
Line 196: Line 182:
# configurazioni varie da insegnare ai client Windows (non hanno effetto su linux, a quanto ne so) # 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.
Line 199: Line 188:
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
push "dhcp-option DOMAIN pippo.locale"

# consento ai clients di vedersi fra di loro (se non volete, togliete la riga)
client-to-client
Line 210: Line 196:
# downgrade dei privilegi utente dopo l'avvio: # downgrade dei privilegi dopo l'avvio del server:
Line 221: Line 207:
# 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
# log verboso per debug
Line 234: Line 210:
 * 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.
Line 250: Line 213:
Line 252: Line 216:
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}}}
{{{
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, scaricandolo da http://www.openvpn.net, nella sezione "Community software / downloads". Il link diretto, che non e` detto che funzioni sempre, e` questo: https://openvpn.net/community-downloads/
 * Raccogliere tutti i files necessari per il client, che sono "ca.crt", "tls-auth.key" (se lo volete usare), "client1.crt" e "client1.key"
 * Creare il file di configurazione con il nome che volete voi, purche` abbia estensione "ovpn". Ad esempio, il file potrebbe essere {{{ufficio.ovpn}}}. Il contenuto sarà questo:
 {{{
Line 263: Line 228:
Line 266: Line 232:
Line 270: Line 237:
Line 273: Line 241:

# 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.
Line 274: Line 246:
# autenticazione con user e password da PAM (togliere se non si usa)
auth-user-pass
Line 279: Line 250:
 * 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 con i certificati embedded ===

Volendo creare una configurazione unica con dentro i certificati, e` possibile usare questo formato: 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.
 * Tutti i files che abbiamo messo assieme vanno quindi messi nella directory delle configurazioni del client VPN, che è (alla versione attuale del client) {{{c:\Program Files\OpenVPN\config}}} oppure {{{c:\Users\$USERNAME\OpenVPN\config}}}


----

=== Configurazione "monolitica" con i certificati entrocontenuti ===

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.

''' In fondo alla pagina c'è uno script per convertire configurazioni standard in monolitiche (lo script gira su linux, ma ovviamente genera config per qualsiasi client) '''


Tutte le voci di configurazione che non fanno riferimento a dei files vanno lasciate esattamente come prima.
Line 295: Line 269:

# qui vanno tutte le voci di config
# che non fanno riferimento a dei files
Line 318: Line 296:
----
=== Autenticazione con username e password ===

Openvpn prevede una autenticazione mista (certificati + username e password). La ritengo mediamente inutile, in quanto un certificato (dotato di una sua password) è altrettanto sicuro. In ogni caso gli appunti che avevo online (se andate a vedere le vecchie versioni di questa pagina li trovate) credo che non siano più funzionanti, troppo vecchi. Dovrei rifarli.

----
Line 322: Line 306:
Per la gestione delle chiavi, riferirsi alla sezione Linux-Windows, perche` e` identica. Per la gestione delle chiavi, riferirsi alla sezione precedente, perche` e` identica.
Line 722: Line 706:
Line 727: Line 710:
 * 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.

OpenVPN

Openvpn è disponibile per praticamente tutti i sistemi operativi. Linux, Windows, BSD, Macos, ios, android. Qui elenco una serie di configurazoni "di base" per usare Openvpn in diverse situazioni. Non sono tutte configurazioni "pronte" e questa pagina è decisamente disordinata, in quanto le possibili varianti sono davvero tante.

Fra l'altro openvpn ha avuto una certa evoluzione degli ultimi anni e sono cambiate diverse cose. Alcune opzioni come la compressione sono state deprecate in maniera un pochino troppo "hard", rompendo le configurazioni pre-esistenti. Lo stesso vale per certi algoritmi crittografici. Per rendere le cose più semplici, il client per Macos e quello per ios hanno un loro concetto personale, diverso da tutti gli altri, di regole per la gestione del traffico nel tunnel.


Questa e` la configurazione piu` semplice del mondo, non la piu` sicura. Tuttavia è comoda da realizzare, e non è meno sicura del 99% delle connessioni ipsec che vedo in giro dai clienti con i loro firewall commerciali da 10.000 euro, una chiave preshared e algoritmi obsoleti. Questa configurazione crea un tunnel, non un bridge. In altri termini fa routing a layer 3 e non bridging a layer 2.

  • 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>
    
    # algoritmi crittografici piu` sicuri rispetto ai vecchi default
    cipher AES-256-CBC
    auth SHA512
    
    
    # dropppo i privilegi
    user nobody
    group nogroup
    
    
    # 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

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

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 diversi dispositivi portatili 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 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.

Impostazione server Linux

  • Prima di tutto, installare il pacchetto openvpn
  • Occorre crearsi una propria CA interna per generare i certificati che useremo per identificare il server e i client. Per fare questo usiamo Easy RSA ../EasyRSA

  • Attenzione: la CA va conservata in una macchina sicura. Se qualcuno si impossessa delle chiavi della CA puo` generare certificati validi!
  • Seguendo quanto indicato qui ../EasyRSA dovrete di fatto fare 4 passi:

    • Creare la CA stessa
    • Creare una chiave per il vostro server che sia di tipo server
    • Creare una chiave per il vostro primo client (che non sia di tipo server)
    • Creare il file contenente i parametri DH, per il server. (procedura molto lenta)
  • Eventualmente (non è obbligatorio) possiamo 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). 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.

  • Copiare i files "ca.crt", "dh.pem" (o altro nome del file dh, a seconda di come l'avete chiamato), "server.crt" e "server.key" dalla directory delle chiavi della CA (dentro pki/private e pki/issued nel percorso della CA) sul server in /etc/openvpn

  • Copiare i files "ca.crt", "tls-auth.key" (se lo volete usare), "client1.crt" e "client1.key" sul client (la posizione di questi files dipende dal client, in ogni caso tenete conto che servono questi files sul client)
  • Creare un file di configurazione in /etc/openvpn con un nome tipo "server.conf", cosi` fatto:

    # configurazione per openvpn 2.4
    # 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.
    
    
    # device usato dalla vpn (univoco per ogni istanza di openvpn)
    dev tun0
    
    # algoritmi crittografici piu` sicuri del vecchio default
    cipher AES-256-CBC
    auth SHA512
    
    # 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
    
    # 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"
    
    # 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
  • 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, scaricandolo da http://www.openvpn.net, nella sezione "Community software / downloads". Il link diretto, che non e` detto che funzioni sempre, e` questo: https://openvpn.net/community-downloads/

  • Raccogliere tutti i files necessari per il client, che sono "ca.crt", "tls-auth.key" (se lo volete usare), "client1.crt" e "client1.key"
  • Creare il file di configurazione con il nome che volete voi, purche` abbia estensione "ovpn". Ad esempio, il file potrebbe essere ufficio.ovpn. Il contenuto sarà questo:

    client
    dev tun
    proto udp
    nobind
    float
    remote <hostname o ip pubblico del server>
    
    # algoritmi crittografici piu` sicuri
    cipher AES-256-CBC
    auth SHA512
    
    # 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
  • Tutti i files che abbiamo messo assieme vanno quindi messi nella directory delle configurazioni del client VPN, che è (alla versione attuale del client) c:\Program Files\OpenVPN\config oppure c:\Users\$USERNAME\OpenVPN\config


Configurazione "monolitica" con i certificati entrocontenuti

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.

In fondo alla pagina c'è uno script per convertire configurazioni standard in monolitiche (lo script gira su linux, ma ovviamente genera config per qualsiasi client)

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>

Autenticazione con username e password

Openvpn prevede una autenticazione mista (certificati + username e password). La ritengo mediamente inutile, in quanto un certificato (dotato di una sua password) è altrettanto sicuro. In ogni caso gli appunti che avevo online (se andate a vedere le vecchie versioni di questa pagina li trovate) credo che non siano più funzionanti, troppo vecchi. Dovrei rifarli.


Configurazione LAN to LAN fra due Linux, usando le chiavi asimmetriche

Per la gestione delle chiavi, riferirsi alla sezione precedente, 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

# algoritmi crittografici piu` sicuri
cipher AES-256-CBC
auth SHA512

# 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

# 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

# algoritmi crittografici piu` sicuri
cipher AES-256-CBC
auth SHA512

# 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

# 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

# algoritmi crittografici piu` sicuri
cipher AES-256-CBC
auth SHA512

# 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

# 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

# algoritmi crittografici piu` sicuri
cipher AES-256-CBC
auth SHA512

# 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
tls-auth tls-auth.key 1
#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


Problemi di MTU

Se mandando pacchetti grandi la VPN sembra morire, probabilmente avete problemi di MTU sul percorso. Potete mettere una pezza inserendo nella configurazione (del server o del client, basta uno solo dei due) la riga

mssfix 1450

oppure potete provare anche valori diversi.

Applicando (lato server) a un link fra due connessioni FTTH e VDSL, che andando in pppoe hanno MTU di 1492, un mssfix di 1450 la risultante velocità di un rsync (con forte traffico dal client al server) dentro la VPN è passata da circa 8 Mbit a 49 Mbit fissi. Considerando che il link della VDSL è da 50 Mbit e quello della FTTH da 100, direi che abbia fatto una differenza abissale.

La cosa buffa e` che leggendo il manuale di openvpn intuisco che 1450 dovrebbe essere il valore di default, ma ho verificato che impostandolo a 1450 si risolvono problemi, il che mi fa pensare che forse il valore di default era diverso da 1450 in alcune versioni piu` vecchie di openvpn. In ogni caso il trucco e` provare ad abbassarlo e vedere se si mette a funzionare correttamente.

Sempre stando al manuale, con 1450 come valore del parametro mssfix, il pacchetto udp risultante (fuori dalla vpn) dovrebbe poter passare su un path MTU di 1473 bytes, quindi dovrebbe stare dentro a qualsiasi connessione "normale", comprese quelle in pppoe che hanno MTU di 1492.

Un'altra soluzione potrebbe essere usare "fragment" per forzare la frammentazione DENTRO la VPN, in modo trasparente per i client. Questo pero` aumenta di 4 bytes la dimensione di ogni pacchetto.

fragment 1300
mssfix

Test del MTU

lanciando uno dei due lati della vpn (il client, tipicamente) con il parametro "--mtu-test", si fa un test dell' MTU sul link. Un esempio di esecuzione potrebbe essere questo:

sudo openvpn --mtu-test --config il_tuo_file_di_config.ovpn 

Il risultato mostrera` la dimensione massima dei pacchetti che openvpn e` riuscito a fare transitare nei due versi. Attenzione però: questo risultato comprende una eventuale frammentazione e ricostruzione ad opera dei vari apparati di rete lungo il tragitto. Se si vuole verificare l' MTU senza alcuna frammentazione, occorre eseguire il test cosi`:

sudo openvpn --mtu-disc yes --mtu-test --config il_tuo_file_di_config.ovpn --proto udp4

In questo modo si setta il flag DF nei pacchetti usati nel test, e si otterra` tipicamente un valore piu` basso come risultato. Se si tiene conto di questo valore nell'impostare mssfix e/o fragment dentro la vpn, si dovrebbe ottenere una condizione nella quale i pacchetti non vengono mai frammentati e quindi non di dovrebbero avere problemi di latenza, di ordine di arrivo non congruente, di firewall che bloccano i frammenti perche` sono stronzi, ecc.


Come revocare un certificato

Se dovete revocare uno o piu` certificati, occorre:

  • Revocare il certificato (o i certificati) di vostro interesse, in questo modo:
    • Andare dentro alla directory della CA (easy-rsa)
    • Eseguire . vars

    • Eseguire il comando per revocare il certificato: ./revoke-full <nome certificato> (il nome va senza estensione).

    • L'output del comando mostrera` un "error 23 at 0 depth lookup:certificate revoked". Questo e` giusto, indica che il certificato e` revocato.
    • Eventualmente revocare altri certificati, se necessario, usando sempre il comando revoke_full

  • Copiare il file keys/crl.pem (si trova sotto la directory della CA) dentro a /etc/openvpn mantenendo il nome crl.pem. Questo file puo` essere leggibile da chiunque.

  • Se il file crl.pem non era presente prima dentro a /etc/openvpn, allora occorre anche modificare il file di configurazione di openvpn, aggiungendo una riga che dice:

    • crl-verify /etc/openvpn/crl.pem
  • Fatto tutto questo, occorre riavviare il processo di openvpn per fargli leggere il file crl.pem appena creato.

Va ricordato che qualora si revochino altri certificati in futuro, occorre ricopiare il file crl.pem dalla directory keys della CA alla directory dove lo cerca openvpn, e poi va riavviato il processo di openvpn.

Usare il CCD per dare ip statici

Questo e` l'elenco dei gruppi di ip validi nel comando ifconfig-push dentro al file CCD, considerando la classica allocazione di ip in subent di 4, richiesta dai client windows:

[  1,  2] [  5,  6] [  9, 10] [ 13, 14] [ 17, 18]
[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
[101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178]
[181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218]
[221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]

Il comando da usare sara` quindi una cosa tipo:

ifconfig-push 10.127.0.253 10.127.0.254

Il primo ip verra` dato al client e il secondo al server.


Integrazione con Dnsmasq per risolvere i nomi dei client in vpn

Vedasi la pagina di Dnsmasq: LinuxDebian/DnsMasq


Problemi con il client iOS (iphone/ipad) e MacOS

Il client openvpn di iOS è ovviamente stronzo, come quasi ogni cosa iQualcosa. Se gli indichi un DNS e un DOMAIN con le "dhcp-option", lui decide che chiama il tuo dns solo per il dominio indicato nella opzione DOMAIN, e gli altri li chiede su internet. Il risultato è ovviamente un casino, perché tu ti aspetti che il client usi il DNS che gli hai passato nella dhcp-option, e lui invece lo usa solo per il dominio che gli hai passato. È possibile (e necessario) quindi passargli più righe di "DOMAIN", andando a coprire tutti i dominio che si vuole vengano risolti dal DNS interno della VPN e non da quello esterno.

Tunnelblick, il client per MAcOS, non è da meno, nel senso che imposta dei parametri di connessione (mtu, algoritmi di crittografia, ecc) come gli pare, con il risultato che i suoi paramentri vanno tipicamente in conflitto con quelli che imposti tu nel server. Puoi vedere questi conflitti nel log del client.

22 ottobre 2018: L'uso della compressione si è rivelato insicuro, e alcuni client (ios) hanno disattivato la compressione senza dire nulla all'utente, a partire dalla versione 3.0.2. Se la vostra VPN usava la compressione e ora non funziona più, o la togliete anche dal server, o la riattivate a mano nei client. In ogni caso a questo punto è opportuno non usare più la compressione nelle nuove installazioni.

Openvpn nuovo con certificati vecchi

Se si hanno ancora certificati che usavano l' MD5 e non l' SHA256, occorre inserire questa riga nella configurazione:

tls-cipher "DEFAULT:@SECLEVEL=0"

TAP adapter e windows 10

Se in windows 10 il "TAP adapter" non si installa dal pacchetto di installazione di openvpn, potete provare a scaricare e installare questo: https://build.openvpn.net/downloads/releases/tap-windows-9.21.2.exe che pare funzionare. Questo non è l'ultimissima versione, ma funziona. Le versioni successive le potete vedere andando a https://build.openvpn.net/downloads/releases/. Nel caso non sia più disponibile ho salvato il file e allegato a questa pagina, quindi è scaricabile da questo sito.


Script per generare configurazioni monolitiche

Se servisse generare delle configurazioni con i certificati compresi dentro al file di config, c'e` questo semplice script che permette di farlo. Prende in input il nome di un file di configurazione, e si aspetta di trovare nello stesso percorso i files dei certificati cosi` come richiamati dentro al file di configurazione, e genera un nuovo file di configurazione che contiene i certificati al loro interno. unifier.sh


Note

  • 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.

OpenVpn (last edited 2020-05-21 15:38:35 by Kurgan)