Per accedere al server Linux di un cliente mi sono stati forniti un client VPN ed i dati di accesso. Ovviamente il client è solo per Windows, e dovendo scambiare file con il server Linux ero costretto a fare il reboot del computer e passare a Windows, dopo aver lavorato i file con Linux. Insomma, un bagno di sangue.

Smanettando per qualche ora sono riuscito a far funzionare OpenSWAN con l’appliance SonicWall, di cui, per non precisati motivi di sicurezza, non mi è stato fornito alcun dettaglio: modello, configurazione, tipo di VPN, algoritmi. Praticamente ho dovuto fare tutto da solo.

Ecco il risultato della battaglia.

Un po’ di teoria

L’argomento è realmente vastissimo e, come potete facilmente immaginare, pieno di confusione. Esistono VPN su tunnel SSL, su tunnel SSH oppure che sfruttano protocolli IPSEC, in parte standardizzati. Insomma una giungla. Ed ovviamente ogni produttore ha la sua ‘interpretazione’ dei protocolli standard.

Una VPN che si rispetti passa due fasi principali prima di considerare stabilita la connessione: la fase di autenticazione e la fase di attivazione del tunnel cifrato. Sono previsti quindi due diversi gruppi di protocolli, uno per fase. Nella configurazione va specificato tutto il gruppo di protocolli necessari, oppure le scelte possibili, che poi vengono negoziate con l’altro lato del tunnel. Già per il meccanismo di autenticazione esistono più scelte possibili: usare una chiave condivisa (modalità PSK, “pre-shared key”), che deve essere conosciuta da entrambi i lati della VPN, oppure una chiave crittografica RSA (modalità RSA-SIG), o infine un certificato X.509, ed ognuna prevede una configurazione differente. Già questo è sufficiente per capire il livello di complessità dell’argomento. Ma non basta. Per rendere più rapido l’avvio della VPN si può scegliere un comportamento più “deciso” del client, attivando la modalità aggressiva. In questo modo il client propone all’altro lato del tunnel solo un tipo di algoritmo per autenticazione e cifratura, una sorta di “prendere o lasciare”. Il collegamento si stabilisce più in fretta, ma abbiamo la limitazione che dobbiamo sapere in anticipo cosa accetta l’altro lato, il cosiddetto lato destro. Nelle connessioni VPN si distingue fra lato sinistro, ossia il nostro computer, o client, e lato destro, il server o fornitore della VPN. Non è finita.

Una volta stabilito il collegamento, con il tunnel attivo, deve poi essere definito il modo in cui il collegamento viene visto dal lato del protocollo di rete IP. Fondamentalmente esistono due tipi di architettura: una dove il nostro computer viene fisicamente “inserito” nella rete remota, acquisendo indirizzo, route di default e DNS al momento dell’attivazione del tunnel; l’altra invece imposta soltanto una route statica verso il computer o la subnet remota, dipende dalla configurazione. In sostanza il nostro computer rimane col suo indirizzo IP, la sua route di default ed i suoi DNS, ed acquisisce soltanto l’accesso un altro segmento di rete, ovviamente con indirizzi privati.

Nella versione installata dal cliente è previsto appunto questo secondo scenario.

Riepiloghiamo: installeremo una VPN in modalità chiave condivisa (PSK), con modalità aggressiva.

Installare OpenSWAN in Fedora

Il pacchetto è presente nei depositi software ufficiali di Fedora, per cui non serve altro che un semplice comando:


# yum install openswan

I file necessari per la configurazione sono nella directory /etc e in /etc/ipsec.d. In /etc abbiamo ipsec.conf e ipsec.secrets. Il secondo contiene una direttiva di inclusione di tutti i file con estensione .secrets nella directory /etc/ipsec.d. Il primo è più interessante, e contiene istruzioni per impostare il livello di debug dei vari servizi di OpenSWAN, utili per capire se le cose vanno bene oppure no. In particolare va tolto il commento alla riga plutodebug che va impostato su “all”. In questo modo avremo il massimo livello di log, indispensabile per capire cosa succede. Se siamo dietro un firewall ci accertiamo anche che nel file sia presente e non commentata la direttiva nat_traversal=yes, che avverte OpenSWAN ed il server con cui andiamo a stabilire la VPN che siamo dietro ad un firewall che cambia i nostri indirizzi IP.

Per fare le cose ordinate, creeremo due file nella directory /etc/ipsec.d: uno per la configurazione della nostra VPN ed uno per la chiave segreta condivisa. Chiameremo i file miavpn.conf e miavpn.secrets, mentre la connessione sarà chiamata mia, con palese mancanza di fantasia.

Il contenuto del file miavpn.conf è più o meno questo:


conn mia
        type=tunnel
        leftid=hawking
        # Left security gateway, subnet behind it, next hop toward right.
        left=%defaultroute
        # %defaultroute will suffice in the vast majority of setups
        # Right security gateway, subnet behind it, next hop toward right.
        right=ip-del-lato-destro
        rightsubnet=172.16.0.0/16
        rightid=id-unico-del-sonicwall-lato-destro
        auto=add
        auth=esp
        ike=3des-sha1-modp1024
        esp=3des-sha1
        xauth=yes
        leftxauthclient=yes
        authby=secret
        aggrmode=yes
        pfs=no

include /etc/ipsec.d/examples/no_oe.conf

Andiamo a guardare i singoli parametri. Per prima cosa, facciamo attenzione all’indentazione: l’intestazione che definisce una connessione deve iniziare nella prima colonna, mentre i parametri che le definiscono devono essere elencati sotto questa e avere almeno uno spazio o una tabulazione ad inizio riga. Ogni file può contenere più configurazioni di connessione, ma per ordine e pulizia consiglio di usare un file per ogni VPN.

conn mia
Questa è l’intestazione che definisce una nuova connessione dal nome “mia”
type=tunnel (default)
Specifica un collegamento di tipo host-to-host, host-to-subnet oppure subnet-to-subnet.
leftid=hawking
E’ l’identificativo del nostro computer, in questo caso il nome (il mio si chiama così in onore del noto fisico). Servirà poi per selezionare la chiave segreta dal file corrispondente.
left=%defaultroute
Con questa voce diciamo ad OpenSWAN di determinare automaticamente i valori di indirizzo locale, subnet locale e default route per il nostro computer.
right=ip-del-lato-destro
Qui mettiamo l’indirizzo a cui dobbiamo connetterci per stabilire la VPN. Nel mio caso era l’indirizzo Internet del SonicWall.
rightsubnet=172.16.0.0/16
Qui va determinata la subnet dal lato destro a cui potremo accedere dopo l’attivazione della VPN. Se il nostro IP e la nostra subnet collidono con questi indirizzi potremmo avere problemi. Questi valori li può fornire solo chi ha impostato il SonicWall dal lato destro, oppure se si ha a disposizione un computer Windows si può installare il client e vedere a connessione stabilita che valori fornisce il SonicWall remoto. Questo “trucco” è utile anche per stabilire altri parametri, se non è possibile ottenerli dall’amministratore del SonicWall.
rightid=id-unico-del-sonicwall-lato-destro
Questo è l’identificativo unico dell’appliance SonicWall, differente da esemplare ad esemplare. Per averlo, sempre supponendo di non avere collaborazione dalla parte opposta, si può attivare la connessione con tutti i parametri inseriti, meno questo, e nel log di connessione si ottiene l’identificativo. OpenSWAN rifiuta connessioni senza identificativo remoto, per cui anche se tutti i parametri sono corretti ma non abbiamo questo identificativo otteniamo un messaggio come questo:


002 "mia" #1: Aggressive mode peer ID is ID_FQDN: '@0123456789AB'
003 "mia" #1: no suitable connection for peer '@0123456789AB'
003 "mia" #1: initial Aggressive Mode packet claiming to be from 10.10.10.1
on 10.10.10.1 but no connection has been authorized

Dove @0123456789A è l’identificativo del SonicWall remoto e 10.10.10.1 è l’indirizzo IP dello stesso sonicwall (qui fittizio). Questo identificativo è proprio quello che cerchiamo.

auto=add
Questa è l’azione che viene eseguita all’avvio del supporto IPSEC con questa connessione. Si può anche specificare start, ma nel mio caso ho dovuto avviare a mano per via del tipo di autenticazione, che richiede il passaggio di username e password per l’accesso, valori che passo manualmente, come vedremo dopo. In questo caso l’azione si limita ad aggiungere la connessione “mia” all’elenco delle VPN conosciute.
ike=3des-sha1-modp1024
Questa è la tripletta di algoritmi di cifratura ed autenticazione utilizzate nella fase 1 della connessione, quando si effettua appunto l’autenticazione e i due lati della VPN si accordano per gli algoritmi da usare nella seconda fase. Anche per questi si possono usare quelli che si trovano con il “trucco” della connessione con Windows. Il valore è diviso in tre parti e se una viene omessa viene usato il default. Se i valori scelti non combaciano si ottiene un messaggio di questo tipo:


112 "mia" #1: STATE_AGGR_I1: initiate
010 "mia" #1: STATE_AGGR_I1: retransmission; will wait 20s for response

ad indicazione che i protocolli scelti non sono quelli accettati dal lato destro.

esp=3des-sha1
Questo è invece l’algoritmo utilizzato per la fase 2 dell’attivazione del tunnel sicuro. ESP sta per Encrypted Secure Payload, ed è il “contenuto” della connessione, ossia i nostri dati che passano per la VPN. In questo caso gli algoritmi erano questi, sempre rilevati dal client Windows.
xauth=yes
leftxauthclient=yes
Questi due parametri specificano il tipo di autenticazione, ossia attraverso la coppia username e password fornita da chi ha impostato il SonicWall. Il primo indica appunto questo tipo di autenticazione, mentre il secondo indica che il nostro computer fornirà le credenziali, e l’altro dovrà controllarle. Questi due parametri, secondo il manuale di OpenSWAN, obbligano ad avviare la connessione interattivamente e non in automatico, come vedremo.
authby=secret
Questa è la configurazione che specifica il tipo di mutua autenticazione dei due computer che formeranno la VPN. In questo caso è la chiave segreta condivisa, una password che conoscono i due estremi della VPN e che non viene mai scambiata lungo la connessione stessa. Nel mio caso è una lunga stringa. Ovviamente è una informazione riservata e deve essere scambiata lungo un canale sicuro, quindi niente e-mail, a meno che non sia usata una cifratura seria del messaggio.
aggrmode=yes
Questo parametro serve appunto a selezionare il modo aggressivo, che stabilisce molto rapidamente la VPN. Di contro, se uno qualsiasi dei parametri non è accettato da una delle parti la VPN non verrà attivata senza appello.
pfs=no
La sigla sta per Perfect Forward Secrecy e indica un tipo di comportamento sul canale di scambio delle chiavi di cifratura che in caso di intrusione rende perfettamente sicure le chiavi generate fino a quel momento. Nel mio caso era disattivato sul SonicWall remoto.
include /etc/ipsec.d/examples/no_oe.conf
Includere questo file nella configurazione per far funzionare il tutto. Senza questo file, OpenSWAN cerca di utilizzare un protocollo chiamato Opportunistic Encryption che richiede particolari configurazioni dei record DNS del lato destro della connessione. Per qualche motivo che non ho compreso, se non disabilito questo tipo di protocollo, non c’è verso di ottenere una VPN.

Veniamo ora al file che conterrà la chiave segreta condivisa tra i due sistemi. Il file è miavpn.secrets (per chiarezza è meglio se ha lo stesso nome del file che contiene la configurazione), ed il contenuto è questo:


# This file holds shared secrets or RSA private keys for inter-Pluto
# authentication. See ipsec_pluto(8) manpage, and HTML documentation.

@0123456789AB hawking : PSK "chiavesegreta"

Notare che la riga non deve contenere spazi iniziali, altrimenti viene ignorata. Abbiamo l’identificativo unico del SonicWall ed il nome del mio computer, poi un carattere due punti, la parola chiave PSK che identifica appunto la Pre-Shared Key ed infine la chiave condivisa, che in questo caso è la stringa "chiavesegreta". In questo caso, visto che abbiamo una sola VPN, prima dei due punti avremmo potuto non specificare niente, ma in caso contrario va segnalato a OpenSWAN quali chiavi deve utilizzare in funzione dei partecipanti alla VPN. Di solito si usa l’identificativo unico del SonicWall e il nostro IP. Se il nostro IP è dinamico conviene usare il nome del computer, che viene convertito automaticamente nell’IP o nell’indirizzo 127.0.0.1.

La configurazione dovrebbe essere a posto. Ora passiamo ad attivare la connessione.

I comandi da dare in sequenza sono, tutti da utente root:


# ipsec setup --start
Avvio di IPsec:  Starting Openswan IPsec 2.4.9...      [  OK  ]

che serve ad avviare il servizio IPSEC, seguito da:


# ipsec whack  --name mia --initiate
...
...
002 "mia" #2: transition from state STATE_AGGR_I1 to state STATE_AGGR_I2
004 "mia" #2: STATE_AGGR_I2: sent AI2, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
041 "mia" #2: mia prompt for Username:
Name enter: inserite il vostro username
040 "mia" #2: mia prompt for Password:
Enter secret: inserite la password
002 "mia" #2: XAUTH: Answering XAUTH challenge with user='username'
002 "mia" #2: XAUTH: Successfully Authenticated
002 "mia" #2: transition from state STATE_XAUTH_I0 to state STATE_XAUTH_I1
004 "mia" #2: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set
002 "mia" #3: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#2}
117 "mia" #3: STATE_QUICK_I1: initiate
002 "mia" #3: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
004 "mia" #3: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xd3a05f4d <0xeea312b0
xfrm=3DES_0-HMAC_SHA1 NATD=10.10.10.1:4500 DPD=none}
#

L'indirizzo IP sull'ultima riga è quello del lato destro, ossia il computer verso cui tentiamo di stabilire la VPN. Dopo l'attivazione la tabella di routing nel nostro computer viene modificata in questo modo:


# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.42.0    *               255.255.255.0   U     0      0        0 eth0
172.16.0.0      *               255.255.0.0     U     0      0        0 eth0
default         192.168.42.1    0.0.0.0         UG    0      0        0 eth0

è stata aggiunta la riga centrale, con l'instradamento verso la subnet remota.

Per disconnettere la VPN possiamo usare il comando:


# ipsec setup --stop
Arresto di IPsec:  Stopping Openswan IPsec...         [  OK  ]

Al momento dell'attivazione della connessione si può anche passare sulla riga di comando direttamente sia username che password in questo modo:


# ipsec whack --name mia --xauthname nome --xauthpass pass --initiate

dove nome è lo username e pass è la vostra password.

Siamo al termine. L'argomento è complesso e per nulla intuitivo, e vi confesso che gran parte di quello che ho letto ha solo aumentato la mia confusione. Al momento ho capito quanto basta per far funzionare la VPN con l'appliance SonicWall per quello che mi serve, e ciò mi basta.

Riferimenti