SSTP-tidsavbrot eller sertifikatfeil: slik skil du dei

Ei SSTP-tilkopling feilar på to måtar som ser like ut frå stolen til brukaren, og reparasjonen for kvar ligg på eit ulikt lag. Eit tidsavbrot tyder at ei naudsynt utveksling aldri vart fullført; ein sertifikatfeil tyder at identitetsmateriale kom og vart avvist. Handsama du det andre som det første, går du mot brannmurar og passord som aldri var problemet. Det avgjerande beviset står i loggen til klienten sjølv, om du les han før du endrar noko.

To feil, to ulike utvekslingar

SSTP ber ein tunnel inne i ei økt med HTTPS-form, difor overlever han nettverk som ikkje tillèt anna enn 443. Klienten fullfører eit TLS-handtrykk, sender ein HTTP-førespurnad med ein protokollspesifikk metode, og deretter går tunnelen inne i den straumen. Ein feil på eit av desse trinna stoggar tilkoplinga, og berre dei seinare involverer påloggingsinformasjon.

Den rekkjefølgja er diagnosen. Om TLS-handtrykket aldri vert fullført, vart ingen påloggingsinformasjon send, så nullstilling av passord kan ikkje hjelpe. Om handtrykket vert fullført og deretter stoggar, vart identiteten godteken og noko i førespurnadsvegen avviste han. Om handtrykket feilar med ei valideringsmelding, svara tenaren og klienten likte ikkje det han høyrde. Tre utfall, tre lag.

Logglinja nemner vanlegvis kva av dei tre du er i, difor er det verdt å fanga ho før den første endringa.

Eit tidsavbrot tyder at eit trinn aldri vart fullført

Start med namneoppslag og TCP-tilgjenge, fordi eit tidsavbrot der ser identisk ut med eit tidsavbrot seinare. Ein portkontroll som rapporterer 443 open beviser at ein lyttar godtok ei tilkopling, og ingenting utover det.

Den neste mistenkte er vegen og ikkje verten. Proxyar og applikasjonsmedvitne brannmurar avviser stundom førespurnadsmetoden SSTP brukar, eller slepp ein straum som blir verande open i timar, og begge åtferdene ser ut som eit tidsavbrot frå klienten. Ei vanleg HTTPS-side frå same vert lastar perfekt medan tunnelmetoden vert avvist, difor beviser det så lite å bla til endepunktet. Test frå eit nettverk utan proxyen for å skilja dei to tilfella.

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

Eit tidsavbrot før noko svar frå motparten seier ingenting om kontoen, og å endra passordet på det tidspunktet legg berre til ein variabel.

Ein sertifikatfeil tyder at identiteten vart avvist

Her svara tenaren faktisk, så nettverket verkar og spørsmålet flyttar til identitet. Samanlikn namnet klienten ringer med namna sertifikatet faktisk hevdar, og kontroller deretter gyldigheitsdatoar og utferdarkjeda.

Ein privat CA klienten ikkje stolar på gir same feilklasse som eit utlate sertifikat, og det same gjer ei klokke som er timar feil. Å ringa den rå adressa skaper eit nytt avvik, fordi eit sertifikat hevdar namn og ikkje adresser. I ein administrert utrulling hentar du den tiltenkte tillitskonfigurasjonen frå administratoren i staden for å godta ei erstatningsrot som ei feilsida tilbyr. Valideringa blir verande på medan du rettar årsaka.

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

Hald det vellukka TLS-trinnet intakt når det først passerer, fordi å rulle det tilbake seinare løyner kva endring som faktisk reparerte tunnelen.

Kvar dei to blir blanda saman

Begge feila viser seg som ei tilkopling som ikkje kjem opp, og begge kjem etter at brukaren har endra noko urelatert. Det samanfallet er det som får den feile reparasjonen til å sjå truverdig ut ei stund.

To vanar held dei frå kvarandre. Fang klientloggen før du rører konfigurasjonen, slik at den første tilstanden blir bevart. Endra eitt lag per forsøk, slik at neste resultat høyrer til ein kjend variabel. Ein portkontroll og ein nettlesar er delvise observasjonar og ikkje heile sekvensen, og ingen av dei erstattar rapporten til klienten sjølv. Ingen av vanane kostar noko, og begge forkortar undersøkinga.

Sertifikatsspørsmålet og tilgjengespmålet er dokumenterte kvar for seg av ein grunn.

Test på nytt med den ekte klienten, og gå så innover

Når den konkrete rettinga er på plass, prøv igjen med den faktiske SSTP-klienten og den ekte profilen, ikkje med ein nettlesarfane.

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

Om økta koplar til og ressursar framleis feilar, er ikkje tunnelen lenger den mistenkte: gå vidare til rutingsetting, DNS og tenestetilgang. Det er ei anna undersøking med andre bevis. Å halda på dei fungerande TLS- og autentiseringstrinna hindrar at det blir ei gjentaking av den første. Skriv trinnet som feila i saka, elles byrjar neste person på toppen igjen.