Časovna omejitev SSTP ali napaka potrdila: kako ju ločiti

Povezava SSTP odpove na dva načina, ki sta s stola uporabnika videti enako, popravilo vsakega pa je na drugem sloju. Časovna omejitev pomeni, da se zahtevana izmenjava ni nikoli končala; napaka potrdila pomeni, da je identitetno gradivo prispelo in bilo zavrnjeno. Če drugo obravnavate kot prvo, se odpravite k požarnim zidovom in geslom, ki nikoli niso bili težava. Razločevalni dokaz je v dnevniku samega odjemalca, če ga preberete, preden karkoli spremenite.

Dve okvari, dve različni izmenjavi

SSTP prenaša tunel znotraj seje v obliki HTTPS, zato preživi v omrežjih, ki ne dovolijo ničesar razen 443. Odjemalec dokonča rokovanje TLS, pošlje zahtevo HTTP z metodo, značilno za protokol, nato pa tunel teče znotraj tega toka. Okvara na katerem koli od teh korakov ustavi povezavo, in samo poznejši vključujejo poverilnice.

To zaporedje je diagnoza. Če se rokovanje TLS nikoli ne konča, nobene poverilnice niso bile poslane, zato ponastavitev gesla ne more pomagati. Če se rokovanje konča in nato obstane, je bila identiteta sprejeta in nekaj na poti zahteve jo je zavrnilo. Če rokovanje odpove s sporočilom o preverjanju, je strežnik odgovoril in odjemalcu ni bilo všeč, kar je slišal. Trije izidi, trije sloji.

Vrstica v dnevniku običajno pove, v katerem od treh ste, zato jo je vredno zajeti pred prvo spremembo.

Časovna omejitev pomeni, da se faza ni nikoli končala

Začnite z razreševanjem imen in dosegljivostjo TCP, ker je časovna omejitev tam videti enako kot poznejša. Preverjalnik vrat, ki poroča, da je 443 odprt, dokazuje le, da je poslušalec sprejel povezavo, in nič več.

Naslednji osumljenec je pot in ne gostitelj. Posredniki in požarni zidovi, ki poznajo aplikacije, včasih zavrnejo metodo zahteve, ki jo uporablja SSTP, ali spustijo tok, ki ostane odprt ure dolgo, in oba vedenja sta z vidika odjemalca videti kot časovna omejitev. Obična stran HTTPS z istega gostitelja se naloži brezhibno, medtem ko je metoda tunela zavrnjena, zato brskanje do končne točke dokaže tako malo. Preizkusite iz omrežja brez posrednika, da ločite ta dva primera.

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

Časovna omejitev pred kakršnim koli odgovorom druge strani ne pove ničesar o računu, in menjava gesla v tistem trenutku doda le spremenljivko.

Napaka potrdila pomeni, da je bila identiteta zavrnjena

Tu je strežnik res odgovoril, zato omrežje deluje in vprašanje se premakne na identiteto. Primerjajte ime, s katerim odjemalec kliče, z imeni, ki jih potrdilo dejansko zatrjuje, nato preverite datume veljavnosti in izdajateljsko verigo.

Zasebna CA, ki ji odjemalec ne zaupa, ustvari isti razred napake kot poteklo potrdilo, enako pa tudi ura, ki zaostaja za ure. Klicanje na surov naslov ustvari novo neujemanje, ker potrdilo zatrjuje imena in ne naslovov. V upravljani namestitvi pridobite predvideno konfiguracijo zaupanja pri njenem skrbniku, namesto da bi sprejeli nadomestni koren, ki ga ponuja stran z napako. Preverjanje ostane vključeno, medtem ko odpravljate vzrok.

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

Uspelo fazo TLS po prehodu pustite nedotaknjeno, ker njena poznejša razveljavitev skrije, katera sprememba je tunel dejansko popravila.

Kjer se oba zamenjata

Obe okvari se pojavita kot povezava, ki se ne dvigne, in obe prideta potem, ko je uporabnik spremenil nekaj nepovezanega. Prav to naključje naredi napačno popravilo za nekaj časa verjetno.

Dve navadi ju držita ločeni. Zajemite dnevnik odjemalca, preden se dotaknete konfiguracije, da prvo stanje ostane. Spreminjajte en sloj na poskus, da naslednji rezultat pripada znani spremenljivki. Preverjalnik vrat in brskalnik sta delna opazovanja in ne celotno zaporedje, in nobeno ne nadomesti poročila odjemalca samega. Nobena navada nič ne stane in obe skrajšata preiskavo.

Vprašanje potrdila in vprašanje dosegljivosti sta dokumentirani ločeno z razlogom.

Znova preizkusite s pravim odjemalcem, nato pojdite navznoter

Ko je konkretni popravek na mestu, poskusite znova z dejanskim odjemalcem SSTP in pravim profilom, ne z zavihkom brskalnika.

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

Če se seja poveže in viri še vedno odpovedujejo, tunel ni več osumljenec: pojdite na usmerjanje, DNS in dostop do storitev. To je druga preiskava z drugimi dokazi. Ohranjanje delujočih faz TLS in preverjanja prepreči, da bi postala ponovitev prve. V prijavo zapišite fazo, ki je odpovedala, sicer bo naslednja oseba spet začela od zgoraj.