Avanti Indietro Indice

5. Implementazione

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.

5.1 Pianificazione

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.

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.

Per gli indirizzi esterni, non abbiamo bisogno di conoscerli. L'unica cosa che si deve avere è il proprio indirizzo, fornito dal proprio ISP.

5.2 Raccogliere gli strumenti

Ora abbiamo bisogno di alcuni software, trova i seguenti programmi e installali dove specificato.

Per il Server:

Per il Client:

5.3 Server: compilare il kernel

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 Kernel HOWTO.

Per i kernel 2.0:

Per i kernel 2.2:

5.4 Server: Configurare la rete

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.

Configurare le interfaccie di rete

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 Networking HOWTO

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.

Per i kernel 2.0, usa le impostazioni seguenti: 

# /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

Per i kernel 2.2, usa le impostazioni seguenti: 

# /sbin/ifconfig eth1 192.168.40.254 netmask 255.255.255.0 broadcast 
192.168.40.255

A questo punto le interfaccie sono attive. Puoi parlare alle macchine attraverso entrambe le reti connesse al server.

Imposta i percorsi (routes)

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: 

# /sbin/route add -net 192.168.0.0 gw 192.168.254.254 netmask 255.255.0.0 
dev eth1

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.

Realizzare le regole di filtraggio. Making filter rules

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.

Per impostare le regole con ipfwadm, lancialo in questa maniera: 

# /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

Per impostare le regole con ipchains, lancialo in questa maniera: 

# /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

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.

Routing

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 route sul server. Il solo problema è che per far in modo che il comando route 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: 

/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

5.5 Server: Configurare pppd

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.

/etc/ppp/

Questa directory deve contenere necessariamente alcuni files. Probabilmente avrai già un file chiamato options. Questo file contiente tutte le opzioni globali di pppd. Queste opzioni non possono essere sovrascritte da pppd da linea di comando.

/etc/ppp/options

Il file options dovrebbe contenere almeno le seguenti righe: 

ipcp-accept-local
ipcp-accept-remote
proxyarp
noauth

Le prime due righe dicono a pppd 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.

La terza linea è molto importante. Dalle man page di pppd: 

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.

Questo è importante perchè se non viene fatto, il traffico locale non sarà in grado di ritornare attraverso il tunnel.

L'ultima linea è la più importante. Questa dice a pppd di permettere connessioni senza username e password. Tale procedura è sicura finchè l'autenticazione viene gestita da sshd.

Evitare conflitti

Se gestisci altri servizi con pppd, dovrai considerare che le configurazioni di questi altri servizi potrebbero non essere le stesse di cui avrà bisogno una VPN. pppd è disegnato in modo tale che opzioni del file principale /etc/ppp/options 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 pppd stà girando.

5.6 Server: Configurare sshd

Qui di seguito descrivo il mio file /etc/sshd_config. Il tuo dovrebbe essere lo stesso o almeno simile: 

# 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

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 pppd dal lato client. Permetto ancora il login da root, ma può essere eseguito solamente con una chiave, ciò è adeguatamente sicuro.

5.7 Server: configurare gli account utente

Ora configureremo gli account utente.

Aggiungere il gruppo vpn-users

Lancia semplicemente: 

# /usr/sbin/groupadd vpn-users

Ora, edita /etc/group 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.

Creare la home directory di vpn-users

Useremo una home directory singola per tutti gli utenti del gruppo. Cosi' si dovrà lanciare semplicemente: 

# mkdir /home/vpn-users

La directory .ssh

Ora creiamo la directory .ssh nella home directory di vpn-users. 

# mkdir /home/vpn-users/.ssh

Aggiungere utenti

Ora inizia la parte divertente. Andiamo ad editare il file /etc/passwd a mano. :) Normalmente è il sistema a gestire questo file, ma per un setup 'sporco' come questo, è più semplice farselo. Per iniziare, apri il file /etc/passwd e verifica cosa si trova all'interno. Qui sotto c'è un esempio di ciò che dovresti trovare: 

...
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
...

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 /home/vpn-users, e la shell in /usr/sbin/pppd. E questo è tutto. Ora copia la riga per aggiungere utenti.Modifica il primo e il quinto campo e l'utente sarà configurato.

5.8 Server: Amministrazione

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.

who

Visualizza gli utenti correntemente connessi, così come quando si sono connessi, da dove (nome o IP, e su quale porta).

w

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 w per saperne di più.

last [username]

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 grep o head per trovare esattamente quello che vuoi sapere.

Puoi anche controllare quali utenti hanno il permesso di connetersi modificando il file /home/vpn-users/.ssh/authorized_keys. Se rimuovi la linea con la chiave pubblica dell'utente da questo file, non riuscirà più a connettersi.

5.9 Client: compilare il kernel.

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 Kernel HOWTO.

Per i kernel 2.0:

Per i kernel 2.2:

5.10 Client: Configurare la rete

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.

Interfaccia

Abbiamo bisogno per prima cosa di attivare l'interfaccia interna di rete. Per far cio, aggiungi le seguenti linee al tuo file (o equivalente) /etc/rc.d/rc.inet1:

Per i kernel 2.0: 

/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

Per i kernel 2.2: 

/sbin/ifconfig eth1 192.168.10.253 broadcast 192.168.10.255 netmask 
255.255.255.0

Regole di filtraggio

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) /etc/rc.d/rc.inet1:

Per i kernel 2.0: 

/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

Per i kernel 2.2: 

/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

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.

Routing

Il solo instradamento extra di cui abbiamo bisogno è creato dallo script che attiva il tunnel.

5.11 Client: Configurare pppd

Non dovresti aver bisogno di editare il file /etc/ppp/options a questo punto. Controlla se l'opzione "auth" è presente, o alcune delle altre opzioni privilegiate. Provalo, e se fallisce, un /etc/ppp/options 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 pppd per null'altro che questo.

5.12 Client: Configurare ssh

Come root sul client, esegui le seguenti linee: 

# mkdir /root/.ssh
# ssh-keygen -f /root/.ssh/identity.vpn -P ""

Questo creerà due files, identity.vpn e identity.vpn.pub nella directory .ssh. Il primo è la tua chiave privata, e dovrebbe essere tenuta al sicuro. MAI SPEDIRLA ATTRAVERSO LA RETE 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ì: 

1024 35 1430723736674162619588314275167.......250872101150654839 
root@vpn-client.mycompany.com

La chiave reale è più lunga di questa, comunque, ma non voglio riempire lo schermo per rappresentarla tutta. Copia la chiave nel file sul server /home/vpn-users/.ssh/authorized_keys. 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.

5.13 Client: Attivare la connessione

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 ssh. Lancia questo: 

# ssh vpn.mycompany.com

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. 

# /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

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 sezione trabocchetti.

5.14 Client: Configurare gli instradamenti.

Ora configuriamo l'instradamento per spedire il traffico attraverso il tunnel. Lancia questo: 

# /sbin/route add -net 192.168.0.0 gw vpn-internal.mycompany.com netmask 
255.255.0.0

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 ping e traceroute per identificare dove si potrebbe annidare il problema. Se finalmente funziona, configura degli script che facciano il lavoro per te.

5.15 Client: Scripting

Usa lo script vpnd mostrato qui. Solamente devi modificarlo un poco. Esegui le seguenti modifiche:

Mantienila attiva

Anche se gli script bash sono generalmente stabili, abbiamo scoperto che possono fallire. Per essere sicuri che lo script vpnd rimanga attivo, aggiungiamo una linea alla crontab del client che lancia lo script check-vpnd. Viene lanciato ogni 5 minuti circa. Se vpnd stà effettivamente funzionando, check-vpnd non sprecherà risorse di CPU.

Avanti Indietro Indice

Hosting by: hurra.com
Generated: 2007-01-26 17:56:21