SSTP prvo provjerava server, a korisnika tek kasnije
SSTP prvo provjerava certifikat servera, a korisnika kasnije autentificira preko PPP-a. Uskladite grešku s fazom umjesto da dirate obje faze odjednom.
SSTP klijent može završiti TLS i ipak odbiti korisnika sekundu kasnije. Taj slijed nije greška, to je protokolni stog: prvo sigurnost prijenosa, zatim autentifikacija korisnika. Budući da dvije faze ne uspijevaju s različitim porukama, trebaju i različite popravke. Čitanje koja je faza proizvela grešku veći je dio dijagnoze.
Pouzdan certifikat dokazuje krajnju točku; o računu ne govori ništa.
Šta TLS rukovanje uspostavlja
Klijent provjerava certifikat koji server predstavlja prema svom spremištu povjerenja, traženom imenu hosta, prozoru valjanosti i svakoj dodatnoj politici koju platforma primjenjuje. To štiti vezu s namjeravanom krajnjom točkom. Ne dokazuje da je određeni račun omogućen, neistekao ili ovlašten za daljinski pristup. To su odvojena pitanja koja kasnije postavlja druga komponenta.
Zato je uklanjanje provjera certifikata da bi se došlo do prijave pogrešna popravka. Dobijete prijavu na vezi koju ne možete provjeriti. Greška certifikata pripada imenu hosta, satu, lancu ili konfiguraciji povjerenja.
Šta SSTP i PPP dodaju povrh toga
SSTP radi preko HTTPS-a i nosi PPP unutar sebe, s vlastitom razmjenom kontrole oko veze. PPP zatim izvodi svoje faze veze i autentifikacije, a metoda autentifikacije ovisi o politici servera i mogućnostima klijenta. PAP, CHAP, MS-CHAPv2 i EAP sve su PPP opcije autentifikacije s vrlo različitim svojstvima. VPN-ova provjera korisnika je ta PPP faza, a ne TLS sloj ispod nje.
Odbijanje korisnika stoga može značiti vjerodajnice, ograničenje računa ili neslaganje metode.
Razlog na strani servera mnogo je korisniji od resetiranja svake tajne u profilu. Događaj onemogućenog računa i neuspjeh pregovaranja metode izgledaju slično na klijentu i nemaju ništa zajedničko na serveru.
Uskladite grešku s fazom
Provjerite doseže li veza TLS, zatim SSTP HTTP razmjenu, zatim PPP fazu. Držite vremenske oznake u zapisima poravnate između pokušaja kako se raniji neuspjeh ne bi zamijenio s kasnijim uspjehom. Klijent koji bilježi dva pokušaja u jednom prozoru inače će izgledati kao da je pao u zadnjoj fazi do koje je stigao. Čitajte prvu relevantnu grešku, a ne zadnji redak.
Isto poravnanje važno je na strani servera, gdje su zapis autentifikacije i zapis prijenosa često odvojene datoteke s odvojenim satovima. Dvije minute razlike dovoljne su da očigledan uzrok izgleda nemoguć.
Nakon prijave autorizacija je i dalje odvojena
Uspješna prijava ne daje svaki privatni resurs. Rute određuju šta je dostupno, DNS određuje šta se razrješava, a svaka usluga i dalje primjenjuje vlastita dopuštenja. Sesija koja pokazuje povezano govori o tunelu, ne o dijeljenju datoteka. Kada se korisnik može povezati, a ne može dosegnuti jedan host, faza tunela je već završena.
To je isto slojevanje koje je pokazalo rukovanje, jednu razinu više.
Zadržite oporavak računa u okviru procesa koji podržava operater, umjesto da mijenjate postavke prijenosa kao odgovor na izričito odbijanje korisnika. Mijenjanje prijenosa da bi se popravio onemogućen račun vrsta je popravka koja izgleda da radi kada se račun ponovno omogući iz nepovezanog razloga.