SSTP ay nagpapatunay muna ng server at pagkatapos ng user

Ang isang SSTP client ay maaaring makumpleto ang TLS at tanggihan pa rin ang user isang segundo mamaya. Ang pagkakasunod-sunod na iyon ay hindi bug, ito ang protocol stack: seguridad ng transportasyon muna, pagpapatunay ng user pagkatapos. Dahil nabigo ang dalawang yugto sa magkaibang mensahe, kailangan din nila ng magkaibang pag-aayos. Ang pagbasa kung aling yugto ang gumawa ng error ay ang malaking bahagi ng diagnosis.

Ang pinagkakatiwalaang sertipiko ay nagpapatunay ng endpoint; wala itong sinasabi tungkol sa account.

Ano ang itinatag ng TLS handshake

Ang client ay nagbe-verify ng sertipikong inihain ng server laban sa trust store nito, sa hinihinging hostname, sa validity window at sa anumang karagdagang patakaran na inilalapat ng platform. Pinoprotektahan nito ang koneksyon sa inilaan na endpoint. Hindi nito pinatutunayan na ang isang partikular na account ay naka-enable, hindi pa nag-expire o pinapayagan para sa remote access. Iyon ay magkahiwalay na tanong na itatanong mamaya ng ibang component.

Kaya ang pag-alis ng mga pagsusuri ng sertipiko para maabot ang login prompt ay maling pag-aayos. Makakakuha ka ng login prompt sa koneksyong hindi mo ma-verify. Ang error sa sertipiko ay kabilang sa hostname, orasan, chain o configuration ng tiwala.

Ano ang idinaragdag ng SSTP at PPP sa itaas

Tumatakbo ang SSTP sa ibabaw ng HTTPS at nagdadala ng PPP sa loob nito, kasama ang sarili nitong palitan ng kontrol sa paligid ng koneksyon. Pagkatapos ay pinapatakbo ng PPP ang mga yugto nito ng link at pagpapatunay, at ang paraan ng pagpapatunay ay depende sa patakaran ng server at kakayahan ng client. Ang PAP, CHAP, MS-CHAPv2 at EAP ay lahat ng opsyon sa pagpapatunay ng PPP na may lubos na magkaibang katangian. Ang pagsusuri ng user ng VPN ay ang yugto ng PPP na iyon, hindi ang layer ng TLS sa ilalim nito.

Kaya ang pagtanggi sa user ay maaaring mangahulugan ng mga kredensyal, paghihigpit sa account o hindi pagtutugma ng paraan.

Ang dahilan sa panig ng server ay mas kapaki-pakinabang kaysa sa pag-reset ng bawat sikreto sa profile. Ang kaganapan ng na-disable na account at ang pagkabigo ng negosasyon ng paraan ay magkamukha sa client at walang pagkakatulad sa server.

Itugma ang error sa yugto

Suriin kung naaabot ng koneksyon ang TLS, pagkatapos ang palitan ng HTTP ng SSTP, pagkatapos ang yugto ng PPP. Panatilihing nakahanay ang mga timestamp ng log sa mga pagtatangka upang ang naunang pagkabigo ay hindi malito sa susunod na tagumpay. Ang isang client na nagla-log ng dalawang pagtatangka sa isang window ay mukhang nabigo sa huling yugtong naabot nito. Basahin ang unang kaugnay na error, hindi ang huling linya.

Ang parehong pagkakahanay ay mahalaga sa panig ng server, kung saan ang talaan ng pagpapatunay at ang log ng transportasyon ay madalas na magkahiwalay na file na may magkahiwalay na orasan. Sapat na ang dalawang minuto ng pagkahiwalay upang gawing imposible ang isang malinaw na dahilan.

Pagkatapos ng pag-login, hiwalay pa rin ang awtorisasyon

Ang matagumpay na pag-login ay hindi nagbibigay ng bawat pribadong mapagkukunan. Itinatakda ng mga ruta kung ano ang maaabot, itinatakda ng DNS kung ano ang nareresolba, at inilalapat pa rin ng bawat serbisyo ang sarili nitong mga pahintulot. Ang sesyong ipinapakitang konektado ay isang pahayag tungkol sa tunnel, hindi tungkol sa pagbabahagi ng file. Kapag ang user ay makakonekta at hindi maabot ang isang host, tapos na ang yugto ng tunnel.

Iyon ang parehong paglalagay ng layer na ipinakita ng handshake, isang antas na mas mataas.

Panatilihin ang pagbawi ng account sa loob ng sinusuportahang proseso ng operator sa halip na baguhin ang mga setting ng transportasyon bilang tugon sa tahasang pagtanggi ng user. Ang pagbabago ng transportasyon para ayusin ang na-disable na account ay ang uri ng pag-aayos na tila gumagana kapag ang account ay muling na-enable para sa walang kaugnayang dahilan.