|
|
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [volume] [parte]
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.
Inizialmente, si hanno due reti private separate, come quelle dello schema seguente:
|
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:
|
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:
|
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:
|
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 402.5. Opzioni utili nell'uso di ssh quando si vuole stabilire un tunnel cifrato. |
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]
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]
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:
|
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.
|
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:
|
Naturalmente, anche il file /etc/ssh/sshd_config del lato servente deve essere redatto in modo tale da consentire un accesso di questo tipo:
|
Appunti di informatica libera 2007.02 --- Copyright © 2000-2007 Daniele Giacomini -- <daniele (ad) swlibero·org>
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]
