SSTP спачатку аўтэнтыфікуе сервер, а потым карыстальніка

Кліент SSTP можа завяршыць TLS і праз секунду ўсё роўна адхіліць карыстальніка. Гэта паслядоўнасць не памылка, а стэк пратаколаў: спачатку бяспека транспарту, потым аўтэнтыфікацыя карыстальніка. Паколькі два этапы правальваюцца з рознымі паведамленнямі, ім патрэбныя і розныя выпраўленні. Чытанне таго, які этап спарадзіў памылку, — гэта большая частка дыягностыкі.

Давераны сертыфікат даказвае канечную кропку; пра ўліковы запіс ён не кажа нічога.

Што ўстанаўлівае рукапацісканне TLS

Кліент правярае прадстаўлены серверам сертыфікат супраць свайго сховішча даверу, запытанага імя хоста, акна сапраўднасці і любой дадатковай палітыкі, якую ўжывае платформа. Гэта абараняе злучэнне з патрэбнай канечнай кропкай. Але не даказвае, што пэўны ўліковы запіс уключаны, не пратэрмінаваны або мае дазвол на аддалены доступ. Гэта асобныя пытанні, якія пазней задае іншы кампанент.

Менавіта таму выдаленне праверак сертыфіката, каб дайсці да запыту ўваходу, — няправільнае выпраўленне. Вы атрымліваеце запыт уваходу на злучэнні, якое не можаце праверыць. Памылка сертыфіката адносіцца да імя хоста, гадзінніка, ланцужка або канфігурацыі даверу.

Што дадаюць SSTP і PPP зверху

SSTP працуе праз HTTPS і нясе ўнутры PPP, з уласным абменам кіравання вакол злучэння. Затым PPP выконвае свае этапы звяна і аўтэнтыфікацыі, а метад аўтэнтыфікацыі залежыць ад палітыкі сервера і магчымасцей кліента. PAP, CHAP, MS-CHAPv2 і EAP — усе гэта варыянты аўтэнтыфікацыі PPP з вельмі рознымі ўласцівасцямі. Праверка карыстальніка ў VPN — гэта менавіта этап PPP, а не пласт TLS пад ім.

Таму адхіленне карыстальніка можа азначаць уліковыя даныя, абмежаванне ўліковага запісу або неадпаведнасць метаду.

Прычына на баку сервера значна карыснейшая за скід усіх сакрэтаў у профілі. Падзея адключэння ўліковага запісу і збой перамовы метаду выглядаюць падобна на кліенце і не маюць нічога агульнага на серверы.

Супастаўце памылку з этапам

Праверце, ці дасягае злучэнне TLS, потым абмену SSTP праз HTTP, потым этапу PPP. Трымайце адзнакі часу ў журналах выраўнаванымі паміж спробамі, каб ранейшы збой не блыталі з пазнейшым поспехам. Кліент, які запісвае дзве спробы ў адно акно, інакш будзе выглядаць так, быццам ён збайчаў на апошнім дасягнутым этапе. Чытайце першую значную памылку, а не апошні радок.

Тое ж выраўноўванне важнае на баку сервера, дзе запіс аўтэнтыфікацыі і журнал транспарту часта з’яўляюцца асобнымі файламі з асобнымі гадзіннікамі. Дзвюх хвілін разыходжання дастаткова, каб відавочная прычына выглядала немагчымай.

Пасля ўваходу аўтарызацыя ўсё яшчэ асобная

Паспяховы ўваход не дае доступу да кожнага прыватнага рэсурсу. Маршруты вызначаюць, да чаго можна дабрацца, DNS вызначае, што развяртаецца, і кожная служба ўсё яшчэ ўжывае свае ўласныя дазволы. Сеанс, які паказвае «падключана», — гэта сцвярджэнне пра тунель, а не пра агульны доступ да файлаў. Калі карыстальнік можа падключыцца і не можа дасягнуць аднаго хоста, этап тунелю ўжо скончаны.

Гэта тое ж шматузроўневае ўпарадкаванне, якое паказала рукапацісканне, на ўзровень вышэй.

Трымайце аднаўленне ўліковага запісу ў межах працэсу, які падтрымлівае аператар, замест таго каб змяняць налады транспарту ў адказ на яўную адмову карыстальніку. Змяняць транспарт, каб выправіць адключаны ўліковы запіс, — гэта той від выпраўлення, які здаецца рабочым, калі ўліковы запіс зноў уключаюць з непаўязанай прычыны.