Il tunneling diviso PPTP non funziona: correggi prima il percorso GRE

Osservate una connessione PPTP che sale ed è facile credere che la parte difficile sia finita: il client si autentica, compare un adattatore ppp0 o WAN Miniport e la finestra di stato diventa verde. Poi la prima richiesta a un host interno va in timeout e la colpa è del profilo. In pratica ci sono due livelli indipendenti da superare: il trasporto esterno che porta TCP 1723 e GRE, e la politica interna che decide quali destinazioni usano l’interfaccia PPP. Uno stato verde dimostra solo che il primo livello ha negoziato; del secondo non dice nulla.

Seguite il client dal profilo alla socket di controllo

Aprire il log del client e trovare il punto in cui contatta il server. PPTP apre prima una connessione TCP alla porta 1723 e negozia i parametri del tunnel su quel canale. Se questo passo fallisce, nulla di successivo conta, e l’errore di solito indica l’indirizzo del server o un timeout.

Confermate la connessione di controllo sul filo prima di toccare qualsiasi rotta. Sul client o su una porta mirror, catturate TCP 1723 per un tentativo di connessione:

sudo tcpdump -ni any 'tcp port 1723' -c 20

Una stretta di mano completata e una sessione stabilita significano che il canale di controllo esterno funziona. Un SYN che non riceve mai un SYN-ACK indica un firewall, un indirizzo del server errato o un provider che filtra la porta. Una stretta di mano seguita da un reset immediato spesso significa che il server ha rifiutato le credenziali o il tipo di tunnel.

GRE è un secondo protocollo, non una porta

PPTP trasporta il carico PPP dentro GRE esteso, il protocollo IP 47, che non ha un numero di porta che un router possa seguire. Per questo una regola che consente TCP 1723 può ancora lasciare il tunnel senza percorso dati. I dispositivi NAT con stato devono capire l’ID di chiamata dentro GRE per rimappare le risposte, e molti non lo fanno. La specifica PPTP tiene il canale di controllo e il carico GRE come pezzi separati, e anche il vostro piano di test deve farlo.

Tenete d’occhio il protocollo 47 nella stessa cattura, poi confrontate ciò che esce con ciò che torna:

sudo tcpdump -ni any 'proto gre' -c 20

I pacchetti che escono senza risposte, mentre TCP 1723 resta sano, sono la firma classica di GRE bloccato. Il passthrough PPTP su un router domestico è una funzione di quel firmware specifico, quindi una rete d’albergo funzionante non dimostra nulla sulla successiva. Se il router non offre passthrough e non potete cambiarlo, il problema è la scelta del protocollo, non la tabella delle rotte.

Dimostrate che il tunnel sposta un pacchetto

Quando GRE fluisce, la negoziazione PPP assegna un indirizzo all’interfaccia del client. Leggete l’assegnazione invece di presumerla:

ip -4 addr show ppp0

Fate ping all’indirizzo del peer mostrato come destinazione del collegamento punto a punto. Una risposta in questa fase dimostra che il percorso incapsulato funziona da estremo a estremo e che il server risponde dentro il tunnel. Se il peer risponde ma gli host interni no, il trasporto esterno è a posto e il guasto si è spostato verso l’interno.

Fatelo prima di aggiungere qualsiasi rotta divisa. Un cambio di rotta fatto mentre il trasporto è rotto crea una seconda variabile e nasconde la prima.

Scrivete la politica divisa, DNS incluso

L’instradamento diviso è un elenco di decisioni, non una casella di controllo. Ogni prefisso privato che deve attraversare il tunnel ha bisogno di una rotta attraverso l’interfaccia PPP, e ogni prefisso che deve restare locale deve esserne assente. Una rotta per una sottorete applicativa senza una rotta corrispondente al suo resolver privato è un modo comune di creare un’interruzione che sembra un’applicazione rotta.

Controllate la decisione che il kernel prende per un indirizzo di ogni categoria:

ip route get 10.20.5.10
ip route get 203.0.113.25

La prima deve nominare ppp0, la seconda il gateway ordinario. Se entrambe nominano la stessa interfaccia, la politica non è affatto divisa. Aggiungete l’indirizzo del server DNS stesso alla lista tunnel, altrimenti la risoluzione dei nomi per gli host interni esce dal resolver locale e non restituisce nulla di utile.

Un controllo ripetibile in cinque passi

Eseguite i livelli in ordine e fermatevi al primo che fallisce: canale di controllo, visibilità di GRE, risposta del peer PPP, rotta divisa per un indirizzo interno e una richiesta applicativa attraverso il tunnel. Ogni passo ha il suo comando, così un guasto è attribuibile invece che misterioso.

Una versione compatta per un client Linux è questa:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Su Windows vale lo stesso ordine con route print e lo stato dell’adattatore mostrato nel client. PPTP è un protocollo legacy, e se il server offre SSTP o IKEv2, spostarsi è di solito un uso migliore del tempo che regolare un percorso che dipende dal passaggio del protocollo 47 a ogni salto. Controllate il certificato e il contratto di autenticazione del sostituto invece di copiare un vecchio profilo in una nuova versione.