VPN PPP-SSH Mini-HOWTO
Scott Bronson
bronson@trestle.com
2001-07-29
Diario delle revisioni
Revisione v1.00 2002-01-16 Corretto da: sb
Release (pubblica) iniziale.
Una VPN PPP-SSH è con ogni probabilità il più semplice tipo di VPN da
configurare. Non occorre altro che le comuni utility PPP e SSH per
creare un tunnel di rete tra due host.
Tradotto da Manuel Spezzani, Alberto Ronzoni, Daniele Gozzi, Laura
Ferretti e Daniela Saladino nell'ambito del corso di Inglese Tecnico
presso l'Università degli Studi di Modena e Reggio Emilia (a.a.
2004/2005)
_________________________________________________________________
Sommario
1. Introduzione
1.1. Copyright
1.2. Disclaimer
1.3. Credits
2. Introduzione
2.1. Benefici di PPP-SSH
2.2. Inconvenienti del PPP-SSH
2.3. Letture Consigliate
2.4. Alternative
3. Installazione del Software
3.1. Terminologia
3.2. Requisiti
3.3. Progettazione
3.4. Configurare PPP
3.5. Permettere a SSH l'attraversamento del firewall
4. Configurare il server
4.1. Creazione di un utente ad uso VPN
4.2. Configurazione di un login autenticato
4.3. Configurare sudo
5. Configurazione del Client
5.1. Installare lo Script
5.2. Lo Script vpn-pppssh
6. Attivare il Link
6.1. Difficoltà e problemi
7. Integrazione della VPN nel proprio sistema
7.1. Connessione all'avvio del sistema
7.2. Connettersi attraverso Dial-Up
8. Inoltro tra subnet
8.1. Inoltro
8.2. Rendersi gateway
8.3. Routing
8.4. Mascheramento
8.5. E ora proviamolo
1. Introduzione
Le tecniche descritte in questo HOWTO utilizzano PPP per convertire i
pacchetti in un flusso di caratteri e SSH per crittarlo e trasmetterlo al
computer remoto. Alla maggior parte degli amministratori di sistema sono
familiari gli strumenti e i file di configurazione necessari per impostare
una VPN PPP-SSH.
Benché funzioni bene con carichi moderati su una connessione affidabile, si
fa presente che una VPN PPP-SSH è soggetta ad alcuni problemi di
scalabilità. Una lista di benefici è inclusa in la Sezione 2.1 e le
controindicazioni in la Sezione 2.2 così è possibile decidere autonomamente
se una VPN PPP-SSH è idonea alle proprie necessità.
_________________________________________________________________
1.1. Copyright
Copyright © 2001 Scott Bronson. This document may be distributed under the
terms set forth in the GNU Free Documentation License. A copy of this
license can be found at http://www.fsf.org/licenses/fdl.html.
_________________________________________________________________
1.2. Disclaimer
You use the information in this document entirely at your own risk. I
especially make no guarantees as to the legality or cryptographic strength
of the techniques described here. If you feel that you cannot take full
responsibility for your setup, then you need to put down this HOWTO and hire
one of the many excellent companies who provide accountable, professional
VPN service.
_________________________________________________________________
1.3. Credits
I took some notes as I adapted Bart Trojanowski's excellent instructions to
a newer version of PPP running on my Debian system. A few weeks later, I
converted the notes into SGML. Eventually, those evolved into this HOWTO.
Bart's instructions were based on Arpad Magosanyi's good but now fairly
dated VPN Mini-HOWTO. If you run into troubles and my document doesn't seem
to help, or if you're running an older version of the Linux kernel or PPP,
you'll definitely want to give his HOWTO a read.
_________________________________________________________________
2. Introduzione
2.1. Benefici di PPP-SSH
Dall'installazione di una Virtual Private Network PPP-SSH derivano svariati
benefici. È relativamente immediato, impiega strumenti comuni per cui non
necessitano modifiche e probabilmente non richiederà un riavvio del sistema
per la creazione del collegamento. Segue una lista più completa:
È facile da installare
Probabilmente non sarà necessario applicare patch al kernel o
compilarlo nuovamente, installare LILO, riavviare o eseguire
altre attività amministrative potenzialmente pericolose. PPP e
SSH sono inclusi nella maggior parte delle distribuzioni, e la
maggior parte dei kernel è preconfigurato per utilizzarli.
È facile da configurare
Non dovrebbe essere necessario modificare i file di
configurazione esistenti. Semplicemente basterà apportare
modifiche al file di script fornito più avanti in questo stesso
documento, che contiene tutte i dati di configurazione per la
VPN, e poi eseguirlo sulla macchina client. Qualsiasi
configurazione preesistente di PPP e SSH dovrebbe continuare a
funzionare correttamente.
Nessuna modifica al firewall
Se il protocollo SSH attraversa il firewall, allora anche PPP
su SSH lo attraverserà. (Se non si sta già impiegando SSH:
perché no? Ai giorni nostri è uno strumento quasi
indispensabile per gli amministratori di sistema.)
Non necessita di utilizzare il routing manuale, per evitare danni
pppd imposta automaticamente i parametri di routing. Inoltre,
nel caso in cui fosse necessario un routing particolarmente
complesso, è molto semplice inserire comandi personalizzati nel
file di script.
Non è necessario un indirizzo IP statico
Le VPN PPP-SSH non hanno difficoltà nel gestire indirizzi IP
dinamici. Il client deve essere in grado di trovare il server a
cui connettersi, chiaramente, quindi basta utilizzare un DNS.
Installare una VPN su una connessione dialup non presenta
problemi.
È semplice creare Tunnel Multipli
Impostare tunnel multipli verso un unico computer è semplice.
Occorre semplicemente assicurarsi che gli indirizzi IP delle
interfacce di rete del tunnel siano distinti.
_________________________________________________________________
2.2. Inconvenienti del PPP-SSH
Questo tipo di VPN presenta qualche difficoltà. Solitamente, se trascurato
non funziona molto bene. Se siete alla ricerca di VPN efficienti che una
volta configurate possono essere dimenticate, probabilmente troverete
PPP-SSH leggermente frustrante. Alcune alternative sono descritte in la
Sezione 2.4.
Provare a gestire una connessione TCP
Nel caso in cui la connessione TCP SSH venisse interrotta per
qualsiasi ragione, la VPN cesserebbe di funzionare così come
tutti i tunnel delle connessioni TCP. Se avete un collegamento
poco affidabile (cioè è difficile effettuare il download di più
di poche decine di megabyte in una volta sola) dovrete
riavviare la VPN molto spesso.
Inviare pacchetti IP tramite stream TCP
Il protocollo TCP consiste di flussi di dati costruiti sui
pacchetti IP. Tentando successivamente di inviare i pacchetti
IP sullo stream TCP (come si vorrebbe fare), il conflitto fra i
due protocolli diventa evidente. Nella maggior parte dei casi,
si manifesta attraverso strani ritardi, perdita di
informazioni, e variazioni anomale. A volte si potrebbero
manifestare problemi durante il caricamento, altre in quasi
assenza di traffico. A parte cambiare l'intero modello OSI
(improponibile), non c'è molto altro che si può fare a
riguardo.
Tendenza alla saturazione della banda
Per qualche motivo, quando il carico della rete aumenta, una
connessione TCP ridiretta nel tunnel tende a saturare tutta la
banda disponibile mentre le altre vengono ignorate. Questo
porta a timeout e perdita di connessioni. Teoricamente, questo
problema potrebbe essere risolto.
Non si può avere la certezza della perdita della connessione
I keepalive sono piccoli pacchetti inviati per comunicare
all'altra macchina che la connessione è ancora esistente. Se il
carico della rete diventa troppo elevato, i keepalive saranno
ritardati. L'altra macchina assumerà erroneamente che la
connessione sia stata interrotta e chiuderà il proprio lato
della connessione.
Senza keepalive, tuttavia, non c'è modo per nessuna delle due
macchine di comunicare che la connessione è stata interrotta.
Quando una macchina tenta di ripristinare la connessione e
l'altra pensa che questo sia già stato fatto, sorgerà la
confusione. Molto spesso il risultato è che si vedono
molteplici dispositivi per la connessione ppp, route duplicate,
e tunnel che apparentemente sono attivi ma che perdono tutti i
pacchetti. Un uso indiscriminato di "killall -9 pppd"
solitamente riporta le cose a posto. Uno script di avvio più
intelligente probabilmente potrebbe migliorare la situazione.
Troppe connessioni simultanee provocano problemi
Quando uso una normale connessione PPP tramite un modem 56K e
Postfix apre più di 10 connessioni per inviare la posta, tutto
funziona bene. Però, tentando la stessa operazione su una VPN
con tunnel su una connessione DSL molto più veloce, si verifica
uno stallo. Il tempo di ping si alza vertiginosamente (2 minuti
e oltre), il traffico si riduce per un momento, quindi si
interrompe completamente. L'unico modo per ristabilire la
funzionalità della rete è riavviare il tunnel. Non sono sicuro
che questo sia un bug o una limitazione intrinseca. Ridurre il
numero di connessioni utilizzate da Postfix per inviare la
posta in uscita risolve il problema nel mio caso...
Grande overhead e grande latenza
Il tempo di ping sulla mia connessione a 56K è solitamente
nell'ordine di 130-170 ms. Tuttavia, il tempo di ping su una
VPN PPP-SSH avviata sulla stessa connessione è nell'ordine di
300-330 ms. Utilizzare la compressione PPP può aiutare
abbastanza nel caso in cui si stiano trasmettendo dati
comprimibili. Ad esempio, le email sono comprimibili, mentre i
file Vorbis no.
_________________________________________________________________
2.3. Letture Consigliate
FAQ VPN
La VPN FAQ su http://kubarb.phsx.ukans.edu/~tbird/vpn/FAQ.html
è veramente un'ottima risorsa. È completa, ragionevolmente
aggiornata, e non ha paura di esprimere un'opinione.
Linux Kernel HOWTO
Se il kernel non dispone delle capacità di PPP e IP Forwarding,
il Linux Kernel HOWTO spiega come ricompilare un kernel per
aggiungerle. Inoltre spiega come inserire e togliere il modulo
PPP dal kernel.
PPP HOWTO
Spiega come installare e configurare il demone PPP se la
distribuzione non lo fa automaticamente. Inoltre contiene
un'ottima sezione che spiega come collegare due reti attraverso
PPP. Questo è esattamente quello che stiamo facendo, eccetto
per il fatto che stiamo aggiungendo il supporto per la
crittazione. Può essere reperito in
http://www.linuxdoc.org/HOWTO/PPP-HOWTO/index.html.
SSH HOWTO
Spero che esista un SSH HOWTO! Per adesso, la documentazione
contenuta nella propria distribuzione dovrebbe essere un buon
inizio. Si può anche visitare il sito web di OpenSSH OpenSSH
web site.
Documentazione per il networking
Se non si è molto abili con il networking, si può consultare la
guida a Linux Network Administrators . È un'eccellente
introduzione ai principali concetti che verranno utilizzati in
seguito. Si può inoltre trovare il Linux Networking HOWTO
presso
http://www.linuxdoc.org/HOWTO/Networking-Overview-HOWTO.html,
che è un'utile introduzione, specialmente per le sezioni su
TCP/IP, PPP, e sul tunneling.
_________________________________________________________________
2.4. Alternative
Ora nel mondo ci sono molte tecnologie VPN. Se PPP-SSH non soddisfa le
necessità, si può consultare uno dei seguenti pacchetti.
ipsec
ipsec descrive un insieme di protocolli di basso-livello, ESP e
AH, per eseguire l'autenticazione e crittazione a livello dei
pacchetti. Impiega inoltre un protocollo di alto-livello, IKE,
per negoziare parametri di connessione e scambiare chiavi di
crittazione.
FreeS/WAN è probabilmente il migliore Linux ipsec implementato
oggi. Può risultare molto difficile installarlo, specialmente
per chi non ha molta familiarità con il networking, tuttavia è
molto stabile una volta configurato. Si può saperne di più in
FreeS/WAN home page.
Un'altra efficiente e libera implementazione di ipsec è
Cerberus. Sfortunatamente, l'Istituto Nazionale di Standard e
Tecnologie (NIST) distribuisce Cerberus solo a cittadini
statunitensi e canadesi che attualmente vivono negli Stati
Uniti o in Canada. Perciò, a seconda della persona che lo
richiede, diventa moderatamente difficile o effettivamente
impossibile ottenere Cerberus.
PPTP
PPTP (Point-to-Point Tunnelling Protocol) è un protocollo VPN
sviluppato da Microsoft RFC2637. È una tecnologia molto diffusa
e di facile comprensione e ha molte implementazioni mature su
tutte le piattaforme computer comunemente usate. Comunque PPTP
è generalmente considerato un protocollo con una sicurezza
alquanto debole.
Probabilmente la migliore implementazione di Linux PPTP è
PoPToP, che si può trovare presso http://poptop.lineo.com/.
CIPE
CIPE è un protocollo di Olaf Titz che incapsula il traffico IP
in pacchetti UDP. Esso ha sia una versione Linux che una
versione Windows. Non l'ho ancora utilizzato, ma è in pieno
sviluppo e sembra essere molto promettente. Per ulteriori
informazioni, CIPE-MASQ Mini-HOWTO è una lettura concisa ma
piena di informazioni.
_________________________________________________________________
3. Installazione del Software
3.1. Terminologia
Poiché l'installazione di VPN assomiglia molto a una transazione
client-server, mi servirò di questa terminologia per dare un nome al
computer alla fine di ogni passaggio:
Server
È un computer che aspetta passivamente l'arrivo di richieste di
connessione VPN. Fuunziona completamente incustodito.
Client
È un computer che inizializza le richieste di connessione,
chiedendo al Server di creare una VPN.
_________________________________________________________________
3.2. Requisiti
* Nel kernel deve essere presente, compilato, il supporto a TCP/IP e
PPP. Quasi tutti le distribuzioni includono direttamente il
supporto a PPP. Se la vostra non lo include, o se state usando un
kernel particlare, includerò ulteriori dettagli a riguardo,in la
Sezione 3.4.
* Bisogna installare il demone pppd. Questo probabilmente è incluso
nella vostra distribuzione. Io sto usando ppp-2.3.11. Le versioni
successive dovrebbero funzionare bene, come anche le versioni
precedenti, finché supportano le opzioni "pty". Non è necessario
installare chat o alcun altro strumento destinato a funzionare
insieme a PPP: è sufficiente avere pppd.
* La macchina client deve avere installato il client ssh. Esistono
svariate versioni di ssh in circolazione, ma dovrebbero funzionare
tutte quante. Per la redazione di questo HOWTO è stato utilizzato
OpenSSH per OpenBSD, versione 2.2.0p1.
* La macchina server deve disporre del demone sshd per fare fronte
alle richieste del client. OpenSSH comprende un demone ssh molto
buono.
* Per ultima cosa potrebbe essere richiesto di installare sudo sul
server. È possibile trovare ulteriori informazioni riguardo a sudo
in Linux Administrator's Security Guide, nella sezione Tool
Amministrativi e in Linux Security HOWTO,nella sezione Root
Security. Inoltre potrebbe essere di aiuto leggere sudo's home
page.
_________________________________________________________________
3.3. Progettazione
Per impostare un collegamento PPP-SSH occorre specificare i seguenti
parametri:
Hostname del server
Qual'è lo hostname o l'indirizzo IP del server VPN?
Utente del server VPN
Sul vostro server, con quale nome utente il software per la VPN
funzionerà? Questo HOWTO comprende istruzioni riguardanti la
creazione di un utente di nome "vpn" specificamente per questo
scopo. Il software non deve essere eseguito da root! Per
esigenze di sicurezza e di registrazione degli accessi, si
dovrebbe usare un account riservato.
Indirizzo IP dell'interfaccia del server
La VPN PPP-SSH necessita di interfacce di rete dedicate sia sul
client che sul server. L'interfaccia sarà pppN, dove N è il
numero della prima interfaccia ppp inutilizzata (per esempio
sarà ppp1 se si sta già utilizzando ppp0 per una chiamata con
il modem).
Sarà necessario specificare l'indirizzo IP per l'interfaccia
sul server. Questo indirizzo sarà visibile solo da client e
server (e dalle macchine sulle subnet a cui il client o il
server potrebbero inoltrare i pacchetti de-mascherati).
Se non è noto l'indirizzo IP da specificare, si legga il
capitolo 2.2 in Linux Network Administrators Guide e si guardi
in particolare alla tabella 2-1. Per esempio, 192.168.0.1 è una
buona scelta.
Indirizzo IP dell'interfaccia del client.
È necessario impostare l'indirizzo IP dell'interfaccia sul
client. Deve ovviamente apartenere alla stessa rete
dell'indirizzo del server. Non deve essere in conflitto con
altre reti dal lato del client e non può essere lo stesso
indirizzo IP dell'interfaccia di rete del server. Se è stato
scelto 192.168.0.1 per la precedente risposta, probabilmente
qui si dovrebbe usare 192.168.0.2.
La mia configurazione è:
SERVER_HOSTNAME = eldivino.domain.com
SERVER_USERNAME = vpn
SERVER_IFIPADDR = 192.168.3.1
CLIENT_IFIPADDR = 192.168.3.2
_________________________________________________________________
3.4. Configurare PPP
Il codice per PPP può essere compilato nel kernel stesso o può essere
presente in moduli caricabili nel kernel. Se è stato compilato nel kernel,
si può saltare al passo successivo: non occorre altro. Invece, se si sta
caricando PPP sotto forma di moduli, bisogna assicurarsi che vengano
caricati in modo appropriato.
Si può controllare se ppp è incluso nella lista di tutti i moduli
correntemente caricati eseguendo lsmod. Si ricordi di controllare che il
modulo PPP sia caricato sia sul client che sul server.
server$ /sbin/lsmod
Module Size Used by
ppp 20780 0 (unused)
slhc 4376 0 [ppp]
3c59x 21636 1
client$ lsmod
Module Size Used by
ppp_deflate 40308 0 (autoclean)
bsd_comp 4076 0 (autoclean)
ppp 20844 2 [ppp_deflate bsd_comp]
slhc 4376 1 [ppp]
Se si è sicuri di avere compilato ppp come modulo, ma non è caricato
nel kernel, si provi a caricarlo con modprobe.
# modprobe ppp
Se modprobe non ritorna alcun errore, si controlli di nuovo lsmod: a
questo punto ppp dovrebbe essere presente nella lista. Se è così,
significa che il modulo ppp non viene caricato al momento dell'avvio.
Ciò non costituisce un problema se si ha intenzione di eseguire il
demone per il kernel, poiché i moduli PPP verranno caricati su
richiesta. Se non si intende fare così, si renderà necessario caricare
i moduli al momento dell'avvio inserendo una riga contenente la sola
parola "ppp" nel file /etc/modules.
Si veda Linux Kernel HOWTO per maggiori informazioni al riguardo.
_________________________________________________________________
3.5. Permettere a SSH l'attraversamento del firewall
Il traffico di rete tra le due macchine (risultante dal tunnel,
naturalmente) sarà basato sul solo protocollo SSH.
SSH impiega solo flussi TCP, nessun pacchetto UDP o ICMP. Il server ssh
(sshd) normalmente è in ascolto sulla porta 22. Il client (dato che useremo
il flag -P) utilizzerà solo le porte non privilegiate dalla 1024 alla 65535.
Questa descrizione dovrebbe fornire informazioni sufficienti per potere
impostare un firewall.
Per esempio, ecco i comandi per ipchains necessari a permettere le
connessioni ssh verso il server. Consentiremo di passare alle connessioni
dirette alla porta 22 sulla macchina locale e provenienti da qualsiasi porta
sulla macchina remota. SI sostituisca eth0 con l'interfaccia di rete su cui
viaggerà il traffico ssh e $IPADDR con l'indirizzo IP di quella interfaccia.
ipchains -A input -i eth0 -p tcp -d $IPADDR 22 -j ACCEPT
ipchains -A output -i eth0 -p tcp ! -y -s $IPADDR 22 -j ACCEPT
I comandi seguenti sono necessari per impostare il firewall sulla
macchina client. Non sono permesse le connessioni ssh in ingresso,
mentre viene consentito al protocollo di passare tra la porta 22 della
macchina remota e le porte non privilegiate su questa macchina. Ancora
una volta, si sostituisca a eth0 l'interfaccia che trasporterà il
traffico ssh, e a $IPADDR l'indirizzo IP di tale interfaccia.
ipchains -A input -i eth0 -p tcp ! -y --source-port 22 -d $IPADDR 1024:65535 -
j ACCEPT
ipchains -A output -i eth0 -p tcp -s $IPADDR 1024:65535 --destination-port 22 -
j ACCEPT
_________________________________________________________________
4. Configurare il server
È necessario configurare il server affinché risponda alle richieste del
client per creare il tunnel.
_________________________________________________________________
4.1. Creazione di un utente ad uso VPN
Le richieste di VPN con SSH devono essere dirette ad un particolare utente
sul server. Per sicurezza e tracciabilità, si raccomanda di riservare un
utente per le sole risposte alle richieste di VPN. Con i passi seguenti si
creerà un utente di sistema con il nome "vpn" per questo scopo.
1. Come prima cosa, si crei l'account utente. Esistono account con ID
in due intervalli: quello di sistema (solitamente tra 100 e 999) e
quello degli utenti comuni (1000 e oltre). "--system" comunica a
adduser di aggiungere l'utente nell'intervallo di sistema e di
assegnargli /bin/false come shell di login. "--group" sta a
indicare di creare un gruppo con lo stesso nome dell'utente, e di
aggiungervi l'utente stesso.
server# adduser --sytem --group vpn
2. Dato che l'utente vpn necessita di effettuare il login via ssh, si
cambi la shell di vpn da /bin/false a /bin/bash nel file
/etc/passwd. È possibile modificare /etc/passwd utilizzando vi o
qualsiasi altro editor di testo.
3. Si crei una password per l'utente vpn. Può e dovrebbe essere molto
complessa, dato che verrà digitata solo alcune volte mentre si
imposta la VPN. Dopo non sarà più necessario digitarla di nuovo.
server# passwd vpn
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
4. Ora si provi a collegarsi al server per assicurarsi di avere
creato l'account correttamente.
client% ssh eldivino.domain.com -l vpn
vpn@eldivino's password:
Linux eldivino 2.2.19 #6 Mon Jun 4 10:32:19 PDT 2001 i686 unknown
No mail.
vpn@eldivino:~$
Potrebbe essere necessario un po' di tempo a ssh per collegarsi se
non si è impostato correttamente il DNS inverso. Si può correggere
tale problema in qualsiasi momento. Esso causerà soltanto un
ritardo nell'avvio della VPN: non le impedirà di funzionare.
Se il programma ssh rimane bloccato, allora il protocollo ssh
viene probabilmente scartato da un firewall tra le due macchine.
Si veda nuovamente la sezione la Sezione 3.5.
_________________________________________________________________
4.2. Configurazione di un login autenticato
Sarebbe scomodo dovere digitare una password ogni volta che si desidera
avviare il collegamento VPN, quindi imposteremo l'autenticazione tramite RSA
di SSH. Si salti questa sezione se non si considera impraticabile la
soluzione di digitare una password ogni volta.
1. È necessario assicurarsi che l'account root sulla macchina client
abbia una chiave pubblica nella propria home directory
(~/root/.ssh/identity.pub). Se tale file non esiste è necessario
crearlo. Come utente root si esegua ssh-keygen:
# ssh-keygen
Generating public/private rsa1 key pair.
Enter file in which to save the key (/root/.ssh/identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/identity.
Your public key has been saved in /root/.ssh/identity.pub.
The key fingerprint is:
15:61:57:7e:5c:26:91:09:5c:e6:10:b7:a1:74:bd:25 root@paradis
2. Ora, si copi identity.pub al posto del file authorized_keys
nell'account vpn sul server. Quasi sicuramente sarà da creare
eseguendo i seguenti comandi sul server.
server# cd ~vpn
server# mkdir .ssh
server# chown root.vpn .ssh
server# chmod 755 .ssh
server# cd .ssh
Si copi il file /root/.ssh/identity.pub sul client nella posizione
~vpn/.ssh/authorized_keys (è costituito da una sola riga). È
possibile aggiungere altre linee ad authorized_keys, una per ogni
client, se si desidera consentire più connessioni da client
diversi.
server# chown root.vpn authorized_keys
server# chmod 644 authorized_keys
3. Diventando root sul client si provi a collegarsi con SSH al
server. Si può utilizzare o meno l'opzione -P, a seconda di come è
configurato il firewall sul client. Se la porta 22 è bloccata sul
client (che non è una brutta idea se si ha un server ssh in
esecuzione), l'opzione -P dice a ssh di usare una porta non
privilegiata anche se sta eseguendo come utente privilegiato.
client# ssh -P eldivino.domain.com -l vpn
Linux eldivino 2.2.19 #6 Mon Jun 4 11:03:22 PDT 2001 i686 unknown
No mail.
vpn@eldivino:~$
In questo modo ci si è appena autenticati con RSA. Bisogna tenere
segreta la propria chiave privata (~root/.ssh/identity file sulla
macchina client). Chiunque abbia accesso a questo file può
collegarsi all'account vpn sul server.
_________________________________________________________________
4.3. Configurare sudo
pppd richiede di essere avviato come root. Comunque, sul server, stiamo
avviando tutto come utente "vpn". Come può l'utente vpn eseguire pppd?
Ci sono molti modi di risolvere questo problema. Uno è utilizzare il bit
suid, ed impostare i permessi per i gruppi. Però questo può condurre a
confusione e difficoltà nell'amministrare agevolmente, creando falle non
intenzionali nella sicurezza del sistema. Personalmente, ho trovato che
l'utility sudo sia la soluzione migliore.
sudo dà agli utenti ordinari i privilegi del superutente, ma solo per una
serie molto limitata di comandi. L'amministratore di sistema può decidere
quali comandi sono consentiti e quanto log produrre. Nel nostro caso,
vogliamo consentire all'utente "vpn" di avviare pppd con i privilegi di
superutente, ma non vogliamo consentirgli di fare altro.
1. Occorre editare il file di configurazione di sudo, /etc/sudoers.
Per impostare le restrizioni adeguate, in modo da prevenire
inconvenienti e corse critiche, si usi il comando visudo che
permette di editare /etc/sudoers. Chi non ha familiarità con vi,
può consultare VIM HOWTO.
server# visudo
Aggiungere queste due righe alla fine del file:
Cmnd_Alias VPN=/usr/sbin/pppd
vpn ALL=NOPASSWD: VPN
2. Ora, occorre verificare che sudo sia configurato correttamente.
Per farlo basta provare a lanciare, come utente "vpn", pppd
utilizzando sudo:
server# su - vpn
server$ sudo /usr/sbin/pppd noauth
~9}#ÀZ}!}!} }9}"}k} }r} }'}%}zt2-·}'}"}
Se si ottiene un mucchio di spazzatura PPP sullo schermo (come
l'ultima linea riportata sopra), questo è un risultato positivo.
Significa che l'utente vpn è autorizzato a lanciare pppd. Ora è
possibile andare su un altro terminale e terminare il processo,
oppure si può aspettare che pppd termini l'esecuzione. Dovrebbe
smettere di provare a connettersi dopo circa 30 secondi.
Invece, se si ottiene "bash: /usr/sbin/pppd: Permission denied" o
qualche altro tipo di errore, o chiede una password, allora sudo
probabilmente non funziona. Occorrerà cercare di trovare cosa non
va. Si verifichi che pppd sia in /usr/sbin e che il file sudoers
sia stato compilato correttamente.
_________________________________________________________________
5. Configurazione del Client
Se ppp e ssh sono configurate sul client, e il server è pronto per la
connessione, allora tutto quello che dovete fare sul client è di creare lo
script per attivare il link.
_________________________________________________________________
5.1. Installare lo Script
La connessione VPN può essere inizializzata utilizzando il seguente script
vpn-pppssh.
1. Salvate questo file sul client (non è importante dove, ad esempio
/usr/local/bin/vpn-pppssh) e rendetelo eseguibile attraverso il
comando "chmod a+x vpn-pppssh".
2. Impostate i campi all'inizio del file con i valori che avete
deciso in la Sezione 3.3.
Ricordate che viene eseguito attraverso una shell bash, per cui
dovete evitare di inserire spazi tra i segni di uguale, utilizzate
le virgolette dove necessario e i metacaratteri di escape come $.
Per maggiori dettagli leggete BASH Programming Introduction o
Advanced Bash Scripting Guide.
SERVER_HOSTNAME=eldivino.domain.com
SERVER_USERNAME=vpn
SERVER_IFIPADDR=192.168.3.2
CLIENT_IFIPADDR=192.168.3.1
Eseguite "vpn-pppssh config" per visualizzare una lista delle
possibili configurazioni. In questo modo potete essere certi che
le vostre impostazioni siano state interpretate correttamente.
_________________________________________________________________
5.2. Lo Script vpn-pppssh
Qui trovate lo script vpn-pppssh. È composto da una sola linea di codice
(quella che comincia con "PPPD" nel paragrafo iniziale). Tutto il resto del
file è solamente codice di supporto, non indispensabile.
#!/bin/sh
# /usr/local/bin/vpn-pppssh
#
# This script initiates a ppp-ssh vpn connection.
# see the VPN PPP-SSH HOWTO on http://www.linuxdoc.org for more information.
#
# revision history:
# 1.6 11-Nov-1996 miquels@cistron.nl
# 1.7 20-Dec-1999 bart@jukie.net
# 2.0 16-May-2001 bronson@trestle.com
#
# You will need to change these variables...
#
# The host name or IP address of the SSH server that we are
# sending the connection request to:
SERVER_HOSTNAME=eldivino.domain.com
# The username on the VPN server that will run the tunnel.
# For security reasons, this should NOT be root. (Any user
# that can use PPP can intitiate the connection on the client)
SERVER_USERNAME=vpn
# The VPN network interface on the server should use this address:
SERVER_IFIPADDR=192.168.3.2
# ...and on the client, this address:
CLIENT_IFIPADDR=192.168.3.1
# This tells ssh to use unprivileged high ports, even though it's
# running as root. This way, you don't have to punch custom holes
# through your firewall.
LOCAL_SSH_OPTS="-P"
#
# The rest of this file should not need to be changed.
#
PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/bin/X11/:
#
# required commands...
#
PPPD=/usr/sbin/pppd
SSH=/usr/bin/ssh
if ! test -f $PPPD ; then echo "can't find $PPPD"; exit 3; fi
if ! test -f $SSH ; then echo "can't find $SSH"; exit 4; fi
case "$1" in
start)
# echo -n "Starting vpn to $SERVER_HOSTNAME: "
${PPPD} updetach noauth passive pty "${SSH} ${LOCAL_SSH_OPTS}
${SERVER_HOSTNAME} -l${SERVER_USERNAME} -o Batchmode=yes sudo ${PPPD}
nodetach notty noauth" ipparam vpn ${CLIENT_IFIPADDR}:${SERVER_IFIPADDR}
# echo "connected."
;;
stop)
# echo -n "Stopping vpn to $SERVER_HOSTNAME: "
PID=`ps ax | grep "${SSH} ${LOCAL_SSH_OPTS} ${SERVER_HOSTNAME}
-l${SERVER_USERNAME} -o" | grep -v ' passive ' | grep -v 'grep ' | awk
'{print $1}'`
if [ "${PID}" != "" ]; then
kill $PID
echo "disconnected."
else
echo "Failed to find PID for the connection"
fi
;;
config)
echo "SERVER_HOSTNAME=$SERVER_HOSTNAME"
echo "SERVER_USERNAME=$SERVER_USERNAME"
echo "SERVER_IFIPADDR=$SERVER_IFIPADDR"
echo "CLIENT_IFIPADDR=$CLIENT_IFIPADDR"
;;
*)
echo "Usage: vpn {start|stop|config}"
exit 1
;;
esac
exit 0
_________________________________________________________________
6. Attivare il Link
Adesso tutto dovrebbe essere impostato. Fate un respiro profondo e provate
ad attivare il collegamento.
1. Diventate root sulla macchina client ed eseguite lo script
vpn-pppssh.
client# /usr/local/bin/vpn-pppssh start
2. Ci metterà un momento a connettersi, poi dovrebbe visualizzare
qualcosa di simile a
Using interface ppp1
Connect: ppp1 <--> /dev/pts/1
local IP address 192.168.3.1
remote IP address 192.168.3.2
3. Ha funzionato? Prima di tutto provate a inviare un ping
all'interfaccia VPN del client:
client$ ping 192.168.3.2
4. Se ha funzionato, potete raggiungere l'interfaccia del client. Non
entusiasmatevi troppo ancora: questa era la parte facile. Adesso,
provate a inviare un ping verso l'interfaccia VPN del server:
client$ ping 192.168.3.1
Se vi risponde, allora congratulazioni! La vostra PPP-SSH VPN
sembra essere attiva. I pacchetti stanno transitando con successo
in entrambe le direzioni. Ora potreste provare a effettuare un
login nel client e a inviare un ping al client dal server, ma
arrivati fino a questo punto è praticamente sicuro che funzioni.
Potete interrompere VPN attraverso "vpn-pppssh stop".
Adesso che il tunnel funziona, potete integrarlo all'interno del
vostro sistema in modo che si attivi automaticamente come descritto in
la Sezione 7. Inoltre, se volete inviare dei pacchetti da un'intera
sottorete attraverso il link (piuttosto che solo i pacchetti creati
dal client e dal server come avete configurato adesso) leggete la
Sezione 8.
_________________________________________________________________
6.1. Difficoltà e problemi
Lo script stesso è abbastanza semplice. L'intero sistema, comunque,
coinvolge molte piccole parti. Se anche solo una di esse non è configurata,
può impedire che la vostra VPN funzioni, senza nemmeno messaggi che
spieghino il perché. Questa è una lista di cose da controllare se ci si
trova in difficoltà:
* Fare un doppio o triplo controllo sui propri parametri di rete. Si
provi a lanciare "vpn-pppssh config" per assicurarsi che la
configurazione sia corretta e che la shell non abbia alterato
alcuni valori.
* Ripercorrere ogni passo e assicurarsi che tutto sia a posto.
* Provare temporaneamente a spegnere qualsiasi firewall sul client,
sul server, e sulle macchine intermedie in modo da vedere se
qualcuno di questi sta bloccando il traffico (è improbabile che
sia questa la causa se si può utilizzare SSH tra le due macchine).
* Assicurarsi che le proprie route siano corrette. Si può avere una
lista delle proprie route usando "route -n". Visitare Linux
Network Administrators Guide e
http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html per maggiori
informazioni.
_________________________________________________________________
6.1.1. sendto: Operation not permitted
Quando si cerca di fare ping alle interfacce VPN, se si ottiene l'errore
"sendto: Operation not permitted", si sta probabilmente incappando in un
firewall sulla macchina locale che scarta i pacchetti prima che giungano
alla interfaccia di rete. Il firewall deve consentire il traffico SSH sulla
rete normale e deve fare passare tutto il traffico sull'interfacia VPN.
I comandi per ipchains che creano una apertura nel firewall per
l'interfaccia PPP assomiglieranno ai seguenti:
ipchains -I input 1 -i ppp1 -s 192.168.3.0/24 -j ACCEPT
ipchains -I output 1 -i ppp1 -d 192.168.3.0/24 -j ACCEPT
Ovviamente, ppp1 deve essere l'interfaccia di rete della VPN PPP-SSH,
e l'indirizzo IP deve coincidere con l'indirizzo dell'interfaccia
locale. Occore controllare che il traffico sia consentito sia sul
client che sul server.
Consultare Linux Firewall HOWTO, IPChains HOWTO per il kernel 2.2, o
la documentazione di iptables per il kernel 2.4.
_________________________________________________________________
7. Integrazione della VPN nel proprio sistema
Avviare il collegamento manualmente risulta laborioso dopo un po'.
Probabilmente si desidera che la VPN venga creata all'avvio del computer o
quando si instaura una connessione dial-up.
_________________________________________________________________
7.1. Connessione all'avvio del sistema
È piuttosto semplice fare in modo che questo script venga eseguito al
momento dell'avvio. Considereremo di impiegare la comune configurazione
System V initscript. Se non è questo il caso, si dovrà individuare da soli
un modo diverso per integrare lo script nel proprio sistema.
1. Si copi o si crei un link simbolico di vpn-pppssh in /etc/init.d.
cp /usr/local/bin/vpn-pppssh /etc/init.d/vpn-pppssh
2. Togliere il segno di commento alle righe echo presenti nelle
funzioni start e stop dello script vpn-pppssh per abilitare i
messaggi "Starting" e "done" all'avvio.
3. Inserire "> /dev/null 2>&1" dopo la linea che inizia con "${PPPD}"
nella sezione start dello script. Questo impedisce che i lunghi
messaggi di pppd rendano confusa la schermata di avvio. È
possibile anche ridirigere i messaggi di pppd (che possono
includere informazioni sugli errori) in un file di log o, se non
si hanno pretese di tipo estetico, si può ignorarli e lasciare lo
schermo confuso.
4. A questo punto si può creare semplicemente un link al proprio
script in ciascuno dei sei runlevel.
client$ ln -s /etc/init.d/vpn-pppssh /etc/rc0.d/K10vpn-pppssh
client$ ln -s /etc/init.d/vpn-pppssh /etc/rc1.d/K10vpn-pppssh
client$ ln -s /etc/init.d/vpn-pppssh /etc/rc2.d/S99vpn-pppssh
client$ ln -s /etc/init.d/vpn-pppssh /etc/rc3.d/S99vpn-pppssh
client$ ln -s /etc/init.d/vpn-pppssh /etc/rc4.d/S99vpn-pppssh
client$ ln -s /etc/init.d/vpn-pppssh /etc/rc5.d/S99vpn-pppssh
client$ ln -s /etc/init.d/vpn-pppssh /etc/rc6.d/K10vpn-pppssh
Adesso, quando riavviate la macchina, la vpn dovrebbe attivarsi verso
la fine del processo di boot. Quando viene raggiunto questo script, la
macchina attenderà che la VPN sia attiva prima di continuare il boot.
Se questo è un problema, potete scrivere il vostro script
/etc/init.d/vpn-pppssh che chiama lo script /usr/local/bin/vpn-pppssh
in background. Il collegamento sarà attivo non appena la macchina avrà
finito il boot.
Per attivare e disattivare manualmente il collegamento, basta eseguire
lo script vpn-pppssh direttamente da /etc/init.d:
client$ /etc/init.d/vpn-pppssh stop
client$ /etc/init.d/vpn-pppssh start
_________________________________________________________________
7.2. Connettersi attraverso Dial-Up
Se vi state collegando ad internet tramite PPP, potete attivare la VPN ogni
volta che attivate la connessione. Questo non è difficile, ma richiede una
versione recente di pppd, che supporti sia l'opzione ipparam che le
directory ip-up.d e ip-down.d.
1. Create il file "vpn-up" in /etc/ppp/ip-up.d:
#!/bin/sh
if [ "$PPP_IPPARAM" = "vpn" ]; then
# Don't bring up the vpn if we're bringing up the vpn.
exit 0
fi
/usr/local/bin/vpn start
L'espressione if gestisce la ri-invocazione. Se si sta creando il
normale collegamento PPP, si desidera che anche la VPN venga
avviata. Ma la VPN stessa è un collegamento PPP! Se non ne venisse
tenuto conto, PPP verrebbe istanziato ricorsivamente fino a
condurre la macchina ad un arresto.
Il segreto sta nel parametro "ipparm vpn" all'interno dello script
vpn-pppssh. Esso imposta la variabile IPPARAM per la corrente
invocazione di "vpn", che poi verrà controllata nello script di
avvio. Se è impostata a vpn, sappiamo di avere già l'avvio della
vpn in corso, quindi si esce senza riportare errori. In caso
contrario si esegue l'avvio.
2. Se si desidera creare una apertura nel proprio firewall
appositamente per l'avvio della VPN, è sufficiente creare un file
/etc/ppp/ip-up.d/vpn-fw con il seguente contenuto. Tutte le
variabili della shell indicate vengono fornite da pppd, quindi
dovrebbe essere possibile utilizzare questo script senza
modifiche.
#!/bin/sh
# Punch a hole in the firewall for the VPN
if [ "$PPP_IPPARAM" = "vpn" ]; then
ipchains -I input 1 -i $PPP_IFACE -s $PPP_REMOTE -d $PPP_LOCAL -j ACCEP
T
ipchains -I output 1 -i $PPP_IFACE -s $PPP_LOCAL -d $PPP_REMOTE -j ACCE
PT
fi
3. Si crei il file "vpn-down" in /etc/ppp/ip-down.d/vpn-pppssh:
#!/bin/sh
if [ "$PPP_IPPARAM" = "vpn" ]; then
# Don't bring down the VPN if we're bringing down the vpn.
exit 0
fi
/usr/local/bin/vpn stop
Tutti gli script citati devono essere resi eseguibili (chmod a+x
/etc/ppp/ip-up.d/vpn-pppssh). A questo punto, quando si avvia il
collegamento PPP, contemporaneamente dovrebbe essere avviata la VPN.
Al momento di arrestarlo la VPN scomparirà. È facilissimo.
_________________________________________________________________
8. Inoltro tra subnet
La lettura di questa sezione è necesssaria solo se si sta cercando di
connettere intere reti, non solo singoli host. Si assume che il tunnel da
host a host sia già funzionante, al punto che computer client e server
possano scambiarsi dei ping senza problemi. A questo punto è necesario
consentire anche alle reti connesse alle macchine client e server di
utilizzare il tunnel.
_________________________________________________________________
8.1. Inoltro
Come prima cosa, ci si deve assicurare che ai pacchetti venga consentito
l'inoltro attraverso le interfacce di rete. Si può attivare questa opzione
attraverso l'interfaccia di configurazione proc. È opportuno fare ciò al
momento dell'avvio, ma si può anche inserirlo nello script vpn-pppssh, o
perfino creare uno script nella directory /etc/init.d/ip-up.d (si veda la
Sezione 7.2).
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/conf/ppp1 (1) /forwarding
(1)
Ovviamente è necessario sostituire a ppp1 l'interfaccia
corretta (quella associata a SERVER_IFIPADDR o a
CLIENT_IFIPADDR, a seconda che si stia operando sul server o
sul client).
_________________________________________________________________
8.2. Rendersi gateway
Su tutti i computer della sottorete, si deve impostare l'host locale della
VPN come il gateway per tutte le reti situate dall'altra parte del tunnel.
Questo dice ai computer "Se avete pacchetti destinati all'estremo opposto
della VPN, inviateli all'host locale della VPN". Si tenga presente che se
l'host VPN è già il gateway predefinito di tutti i computer non occorre fare
altro: i pacchetti saranno inoltrati automaticamente.
Nell'esempio riportato sotto, il mio host VPN ha indirizzo IP 192.168.1.1
sulla rete locale e indirizzo IP 192.168.3.2 sulla rete VPN. Quest'ultima,
contenente le interfacce VPN del client, del server e di tutti i computer
sul lato opposto del collegamento, ha indirizzo 192.168.3.0/24. Qundi, su
ogni computer locale a cui si desidera consentire di inviare pacchetti
attraverso la VPN è necessario eseguire il seguente comando:
# route add -net 192.168.3.0 netmask 255.255.255.0 gw 192.168.1.1
Ora, qualsiasi pacchetto destinato alla rete 192.168.3.0/24 da questa
macchina verrà consegnato all'host 192.168.1.1 sulla rete locale per
l'inoltro attraverso la VPN.
_________________________________________________________________
8.3. Routing
Non dovrebbe essere necessario impostare un routing personalizzato: pppd si
occupa di tutto. Tuttavia, se trovate che pppd non soddisfi completamente i
vostri bisogni, i campi per personalizzare il routing si trovano all'interno
dello script vpn-pppssh. Per cambiare il routing sul client, eseguite
semplicemente route. Per cambiare il routing sul server utilizzate ssh,
mandando i comandi necessari. Qui potete trovare un esempio:
route add -net $NET1 gw $SERVER_IFIPADDR
ssh -o Batchmode=yes $SERVER_HOSTNAME -l$SERVER_USERNAME route add -net $NET2 g
w $CLIENT_IFIPADDR
_________________________________________________________________
8.4. Mascheramento
È persino possibile configurare uno o entrambi gli host per mascherare tutte
le connessioni attraverso il tunnel vpn. Consultare IP Masquerade HOWTO per
ulteriori dettagli.
# ipchains -A forward -i ppp1 -s 192.168.0.0/24 -j MASQ
_________________________________________________________________
8.5. E ora proviamolo
Questo dovrebbe essere tutto quello che serve per inviare pacchetti
all'altra macchina da una sottorete connessa al client o al server. La
vostra VPN PPP-SSH potrà lavorare silenziosamente e in maniera affidabile
negli anni a venire.