Diff for "OpenVpn"

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.

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

Impostazione server Linux

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

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

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

# 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.
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
# 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 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)

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

# 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

# abilito la compressione (se voglio)
comp-lzo

# log level (da 0 per il minimo a 9 per il massimo)
verb 3

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