Un utilizator nu se poate conecta la VPN: un diagnostic ordonat

Când o persoană nu reușește să se conecteze în timp ce restul echipei continuă să lucreze, întrebarea utilă nu este ce s-a stricat, ci care strat nu a fost de acord. Autentificarea este un lanț: clientul pornește, gateway-ul răspunde, o identitate este afirmată, un al doilea factor este satisfăcut, politica este evaluată, și abia apoi curge traficul. O întrerupere oriunde în acel lanț ajunge la dumneavoastră ca aceeași propoziție de la utilizator, așa că prima sarcină este să găsiți veriga care a eșuat cu adevărat.

Tratați raportul ca punct de plecare și nu ca diagnostic. Verificările de mai jos merg de la cea mai ieftină, iar fiecare este scrisă să încheie investigația atunci când eșuează.

Stabiliți etapa și marca de timp

Notați patru lucruri înainte de a atinge orice configurație: clientul și versiunea lui, formularea exactă de pe ecran, minutul încercării și rețeaua în care se afla persoana. Formularea poartă informație reală, pentru că acreditările respinse, un gateway care nu răspunde și o autentificare finalizată care tot nu poate deschide o pagină internă sunt trei probleme diferite cu trei responsabili diferiți. Observați dacă clientul a produs o linie de jurnal locală, fiindcă un client care nu a trimis niciodată un pachet nu are nimic de adăugat la o căutare pe partea de server. Cu marca de timp înregistrată, fiecare interogare ulterioară devine o căutare, nu o vânătoare.

Opriți ghicirea parolelor în acest punct. Unde contul are o limită de reîncercări, o rafală de încercări rapide îl poate bloca și poate adăuga o a doua defecțiune artificială peste cea reală. Înregistrați câte încercări au fost deja făcute, ca o blocare să nu fie confundată mai târziu cu un simptom nou. Un cont blocat vă ia și capacitatea de a distinge o parolă greșită de o politică respinsă, fiindcă ambele sosesc ca refuz.

Citiți evenimentul de identitate pentru acea singură încercare

Rugați administratorul să extragă înregistrarea de autentificare care corespunde minutului notat. Într-o implementare Windows NPS, ghidul de depanare NPS al Microsoft documentează evenimentul de respingere 6273 împreună cu codul de motiv care îl însoțește, iar acesta separă de obicei un utilizator necunoscut, acreditări proaste, o nepotrivire de politică și un apel abandonat dintr-un motiv fără legătură.

Un rezultat gol este și el informație. Dacă nimic nu a ajuns la serviciul de identitate, încercarea a murit mai devreme: o adresă de gateway învechită în profil, un ascultător la care clientul nu poate ajunge sau un host scos din uz în timp ce profilul continua să trăiască. Dacă înregistrarea există și raportează succes, acreditările nu sunt problema, iar discuția se mută spre autorizare sau spre rutarea din spatele gateway-ului. Aceste două rezultate indică direcții opuse, de aceea căutarea în jurnale trebuie să aibă loc înainte ca cineva să reinstaleze un client.

Păstrați codul de motiv în tichet. Acel singur câmp transformă următoarea apariție într-o căutare de cinci minute în loc de o investigație repetată. Împerecheați-l cu versiunea clientului, fiindcă un cod care apare într-o compilare este o altă conversație decât unul care apare în fiecare compilare.

Schimbați o singură condiție o dată, în limitele politicii

Tentația este să reinstalați clientul, să resetați parola și să mutați laptopul într-o altă rețea dintr-o singură trecere. Asta repară uneori simptomul și distruge mereu dovezile. Alegeți în schimb o singură înlocuire permisă: aceeași persoană pe un al doilea dispozitiv înregistrat, sau o identitate de test aprobată pe același dispozitiv. Fiecare înlocuire răspunde exact la o întrebare, așa că un succes restrânge defecțiunea la partea pe care ați schimbat-o în loc să dea vina pe VPN în ansamblu.

Nu împrumutați acreditările unui coleg pentru această comparație. Folosiți o identitate de test prin procesul acceptat și nu copiați niciodată o cheie de dispozitiv și nu săriți înregistrarea pentru că ar fi mai rapid. Unde politica interzice complet o înlocuire, acea restricție face parte din sistemul testat și aparține înregistrării, nu unei soluții ocolitoare.

Confirmați reparația pe calea inițială

Când veriga ruptă este identificată, reparați doar acea verigă și repetați încercarea inițială: aceeași persoană, același dispozitiv, aceeași rețea, aceeași aplicație. Un cont de test care se conectează din VLAN-ul de administrare dovedește că gateway-ul este viu și nu dovedește nimic despre marțea dimineața a utilizatorului. Rugați utilizatorul să efectueze acțiunea care a eșuat, nu una mai simplă, fiindcă un ping reușit spune puțin despre o partajare de fișiere respinsă.

Închideți tichetul cu ce a fost exclus și ce s-a schimbat. Acea notă este diferența dintre o salvare punctuală și ceva ce următorul inginer de gardă va putea refolosi.