Introduzione a PopTop - PPTP Server OpenSource

PopTop è l'implementazione pptp opensource più diffusa ed utilizzata per permettere ad un sistema Unix, tipicamente Linux, di fare da server PPTP per client che supportano questo protocollo per VPN (implementato nativamente su Windows).

Per funzionare poptop si appoggia al pppd comunemente disponibile nelle varie distribuzioni Linux e richiede una configurazione relativamente semplice, ma se si deve interoperare con client Windows E supportare i suoi metodi di default di autenticazione (MSCHAP v2)  e criptazione (MPPE) è necessario avere il supporto del modulo mppe nel kernel, con qualche complicazione in più per il setup iniziale.

INSTALLAZIONE
Dal sito ufficiale è facilmente raggiungibile l'area download che si appoggia a sourceforge.
Si presentano diversi tipi di file (tar.gz dei sorgenti o pacchetti precompilati per alcune delle prinicpali distribuzioni):
- mppe module builder serve per avere il supporto mppe e qundi avere piena interoperabilità con client Windows. Vengono utilizzati due componenti: il comodissimo dkms che permette di ricompilare on.the-fly moduli aggiuntivi del kernel quando questo viene aggiornato (evitando il rischio che il modulo mppe diventi inutilizzabile al primo aggiornamento del kernel) e il vero e proprio modulo mppe, kernel_ppp_mppe, pacchettizzato in modo da essere usato con dkms.
- ppp che contiene anche il server pppd in una versione sufficientemente aggiornata o patchata per supportare mppe (quella di default presente nella propria distribuzione potrebbe non farlo).
- pptpd il server PopTop vero e proprio.

Per l'installazione si suggerisce l'uso dei pacchetti rpm precompilati e di generarsi i propri rpm partendo dagli rpm dei sorgenti (Installare il src.rpm e ricostruire il pacchetto RPM per la propria macchina con rpmbuild -ba /usr/src/redhat/SPEC/pptpd.spec).
SU Debian pptpd è disponibile direttmanete (apt-get install pptpd).
Se si vuole procedere compilando i sorgenti leggere la documentazione sul sito ufficiale.

CONFIGURAZIONE
I file di configurazione essenziali sono 3 /etc/pptpd.conf, /etc/ppp/options.pptpd e /etc/ppp/chap-secrets:
/etc/pptpd.conf contiene informazioni su quali IP assegnare ai client che si collegano e qualche parametro che generalmente non si modifica.
DI fatto il suo contentuo potrebbe limitarsi a qualcosa tipo:
option /etc/ppp/options.pptpd Esplicita la posizione del file che contiene i parametri ppp da usare per le connessioni pptp
localip 10.0.0.60 L'IP sulla rete interna del server PPTP
remoteip 10.0.0.110-119 Il range di IP che si vuole assegnare ai client PPTP che si collegano sulla rete interna
.
Può inoltre servire impostare:
bcrelay eth0 Abilita il broadcast dai client alla rete interna (qui su interfaccia eth0), necessario per queli protocolli che si basano su broadcast per funzionare correttamente (può essere utile per sfogliare reti Windows)

/etc/ppp/options.pptpd contiene i parametri ppp da utilizzare ed è quello dove è più importante prestare attenzione ad alcuni dettagli che determinano quali metodi di autenticazione e protocolli di criptazione utilizzare.
In particolare per definire se usare il protocollo mppe e il metodo di autenticazione esistono due diverse sintassi a seconda della versione del pppd installata a disposizione (notare che questo di fatto è un file di configurazione del ppp e di come negoziare la connessione ppp fra server e client).

La sintassi vecchia, che vale per il fork mppe compatibile di ppp 2.4.1, prevede parametri come:
-chap Rifiuta autenticazione CHAP
-mschap Rifiuta autenticazione MSCHAP
+chapms-v2 Forza l'uso di autenticazione basata su MSCHAP v2
mppe-128 Imposta supporto mppe con cifratura a 128 bit
mppe-stateless Abilita mppe in modalità stateless

(Questi sono quelli che forzano MSCHAP2 e mppe e sono compatibili con le impostazioni standard delle VPN Windows).

La sintassi nuova, valida per ppp 2.4.2 e successivi prevede, sempre per i parametri di default per client Windows:
refuse-pap Rifiuta autenticazione PAP (plaintext)
refuse-chap Rifiuta autenticazione CHAP
refuse-mschap Rifiuta autenticazione MSCHAP
require-mschap-v2  Forza l'uso di autenticazione basata su MSCHAP v2
require-mppe  Imposta supporto mppecon cifratura a 128 bit
nomppe-stateful Abilita mppe in modalità stateless


Altri parametri generalmente usati, comuni a tutte le versioni, sono:
lock Crea un file di lock per il server pppd. Nel dubbio, lasciarlo.
debug Abilita il debug della connessione, di solito si trovano i log in /var/log/messages
name nome_server Imposta il nome del server pptd. Deve coincidere con quanto scritto in /etc/ppp/chap-secrets
mtu 1500 Imposta l'MTU dei pacchetti
auth Richiede l'autenticazione del client. Necessario su un server ppp
proxyarp Imposta sul server una arp entry con l'IP assegnato al client, necessario per rendere quest'ultimo visibile agli altri host nella lan del server.
nobsdcomp Disabilita compressione BSD
ms-wins 10.0.0.150 Imposta l'IP del server WINS da assegnare ai client
ms-dns 10.0.0.150 Imposta l'IP del server DNS da assegnare ai client


Le login e le password utilizzabili per i collegamenti vanno scritte in /etc/ppp/chap-secrets la cui sintassi è semplice, preve una riga per utente, con i seguenti dati separati da un tab: nome utente, nome del server (specificato con l'opzione "name" in /etc/ppp/options.pptpd), password (in chiaro!) e eventuale IP da cui il client può collegarsi (usare * per non imporre restrizioni). Ad esempio:
pippo      nome_server      pippo_password      *
Se si è compilato pptp con il supporto smbauth, è possibile autenticare gli utenti via samba, con una configurazione tipo
*      nome_server      &/etc/samba/smbpasswd      *
E' inoltre possibile autenticare gli utenti usando un server radius, per dettagli consultare la documentazione sul sito ufficiale.

FIREWALLING E NETWORKING
Ogni client connesso crea una nuova interfaccia sul server, chiamata ppp0 per il primo, ppp1 per il secondo e via dicendo.
A livello di firewalling si devono quindi considerare diversi aspetti:
- deve essere abilitato il traffico, nella catena di FORWARD, fra la rete interna del firewall e queste interfacce pppX. Ovviamente si possono configurare le limitazioni che servono (accesso solo a determinati host interni ecc.).
- L'interfaccia esterna del vpn server deve permettere l'accesso, dall'IP del client, alla porta tcp 1723 (per l'autenticazione) e il protocollo di trasporto GRE (ip type 47) per il tunnel.
- L'ip forwarding deve essere abilitato sul kernel.

Un esempio essenziale di configurazione delle iptables su un VPN server dove eth0 è l'interfaccia interna e l'eth1 è quella esterna può essere (qui vengono previsti solo due collegamenti ppp contemporanei):
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -p tcp --dport 1723 -i eth1 -j ACCEPT
-A INPUT -p gre -i eth1 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -i ppp0 -j ACCEPT
-A FORWARD -i ppp1 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
COMMIT


In genere, per qualsiasi VPN server che per natura deve essere accessbile da arbitrari IP esterni e avere una interfaccia su una rete interna, non è il massimo avere le porte su cui si negozia il tunnel sempre accessibili. Al riguardo valutare soluzioni di port knocking che aprano la possibilità di accedere solo a determinate condizioni.

Privacy Policy