L2TP senza IPsec su Linux: xl2tpd, pppd e NAT

Il L2TP nudo è PPP dentro una busta, e nient'altro. Trasporta i vostri frame; non li cifra e non dimostra chi siede all'altro capo, ed è per questo che quasi ogni distribuzione infila IPsec sotto. Motivi onesti per usare la versione nuda esistono ancora: un banco di laboratorio, un passo di migrazione o un collegamento già dentro un altro percorso protetto.

Se proseguite, mettete quell'avvertenza nella nota di progetto e lasciatela lì. Quello che segue è il percorso operativo che uso su host della famiglia Debian e RHEL: quale file si occupa di cosa, la MTU che evita il blocco classico e le regole di inoltro che rendono utile il tunnel.

Tre file si dividono il lavoro

xl2tpd termina la connessione di controllo e affida ogni sessione a un demone PPP, quindi la configurazione è divisa tra due programmi che non leggono mai i file l'uno dell'altro. L'ascoltatore vive in /etc/xl2tpd/xl2tpd.conf, dentro una sezione [lns default] che nomina il pool di indirizzi con ip range, il lato server con local ip e la consegna a PPP con pppoptfile. Attivate require authentication = yes, lasciate abilitati length bit e flow bit, e scegliete un pool che nient'altro sull'host stia già usando.

La politica PPP appartiene al file che quell'opzione nomina, di solito /etc/ppp/options.xl2tpd: auth, i rifiuti per pap, chap e mschap, require-mschap-v2, una MTU e una MRU di 1460 e un indirizzo DNS che il client può raggiungere dopo che il collegamento è attivo. Le credenziali sono ancora un terzo file, /etc/ppp/chap-secrets, dove il secondo campo deve corrispondere al nome della sezione LNS e il quarto può fissare un indirizzo specifico del pool.

Perché il tunnel si connette e poi si blocca

Un frame Ethernet da 1500 byte non entra in un percorso che spende già byte per le proprie intestazioni. L'intestazione IPv4 esterna costa 20, UDP costa 8 e quella L2TP circa 12, il che lascia 1460 per PPP e il suo carico. È proprio annunciare quel numero più piccolo in PPP che impedisce ai pacchetti grandi di essere frammentati o scartati in silenzio da qualche parte nel mezzo.

Il sintomo è un tunnel che sembra sano finché non arriva traffico reale: i ping e i messaggi di controllo passano, una copia di file si blocca, niente nel registro lo spiega. Abbassate MTU e MRU insieme a entrambe le estremità. Regolare solo il client trasforma spesso un blocco netto in uno intermittente, che è peggiore da diagnosticare.

Una porta porta due conversazioni

L'UDP 1701 sta sotto entrambe le metà del protocollo, e questo solo fatto rompe più regole di firewall di qualsiasi altra parte dell'installazione. Prima arrivano una richiesta di inizio connessione di controllo e la sua risposta; la richiesta di sessione e la conferma che seguono non stabiliscono altro che la coppia di identificatori. Poi subentra PPP, con il controllo del collegamento, poi l'autenticazione, poi il protocollo di controllo IP per concordare gli indirizzi. Ogni fase ha il proprio vocabolario nel registro, e nessuna si annuncia come guasto L2TP.

Leggere una cattura esattamente in quest'ordine vi dice quale fase è fallita, e un guasto di autenticazione PPP non si riparerà modificando xl2tpd. La porta condivisa spiega un altro guasto comune: una regola che permette solo i primi pacchetti di un flusso lascia stabilire la sessione e poi blocca il trasferimento. Consentite 1701 per tutta la conversazione, in entrambe le direzioni.

Rendere utile il tunnel: inoltro e NAT

Una sessione da sola raggiunge solo il server. L'accesso a internet dei client richiede inoltro, una regola NAT per il pool sul collegamento in uscita e un DNS che il client possa davvero interrogare una volta attivo il collegamento. Il pool deve anche restare fuori dall'intervallo della LAN, altrimenti le risposte indirizzate ai client vengono consegnate localmente invece di essere respinte nel tunnel.

Sul server, abilitate l'inoltro con sysctl -w net.ipv4.ip_forward=1, traducete il pool con iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, poi accettate il traffico uscente del tunnel con una regola FORWARD per -i ppp0 -o eth0 e il traffico di ritorno con la regola speculare più -m state --state RELATED,ESTABLISHED. Rendete permanenti quelle regole tra i riavvii, perché un server che torna senza di esse sembra esattamente una configurazione L2TP rotta.

Raggiungere la LAN del server è un altro compito: aggiungete una rotta di ritorno per il pool sul router della LAN, oppure proxy ARP sul server. Nascondere i client dietro NAT quando qualcosa dentro la LAN deve indirizzarli direttamente non fa che programmare una seconda sessione di debug per più tardi.

Cosa non fa la pila nuda e come verificarlo

Nessuna parte di questa pila cifra i frame PPP, e nulla in essa autentica l'estremità remota come il server che avete davvero scelto. MS-CHAPv2 protegge sì lo scambio delle credenziali da un ascoltatore che si limita a guardare, ma un attaccante posizionato sul percorso può ancora interferire con la sessione. Il client nativo di Windows offre L2TP solo insieme a IPsec, quindi mettete in conto Linux, firmware dei router e client di terze parti come interlocutori. Trattate la configurazione nuda come un gradino diagnostico, mai come il punto in cui fermarvi.

Verificate in un ordine fisso: eseguite xl2tpd -D in primo piano, osservate il registro per la fase PPP, leggete l'indirizzo assegnato da ip addr alle due estremità, poi catturate l'UDP 1701 per confermare che i dati scorrano dopo che la sessione è attiva. Se tutti e quattro coincidono e il traffico fallisce ancora, la colpa è dell'instradamento, del NAT o della MTU, non dell'L2TP stesso.