Errore PPTP 800 contro 812 e cadute dopo un minuto

Tre messaggi di errore di un solo client PPTP di solito descrivono tre guasti diversi. L’errore 800 significa che il tunnel non si è mai formato, l’errore 812 significa che il server ha rifiutato il metodo di autenticazione, e una caduta dopo un minuto è un timer keepalive che decide che un peer sano se n’è andato. Ogni fase fallisce per la propria ragione, quindi ciascuna richiede il proprio controllo.

L’errore 800 significa che il tunnel non si è mai formato

Windows segnala l’errore 800 quando non riesce affatto a costruire il tunnel, e il testo su un server irraggiungibile o parametri di sicurezza inadatti è un riepilogo, non una diagnosi. PPTP ha bisogno di due cose separate dalla rete prima che venga esaminata qualsiasi credenziale. TCP 1723 trasporta il canale di controllo, e il protocollo IP 47, GRE, trasporta il carico incapsulato.

Prova quel percorso esterno da fuori della tua LAN, perché una connessione che funziona in ufficio non dimostra nulla sul bordo:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Se 1723 risponde e la cattura resta vuota mentre il client tenta di connettersi, il percorso sta scartando il protocollo 47. Un router con 1723 inoltrato ma il passthrough PPTP disattivato produce esattamente quel modello: la stretta di mano TCP si completa, poi i pacchetti GRE spariscono, così il guasto sembra un problema di credenziali anche se non è stato tentato alcun accesso.

Indirizza l’inoltro all’indirizzo LAN attuale del server, attiva il passthrough PPTP dove il router lo offre e riprova dallo stesso punto esterno. Quando GRE viene filtrato a monte e non puoi cambiarlo, SSTP su TCP 443 o L2TP/IPsec su UDP 500 e 4500 ha migliori possibilità di qualsiasi modifica tu possa fare sul lato Windows.

L’errore 812 è il server che rifiuta il tuo metodo di autenticazione

L’errore 812 torna dopo che il tunnel è su, per questo sembra un problema di password. Il server rifiuta il metodo di autenticazione negoziato per la connessione, non necessariamente la password stessa. Sul client, apri la voce VPN, vai alla scheda sicurezza, imposta il tipo su Point-to-Point Tunneling Protocol, scegli l’elenco esplicito dei protocolli e seleziona Microsoft CHAP versione 2.

Puoi leggere l’impostazione attuale senza passare dalla finestra di dialogo:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

Un server che richiede MS-CHAP v2 rifiuta un client lasciato su PAP o su un tipo automatico che negozia qualcosa di più debole, e l’errore arriva prima che venga valutata qualsiasi password utente. Il formato dell’account è l’altra metà dello stesso rifiuto. In un caso Windows ha inviato un’identità di account Microsoft nella forma MicrosoftAccount\[email protected] mentre il server voleva un account locale o di dominio. Digitare SERVERNAME\username ha detto a Windows quale archivio account consultare e ha eliminato l’errore. Inserisci il nome a mano invece di lasciare che una credenziale salvata ripeta un formato precedente.

Le cadute dopo un minuto sono una decisione di keepalive

Quando il tunnel si connette, passa un po’ di traffico e poi si disconnette, guarda il comportamento dell’eco LCP del server prima di toccare il client. Il demone chiede periodicamente al peer di confermare che è ancora lì. Se arrivano troppe poche risposte entro il budget configurato, la sessione viene abbattuta anche se l’utente ha ancora un collegamento funzionante.

Su un server Linux pptpd quei valori vivono in /etc/ppp/options.pptpd, e la riparazione abituale è allargare il budget invece di accorciare l’intervallo:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Trenta mancate risposte a un intervallo di cinque secondi perdonano una breve pausa invece di dichiarare il peer sparito. Ridurre il conteggio a uno o due trasforma il jitter normale su un percorso tradotto in una disconnessione più o meno ogni minuto. Se il tuo server è Windows RRAS invece di pptpd, guarda invece il timeout della sessione PPP e il criterio di disconnessione per inattività. Quelli vivono altrove, e modificare un file pppd che non esiste non cambierà nulla.

Le sottoreti sovrapposte rompono il percorso dati

Un tunnel PPTP può autenticarsi in modo pulito e comunque non raggiungere nulla quando entrambe le sedi usano lo stesso intervallo privato, per esempio 192.168.1.0/24 in ufficio e a casa. Il client non può dire a quale host si riferisce un dato indirizzo, e alcuni stack rifiutano del tutto di installare la rotta invece di sceglierne una.

Trattalo come un difetto di progettazione e rinumera un lato, oppure dai al client un intervallo di accesso tradotto di proposito. Il debug del client PPTP non può riparare uno spazio di indirizzi che esiste due volte, e il sintomo continuerà a sembrare una caduta casuale.

Inizia dalla fase che ha fallito: GRE per l’800, il metodo e la stringa dell’account per l’812, impostazioni di eco per un tunnel che muore secondo l’orario.