VPN-ul din Windows nu se conectează? Potrivește codul cu jurnalul de evenimente

Vineri funcționa. Luni același client Windows răspunde cu o casetă de dialog care spune că încercarea de conectare a eșuat, iar propoziția de dedesubt este una pe care ai mai văzut-o pentru o duzină de probleme fără legătură. Acea casetă este sfârșitul unui lanț, nu începutul. Windows ascunde etapa în care încercarea a murit cu adevărat, iar două dovezi mici o numesc: codul numeric al rezultatului și un eveniment RasClient din același minut. Aceasta este ordinea pe care o folosesc — fixează încercarea, citește codul, extrage evenimentul și apoi schimbă exact un strat.

Textul casetei de dialog este ultimul pas, nu cauza

Propoziția pe care o citești este aleasă după ce încercarea s-a desfășurat deja. „Conexiunea a fost terminată de computerul la distanță înainte de a se stabili conexiunea” apare când un server închide la mijlocul negocierii, când IPsec a eșuat înainte ca numele tău de utilizator să fie trimis, și când o politică a respins tunelul din start. Trei proprietari diferiți, o propoziție. Tratează formularea ca o clasă de simptome și nu o lăsa să dirijeze nimic până când codul nu este de acord cu ea.

Ce mai poți fixa este încercarea în sine. Notează numele conexiunii, tipul de tunel salvat în profil — PPTP, L2TP/IPsec, SSTP sau IKEv2 —, ora până la secundă și codul. Dacă nu ești sigur ce protocol a rulat de fapt, deschide %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk și citește intrarea în loc să te bazezi pe memorie; un profil refolosit pentru un protocol nou își păstrează vechiul nume de afișare.

Citește numărul înainte de a citi cuvintele

Codurile cad în trei etape, și etapa contează mai mult decât formularea exactă: un schimb de autentificare la care s-a ajuns și care a fost refuzat, un server care nu a răspuns niciodată, sau o negociere care s-a prăbușit după ce legătura a urcat. 691 este primul tip — verificarea acreditărilor a rulat și a eșuat, fie din cauza unei parole greșite, a unui cont blocat sau expirat, fie a unui protocol de autentificare pe care serverul nu îl acceptă. 812 este și el un refuz, dar cu acreditări valide: o politică de pe serverul de acces la distanță a decis împotriva ta. Microsoft întreține lista codurilor de eroare pentru conexiunile prin apel și VPN canonică, și merită să citești acolo numărul tău înainte de a căuta textul mesajului.

809 este clasa opusă: nu a revenit nimic. Aceasta este o problemă de cale — TCP 443 filtrat pentru SSTP, GRE blocat pentru PPTP, UDP 500 și 4500 sau ESP aruncate pentru trecerea IPsec. O parolă nouă nu poate rezolva asta, iar un certificat nou nici atât. 720 înseamnă că legătura a urcat și PPP nu a terminat niciodată negocierea, ceea ce indică o incompatibilitate de protocol sau un server care nu a putut aloca o adresă. 789, sau 13801 pe IKEv2, este identitatea din interiorul IPsec: un certificat al cărui subiect nu se potrivește cu numele pe care îl formezi, un lanț neîncrezut, sau o cheie partajată în prealabil care diferă între cele două capete.

Extrage evenimentul RasClient din același minut

În Vizualizatorul de evenimente, Windows Logs > Application filtrat după sursă RasClient este primul loc unde să te uiți. Articolul Microsoft despre eroarea 720 indică evenimentul 20227 din acel jurnal. Același furnizor emite alți identificatori pentru alte rezultate, așa că citește mesajul și codul rezultatului încorporat în el în loc să tratezi ID-ul ca diagnostic; o casetă generică plus un 20227 care poartă 720 este deja o poveste mult mai îngustă.

Din PowerShell, fără să dai clic prin GUI:

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

Un rezultat gol este informativ. De obicei înseamnă că formarea nu a mers niciodată destul de departe ca RAS să înregistreze ceva, sau că software-ul care a eșuat nu este deloc clientul nativ — clienții terți își țin propria diagnoză și adesea nu scriu nimic în jurnalul Application. Verifică jurnalul furnizorului înainte de a concluziona că înregistrarea evenimentelor este stricată.

Construiește o singură cronologie în loc de o grămadă de evenimente

Buclele de reîncercare produc zgomot. Cinci reconectări automate lasă un grup de evenimente, iar tentația este să le citești ca o singură secvență cu o singură cauză. Sunt cinci încercări separate, și doar unele au ajuns la un server. Ia o fereastră de două sau trei minute, un singur nume de conexiune, și listează fiecare eveniment cu propriul cod înainte de a interpreta ceva.

Apoi întreabă unde s-a oprit încercarea. Când gateway-ul sau backend-ul de autentificare nu păstrează nicio înregistrare pentru acel marcaj de timp, clientul nu a ajuns niciodată acolo, și te uiți la o problemă de accesibilitate. Când backend-ul arată o cerere și un refuz, decizia a fost luată acolo, și se aplică clasa acreditărilor sau a politicii. Compară ceasurile înainte de a compara orele: clienții raportează ora locală, multe gateway-uri înregistrează în UTC, iar o diferență va face o pereche perfect corelată să pară fără legătură.

Pentru o captură repetabilă, formează din linia de comandă și lasă-o să tipărească rezultatul:

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

Consola arată numărul pe care GUI-ul îl ascunde în spatele unui text prietenos, iar rularea de două ori îți spune dacă codul este stabil sau intermitent.

Ce îți spune fiecare etapă să schimbi

Numirea etapei este utilă doar dacă micșorează setul de schimbări la un singur strat:

• 691 — autentificare: metoda EAP pe care o oferă clientul față de cea pe care o acceptă serverul, starea contului, expirarea parolei, permisiunea de acces prin apel.
• 812 — politica serverului: politica de acces la distanță sau regula NPS care se potrivește acestui utilizator și acestei ferestre de timp.
• 809 — accesibilitate: reguli de firewall pe cale, NAT și trecerea protocolului, portul de care are nevoie tipul de tunel ales.
• 720 — negocierea PPP: incompatibilitate de protocol de autentificare, alocarea adresei, o setare PPP de pe partea serverului.
• 789 / 13801 — identitatea IPsec: subiectul certificatului față de numele pe care îl formezi, lanțul de încredere, cheia partajată în prealabil.

Schimbă unul dintre acestea, retestează același profil și notează codul nou. Un cod diferit după o schimbare este progres, nu contradicție: ai mutat eșecul într-o etapă ulterioară, iar așa arată repararea unei strângeri de mână cu mai multe etape. Ce nu ar trebui să faci este să modifici firewall-ul, certificatul și parola într-o singură ședință și apoi să dai meritul celui care a venit ultimul.

Împărtășește dovezile, nu mediul

Mesajele de eveniment sunt mai bogate decât par. Ele poartă numele conexiunii, contul, adesea numele sau adresa internă a gateway-ului, și uneori o amprentă de certificat. Păstrează originalul acolo unde îi este locul și construiește o copie redactată separată pentru oricine altcineva; rescrierea cronologiei din memorie pierde exact detaliile care o fac utilă.

O predare care va fi lucrată are nevoie de cinci câmpuri: codul, etapa căreia îi aparține, clientul și tipul de tunel, marcajul de timp cu fusul lui orar, și dacă gateway-ul a văzut cererea. Tot restul este opțional. Cu aceste cinci, următoarea persoană poate distinge o dispută despre acreditări de una despre rutare fără a repeta investigația.

Înainte de a închide ceva, rulează din nou încercarea pe același profil și confirmă unde ajunge codul acum. Un succes o încheie; un eșec diferit înseamnă că etapa originală este reparată și o ai pe următoarea în mână.