Passthrough PPTP assente: correggi l’errore 807 di Windows VPN

L’inoltro del TCP 1723 spesso apre la prima parte di PPTP e lascia il resto rotto, così Windows restituisce ancora l’errore 807 al tentativo. Il riflesso successivo è aggiungere una regola per la porta 47, ed è proprio quel passaggio a sprecare un pomeriggio: GRE è un numero di protocollo nell’intestazione IP, non una porta che una tabella di inoltro possa far corrispondere. Finché il router non lascia passare il protocollo 47 e non lo lega alla stessa chiamata, il tunnel non può partire. Le sezioni seguenti separano i due canali e poi li provano uno alla volta.

Una tabella delle porte non ha una riga per un numero di protocollo

PPTP usa due conversazioni che falliscono in modi diversi. Quella su TCP 1723 avvia la chiamata, trasmette le informazioni del collegamento e la chiude quando l’utente si disconnette. Il lato del carico utile gira dentro GRE, che l’intestazione IP etichetta con il numero di protocollo 47, e dentro quel tunnel PPP negozia il collegamento mentre MS-CHAPv2 controlla le credenziali.

Poiché GRE non porta alcuna intestazione di trasporto, non espone porte, quindi una regola scritta per le porte non ha nulla con cui corrispondere. Un router che inoltra il 1723 crea una mappatura per quella sessione TCP e si ferma lì. Il firmware che gestisce la seconda metà chiama la funzione passthrough PPTP o PPTP ALG, e alcuni firmware non offrono né l’una né l’altra e non menzionano mai la lacuna. L’etichetta della casella conta meno della domanda se il protocollo 47 sia riconosciuto o no.

Che cosa segnala Windows quando il percorso dati muore

L’errore 807 dice che la connessione non è stata completata, il che in pratica significa che la chiamata ha raggiunto il server e il canale dati non è salito. È un verdetto sul trasporto, non un verdetto sull’account. L’errore 691 è quello che punta alle credenziali o a una discrepanza nel protocollo di autenticazione, quindi ti manda altrove del tutto.

Lavora sul trasporto prima di toccare la password. Cambiare le credenziali per inseguire l’807 lascia il guasto reale al suo posto e rende il tentativo successivo più difficile da leggere.

Perché un secondo client rompe un tunnel funzionante

Senza porte che li distinguano, un dispositivo NAT non può separare due client PPTP come separa due sessioni HTTPS. Per questo molti apparecchi domestici consentono una sola chiamata PPTP e la tracciano per indirizzo di origine. Un portatile che funzionava da solo smette di completare appena un secondo computer compone, e dal lato client il guasto sembra casuale. Questo schema appartiene al firmware, e nessuna modifica del profilo lo altererà.

Osserva la tabella delle connessioni mentre entrambi i client compongono. Se solo il primo host detiene mai una mappatura, il router ha raggiunto il limite di ciò che supporta e nessuna impostazione lato client lo sposterà.

Dimostra quale metà sta fallendo

Conferma che il TCP 1723 arrivi prima di cambiare qualsiasi cosa sul router, perché quella risposta decide quale metà stai provando. Esegui questi comandi dal client Windows verso il tuo nome server. Il primo stampa se la porta ha risposto, e il secondo compone senza finestra di dialogo, il che rende confrontabili i tentativi ripetuti.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Un risultato vero al test della porta significa che il canale di controllo è aperto e che GRE è il sospetto rimasto. Un risultato falso significa che instradamento, filtro o inoltro sono rotti, e nessuna modifica a GRE lo salverà. Il lato dati va osservato dove è visibile, sul server o sul router.

tcpdump -ni any proto 47

L’equivalente in Wireshark è il filtro di visualizzazione ip proto 47, che è più facile affidare a chi non è a proprio agio in una shell. Un GRE che arriva senza che nulla esca in risposta significa che il percorso di ritorno va corretto.

Che cosa corregge davvero l’errore

Dove il router espone l’impostazione, abilita il passthrough PPTP o consenti esplicitamente il protocollo 47 su firmware che accetta regole. Su RouterOS la regola di inoltro fa corrispondere il protocollo direttamente, cosa che un inoltro basato sulle porte non avrebbe mai potuto fare. Il firmware consumer di solito nasconde la stessa decisione dietro una casella, a volte nelle impostazioni di sicurezza anziché nell’inoltro delle porte. Se un tale controllo non esiste, nulla sul client lo compenserà.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Sostituire PPTP è l’altra opzione e spesso la più economica. Un router che termina lui stesso la VPN evita il doppio NAT per i client in ingresso, e un protocollo che un NAT basato sulle porte già gestisce non ha affatto bisogno di passthrough: OpenVPN su UDP, SSTP su TCP 443 o L2TP/IPsec con NAT-T che incapsula ESP in UDP 4500. PPTP dipende anche da MS-CHAPv2, le cui debolezze documentate lo rendono una scelta scarsa per un nuovo impiego anche dopo che l’errore è sparito.

Annota quale regola ha fatto la differenza, perché lo stesso sito incontrerà lo stesso limite quando il secondo utente chiederà l’accesso. Una correzione a livello di protocollo appartiene alle note di rete, dove guarderà il prossimo tecnico.