SSTP laiko limitas arba sertifikato klaida: kaip juos atskirti

SSTP ryšys žlunga dviem būdais, kurie nuo naudotojo kėdės atrodo vienodai, o kiekvieno taisymas yra kitame sluoksnyje. Laiko limitas reiškia, kad reikalingas pasikeitimas niekada nebuvo baigtas; sertifikato klaida reiškia, kad tapatybės medžiaga atėjo ir buvo atmesta. Jei antrąjį traktuosite kaip pirmąjį, pateksite prie ugniasienių ir slaptažodžių, kurie niekada nebuvo problema. Skiriantysis įrodymas yra paties kliento žurnale, jei perskaitysite jį prieš ką nors keisdami.

Dvi nesėkmės, du skirtingi pasikeitimai

SSTP neša tunelį HTTPS formos sesijos viduje, todėl išlieka tinkluose, kurie leidžia tik 443. Klientas baigia TLS rankos paspaudimą, siunčia HTTP užklausą protokolui būdingu metodu, o paskui tunelis eina tame sraute. Nesėkmė bet kuriame iš šių žingsnių sustabdo ryšį, ir tik vėlesni susiję su prisijungimo duomenimis.

Toji tvarka ir yra diagnozė. Jei TLS rankos paspaudimas niekada nebaigiamas, jokie prisijungimo duomenys nebuvo išsiųsti, todėl slaptažodžio atkūrimas negali padėti. Jei rankos paspaudimas baigiamas ir tada sustoja, tapatybė buvo priimta ir kažkas užklausos kelyje ją atmetė. Jei rankos paspaudimas žlunga su patikros pranešimu, serveris atsakė ir klientui nepatiko tai, ką išgirdo. Trys baigtys, trys sluoksniai.

Žurnalo eilutė paprastai nurodo, kuriame iš trijų esate, todėl verta ją užfiksuoti prieš pirmą pakeitimą.

Laiko limitas reiškia, kad etapas niekada nebuvo baigtas

Pradėkite nuo vardų sprendimo ir TCP pasiekiamumo, nes laiko limitas ten atrodo identiškai kaip vėlesnis. Prievadų tikrintuvas, pranešantis, kad 443 atidarytas, įrodo tik tai, kad klausytojas priėmė ryšį, ir nieko daugiau.

Kitas įtariamasis yra kelias, o ne pagrindinis kompiuteris. Tarpiniai serveriai ir programas suprantantys ugniasieniai kartais atmeta užklausos metodą, kurį naudoja SSTP, arba numeta srautą, kuris lieka atidarytas valandų valandas, ir abi elgsenos iš kliento pusės atrodo kaip laiko limitas. Įprastas HTTPS puslapis, kurį pateikia tas pats kompiuteris, įkeliamas nepriekaištingai, kol tunelio metodas atmetamas, todėl naršymas į galinį tašką įrodo taip mažai. Išbandykite iš tinklo be tarpinio serverio, kad atskirtumėte šiuos du atvejus.

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

Laiko limitas prieš bet kokį partnerio atsakymą nieko nesako apie paskyrą, o slaptažodžio keitimas tuo metu tik prideda kintamąjį.

Sertifikato klaida reiškia, kad tapatybė buvo atmesta

Čia serveris tikrai atsakė, taigi tinklas veikia ir klausimas persikelia į tapatybę. Palyginkite vardą, kuriuo klientas skambina, su vardais, kuriuos sertifikatas iš tikrųjų teigia, tada patikrinkite galiojimo datas ir išdavimo grandinę.

Privatus CA, kuriuo klientas nepasitiki, sukuria tą pačią klaidų klasę kaip pasibaigęs sertifikatas, ir taip pat laikrodis, kuris vėluoja valandomis. Skambinimas neapdorotu adresu sukuria naują neatitikimą, nes sertifikatas teigia vardus, o ne adresus. Valdomame diegime pasiimkite numatytą pasitikėjimo konfigūraciją iš jos administratoriaus, o ne priimkite klaidos puslapio siūlomą pakaitinę šaknį. Tikrinimas lieka įjungtas, kol taisote priežastį.

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

Išlaikykite sėkmingą TLS etapą nepaliestą, kai jis praeina, nes jo atšaukimas vėliau paslepia, kuris pakeitimas iš tikrųjų sutaisė tunelį.

Kur šie du sumaišomi

Abi nesėkmės pasirodo kaip ryšys, kuris nepakyla, ir abi ateina po to, kai naudotojas pakeitė ką nors nesusijusio. Būtent tas sutapimas leidžia neteisingam taisymui kurį laiką atrodyti įtikinamai.

Du įpročiai juos išlaiko atskirai. Užfiksuokite kliento žurnalą prieš liesdami konfigūraciją, kad pirmoji būsena išliktų. Keiskite vieną sluoksnį per bandymą, kad kitas rezultatas priklausytų žinomam kintamajam. Prievadų tikrintuvas ir naršyklė yra daliniai stebėjimai, o ne visa seka, ir nė vienas nepakeičia paties kliento ataskaitos. Nė vienas įprotis nieko nekainuoja, ir abu sutrumpina tyrimą.

Sertifikato klausimas ir pasiekiamumo klausimas dokumentuoti atskirai dėl priežasties.

Išbandykite dar kartą su tikru klientu, tada judėkite į vidų

Kai konkretus pataisymas vietoje, bandykite dar kartą su tikru SSTP klientu ir tikru profiliu, o ne su naršyklės kortele.

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

Jei sesija prisijungia, o ištekliai vis dar žlunga, tunelis nebėra įtariamasis: pereikite prie maršrutizavimo, DNS ir prieigos prie paslaugų. Tai kitas tyrimas su kitais įrodymais. Veikiančių TLS ir autentifikavimo etapų išlaikymas neleidžia jam tapti pirmojo pakartojimu. Įrašykite į bilietą etapą, kuris žlugo, antraip kitas žmogus vėl pradės nuo viršaus.