La VPN di Windows non si connette? Abbina il codice al registro eventi

Venerdì funzionava. Lunedì lo stesso client Windows risponde con una finestra che dice che il tentativo di connessione è fallito, e la frase sotto è una che hai già visto per una dozzina di problemi non correlati. Quella finestra è la fine di una catena, non l'inizio. Windows nasconde la fase in cui il tentativo è davvero morto, e due piccole prove la nominano: il codice numerico di risultato e un evento RasClient di quello stesso minuto. Questo è l'ordine che uso — fissa il tentativo, leggi il codice, estrai l'evento, poi cambia esattamente uno strato.

Il testo della finestra è l'ultimo passo, non la causa

La frase che leggi viene scelta dopo che il tentativo si è già svolto. "La connessione è stata terminata dal computer remoto prima che la connessione fosse stabilita" compare quando un server riaggancia a metà negoziazione, quando IPsec è fallito prima che il tuo nome utente fosse mai inviato, e quando un criterio ha rifiutato il tunnel di netto. Tre responsabili diversi, una frase. Tratta la formulazione come una classe di sintomi e non lasciarle guidare nulla finché il codice non è d'accordo.

Quello che puoi ancora fissare è il tentativo stesso. Annota il nome della connessione, il tipo di tunnel salvato nel profilo — PPTP, L2TP/IPsec, SSTP o IKEv2 —, l'ora al secondo e il codice. Se non sei sicuro di quale protocollo abbia davvero girato, apri %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk e leggi la voce invece di fidarti della memoria; un profilo riutilizzato per un nuovo protocollo conserva il suo vecchio nome visualizzato.

Leggi il numero prima di leggere le parole

I codici cadono in tre fasi, e la fase conta più della formulazione esatta: uno scambio di autenticazione raggiunto e rifiutato, un server che non ha mai risposto, o una negoziazione crollata dopo che il collegamento è salito. 691 è il primo tipo — il controllo delle credenziali è stato eseguito ed è fallito, che sia per una password errata, un account bloccato o scaduto, o un protocollo di autenticazione che il server non accetta. 812 è anch'esso un rifiuto, ma con credenziali valide: un criterio sul server di accesso remoto ha deciso contro di te. Microsoft mantiene la lista dei codici di errore per connessioni dial-up e VPN canonica, e vale la pena leggere lì il tuo numero prima di cercare il testo del messaggio.

809 è la classe opposta: non è tornato nulla. È un problema di percorso — TCP 443 filtrato per SSTP, GRE bloccato per PPTP, UDP 500 e 4500 o ESP scartati per il pass-through IPsec. Una nuova password non può risolverlo e nemmeno un certificato nuovo. 720 significa che il collegamento è salito e PPP non ha mai finito di negoziare, il che punta a un disallineamento di protocollo o a un server che non è riuscito ad assegnare un indirizzo. 789, o 13801 su IKEv2, è l'identità dentro IPsec: un certificato il cui soggetto non corrisponde al nome che componi, una catena non attendibile, o una chiave precondivisa che differisce tra i due estremi.

Estrai l'evento RasClient di quello stesso minuto

In Visualizzatore eventi, Windows Logs > Application filtrato per origine RasClient è il primo posto da guardare. L'articolo di Microsoft sull'errore 720 rimanda all'evento 20227 di quel registro. Lo stesso provider emette altri identificatori per altri esiti, quindi leggi il messaggio e il codice di risultato incorporato invece di trattare l'ID come la diagnosi; una finestra generica più un 20227 che porta 720 è già una storia molto più stretta.

Da PowerShell, senza cliccare nell'interfaccia grafica:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

Un risultato vuoto è informativo. Di solito significa che la composizione non è mai arrivata abbastanza lontano perché RAS registrasse qualcosa, o che il software fallito non è affatto il client nativo — i client di terze parti tengono la propria diagnostica e spesso non scrivono nulla nel registro Application. Controlla il registro del fornitore prima di concludere che la registrazione degli eventi è rotta.

Costruisci una sola cronologia invece di un mucchio di eventi

I cicli di nuovo tentativo producono rumore. Cinque riconnessioni automatiche lasciano un grappolo di eventi, e la tentazione è leggerli come un'unica sequenza con un'unica causa. Sono cinque tentativi separati, e solo alcuni hanno raggiunto un server. Prendi una finestra di due o tre minuti, un nome di connessione, ed elenca ogni evento con il proprio codice prima di interpretare qualsiasi cosa.

Poi chiediti dove si è fermato il tentativo. Quando il gateway o il backend di autenticazione non conserva alcun record per quel timestamp, il client non l'ha mai raggiunto, e stai guardando un problema di raggiungibilità. Quando il backend mostra una richiesta e un rifiuto, la decisione è stata presa lì, e si applica la classe credenziali o criterio. Confronta gli orologi prima di confrontare gli orari: i client riportano l'ora locale, molti gateway registrano in UTC, e uno scostamento farà sembrare non correlata una coppia perfettamente correlata.

Per una cattura ripetibile, componi dalla riga di comando e lascia che stampi il risultato:

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

La console mostra il numero che la GUI nasconde dietro un testo amichevole, ed eseguirlo due volte ti dice se il codice è stabile o intermittente.

Cosa ti dice ogni fase di cambiare

Dare un nome alla fase è utile solo se riduce l'insieme delle modifiche a un solo strato:

• 691 — autenticazione: il metodo EAP che il client offre contro quello che il server accetta, lo stato dell'account, la scadenza della password, il permesso di accesso remoto.
• 812 — criterio del server: il criterio di accesso remoto o la regola NPS che corrisponde a questo utente e a questa finestra temporale.
• 809 — raggiungibilità: regole del firewall sul percorso, NAT e pass-through del protocollo, la porta che il tipo di tunnel scelto richiede.
• 720 — negoziazione PPP: disallineamento del protocollo di autenticazione, assegnazione dell'indirizzo, un'impostazione PPP lato server.
• 789 / 13801 — identità IPsec: soggetto del certificato contro il nome che componi, catena di attendibilità, chiave precondivisa.

Cambia una di quelle cose, riprova lo stesso profilo e annota il nuovo codice. Un codice diverso dopo una modifica è un progresso, non una contraddizione: hai spostato il guasto a una fase successiva, ed è così che appare riparare una stretta di mano a più fasi. Quello che non dovresti fare è modificare firewall, certificato e password in un'unica sessione e poi attribuire il merito a quello arrivato per ultimo.

Condividi le prove, non l'ambiente

I messaggi di evento sono più ricchi di quanto sembrino. Portano il nome della connessione, l'account, spesso il nome o l'indirizzo interno del gateway, e talvolta un'impronta di certificato. Conserva l'originale dove deve stare, e costruisci una copia redatta separata per chiunque altro; ribattere la cronologia a memoria perde esattamente i dettagli che la rendono utile.

Un passaggio di consegne che viene lavorato ha bisogno di cinque campi: il codice, la fase a cui appartiene, il client e il tipo di tunnel, il timestamp con il suo fuso orario, e se il gateway ha visto la richiesta. Tutto il resto è facoltativo. Con quei cinque, la persona successiva può distinguere una discussione sulle credenziali da una sull'instradamento senza ripetere l'indagine.

Prima di chiudere qualcosa, riproduci il tentativo sullo stesso profilo e conferma dove atterra ora il codice. Un successo lo chiude; un guasto diverso significa che la fase originale è riparata e hai la successiva in mano.