Server PPTP dietro un router domestico: correggi prima 1723 e GRE

PPTP dietro un router domestico fallisce in due modi non correlati, e confonderli costa una serata intera. Un guasto è un buco nell'inoltro: il router lascia passare TCP 1723 e scarta il protocollo IP 47, quindi il client resta bloccato sull'errore 619. L'altro è un problema di dimensione: il tunnel sale, si autentica e poi si blocca quando un pacchetto di dimensione piena deve attraversare. Capire quale dei due hai è il primo vero passo; il resto confronta ciò che il tuo router può esprimere, non quale marca sia migliore.

Due trasporti, e solo uno ha una porta

PPTP si divide in due trasporti: una connessione di controllo su TCP 1723 e frame PPP incapsulati in GRE esteso, cioè il protocollo IP 47. GRE non ha un numero di porta, quindi una regola scritta come inoltro della porta 1723 non può coprirlo, qualunque nome dia al campo l'interfaccia web. Un router domestico di solito offre una casella chiamata passthrough PPTP invece di una regola di protocollo, e quella casella fa due cose: lascia passare il protocollo 47 attraverso il firewall e insegna al NAT a seguire il flusso GRE. Su un router Linux questi compiti sono moduli separati e regole separate, ed è per questo che un passthrough configurato a metà produce comunque un canale di controllo funzionante. Scopri quale metà è presente prima di cambiare qualcosa.

Anche il firewall del server stesso deve consentire il protocollo 47 dall'indirizzo del router. Un firewall dell'host che accetta solo 1723/tcp riproduce l'errore 619 dall'interno della LAN, così un inoltro rotto e una regola host rotta sembrano identici.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

Se i moduli mancano, caricali con sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre e rendi il caricamento permanente, perché un riavvio che dimentica l'helper trasforma un tunnel funzionante di nuovo nell'errore 619. La regola di inoltro deve accettare il protocollo 47 solo verso l'indirizzo del server, non tutta la LAN. La definizione di RFC 2637 separa il percorso di controllo e quello dei dati, ed è per questo che nessuna singola schermata di inoltro porte descrive PPTP completamente.

Casella di passthrough o regola di protocollo esplicita

Una casella di passthrough che apre solo il firewall è più vicina al giusto di un ALG che riscrive gli identificatori di chiamata. La metà firewall è prevedibile, perché il protocollo 47 viene accettato o scartato, e i contatori dicono quale. La metà della riscrittura è dove i produttori differiscono, perché gli identificatori di chiamata di PPTP sono per tunnel e un NAT che li modifica deve seguire ogni chiamata che tocca. Quando un client si connette e due no, l'ALG è il primo sospetto.

Una regola NAT di destinazione per il 1723 ha anche un problema di proprietà. Se una regola vecchia manda ancora il 1723 a un host che ha smesso di eseguire il server, i pacchetti finiscono su una porta chiusa e il servizio PPTP del router smette di rispondere, cosa che si legge come un guasto del firewall ma in realtà è una destinazione obsoleta. Leggi la regola e la sua destinazione prima di aggiungerne una seconda. Sui router che terminano PPTP da soli, la regola WAN compete con il servizio integrato, quindi scegli un solo proprietario per il 1723 e il protocollo 47.

Due client dietro lo stesso NAT sono il caso che separa un inoltro semplice da uno astuto. Inoltrare il protocollo 47 senza riscrivere gli identificatori di chiamata di solito si comporta meglio di un helper che prova a correggerli.

Misura il tunnel prima di dare la colpa al router

PPTP riduce il carico utile, e quella riduzione è aritmetica, non mistero. Ogni pacchetto del tunnel porta un'intestazione IP esterna, un'intestazione GRE estesa, un'intestazione PPP e, con la cifratura, un'intestazione MPPE. Quando il percorso non può trasportare il frame risultante, i pacchetti piccoli passano, l'accesso si completa e la sessione si blocca la prima volta che un trasferimento di file o uno handshake TLS invia un pacchetto di dimensione piena.

Calcola il numero invece di indovinarlo. Il GRE esteso costa 8 byte, PPP costa 4, MPPE costa 4 e l'intestazione IP esterna costa 20, quindi il tunnel mangia 36 byte prima di qualsiasi carico. Su una WAN PPPoE che termina a 1492, il PPP MTU più grande che ci sta è 1492 meno 36, cioè 1456. Imposta mtu e mru su quel valore nelle opzioni PPP e riprova con un ping senza frammentazione.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

Il ping misura il percorso, non il tunnel: 1464 byte di carico più 28 byte di intestazioni IP e ICMP riempiono esattamente un frame da 1492 byte. Se quel ping fallisce, abbassa il numero finché non passa e sottrai 36 dal risultato. Un MTU del tunnel impostato sopra il limite del percorso produce il blocco senza una sola riga di log che menzioni la dimensione.

PPTP, L2TP/IPsec o OpenVPN sullo stesso router

Lo stesso router può portare uno qualsiasi dei tre tunnel comuni, e la differenza è cosa deve esprimere. PPTP richiede due regole in due livelli diversi. L2TP su IPsec richiede UDP 500 e 4500 per lo scambio di chiavi e, se NAT-T non lo porta, il protocollo 50 per il carico. OpenVPN richiede una sola porta UDP e nessun helper.

La colonna L2TP non è automaticamente più amichevole di GRE. ESP è il protocollo IP 50 e non ha nemmeno una porta, quindi un router che ha difficoltà con il protocollo 47 può averle con il protocollo 50 per lo stesso motivo. NAT-T esiste per incapsulare ESP dentro UDP 4500, e quando entrambe le estremità lo supportano la regola del protocollo 50 diventa superflua. È una proprietà delle estremità, non della casella PPTP del router. Conferma quale incapsulamento ha realmente negoziato il client prima di scrivere regole per entrambi.

OpenVPN è l'opzione con meno parti in movimento lato router. Una porta UDP, un inoltro, nessun helper di tracciamento connessioni e nessuna riscrittura degli identificatori di chiamata. Lo scambio è un client da installare invece di un compositore integrato, e spesso è l'unica ragione per cui PPTP resta nella conversazione.

Cosa riparare e cosa sostituire

Correggere l'inoltro e l'MTU ti dà un tunnel che funziona, non uno che dovresti tenere. L'autenticazione MSCHAPv2 di PPTP è attaccabile da anni, e un tunnel funzionante sposta credenziali che possono essere recuperate offline. Se il dispositivo remoto può eseguire L2TP/IPsec o OpenVPN, tratta la riparazione come una misura temporanea con una data.

La decisione si riduce a cosa supporta l'estremità remota e a quanto deve durare l'accordo. Un apparato legacy che parla solo PPTP riceve la riparazione; tutto ciò che può installare un client viene migrato.

Prima di chiudere il ticket, conferma che il client sopravvive a un trasferimento grande e non solo a un accesso, e che il router mantiene ancora la sua regola del protocollo 47 dopo un riavvio. Un tunnel che passa una copia di file e muore dopo il successivo aggiornamento del firmware non è mai stato finito.