SSTP najprej preveri strežnik in šele nato uporabnika
SSTP najprej preveri strežniško potrdilo in uporabnika overi pozneje, prek PPP. Povežite napako z ustrezno stopnjo, namesto da bi se dotaknili obeh hkrati.
Odjemalec SSTP lahko dokonča TLS in vseeno sekundo pozneje zavrne uporabnika. To zaporedje ni hrošč, to je protokolni sklad: najprej varnost prenosa, nato overjanje uporabnika. Ker obe stopnji spodletita z različnimi sporočili, potrebujeta tudi različne popravke. Branje, katera stopnja je povzročila napako, je večina diagnostike.
Zaupanja vredno potrdilo dokazuje končno točko; o računu ne pove ničesar.
Kaj ugotovi rokovanje TLS
Odjemalec preveri potrdilo, ki ga predstavi strežnik, glede na svojo shrambo zaupanja, zahtevano ime gostitelja, okno veljavnosti in morebitno dodatno politiko, ki jo uporablja platforma. To zaščiti povezavo do predvidene končne točke. Ne dokazuje pa, da je določen račun omogočen, ni potekel ali je pooblaščen za oddaljeni dostop. To so ločena vprašanja, ki jih pozneje postavi druga komponenta.
Zato je odstranjevanje preverjanj potrdil, da bi prišli do poziva za prijavo, napačen popravek. Dobite poziv za prijavo na povezavi, ki je ne morete preveriti. Napaka potrdila spada k imenu gostitelja, uri, verigi ali konfiguraciji zaupanja.
Kaj dodata SSTP in PPP
SSTP teče prek HTTPS in v sebi nosi PPP, z lastno izmenjavo nadzora okoli povezave. Nato PPP izvede svoji stopnji povezave in overjanja, način overjanja pa je odvisen od strežniške politike in zmožnosti odjemalca. PAP, CHAP, MS-CHAPv2 in EAP so vse možnosti overjanja PPP z zelo različnimi lastnostmi. Preverjanje uporabnika v VPN je prav ta stopnja PPP, ne plast TLS pod njo.
Zavrnitev uporabnika lahko torej pomeni poverilnice, omejitev računa ali neujemanje metode.
Vzrok na strani strežnika je veliko bolj uporaben kot ponastavitev vsake skrivnosti v profilu. Dogodek onemogočenega računa in neuspeh pogajanj o metodi sta na odjemalcu videti podobna, na strežniku pa nimata nič skupnega.
Povežite napako s stopnjo
Preverite, ali povezava doseže TLS, nato izmenjavo SSTP po HTTP, nato stopnjo PPP. Časovne žige v dnevnikih držite poravnane med poskusi, da se zgodnejša napaka ne zamenja s poznejšim uspehom. Odjemalec, ki v enem oknu zabeleži dva poskusa, bo sicer videti, kot da je spodletel v zadnji doseženi stopnji. Berite prvo pomembno napako, ne zadnje vrstice.
Enako poravnavanje je pomembno na strani strežnika, kjer sta zapis o overjanju in dnevnik prenosa pogosto ločeni datoteki z ločenima urama. Dve minuti odstopanja sta dovolj, da se očiten vzrok zdi nemogoč.
Po prijavi je pooblastitev še vedno ločena
Uspešna prijava ne podeli vsakega zasebnega vira. Poti določajo, kaj je dosegljivo, DNS določa, kaj se razreši, in vsaka storitev še vedno uporablja svoja dovoljenja. Seja, prikazana kot povezana, je izjava o tunelu, ne o souporabi datotek. Ko se uporabnik lahko poveže in ne doseže enega gostitelja, je stopnja tunela že končana.
To je enako plastenje, kot ga je pokazalo rokovanje, eno raven višje.
Obnovitev računa pustite v procesu, ki ga podpira operater, namesto da bi spreminjali nastavitve prenosa kot odgovor na izrecno zavrnitev uporabnika. Spreminjanje prenosa za popravljanje onemogočenega računa je vrsta popravka, ki se zdi, da deluje, ko je račun znova omogočen iz nepovezanega razloga.