VPN PPP-SSH Mini-HOWTO

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.

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.

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

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.

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.

Impostare tunnel multipli verso un unico computer è semplice. Occorre semplicemente assicurarsi che gli indirizzi IP delle interfacce di rete del tunnel siano distinti.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

È un computer che aspetta passivamente l'arrivo di richieste di connessione VPN. Fuunziona completamente incustodito.

È un computer che inizializza le richieste di connessione, chiedendo al Server di creare una VPN.

Qual'è lo hostname o l'indirizzo IP 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.

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.

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