SSTP vërteton fillimisht serverin dhe më pas përdoruesin

Një klient SSTP mund të përfundojë TLS dhe gjithsesi ta refuzojë përdoruesin një sekondë më vonë. Kjo sekuencë nuk është gabim, është pirg protokollesh: fillimisht siguria e transportit, më pas vërtetimi i përdoruesit. Meqenëse dy fazat dështojnë me mesazhe të ndryshme, atyre u duhen edhe rregullime të ndryshme. Leximi se cila fazë e prodhoi gabimin është pjesa më e madhe e diagnozës.

Një certifikatë e besuar vërteton pikën fundore; për llogarinë nuk thotë asgjë.

Çfarë përcakton shtrëngimi i duarve TLS

Klienti vërteton certifikatën e paraqitur nga serveri kundrejt depove të besimit, emrit të hostit të kërkuar, dritares së vlefshmërisë dhe çdo politike shtesë që zbaton platforma. Kjo mbron lidhjen me pikën fundore të synuar. Por nuk vërteton që një llogari e caktuar është e aktivizuar, e pa skaduar ose e autorizuar për akses në distancë. Këto janë pyetje të veçanta që bëhen më vonë nga një komponent tjetër.

Prandaj heqja e kontrolleve të certifikatës për të arritur tek kërkesa e hyrjes është rregullimi i gabuar. Ju merrni një kërkesë hyrjeje në një lidhje që nuk mund ta verifikoni. Një gabim certifikate i përket emrit të hostit, orës, zinxhirit ose konfigurimit të besimit.

Çfarë shtojnë SSTP dhe PPP sipër

SSTP funksionon mbi HTTPS dhe mbart PPP brenda, me shkëmbimin e vet të kontrollit rreth lidhjes. Më pas PPP ekzekuton fazat e lidhjes dhe vërtetimit, dhe metoda e vërtetimit varet nga politika e serverit dhe aftësia e klientit. PAP, CHAP, MS-CHAPv2 dhe EAP janë të gjitha opsione vërtetimi PPP me veti shumë të ndryshme. Kontrolli i përdoruesit i VPN-së është ajo fazë PPP, jo shtresa TLS nën të.

Prandaj refuzimi i përdoruesit mund të nënkuptojë kredenciale, një kufizim llogarie ose një mospërputhje metode.

Arsyeja në anën e serverit është shumë më e dobishme sesa rivendosja e çdo sekreti në profil. Një ngjarje e llogarisë së çaktivizuar dhe një dështim i negociatës së metodës duken njësoj te klienti dhe nuk kanë asgjë të përbashkët te serveri.

Përputhni gabimin me fazën

Kontrolloni nëse lidhja arrin TLS, më pas shkëmbimin HTTP të SSTP, më pas fazën PPP. Mbani vulat kohore të regjistrave të rreshtuara midis provave, që një dështim i mëparshëm të mos ngatërrohet me një sukses të mëvonshëm. Një klient që regjistron dy prova në një dritare, përndryshe do të duket sikur dështoi në fazën e fundit që arriti. Lexoni gabimin e parë përkatës, jo rreshtin e fundit.

I njëjti rreshtim ka rëndësi në anën e serverit, ku regjistri i vërtetimit dhe regjistri i transportit janë shpesh skedarë të veçantë me orë të veçanta. Dy minuta devijim mjaftojnë për ta bërë një shkak të dukshëm të duket i pamundur.

Pas hyrjes, autorizimi mbetet i veçantë

Një hyrje e suksesshme nuk jep çdo burim privat. Rrugët përcaktojnë çfarë është e arritshme, DNS përcakton çfarë zgjidhet, dhe çdo shërbim ende zbaton lejet e veta. Një sesion i shfaqur si i lidhur është një deklaratë për tunelin, jo për ndarjen e skedarëve. Kur një përdorues mund të lidhet dhe nuk mund të arrijë një host, faza e tunelit ka përfunduar tashmë.

Është i njëjti shtresim që tregoi shtrëngimi i duarve, një nivel më lart.

Mbajeni rikuperimin e llogarisë brenda procesit të mbështetur nga operatori në vend që të ndryshoni cilësimet e transportit si përgjigje ndaj një refuzimi të qartë të përdoruesit. Ndryshimi i transportit për të rregulluar një llogari të çaktivizuar është lloji i rregullimit që duket se funksionon kur llogaria riaktivizohet për një arsye të palidhur.