12737
Comment:
|
← Revision 57 as of 2024-10-14 13:36:26 ⇥
8970
|
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. |
= 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. '''Openvpn nelle versioni 2.5 e successive sta cambiando alcuni comportamenti, algoritmi crittografici, assegnazione degli indirizzi ip. Questo significa che diverse cose nelle config qua indicate valgono solo per versioni recenti di openvpn. Per le versioni vecchie di openvpn sarà possibile consultare le vecchie versioni di questa pagina.''' |
Line 5: | Line 10: |
=== Configurazione di un link fra due reti con chiave preshared === | * [[/Openvpn_LAN2LAN_Preshared]] - Configurazione di un link fra due reti con chiave preshared * [[/Openvpn_Con_Certificati]] - Configurazione per connettere diversi dispositivi portatili a un concentratore con chiavi asimmetriche * [[/Openvpn_LAN2LAN_Con_Certificati]] - Configurazione LAN to LAN fra due Linux, usando le chiavi asimmetriche * [[/Openvpn_LAN2LAN_Multipla]] - Configurazione con un server e tanti client ognuno dei quali ha una sua LAN dietro (con routing per le LAN) * [[/Openvpn_MTU]] - Appunti su come verificare e provare ad aggirare eventuali problemi di MTU * [[/Openvpn_MFA]] - Configurazione di openvpn con chiavi asimmetriche e autenticazione TOTP (Autenticazione a due fattori) |
Line 7: | Line 17: |
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}}} |
|
Line 49: | Line 19: |
=== 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). |
|
Line 83: | Line 22: |
== Appunti vari a rigurardo di Openvpn == | |
Line 84: | Line 24: |
=== Configurazione per connettere portatili con Windows a un concentratore Linux con chiavi asimmetriche === | |
Line 86: | Line 25: |
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. | === Integrazione con Dnsmasq per risolvere i nomi dei client in vpn === |
Line 88: | Line 27: |
==== Impostazione server Linux ==== | Vedasi la pagina di Dnsmasq: [[LinuxDebian/DnsMasq]] |
Line 90: | Line 29: |
* Prima di tutto, installare il pacchetto openvpn 2.0 (o compilarsi la 2.0 dai sorgenti) * 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 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: |
=== Come revocare un certificato === Se dovete revocare uno o piu` certificati, occorre: * Revocare il certificato (o i certificati) di vostro interesse usando easy-rsa o altro metodo * 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. Se si usa una CRL per revocare chiavi, occorre ricordare una cosa molto importante: Openvpn legge la CRL all'avvio, ma se la CRL cambia, tenta di rileggerla in tempo reale ogni volta che riceve una connessione, il che e` giustissimo, ma fate attenzione: Se avete impostato openvpn per droppare i privilegi e girare come "nobody", a questo punto e` facile che non riesca piu` a leggere la CRL, col risultato che '''non accettera` piu` nessuna connessione'''. Occorre quindi riavviare openvpn per riuscire a leggere la CRL, oppure, più saggiamente, '''assicurari che l'utente "nobody" possa leggere il file della CRL'''. === Usare il CCD per dare ip statici === '''Questa configurazione e` relativa alla "topolgy net30" e non è più valida con topologia "subnet" con le versioni di openvpn recenti. In questa nuova topologia si da` un solo ip per client in una classe /24.''' 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: |
Line 98: | Line 54: |
. ./vars ./clean-all ./build-ca |
[ 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] |
Line 102: | Line 68: |
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}}} * Copiare i files "ca.crt", "dh2048.pem", "tls-auth.key","<server>.crt" e "<server>.key" sul server in {{{/etc/openvpn}}} * 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: |
Il comando da usare sara` quindi una cosa tipo: |
Line 117: | Line 72: |
# configurazione per openvpn 2.0 # per gestire un server per molti client |
ifconfig-push 10.127.0.253 10.127.0.254 }}} |
Line 120: | Line 75: |
# interfaccia pubblica, porta e protocollo local 62.123.161.1 port 1194 proto udp |
Il primo ip verra` dato al client e il secondo al server. |
Line 125: | Line 77: |
# device usato dalla vpn dev tun0 |
|
Line 128: | Line 78: |
# io sono il server TLS (sempre vero per una conf a un server e molti client) tls-server |
|
Line 131: | Line 79: |
# il file con dentro il numero primo per l'algoritmo Diffie Helman # (serve solo per il server tls). dh dh2048.pem |
=== Problemi con il client iOS (iphone/ipad) e MacOS === |
Line 135: | Line 81: |
# il file con la chiave pubblica # della CA che ha firmato i certificati per tutti gli endpoint. ca ca.crt |
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. |
Line 139: | Line 83: |
# il file con la chiave pubblica del mio endpoint (il server) cert server.crt |
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. |
Line 142: | Line 85: |
# il file con la chiave privata del mio endpoint (il server) key server.key |
'''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. |
Line 145: | Line 87: |
# 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 |
|
Line 153: | Line 88: |
# 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 |
=== Openvpn nuovo con certificati vecchi === |
Line 158: | Line 90: |
# tengo traccia degli indirizzi assegnati ai server e riassegno sempre # quelli usando questo file. (facoltativo) ifconfig-pool-persist server-pool-cache.txt |
Se si hanno ancora certificati che usavano l' MD5 e non l' SHA256, occorre inserire questa riga nella configurazione: |
Line 162: | Line 92: |
# 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 push "route 192.168.0.0 255.255.255.0" |
{{{ tls-cipher "DEFAULT:@SECLEVEL=0" }}} |
Line 166: | Line 96: |
# configurazioni varie da insegnare ai client push "dhcp-option DNS 192.168.0.1" push "dhcp-option WINS 192.168.0.2" |
|
Line 170: | Line 97: |
# consento ai clients di vedersi fra di loro # client-to-client |
|
Line 173: | Line 98: |
# uso il nome utente come "nome" del client. Togliere se non si usa l'autenticazione username/password con PAM username-as-common-name |
=== Script per generare configurazioni monolitiche === |
Line 176: | Line 100: |
# keepalive e timeout: ping ogni 30 secondi e timeout di 120 secondi. keepalive 30 120 |
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. [[attachment:unifier.sh]] |
Line 179: | Line 103: |
# Compressione sul link comp-lzo |
|
Line 182: | Line 104: |
# downgrade dei privilegi utente dopo l'avvio: user nobody group nogroup |
=== Note Varie === |
Line 186: | Line 106: |
# 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. 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). * 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. * 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". {{{ client dev tun proto udp 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 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 menzionati 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) === 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 forse e` meglio proteggere con password il certificato. |
|
Line 248: | Line 107: |
* 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. |
|
Line 250: | Line 112: |
* Compatibilita` di clienti nuovi con server vecchi: nel conf del client mettere {{{tls-cipher "DEFAULT:@SECLEVEL=0"}}} |
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.
Openvpn nelle versioni 2.5 e successive sta cambiando alcuni comportamenti, algoritmi crittografici, assegnazione degli indirizzi ip. Questo significa che diverse cose nelle config qua indicate valgono solo per versioni recenti di openvpn. Per le versioni vecchie di openvpn sarà possibile consultare le vecchie versioni di questa pagina.
/Openvpn_LAN2LAN_Preshared - Configurazione di un link fra due reti con chiave preshared
/Openvpn_Con_Certificati - Configurazione per connettere diversi dispositivi portatili a un concentratore con chiavi asimmetriche
/Openvpn_LAN2LAN_Con_Certificati - Configurazione LAN to LAN fra due Linux, usando le chiavi asimmetriche
/Openvpn_LAN2LAN_Multipla - Configurazione con un server e tanti client ognuno dei quali ha una sua LAN dietro (con routing per le LAN)
/Openvpn_MTU - Appunti su come verificare e provare ad aggirare eventuali problemi di MTU
/Openvpn_MFA - Configurazione di openvpn con chiavi asimmetriche e autenticazione TOTP (Autenticazione a due fattori)
Appunti vari a rigurardo di Openvpn
Integrazione con Dnsmasq per risolvere i nomi dei client in vpn
Vedasi la pagina di Dnsmasq: LinuxDebian/DnsMasq
Come revocare un certificato
Se dovete revocare uno o piu` certificati, occorre:
- Revocare il certificato (o i certificati) di vostro interesse usando easy-rsa o altro metodo
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.
Se si usa una CRL per revocare chiavi, occorre ricordare una cosa molto importante: Openvpn legge la CRL all'avvio, ma se la CRL cambia, tenta di rileggerla in tempo reale ogni volta che riceve una connessione, il che e` giustissimo, ma fate attenzione: Se avete impostato openvpn per droppare i privilegi e girare come "nobody", a questo punto e` facile che non riesca piu` a leggere la CRL, col risultato che non accettera` piu` nessuna connessione. Occorre quindi riavviare openvpn per riuscire a leggere la CRL, oppure, più saggiamente, assicurari che l'utente "nobody" possa leggere il file della CRL.
Usare il CCD per dare ip statici
Questa configurazione e` relativa alla "topolgy net30" e non è più valida con topologia "subnet" con le versioni di openvpn recenti. In questa nuova topologia si da` un solo ip per client in una classe /24.
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.
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"
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 Varie
- 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.
Compatibilita` di clienti nuovi con server vecchi: nel conf del client mettere tls-cipher "DEFAULT:@SECLEVEL=0"