SSTP autentifică mai întâi serverul și apoi utilizatorul

Un client SSTP poate finaliza TLS și totuși respinge utilizatorul o secundă mai târziu. Această secvență nu este un bug, este stiva de protocoale: mai întâi securitatea transportului, apoi autentificarea utilizatorului. Deoarece cele două etape eșuează cu mesaje diferite, au nevoie și de remedieri diferite. Citirea etapei care a produs eroarea este cea mai mare parte a diagnosticului.

Un certificat de încredere dovedește punctul final; despre cont nu spune nimic.

Ce stabilește strângerea de mână TLS

Clientul validează certificatul prezentat de server față de magazinul său de încredere, numele de gazdă solicitat, fereastra de valabilitate și orice politică suplimentară aplicată de platformă. Asta protejează conexiunea către punctul final vizat. Nu dovedește că un anumit cont este activat, neexpirat sau permis pentru acces la distanță. Acestea sunt întrebări separate puse mai târziu de alt component.

De aceea, eliminarea verificărilor de certificat pentru a ajunge la promptul de autentificare este reparația greșită. Obțineți un prompt de autentificare pe o conexiune pe care nu o puteți verifica. O eroare de certificat ține de numele de gazdă, ceas, lanț sau configurația de încredere.

Ce adaugă SSTP și PPP deasupra

SSTP rulează peste HTTPS și transportă PPP în interior, cu propriul schimb de control în jurul conexiunii. Apoi PPP execută fazele sale de legătură și autentificare, iar metoda de autentificare depinde de politica serverului și de capacitatea clientului. PAP, CHAP, MS-CHAPv2 și EAP sunt toate opțiuni de autentificare PPP cu proprietăți foarte diferite. Verificarea utilizatorului din VPN este acea fază PPP, nu stratul TLS de dedesubt.

Respingerea unui utilizator poate însemna deci acreditări, o restricție de cont sau o nepotrivire de metodă.

Motivul din partea serverului este mult mai util decât resetarea fiecărui secret din profil. Un eveniment de cont dezactivat și o eșuare a negocierii metodei arată similar la client și nu au nimic în comun la server.

Asociați eroarea cu etapa

Verificați dacă conexiunea ajunge la TLS, apoi la schimbul HTTP al SSTP, apoi la faza PPP. Păstrați marcajele de timp din jurnale aliniate între încercări, astfel încât o eșuare anterioară să nu fie confundată cu un succes ulterior. Un client care înregistrează două încercări într-o fereastră va părea altfel că a eșuat la ultima etapă atinsă. Citiți prima eroare relevantă, nu ultima linie.

Aceeași aliniere contează pe partea serverului, unde înregistrarea autentificării și jurnalul de transport sunt adesea fișiere separate cu ceasuri separate. Două minute de decalaj sunt suficiente pentru ca o cauză evidentă să pară imposibilă.

După autentificare, autorizarea rămâne separată

O autentificare reușită nu acordă toate resursele private. Rutele determină ce este accesibil, DNS-ul determină ce se rezolvă, iar fiecare serviciu își aplică în continuare propriile permisiuni. O sesiune afișată ca conectată este o afirmație despre tunel, nu despre partajarea fișierelor. Când un utilizator se poate conecta și nu poate ajunge la o gazdă, faza tunelului s-a încheiat deja.

Este aceeași stratificare pe care a arătat-o strângerea de mână, un nivel mai sus.

Păstrați recuperarea contului în procesul acceptat de operator în loc să modificați setările de transport ca răspuns la un refuz explicit al utilizatorului. Modificarea transportului pentru a repara un cont dezactivat este genul de reparație care pare să funcționeze când contul este reactivat dintr-un motiv nelegat.