<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>VPN HOWTO: Implementazione </TITLE>
<LINK HREF="VPN-HOWTO-6.html" REL=next>
<LINK HREF="VPN-HOWTO-4.html" REL=previous>
<LINK HREF="VPN-HOWTO.html#toc5" REL=contents>
</HEAD>
<BODY>
<A HREF="VPN-HOWTO-6.html">Avanti</A>
<A HREF="VPN-HOWTO-4.html">Indietro</A>
<A HREF="VPN-HOWTO.html#toc5">Indice</A>
<HR>
<H2><A NAME="s5">5. Implementazione </A></H2>
<P>In questa sezione spiegherò passo passo come settare un sistema VPN.
Inizierò con il server, e poi mi muoverò sul client. Per una spiegazione
migliore farò un esempio dove ho inventato una situazione che dovrebbe
richiedere un paio di modi differenti di configurare una VPN.
<H2><A NAME="ss5.1">5.1 Pianificazione</A>
</H2>
<P>Immaginate di avere una società chiamata mycompany.com. Al nostro quartier
generale, usiamo il network 192.168.0.0, dividendo la classe B in 256 classi C
di network che permettono il routing. Abbiamo da configurare solamente due
piccoli uffici remoti, e vogliamo aggiungerli alla nostra rete. Vogliamo,
inoltre, permettere agli impiegati di lavorare da casa usando una linea
DSL e le connessioni cable modem al posto di fargli usare una connessione
dialup. Per iniziare, abbiamo bisongo di pianificare un pò le cose.
<P>Ho deciso che voglio dare ad ogni ufficio remoto un network in classe C
per permettergli di espanderlo se necessario. Così, riservo le sottoreti da
192.168.10.0 a 192.168.11.0. Decido, inoltre, che per gli utenti casalinghi
darò indirizzi IP sufficienti da non aver bisogno di farne il masquerading dal
lato server della VPN. Ogni client avrà un IP proprio interno. Così, ho
bisogno di riservare un'altra classe C per questo, diciamo 192.168.40.0. La
sola cosa che devo fare ora è aggiungere questi range al mio router.
Immaginate che la nostra società possegga un piccolo Cisco (192.168.254.254)
che gestisce tutto il traffico attraverso la nostra OC1. Configurando
l'instradamento sul Cisco in modo che il traffico diretto a queste reti
riservate vada sul nostro server VPN (192.168.40.254). Metterò il server VPN
nella rete degli utenti casalinghi per una ragione che diverrà chiara in
seguito. Chiamerò l'interfaccia esterna del server vpn.company.com, e quella
interna vpn-internal.mycompany.com.
<P>Per gli indirizzi esterni, non abbiamo bisogno di conoscerli. L'unica cosa
che si deve avere è il proprio indirizzo, fornito dal proprio ISP.
<H2><A NAME="ss5.2">5.2 Raccogliere gli strumenti</A>
</H2>
<P>Ora abbiamo bisogno di alcuni software, trova i seguenti programmi e
installali dove specificato.
<H3>Per il Server: </H3>
<P>
<UL>
<LI>pppd (versione 2.3 o superiore)</LI>
<LI>ssh (versione 1.2.26 o superiore)</LI>
</UL>
<H3>Per il Client: </H3>
<P>
<UL>
<LI>pppd (stessa versione del server)</LI>
<LI>ssh</LI>
<LI>
<A HREF="ftp://ftp.vein.hu/ssa/contrib/mag/pty-redir-0.1.tar.gz">pty-redir</A></LI>
</UL>
<H2><A NAME="ss5.3">5.3 Server: compilare il kernel </A>
</H2>
<P>Per iniziare avrai probabilmente bisogno di ricompilare il kernel per il
server. Devi essere sicuro che le seguenti opzioni del kernel siano attivate
in aggiunta alle opzioni di networking base e al resto che tu pensi possa
servirti. Se non hai mai ricompilato il kernel prima ad ora leggi
<A HREF="/HOWTO/Kernel-HOWTO.html">Kernel HOWTO</A>.
<P>
<P>Per i kernel 2.0:
<UL>
<LI>CONFIG_FIREWALL</LI>
<LI>CONFIG_IP_FORWARD</LI>
<LI>CONFIG_IP_FIREWALL</LI>
<LI>CONFIG_IP_ROUTER</LI>
<LI>CONFIG_PPP</LI>
</UL>
<P>Per i kernel 2.2:
<UL>
<LI>CONFIG_FIREWALL</LI>
<LI>CONFIG_IP_ADVANCED_ROUTER</LI>
<LI>CONFIG_IP_FIREWALL</LI>
<LI>CONFIG_IP_ROUTER</LI>
<LI>CONFIG_PPP</LI>
</UL>
<H2><A NAME="ss5.4">5.4 Server: Configurare la rete </A>
</H2>
<P>Se stai approntando un server che ha solo una scheda di rete, suggerisco
l'idea di acquistarne un'altra, e ricablare la tua rete. La cosa migliore per
tenere la tua rete privata è di usare le schede su reti fisicamente distinte.
Così se hai due schede di rete, avrai bisogno di sapere come configurarle
entrambe. Useremo eth0 per l'interfaccia esterna, e eth1 per l'interfaccia
interna.
<H3>Configurare le interfaccie di rete </H3>
<P>Per prima cosa configureremo l'interfaccia esterna del server. Dovresti
già sapere come fare, e probabilmente averlo già fatto. Se non lo hai ancora
fatto, ora è il momento. Se non sai come, vai a leggere l'url
<A HREF="/HOWTO/NET3-4-HOWTO.html">Networking HOWTO</A><P>Ora affrontiamo l'interfaccia interna. In accordo con gli indirizzi
scelti, l'interfaccia interna del server è 192.168.40.254. In questo modo
abbiamo configurato l'interfaccia.
<P>Per i kernel 2.0, usa le impostazioni seguenti:
<P>
<PRE>
# /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast
192.168.40.255
# /sbin/route add -net 192.168.40.0 netmask 255.255.255.0 dev eth1
</PRE>
<P>Per i kernel 2.2, usa le impostazioni seguenti:
<P>
<PRE>
# /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast
192.168.40.255
</PRE>
<P>A questo punto le interfaccie sono attive. Puoi parlare alle macchine
attraverso entrambe le reti connesse al server.
<H3>Imposta i percorsi (routes) </H3>
<P>Ora possiamo parlare alle macchine nella nostra rete locale, ma non
possiamo farlo sul resto della nostra rete interna. Questo richiederà un pò di
linee di codice. Per far in modo di raggiungere le altre macchine nelle altre
sottoreti, abbiamo bisogno di avere un percorso che indichi al traffico di
andare nel router Cisco. Ecco la linea di codice per far questo:
<PRE>
# /sbin/route add -net 192.168.0.0 gw 192.168.254.254 netmask 255.255.0.0
dev eth1
</PRE>
<P>Questa linea dice al kernel che tutto il traffico destinato per la rete
192.168.0.0 dovrebbe uscire da eth1, e che dovrebbe essere passato fuori al
Cisco. Il traffico per la nostra rete locale andrà dove deve poichè le tabelle
di routing sono ordinate per formato di netmask. Se noi vogliamo avere altre
reti interne nella nostra rete, ci servirà una linea di codice come quella
sotto riportata per ogni rete.
<H3>Realizzare le regole di filtraggio. Making filter rules </H3>
<P>Ok, così ora possiamo raggiungere le macchine di cui potremmo avere
bisogno. Ora abbiamo bisogno di scrivere le regole di filtraggio del firewall
che permettono o negano l'accesso attraverso il server VPN.
<P>Per impostare le regole con <CODE>ipfwadm</CODE>, lancialo in questa maniera:
<P>
<PRE>
# /sbin/ipfwadm -F -f
# /sbin/ipfwadm -F -p deny
# /sbin/ipfwadm -F -a accept -S 192.168.40.0/24 -D 192.168.0.0/16
# /sbin/ipfwadm -F -a accept -b -S 192.168.10.0/24 -D 192.168.0.0/16
# /sbin/ipfwadm -F -a accept -b -S 192.168.11.0/24 -D 192.168.0.0/16
</PRE>
<P>Per impostare le regole con <CODE>ipchains</CODE>, lancialo in questa maniera:
<P>
<PRE>
# /sbin/ipchains -F forward
# /sbin/ipchains -P forward DENY
# /sbin/ipchains -A forward -j ACCEPT -s 192.168.40.0/24 -d 192.168.0.0/16
# /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.10.0/24 -d
192.168.0.0/16
# /sbin/ipchains -A forward -j ACCEPT -b -s 192.168.11.0/24 -d
192.168.0.0/16
</PRE>
<P>Tutto ciò dice al kernel di rigettare tutto il traffico eccetto quello
che arriva dalla rete 192.168.40.0/24 e destinato alla rete 192.168.0.0/16. In
più la regola dice al kernel che il traffico passante tra le reti
192.168.10.0/24 e 192.168.0.0/16 è permesso, e lo stesso dicasi per la rete
192.168.11.0. Queste due ultime regole sono bidirezionali, questo è importante
per permettere al routing di lavorare in entrambi i modi.
<H3>Routing </H3>
<P>Per gli utenti casalinghi, tutto inizierà a funzionare bene da adesso.
tuttavia, per gli uffici remoti, abbiamo bisogno di instradare ancora
qualcosa. Prima di tutto, dobbiamo dire al router principale, o Cisco, che gli
uffici remoti sono dietro al Server VPN. Ora specifichiamo gli instradamenti
sul Cisco che dicono di spedire il traffico destinato agli uffici remoti al
server VPN. Ora dobbiamo dire al server VPN cosa fare con il traffico
destinato agli uffici remoti. Per far ciò, useremo il comando <CODE>route</CODE>
sul server. Il solo problema è che per far in modo che il comando
<CODE>route</CODE> funzioni, il link di rete deve essere attivo perchè se fosse
disattivato, questo specifico routing andrebbe perso. La soluzione è quella di
aggiungere gli instradamenti quando gli utenti si connettono, o più
semplicemente, lanciare il comando route frequentemente. Così, crea lo script
e aggiungilo nel tuo crontab per lanciarlo ogni pochi minuti, in esso, metti
le seguenti linee:
<P>
<PRE>
/sbin/route add -net 192.168.11.0 gw 192.168.10.253 netmask 255.255.255.0
/sbin/route add -net 192.168.10.0 gw 192.168.11.253 netmask 255.255.255.0
</PRE>
<H2><A NAME="ss5.5">5.5 Server: Configurare <CODE>pppd</CODE></A>
</H2>
<P>Ora configureremo pppd sul server per gestire le connessioni VPN. Se stai
già usando questo server per gestire gli utenti in dialup o per connettere te
stesso, allora potrai notare che queste modifiche avranno effetto su tutti i
servizi. Parleremo di come evitare i conflitti alla fine di questa sezione.
<H3><CODE>/etc/ppp/</CODE> </H3>
<P>Questa directory deve contenere necessariamente alcuni files.
Probabilmente avrai già un file chiamato <CODE>options</CODE>. Questo file
contiente tutte le opzioni globali di <CODE>pppd</CODE>. Queste opzioni non
possono essere sovrascritte da <CODE>pppd</CODE> da linea di comando.
<H3><CODE>/etc/ppp/options</CODE> </H3>
<P>Il file <CODE>options</CODE> dovrebbe contenere almeno le seguenti righe:
<P>
<PRE>
ipcp-accept-local
ipcp-accept-remote
proxyarp
noauth
</PRE>
<P>Le prime due righe dicono a <CODE>pppd</CODE> cosa accettare dall'altro lato
dell'indirizzo IP ricevuto. Questo è necessario quando vengono collegati gli
uffici remoti, ma può essere disabilitato se si collegano solo utenti da casa.
Va bene lasciarlo attivo, poichè non impedisce al server l'assegnazione degli
indirizzi, esso dice solo che è pronto ad accettare le richieste del client.
<P>La terza linea è molto importante. Dalle man page di <CODE>pppd</CODE>:
<P>
<PRE>
proxyarp
Add an entry to this system's ARP [Address Resolu-
tion Protocol] table with the IP address of the
peer and the Ethernet address of this system. This
will have the effect of making the peer appear to
other systems to be on the local ethernet.
</PRE>
<P>Questo è importante perchè se non viene fatto, il traffico locale non
sarà in grado di ritornare attraverso il tunnel.
<P>L'ultima linea è la più importante. Questa dice a <CODE>pppd</CODE> di
permettere connessioni senza username e password. Tale procedura è sicura
finchè l'autenticazione viene gestita da <CODE>sshd</CODE>.
<H3>Evitare conflitti </H3>
<P>Se gestisci altri servizi con <CODE>pppd</CODE>, dovrai considerare che le
configurazioni di questi altri servizi potrebbero non essere le stesse di cui
avrà bisogno una VPN. <CODE>pppd</CODE> è disegnato in modo tale che opzioni del
file principale <CODE>/etc/ppp/options</CODE> non possano essere sovrascritte da
opzioni specificate in runtime. Questo è fatto, logicamente, per ragioni di
sicurezza. Per evitare conflitti, si deve determinare quali opzioni causano il
conflitto, e spostarle dal file principale in un file di opzioni separato che
venga caricato quando l'applicazione appropriata di <CODE>pppd</CODE> stà girando.
<H2><A NAME="ss5.6">5.6 Server: Configurare <CODE>sshd</CODE></A>
</H2>
<P>Qui di seguito descrivo il mio file <CODE>/etc/sshd_config</CODE>. Il tuo
dovrebbe essere lo stesso o almeno simile:
<P>
<PRE>
# This is the ssh server system wide configuration file.
Port 22
ListenAddress 0.0.0.0
HostKey /etc/ssh_host_key
RandomSeed /etc/ssh_random_seed
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin yes
IgnoreRhosts yes
StrictModes yes
QuietMode no
FascistLogging yes
CheckMail no
IdleTimeout 3d
X11Forwarding no
PrintMotd no
KeepAlive yes
SyslogFacility DAEMON
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
UseLogin no
</PRE>
<P>Il punto importante da notare è che l'autenticazione delle password è
disabilitata come i servizi "r". Ho anche disabilitato il controllo
dell'email e il 'messaggio del giorno' può confondere <CODE>pppd</CODE> dal lato
client. Permetto ancora il login da root, ma può essere eseguito solamente con
una chiave, ciò è adeguatamente sicuro.
<H2><A NAME="user-accounts"></A> <A NAME="ss5.7">5.7 Server: configurare gli account </A>
utente </H2>
<P>Ora configureremo gli account utente.
<H3>Aggiungere il gruppo <CODE>vpn-users</CODE> </H3>
<P>Lancia semplicemente:
<P>
<PRE>
# /usr/sbin/groupadd vpn-users
</PRE>
<P>Ora, edita <CODE>/etc/group</CODE> e guarda l'ulima linea.
Dovrebbe essere la linea del gruppo vpn-users. Nota il terzo campo.
Questo è l'ID di gruppo (GID). Segnatela, ne avremo bisogno fra un minuto. Per
questo esempio il GID è 101.
<H3>Creare la home directory di <CODE>vpn-users</CODE> </H3>
<P>Useremo una home directory singola per tutti gli utenti del gruppo.
Cosi' si dovrà lanciare semplicemente:
<P>
<PRE>
# mkdir /home/vpn-users
</PRE>
<H3>La directory <CODE>.ssh</CODE> </H3>
<P>Ora creiamo la directory <CODE>.ssh</CODE> nella home directory di
<CODE>vpn-users</CODE>.
<P>
<PRE>
# mkdir /home/vpn-users/.ssh
</PRE>
<H3>Aggiungere utenti </H3>
<P>Ora inizia la parte divertente. Andiamo ad editare il file
<CODE>/etc/passwd</CODE> a mano. :) Normalmente è il sistema a gestire questo
file, ma per un setup 'sporco' come questo, è più semplice farselo. Per
iniziare, apri il file <CODE>/etc/passwd</CODE> e verifica cosa si trova
all'interno. Qui sotto c'è un esempio di ciò che dovresti trovare:
<P>
<PRE>
...
nobody:x:65534:100:nobody:/dev/null:
mwilson:x:1000:100:Matthew Wilson,,,:/home/mwilson:/bin/bash
joe:*:1020:101:Joe Mode (home),,,:/home/vpn-users:/usr/sbin/pppd
bill:*:1020:101:Bill Smith (home),,,:/home/vpn-users:/usr/sbin/pppd
frank:*:1020:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd
...
</PRE>
<P>Il primo utente è essenzialmente di default. Il secondo sono io. :) Dopo
questi sono stati fatti alcuni utenti specifici per vpn-users. Il primo campo
è lo username, e il secondo è il campo password. Il terzo è lo user ID (UID) e
il quarto è il l'ID di gruppo (GID). Dopo questi c'è un campo che specifica
alcune informazioni su chi sia l'utente. Il sesto campo è l'home directory
dell'utente e l'ultimo campo specifica la shell. Come puoi vedere, ogni campo
è separato da un due punti. Guarda le ultime tre righe. La sola differenza tra
loro è lo username nel primo campo, e le informazioni utente sul quinto campo.
Quello che vogliamo fare è creare righe come queste per ogni utente. E' meglio
non usare solo un utente per tutte le connessioni, facendo in quella maniera
non saresti in grado di distinguere nulla. Così, copia l'ultima linea di
questo file ed editala cosi che assomigli a quella sopra riportata. Sii sicuro
che il secondo campo sia un asterisco (*). Il secondo campo dovrebbe essere
uguale per tutte le righe del file. Io ho usato 1020. Tu puoi usare un numero
sopra a 1000, poichè i numeri più bassi sono tipicamente riservati per usi del
sistema. Il quarto campo dovrebbe essere riservato all'ID di gruppo di
vpn-users. E' tempo, ora, di usare quanto segnatoci precedentemente. Così
scrivi l'ID di gruppo qui. Come ultima cosa cambia la home directory in
<CODE>/home/vpn-users</CODE>, e la shell in <CODE>/usr/sbin/pppd</CODE>. E questo è
tutto. Ora copia la riga per aggiungere utenti.Modifica il primo e il quinto
campo e l'utente sarà configurato.
<H2><A NAME="ss5.8">5.8 Server: Amministrazione</A>
</H2>
<P>Uno dei vantaggi di usare questo sistema per gli account utente è che tu
puoi avvantaggiarti dei comandi di amministrazione degli utenti di UNIX. Dal
momento che ogni client si connette come utente, tu puoi usare i metodi
standard per avere le statistiche utente. I seguenti sono alcuni comandi che
mi piace usare per vedere se il tutto funziona a dovere.
<P>
<DL>
<P>
<DT><B>who</B><DD><P>Visualizza gli utenti correntemente connessi, così come quando si sono
connessi, da dove (nome o IP, e su quale porta).
<P>
<DT><B>w</B><DD><P>Questo comando visualizza una lista molto estesa di chi è correntemente
connesso. Ti dice pure l'uptime e i carichi per il sistema. In più specifica
il processo corrente dell'utente (il quale dovrebbe essere -pppd per i client
della VPN) così come l'idle time, e l'uso corrente della CPU per tutti i
processi cosiì come il processo corrente. Leggi le man page di <CODE>w</CODE> per
saperne di più.
<P>
<DT><B>last [username]</B><DD><P>Questo visualizza lo storico del login di un utente specifico, o per
tutti gli utenti se l'username passato non è presente. E' molto utile per
testare quanto bene stà funzionando il tunnel e visualizza la lunghezza del
tempo che l'utente è connesso, o lo stato nel quale l'utente è connesso al
momento. Ti metto in guardia del fatto che se un sistema è attivo da molto
tempo questa lista potrebbe essere molto lunga. Filtrala con una pipe
attraverso <CODE>grep</CODE> o <CODE>head</CODE> per trovare esattamente quello che
vuoi sapere.
</DL>
<P>Puoi anche controllare quali utenti hanno il permesso di connetersi
modificando il file <CODE>/home/vpn-users/.ssh/authorized_keys</CODE>. Se rimuovi
la linea con la chiave pubblica dell'utente da questo file, non riuscirà più a
connettersi.
<H2><A NAME="ss5.9">5.9 Client: compilare il kernel.</A>
</H2>
<P>Ora prendiamo in considerazione il client. Per prima cosa dobbiamo ricompilare il kernel in
modo che possa supportare tutte le funzioni di cui abbiamo bisogno. Le richieste
minime sono di avere il ppp nel kernel. Dopo questo, avrai bisogno del
forwarding, firewalling e del gatewaying solo se vuoi permettere ad altre
macchine di accedere al tunnel. Per questo esempio, configurerò una delle
macchine dell'ufficio remoto del mio schema di esempio. Aggiungiamo le
seguenti opzioni sul tuo kernel. Ancora, se non hai mai compilato un kernel in
vita tua, leggi
<A HREF="/HOWTO/Kernel-HOWTO.html">Kernel HOWTO</A>.
<P>Per i kernel 2.0:
<UL>
<LI>CONFIG_PPP</LI>
<LI>CONFIG_FIREWALL</LI>
<LI>CONFIG_IP_FORWARD</LI>
<LI>CONFIG_IP_FIREWALL</LI>
<LI>CONFIG_IP_ROUTER</LI>
<LI>CONFIG_IP_MASQUERADE</LI>
<LI>CONFIG_IP_MASQUERADE_ICMP</LI>
</UL>
<P>Per i kernel 2.2:
<UL>
<LI>CONFIG_PPP</LI>
<LI>CONFIG_FIREWALL</LI>
<LI>CONFIG_IP_ADVANCED_ROUTER</LI>
<LI>CONFIG_IP_FIREWALL</LI>
<LI>CONFIG_IP_ROUTER</LI>
<LI>CONFIG_IP_MASQUERADE</LI>
<LI>CONFIG_IP_MASQUERADE_ICMP</LI>
</UL>
<H2><A NAME="ss5.10">5.10 Client: Configurare la rete </A>
</H2>
<P>Ora dovremo configurare la rete sul tuo PC client. Assumiamo di aver già
configurato la rete esterna e che questa funzioni. Ora configureremo
l'interfaccia interna del client in servizio nella tua intranet.
<H3>Interfaccia </H3>
<P>Abbiamo bisogno per prima cosa di attivare l'interfaccia interna di rete.
Per far cio, aggiungi le seguenti linee al tuo file (o equivalente)
<CODE>/etc/rc.d/rc.inet1</CODE>:
<P>Per i kernel 2.0:
<P>
<PRE>
/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask
255.255.255.0
/sbin/route add -net 192.168.10.0 netmask 255.255.255.0 dev eth1
</PRE>
<P>Per i kernel 2.2:
<P>
<PRE>
/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask
255.255.255.0
</PRE>
<H3>Regole di filtraggio </H3>
<P>Per configurare l'ufficio remoto, dovremo impostare le regole di
filtraggio che permettano al traffico di andare in entrambe le direzioni
attraverso il tunnel. Aggiungi le seguenti linee al tuo file (o equivalente)
<CODE>/etc/rc.d/rc.inet1</CODE>:
<P>Per i kernel 2.0:
<P>
<PRE>
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p deny
/sbin/ipfwadm -F -a accept -b -S 192.168.10.0/24 -D 192.168.0.0/16
</PRE>
<P>Per i kernel 2.2:
<P>
<PRE>
/sbin/ipchains -F forward
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -j ACCEPT -b -s 192.168.10.0/24 -d 192.168.0.0/16
</PRE>
<P>Avrai notato che queste linee assomigliano a quelle che abbiamo sul
server. Questo perchè sono le stesse. Queste regole dicono semplicemente dove
il traffico ha il permesso di andare, e cioè tra queste due reti.
<H3>Routing </H3>
<P>Il solo instradamento extra di cui abbiamo bisogno è creato dallo script
che attiva il tunnel.
<H2><A NAME="ss5.11">5.11 Client: Configurare <CODE>pppd</CODE></A>
</H2>
<P>Non dovresti aver bisogno di editare il file <CODE>/etc/ppp/options</CODE> a
questo punto. Controlla se l'opzione "auth" è presente, o alcune delle altre
opzioni privilegiate. Provalo, e se fallisce, un <CODE>/etc/ppp/options</CODE>
vuoto si attiverà semplicemente conservando le opzioni dal vecchio file per
indagare su cosa si sia corrotto (se non è evidente). Forse non avrai bisogno
di tutto ciò se usi <CODE>pppd</CODE> per null'altro che questo.
<H2><A NAME="ss5.12">5.12 Client: Configurare <CODE>ssh</CODE></A>
</H2>
<P>Come root sul client, esegui le seguenti linee:
<P>
<PRE>
# mkdir /root/.ssh
# ssh-keygen -f /root/.ssh/identity.vpn -P ""
</PRE>
<P>Questo creerà due files, <CODE>identity.vpn</CODE> e <CODE>identity.vpn.pub</CODE>
nella directory <CODE>.ssh</CODE>. Il primo è la tua chiave privata, e dovrebbe
essere tenuta al sicuro. <EM>MAI SPEDIRLA ATTRAVERSO LA RETE</EM> se non
attravreso una sessione crittata. Il secondo file è la tua chiave pubblica, e
puoi spedirla in qualsiasi posto tu voglia, essa serve solo per permettere
l'accesso ad altri sistemi, e non può essere usata in sostituzione alla tua
privata. E' un file di testo con una linea che rappresenta la tua chiave
attuale. Alla fine della linea c'è il campo commento che puoi cambiare senza
paura che la tua chiave sia sprotetta. Un esempio di chiave si presenta più o
meno così:
<P>
<PRE>
1024 35 1430723736674162619588314275167.......250872101150654839
root@vpn-client.mycompany.com
</PRE>
<P>La chiave reale è più lunga di questa, comunque, ma non voglio riempire lo schermo per
rappresentarla tutta. Copia la chiave nel file sul server
<CODE>/home/vpn-users/.ssh/authorized_keys</CODE>. Sii sicuro che ci sia una sola
chiave per linea, e che ogni chiave non sia spezzata in più linee. Potrai
alterare il campo commento con tutto ciò che ti sembrerà utile per ricordarti
quale linea sia associata a quale utente. Ti raccomando caldamente questa
pratica.
<H2><A NAME="ss5.13">5.13 Client: Attivare la connessione</A>
</H2>
<P>Ora proveremo ad attivare la connessione verso il server VPN. Primo avremo
bisogno di tentare una connessione al server specificato nel file known_host
nel file <CODE>ssh</CODE>. Lancia questo:
<P>
<PRE>
# ssh vpn.mycompany.com
</PRE>
<P>Rispondi "yes" quando ti viene chiesto se vuoi continuare a connetterti.
Il server ti risponderà "permission denied", ma è tutto ok. E' importante che
usi lo stesso nome per il server che vuoi usare nello script di connessione.
Ora scrivi le seguenti linee. Avrai bisogno di cambiare la maggior parte delle
opzioni per mettere a punto la configurazione.
<P>
<PRE>
# /usr/sbin/pty-redir /usr/bin/ssh -t -e none -o 'Batchmode yes' -c
blowfish -i /root/.ssh/identity.vpn -l vpn-user vpn.mycompany.com >
/tmp/vpn-device
(now wait about 10 seconds)
# /usr/sbin/pppd `cat /tmp/vpn-device` 192.168.10.254:192.168.40.254
</PRE>
<P>Nota l'indirizzo IP specificato nella linea con pppd. Il primo è
l'indirizzo del client alla fine del tunnel. Il secondo è l'indirizzo del
server alla fine del tunnel, il quale è settato sugli indirizzi interni del
server. Se tutto sembra funzionare, vai avanti. Se no, controlla se hai tutte
le opzioni e se sono scritte correttamente. Se qualcosa continua a non
funzionare, controlla la sezione
<A HREF="VPN-HOWTO-6.html#pitfalls">sezione trabocchetti</A>.
<H2><A NAME="ss5.14">5.14 Client: Configurare gli instradamenti.</A>
</H2>
<P>Ora configuriamo l'instradamento per spedire il traffico attraverso il
tunnel. Lancia questo:
<P>
<PRE>
# /sbin/route add -net 192.168.0.0 gw vpn-internal.mycompany.com netmask
255.255.0.0
</PRE>
<P>Dovresti ora essere in grado di comunicare con le macchine all'altro lato
del tunnel. Fai una prova. Semplice, vero? Se non funziona, prova usando
<CODE>ping</CODE> e <CODE>traceroute</CODE> per identificare dove si potrebbe annidare
il problema. Se finalmente funziona, configura degli script che facciano il
lavoro per te.
<H2><A NAME="ss5.15">5.15 Client: Scripting</A>
</H2>
<P>Usa lo script vpnd mostrato
<A HREF="VPN-HOWTO-4.html#vpnd-script">qui</A>. Solamente
devi modificarlo un poco. Esegui le seguenti modifiche:
<P>
<UL>
<LI>Cambia le variabili in cima per abbinarle alla tua configurazione. La
maggior parte dovrebbero essere a posto, ma se ne hai bisogno puoi cambiarle. </LI>
<LI>Line 27: aggiungi l'IP locale e remoto prima di $PPP_OPTIONS</LI>
<LI>Line 31: Cambia questa linea, e le due dopo essa per configurare gli
instradamenti per le tue reti interne.</LI>
</UL>
<H3>Mantienila attiva </H3>
<P>Anche se gli script bash sono generalmente stabili, abbiamo scoperto che
possono fallire. Per essere sicuri che lo script <CODE>vpnd</CODE> rimanga attivo,
aggiungiamo una linea alla crontab del client che lancia lo script
<CODE>check-vpnd</CODE>. Viene lanciato ogni 5 minuti circa. Se <CODE>vpnd</CODE> stà
effettivamente funzionando, <CODE>check-vpnd</CODE> non sprecherà risorse di CPU.
<HR>
<A HREF="VPN-HOWTO-6.html">Avanti</A>
<A HREF="VPN-HOWTO-4.html">Indietro</A>
<A HREF="VPN-HOWTO.html#toc5">Indice</A>
</BODY>
</HTML>
