Timeout ng SSTP o error sa sertipiko: paano sila ihiwalay

Ang koneksyon ng SSTP ay nabibigo sa dalawang paraan na magkapareho ang hitsura mula sa upuan ng gumagamit, at ang pag-aayos ng bawat isa ay nasa magkaibang antas. Ang timeout ay nangangahulugang may kinakailangang palitan na hindi natapos; ang error sa sertipiko ay nangangahulugang dumating ang materyal ng pagkakakilanlan at tinanggihan ito. Ang pagtrato sa pangalawa na parang una ay magdadala sa iyo sa mga firewall at password na hindi kailanman naging problema. Ang patunay na naghihiwalay sa kanila ay nasa log ng kliyente mismo, kung babasahin mo ito bago magbago ng anuman.

Dalawang kabiguan, dalawang magkaibang palitan

Dinadala ng SSTP ang isang tunnel sa loob ng sesyong hugis HTTPS, kaya nakakaligtas ito sa mga network na walang pinapayagan kundi 443. Kinukumpleto ng kliyente ang TLS handshake, nagpapadala ng HTTP request gamit ang paraang tukoy sa protocol, at pagkatapos ay tumatakbo ang tunnel sa loob ng stream na iyon. Ang kabiguan sa alinman sa mga hakbang na iyon ay humihinto sa koneksyon, at ang mga huling hakbang lamang ang may kinalaman sa mga kredensyal.

Ang pagkakasunod-sunod na iyon ang diagnosis. Kung hindi natatapos ang TLS handshake, walang kredensyal na naipadala, kaya hindi makakatulong ang pag-reset ng password. Kung natapos ang handshake at pagkatapos ay natigil, tinanggap ang pagkakakilanlan at may tinanggihan ito sa landas ng request. Kung nabigo ang handshake na may mensahe ng validation, sumagot ang server at hindi nagustuhan ng kliyente ang narinig nito. Tatlong resulta, tatlong antas.

Karaniwang sinasabi ng linya sa log kung alin sa tatlo ang naroon ka, kaya sulit itong itala bago ang unang pagbabago.

Ang timeout ay nangangahulugang may yugtong hindi natapos

Magsimula sa resolusyon ng pangalan at abot ng TCP, dahil ang timeout doon ay magkapareho ang hitsura sa timeout sa bandang huli. Ang tagasuri ng port na nag-uulat na bukas ang 443 ay nagpapatunay lamang na may tagapakinig na tumanggap ng koneksyon, at wala nang iba pa.

Ang susunod na pinaghihinalaan ay ang landas at hindi ang host. Ang mga proxy at firewall na may kamalayan sa aplikasyon ay minsang tumatanggi sa paraan ng request na ginagamit ng SSTP, o nagtatapon ng stream na nananatiling bukas nang maraming oras, at ang dalawang pag-uugali ay mukhang timeout mula sa panig ng kliyente. Ang ordinaryong pahina ng HTTPS na inihahain ng parehong host ay naglo-load nang maayos habang tinatanggihan ang paraan ng tunnel, kaya napakakaunting pinatutunayan ng pag-browse sa endpoint. Subukan mula sa network na walang proxy upang paghiwalayin ang dalawang kaso.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Ang timeout bago ang anumang sagot ng kabilang panig ay walang sinasabi tungkol sa account, at ang pagpalit ng password sa sandaling iyon ay nagdaragdag lamang ng isang variable.

Ang error sa sertipiko ay nangangahulugang tinanggihan ang pagkakakilanlan

Dito ay talagang sumagot ang server, kaya gumagana ang network at lumilipat ang tanong sa pagkakakilanlan. Ihambing ang pangalang tinatawagan ng kliyente sa mga pangalang talagang inaangkin ng sertipiko, pagkatapos suriin ang mga petsa ng bisa at ang kadena ng nagbigay.

Ang pribadong CA na hindi pinagkakatiwalaan ng kliyente ay gumagawa ng parehong uri ng error tulad ng isang nag-expire na sertipiko, at gayundin ang isang orasan na mali ng ilang oras. Ang pagtawag sa hilaw na address ay lumilikha ng bagong hindi pagkakatugma, dahil ang sertipiko ay nag-aangkin ng mga pangalan at hindi ng mga address. Sa pinamamahalaang deployment, kunin ang inilaan na configuration ng tiwala mula sa administrator nito sa halip na tanggapin ang kapalit na root na iniaalok ng pahina ng error. Nananatiling bukas ang validation habang inaayos mo ang dahilan.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Panatilihing buo ang matagumpay na yugto ng TLS kapag nakalampas na, dahil ang pag-undo nito mamaya ay nagtatago kung aling pagbabago ang talagang nag-ayos ng tunnel.

Kung saan nalilito ang dalawa

Ang dalawang kabiguan ay lumilitaw bilang koneksyong hindi bumabangon, at parehong dumarating pagkatapos na may binago ang gumagamit na walang kaugnayan. Ang pagkakataon na iyon ang nagpapamukhang kapani-paniwala ang maling pag-aayos nang ilang sandali.

Dalawang ugali ang naghihiwalay sa kanila. Itala ang log ng kliyente bago hawakan ang configuration, upang mapangalagaan ang unang kalagayan. Magbago ng isang antas kada pagtatangka, upang ang susunod na resulta ay mapabilang sa kilalang variable. Ang tagasuri ng port at ang browser ay bahagyang obserbasyon at hindi ang buong pagkakasunod-sunod, at wala sa kanila ang pumapalit sa ulat ng kliyente mismo. Walang gastos ang alinman sa ugali, at parehong pinaiikli ang pagsisiyasat.

Ang usapin ng sertipiko at ang usapin ng abot ay dokumentado nang hiwalay sa isang dahilan.

Subukan muli gamit ang tunay na kliyente, pagkatapos ay pumasok sa loob

Kapag nakalagay na ang tiyak na pagwawasto, subukan muli gamit ang aktwal na kliyente ng SSTP at ang tunay na profile, hindi ang tab ng browser.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Kung kumokonekta ang sesyon at nabibigo pa rin ang mga mapagkukunan, ang tunnel ay hindi na pinaghihinalaan: lumipat sa routing, DNS at pag-access sa mga serbisyo. Iba iyon na pagsisiyasat na may ibang ebidensya. Ang pagpapanatili ng gumaganang yugto ng TLS at pagpapatotoo ay pumipigil na maging pag-uulit ito ng una. Isulat sa ticket ang yugtong nabigo, kung hindi ay magsisimula muli ang susunod na tao sa itaas.