PPTP si connette e poi si blocca dietro Linux NAT: l’assistente GRE

Qualcuno inoltra la 1723, il client raggiunge il server, parte l’autenticazione e poi tutto si ferma senza un errore. La conclusione naturale è una password sbagliata, quindi la password viene digitata di nuovo tre volte. L’inoltro era a posto e le credenziali erano a posto. Ciò che si è rotto è un secondo protocollo che l’inoltro non ha mai coperto, e un valore predefinito del kernel che ha smesso silenziosamente di aiutare con esso.

L’inoltro non è mai stato il problema

Una regola di inoltro delle porte descrive il traffico TCP o UDP. Non può descrivere un payload che passa a un altro protocollo IP a metà sessione, e PPTP fa esattamente questo.

Ecco perché la connessione sembra sana fino al momento in cui si blocca. La parte che una regola di porta può governare è riuscita, e la parte che non può governare è quella che ha fallito.

TCP per il controllo, GRE per i dati

La chiamata viene negoziata su TCP 1723. Una volta attiva, il payload passa in GRE, protocollo IP 47, che non porta alcun numero di porta. Una regola che si basa sulle porte non ha nulla con cui confrontarsi.

Ciò che GRE trasporta è un identificatore di chiamata nella sua intestazione, e il traduttore NAT deve riscrivere quel campo in modo coerente in entrambe le direzioni, altrimenti le due metà della sessione smettono di essere d’accordo. Una direzione riscritta e l’altra no producono una sessione che si autentica e poi scarta ogni pacchetto dati. È esattamente la forma del sintomo: successo, poi silenzio.

GRE nudo senza PPTP non richiede questa riscrittura, ed è per questo che un tunnel GRE semplice può funzionare attraverso un router che fallisce per un client PPTP sullo stesso percorso.

Quattro moduli e un sysctl che li ha spenti

Due moduli gestiscono l’incapsulamento, nf_conntrack_proto_gre e nf_nat_proto_gre. Altri due gestiscono l’identificatore di chiamata, nf_conntrack_pptp e nf_nat_pptp. Caricare l’ultimo di questi trascina gli altri tramite dipendenze, quindi un elenco dei moduli dovrebbe mostrare tutti e quattro.

Le istruzioni più vecchie usano un prefisso ip_ dell’era 2.6. Quei comandi possono sembrare in esecuzione mentre non caricano nulla, quindi controllate l’elenco caricato invece dello stato di uscita.

Averli caricati non basta più. Da Linux 4.7 il sysctl net.netfilter.nf_conntrack_helper vale 0 per impostazione predefinita, il che disattiva l’assegnazione automatica degli assistenti per i nuovi flussi. Un router può avere tutti i moduli e comunque non tradurre nulla. Controllate il valore effettivo prima di guardare di nuovo l’elenco dei moduli.

O riattivate l’assegnazione automatica a livello globale, oppure collegate l’assistente ai flussi che ne hanno bisogno e lasciate in pace tutto il resto:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

La seconda opzione è quella da preferire. Limita il comportamento al traffico PPTP invece di riattivare l’assegnazione automatica su tutto il router.

Aprire un protocollo che non ha porte

Una regola del firewall che consente la 1723 non dice nulla sul protocollo 47. Su firewalld, consentite il protocollo nella zona rivolta al client. Su iptables semplice, accettate il protocollo gre nella catena di input.

Poi catturate su entrambi i lati. Pacchetti che lasciano il client senza risposte in arrivo significano che il percorso di ritorno è filtrato, e questo è un guasto diverso da una credenziale rifiutata.

Dopo la connessione, il limite di dimensione

GRE inserisce un’intestazione, e PPP al suo interno ne aggiunge altre, quindi un collegamento funzionante riporta una MTU ben sotto 1500. Le risposte piccole si caricano e quelle grandi si bloccano, il che sembra un secondo problema non correlato che appare nel momento stesso in cui il primo è risolto.

Leggete la MTU sull’adattatore PPP del client e conciliatela con il calcolo del router stesso invece di abbassare i numeri finché qualcosa funziona. I pacchetti di dimensione piena che partono senza che nulla torni indicano quel limite e non la traduzione.

Riparare il percorso rimette l’utente al lavoro, e non rende PPTP una buona scelta. MS-CHAPv2 e RC4 sono deprecati da tempo, quindi trattate il caricamento dei moduli come una correzione temporanea e pianificate il passaggio a un protocollo mantenuto.