[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home] [volume] [parte]


Capitolo 411.   VPN attraverso OpenSSH

In un sistema GNU/Linux, con l'ausilio di OpenSSH, è possibile creare un tunnel cifrato per collegare tra loro due reti private, attraverso Internet.

La creazione del tunnel implica la definizione di un'interfaccia di rete virtuale, che viene configurata convenientemente, come se fosse un'interfaccia reale, attraverso una rete fisica.

411.1   Principio di funzionamento

Inizialmente, si hanno due reti private separate, come quelle dello schema seguente:

reti private

A sinistra si vede una rete locale con indirizzi 172.17.0.0/16, mentre a destra appare un'altra rete locale con indirizzi 172.21.0.0/16. La rete di destra accede a Internet attraverso un elaboratore che svolge il compito di router, avendo all'esterno un indirizzo IPv4 statico raggiungibile (1.2.3.4); la rete a sinistra, invece, ha un router, che però è isolato da un firewall (che in più trasforma anche gli indirizzi).

Fortunatamente, dalla rete di sinistra è possibile accedere all'elaboratore 1.2.3.4 attraverso il protocollo SSH. Pertanto, dalla rete di sinistra, è possibile attivare un tunnel SSH:

reti private

Si suppone che la creazione del tunnel produca l'apparizione, rispettivamente dell'interfaccia di rete virtuale tun1 e tun0. Queste interfacce vengono configurate, da una parte e dall'altra, con l'aggiunta di instradamenti appropriati:

reti private

411.2   Configurazione e opzioni significative

OpenSSH, dal lato servente (dalla parte che deve ricevere la richiesta di connessione), ovvero nel lato destro degli esempi mostrati, deve essere configurato in modo da accettare la creazione di un tunnel. Per questo occorre verificare che nel file /etc/ssh/sshd_config ci sia la direttiva seguente:

...
PermitTunnel point-to-point
...

Inoltre, considerato che il tunnel deve attraversare un NAT (un sistema di trasformazione degli indirizzi), è necessario che ci sia un minimo di scambio di pacchetti, anche se privi di utilità, per evitare che la connessione venga abbattuta (dimenticata) dal NAT stesso. Per questo si possono usare delle opzioni nella riga di comando di ssh, in modo da mantenere «vivo» il collegamento.

Tabella 411.5. Opzioni utili nell'uso di ssh quando si vuole stabilire un tunnel cifrato.

Opzione Descrizione
-C
Richiede che i dati trasmessi siano compressi, per ridurre l'utilizzo di banda.
-f
Richiede che il programma si metta a lavorare sullo sfondo, ma solo prima dell'esecuzione del comando, in modo da consentire, eventualmente, l'inserimento di una parola d'ordine.
-o ServerAliveInterval n
Richiede che ogni n secondi di inattività, venga inviato un pacchetto di richiesta di attenzione al servente, attraverso il canale cifrato.
-o ServerAliveCountMax n
Dopo n tentativi falliti di ottenere una risposta dal servente, la connessione viene abbattuta.
-w tun_loc:tun_rem
Stabilisce i nomi delle interfacce di rete virtuali da creare, presso l'elaboratore locale e presso quello remoto. I nomi devono essere compatibili con il sistema operativo e non devono essere già in uso per altri tunnel.

411.3   Attivazione del tunnel dal lato «cliente»

Dal lato cliente (la parte sinistra degli esempi mostrati), si attiva il tunnel contando di poter creare l'interfaccia tun1 e tun0 rispettivamente:

ssh -o "ServerAliveInterval 1" \
  \    -o "ServerAliveCountMax 700" \
  \    -f \
  \    -w tun1:0\
  \    1.2.3.4 true
[Invio]

Come si può vedere, il tunnel viene creato collegandosi con l'indirizzo IPv4 1.2.3.4, che deve essere raggiungibile attraverso Internet; inoltre, è necessario dare un comando, per quanto inutile (in questo caso si tratta di true). Eventualmente viene richiesto di inserire la parola d'ordine:

root@1.2.3.4's password: digitazione_all'oscuro[Invio]

Si può poi controllare l'esistenza dell'interfaccia tun0:

ifconfig tun1[Invio]

tun1  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:500 
      RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Quindi si può configurare l'interfaccia e gli instradamenti:

ifconfig tun1 172.17.254.21 pointopoint 172.21.254.17[Invio]

route add -net 172.21.0.0 netmask 255.255.0.0 gw 172.21.254.17[Invio]

411.4   Configurazione dal lato «servente»

Dal lato servente, ovvero nel lato destro degli schemi di esempio mostrati, dopo che il tunnel è stato creato, è sufficiente configurare l'interfaccia e gli instradamenti:

ifconfig tun0 172.21.254.17 pointopoint 172.17.254.21[Invio]

route add -net 172.17.0.0 netmask 255.255.0.0 gw 172.17.254.21[Invio]

411.5   Autenticazione automatica

Se per qualche ragione la connessione del tunnel viene abbattuta, gli esempi mostrati non sono sufficienti a ricreare il tunnel stesso. Evidentemente, da entrambe le parti, si rende necessario uno script, che, periodicamente, controlli se è attivo o se deve essere ristabilito il collegamento. Tuttavia, per automatizzare la connessione dal lato cliente, è necessario che l'autenticazione avvenga attraverso l'autorizzazione della chiave pubblica. Sinteticamente, occorre procedere come segue.

Dal lato cliente, l'utente root deve disporre di una coppia di chiavi RSA (dove la chiave privata non deve essere cifrata), che può essere creata così:

ssh-keygen -t rsa -N "" -f /root/.ssh/id_rsa[Invio]

Così facendo, nella directory /root/.ssh/ si devono ottenere i file id_rsa (chiave privata) e id_rsa.pub (chiave pubblica). Il file id_rsa.pub, contenente la chiave pubblica, dovrebbe essere composto da una riga simile a quella seguente:

ssh-rsa AAAAB3NzaC1yc2EAAA...IwAApObsDc1WtKtt20= root@localhost

A questo punto, dal lato servente, l'utente root deve dichiarare valido l'accesso da parte di chi è in grado di cifrare qualcosa che può essere decifrato con quella tale chiave pubblica. Ma, seguendo gli esempi mostrati, si pone un problema nuovo: occorre conoscere con quale indirizzo IPv4 si presenta la connessione.

reti private

Supponendo che il firewall del lato sinistro disponga di un indirizzo IPv4 statico, che corrisponde a 2.3.4.5, nel file /root/.ssh/authorized_keys del lato servente occorre aggiungere la riga seguente:

from="2.3.4.5" ssh-rsa AAAAB3NzaC1yc2EA...ObsDc1WtKtt20= root@localhost

Naturalmente, anche il file /etc/ssh/sshd_config del lato servente deve essere redatto in modo tale da consentire un accesso di questo tipo:

...
PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes
...

Appunti di informatica libera 2008 --- Copyright © 2000-2008 Daniele Giacomini -- <appunti2 (ad) gmail·com>


Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome vpn_attraverso_openssh.htm

[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home]

Valid ISO-HTML!

CSS validator!

Gjlg Metamotore e Web Directory