SSTP pirmiausia autentifikuoja serverį, o vėliau – vartotoją

SSTP klientas gali užbaigti TLS ir vis tiek po sekundės atmesti vartotoją. Ši seka nėra klaida, tai protokolų krūva: pirmiausia transporto saugumas, vėliau vartotojo autentifikavimas. Kadangi du etapai nepavyksta su skirtingomis žinutėmis, jiems reikia ir skirtingų taisymų. Perskaityti, kuris etapas sukėlė klaidą, yra didžioji diagnostikos dalis.

Patikimas sertifikatas įrodo galinį tašką; apie paskyrą jis nieko nesako.

Ką nustato TLS rankos paspaudimas

Klientas tikrina serverio pateiktą sertifikatą pagal savo patikimosios saugyklos, užklausto hosto vardo, galiojimo lango ir bet kokios papildomos platformos taikomos politikos reikalavimus. Tai apsaugo ryšį su numatytu galiniu tašku. Bet neįrodo, kad konkreti paskyra įjungta, nepasibaigusi ar turi teisę naudotis nuotoline prieiga. Tai atskiri klausimai, kuriuos vėliau užduoda kitas komponentas.

Todėl sertifikatų patikrinimų pašalinimas siekiant pasiekti prisijungimo raginimą yra neteisingas taisymas. Jūs gaunate prisijungimo raginimą ryšyje, kurio negalite patikrinti. Sertifikato klaida priklauso hosto vardui, laikrodžiui, grandinei arba patikimumo konfigūracijai.

Ką prideda SSTP ir PPP

SSTP veikia per HTTPS ir viduje neša PPP, turėdamas savo valdymo mainus aplink ryšį. Tada PPP vykdo savo jungties ir autentifikavimo etapus, o autentifikavimo metodas priklauso nuo serverio politikos ir kliento galimybių. PAP, CHAP, MS-CHAPv2 ir EAP yra visos PPP autentifikavimo parinktys, turinčios labai skirtingas savybes. VPN vartotojo patikra yra tas PPP etapas, o ne po juo esantis TLS sluoksnis.

Todėl vartotojo atmetimas gali reikšti prisijungimo duomenis, paskyros apribojimą arba metodo neatitikimą.

Priežastis serverio pusėje yra daug naudingesnė nei iš naujo nustatyti kiekvieną profilio paslaptį. Išjungtos paskyros įvykis ir metodo derybų nepavykimas kliente atrodo panašiai, o serveryje neturi nieko bendra.

Susiekite klaidą su etapu

Patikrinkite, ar ryšys pasiekia TLS, tada SSTP HTTP mainus, tada PPP etapą. Laikykite žurnalų laiko žymes sulygiuotas tarp bandymų, kad ankstesnė nesėkmė nebūtų supainiota su vėlesne sėkme. Klientas, registruojantis du bandymus viename lange, kitaip atrodys kaip nepavykęs paskutiniame pasiektame etape. Skaitykite pirmą svarbią klaidą, o ne paskutinę eilutę.

Tas pats lygiavimas svarbus serverio pusėje, kur autentifikavimo įrašas ir transporto žurnalas dažnai yra atskiri failai su atskirais laikrodžiais. Dviejų minučių poslinkis pakanka, kad akivaizdi priežastis atrodytų neįmanoma.

Prisijungus autorizacija vis dar atskira

Sėkmingas prisijungimas nesuteikia prieigos prie kiekvieno privataus ištekliaus. Maršrutai nustato, kas pasiekiama, DNS nustato, kas išsprendžiama, o kiekviena paslauga vis dar taiko savo leidimus. Sesija, rodoma kaip prisijungta, yra teiginys apie tunelį, o ne apie failų bendrinimą. Kai vartotojas gali prisijungti ir negali pasiekti vieno hosto, tunelio etapas jau baigtas.

Tai tas pats sluoksniavimas, kurį parodė rankos paspaudimas, vienu lygiu aukščiau.

Laikykite paskyros atkūrimą operatoriaus palaikomame procese, o ne keiskite transporto nustatymus reaguodami į aiškų vartotojo atmetimą. Transporto keitimas siekiant sutaisyti išjungtą paskyrą yra toks taisymas, kuris atrodo veikiantis, kai paskyra vėl įjungiama dėl nesusijusios priežasties.