PPTP con Linux Debian (aggiornato a Squeeze)
Questi sono poco piu` che appunti su come mettere online un semplice server PPTP (un protocollo che a mio avviso dovrebbe essere abolito come l' FTP e il fax) usando Linux.
Il PPTP ha un sacco di problemi:
- Usa il protocollo GRE che non tutti i router (quelli da 2 lire) supportano
- Richiede un helper per il NAT lato client, altrimenti se due client nattati dietro lo stesso ip pubblico si connettono allo stesso server vanno a tratti, o l'uno o l'altro
- Credo che sia impossibile da nattare lato server, se per qualsiasi motivo occorre mettere due server dietro lo stesso indirizzo pubblico
- Non consente di "passare" al client informazioni di routing da parte del server, quindi in pratica occorre impostare sul client le regole di routing per la rete che si trova dietro al server.
Nonostante questo, e` usatissimo in quanto e` la VPN standard di Windows. Come siamo messi? Male, molto male.
Installazione di poptop
In Debian, basta installare il pacchetto pptpd con le sue dipendenze, prima fra le quali ovviamente il ppp. Esiste anche il client, che e` "pptp-linux", ma che qui non trattero`. Per poter usare la crittografia e` necessario avere il supporto MPPE nel ppp, in Debian c'e`.
Configurazione di poptop
La configurazione si fa in due passi, una e` la configurazione del demone del pptp e l'altra contiene i parametri che il pptp passa al ppp.
File /etc/pptpd.conf Fate riferimento a quello originale, che e` commentato e molto semplice. Questo e` conciso e contiene quello che serve per funzionare. Credo, ma non sono sicuro, che il ppp legga comunque anche il file /etc/ppp/options oltre a questo, e che faccia un "mix" delle impostazioni. Mi ricordo di aver letto una cosa simile non ricordo dove. Nel caso, se volete togliervi ogni dubbio, rinominate l'eventuale file /etc/ppp/options in modo che non venga piu` letto.
# dove sono le opzioni del ppp option /etc/ppp/pptpd-options # logga gli accessi su wtmp logwtmp # fai relay dei broadcast da eth0 (questa e` la NIC lato LAN del server pptp) bcrelay eth0 # indirizzi locali e remoti: localip e` (puo` essere, non e` obbligatorio) l' ip della NIC lato LAN (la eth0 di prima) # remoteip e` un gruppo di indirizzi contigui che saranno assegnati dinamicamente (o staticamente) ai client. Ovviamente non devono # essere in uso nella LAN, ma sono nella stessa subnet della LAN (usiamo una configurazione in bridge, non in routing) localip 192.168.35.252 remoteip 192.168.35.151-170
File /etc/ppp/pptpd-options. Contiene le opzioni da passare al ppp quando si connette un client pptp. Anche in questo caso consiglio di fare riferimento a quello originale per capire come funzionano le opzioni. Queste opzioni si applicano al ppp e non al pptp, quindi possono variare a seconda della versione di ppp che avete installato e alle patch. Il che non e` affatto "comodo".
# il "nome del server", lo trovate dopo nella configurazione della autenticazione name pptpd # autenticazione e crittografia: accetto solo il massimo possibile della sicurezza, che e` comunque scarsa. # (puo` essere diversa a seconda della vostra versione del ppp) auth refuse-pap refuse-chap refuse-mschap require-mschap-v2 require-mppe-128 # passo ai client gli indirizzi di DNS e WINS. Posso anche metterne due (duplicando le righe) ms-dns 192.168.35.252 ms-wins 192.168.35.252 # opzioni varie del ppp utili in questo setup proxyarp nodefaultroute lock # opzioni di compatibilita` che mi e` capitato di dover usare con client rognosi: nobsdcomp ipcp-accept-local ipcp-accept-remote lcp-echo-failure 30 lcp-echo-interval 5
Autenticazione
Per come e` configurato sopra, il server ppptp autentica gli utenti in chap, quindi dovremo lavorare sul file /etc/ppp/chap-secrets, del quale riporto un esempio qui (l'utente "DOMAIN\\user1" e` un utente che usa anche il dominio nell'autenticazione, si veda la voce "Configurazione dei client Windows" in seguito):
# Secrets for authentication using CHAP # client server secret IP addresses kurgan pptpd lamiapassword * pippo pptpd pluto 192.168.35.160 paperino pptpd quack * DOMAIN\\user1 pptpd pippero *
Questo file contiene lo username dell'utente remoto, il nome del "server" (che occorre se si hanno piu` istanze di qualcosa che usa il ppp e deve autenticare degli utenti), e la password dell'utente. A seguire c'e` un asterisco che significa "prendi un ip a caso fra quelli disponibili" oppure un indirizzo IP preciso da assegnare sempre a quel client li`.
Firewall
Il server ppptp deve accettare connessioni tcp sulla porta di "controllo" del protocollo, e poi il protocollo GRE. Una configurazione valida per iptables e` questa (supponendo che eth1 sia la WAN del nostro server pptp/firewall):
iptables -A INPUT -i eth1 -m state --state NEW -p tcp --dport 1723 -j ACCEPT iptables -A INPUT -i eth1 --protocol 47 -m state --state NEW -j ACCEPT
Configurazione dei client Windows
Sul client Windows (o altro client) e` sufficiente impostare lo username, la password e l'indirizzo del gateway pptp remoto (il pptp server, lato WAN). Alcuni client prevedono un campo "domain". Se potete lo lasciate vuoto. Se il client si impunta a dover inserire un dominio, probabilmente cerchera` di autenticare sul server come "dominio\utente", e voi dovrete configurare di conseguenza il file degli utenti (chap-secrets) in modo da creare un utente che corrisponda alla stringa che il client vi manda.
Problemi di routing sui client
Di default il client Windows quando stabilisce una connessione PPTP definisce una regola che fa passare TUTTO il traffico non locale verso l'interfaccia della VPN. Il server non ha una maniera standard (windows usa un sistema tutto suo che fa uso di un parametro del DHCP sul server) per passare al client informazioni sul routing, quindi se non vi va bene il metodo di windows (default gateway sulla vpn) dovrete arrangiarvi a farvi il routing lato client come meglio credete. Io non ho mai approfondito la cosa perche` cerco di evitare il piu` possibile di usare il PPTP se posso usare alternative, come per esempio l'ottima openvpn.