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.
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.
Ora abbiamo bisogno di alcuni software, trova i seguenti programmi e installali dove specificato.
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:
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.
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.
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.
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.
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
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.
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.
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.
Ora configureremo gli account utente.
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.
vpn-users Useremo una home directory singola per tutti gli utenti del gruppo. Cosi' si dovrà lanciare semplicemente:
# mkdir /home/vpn-users
.ssh Ora creiamo la directory .ssh nella home directory di
vpn-users.
# mkdir /home/vpn-users/.ssh
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.
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.
Visualizza gli utenti correntemente connessi, così come quando si sono connessi, da dove (nome o IP, e su quale porta).
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ù.
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.
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:
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.
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
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.
Il solo instradamento extra di cui abbiamo bisogno è creato dallo script che attiva il tunnel.
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.
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.
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.
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.
Usa lo script vpnd mostrato qui. Solamente devi modificarlo un poco. Esegui le seguenti modifiche:
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.