SSTP-tidsavbrudd eller sertifikatfeil: slik skiller du dem

En SSTP-tilkobling feiler på to måter som ser like ut fra brukerens stol, og reparasjonen for hver ligger på et ulikt lag. En tidsavbrudd betyr at en nødvendig utveksling aldri ble fullført; en sertifikatfeil betyr at identitetsmateriale kom og ble avvist. Behandler du det andre som det første, går du mot brannmurer og passord som aldri var problemet. Det avgjørende beviset står i klientens egen logg, hvis du leser den før du endrer noe.

To feil, to ulike utvekslinger

SSTP bærer en tunnel inne i en økt med HTTPS-form, derfor overlever den nettverk som ikke tillater annet enn 443. Klienten fullfører et TLS-håndtrykk, sender en HTTP-forespørsel med en protokollspesifikk metode, og deretter går tunnelen inne i den strømmen. En feil på et av disse trinnene stopper tilkoblingen, og bare de senere involverer påloggingsinformasjon.

Den rekkefølgen er diagnosen. Hvis TLS-håndtrykket aldri fullføres, ble ingen påloggingsinformasjon sendt, så nullstilling av passord kan ikke hjelpe. Hvis håndtrykket fullføres og deretter stopper, ble identiteten godtatt og noe i forespørselsveien avviste den. Hvis håndtrykket feiler med en valideringsmelding, svarte serveren og klienten likte ikke det den hørte. Tre utfall, tre lag.

Logglinjen angir vanligvis hvilken av de tre du er i, derfor er det verdt å fange den før den første endringen.

Et tidsavbrudd betyr at et trinn aldri ble fullført

Start med navneoppslag og TCP-tilgjengelighet, fordi et tidsavbrudd der ser identisk ut med et tidsavbrudd senere. En portkontroll som rapporterer 443 åpen beviser at en lytter godtok en tilkobling, og ingenting utover det.

Den neste mistenkte er veien og ikke verten. Proxyer og applikasjonsbevisste brannmurer avviser noen ganger forespørselsmetoden SSTP bruker, eller slipper en strøm som forblir åpen i timer, og begge atferdene ser ut som et tidsavbrudd fra klienten. En vanlig HTTPS-side fra samme vert lastes perfekt mens tunnelmetoden avvises, derfor beviser det så lite å bla til endepunktet. Test fra et nettverk uten proxyen for å skille de to tilfellene.

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

Et tidsavbrudd før noe svar fra motparten sier ingenting om kontoen, og å endre passordet på det tidspunktet legger bare til en variabel.

En sertifikatfeil betyr at identiteten ble avvist

Her svarte serveren faktisk, så nettverket virker og spørsmålet flytter til identitet. Sammenlign navnet klienten ringer med navnene sertifikatet faktisk hevder, og kontroller deretter gyldighetsdatoer og utstedelseskjeden.

En privat CA klienten ikke stoler på gir samme feilklasse som et utløpt sertifikat, og det samme gjør en klokke som er timer feil. Å ringe den rå adressen skaper et nytt avvik, fordi et sertifikat hevder navn og ikke adresser. I en administrert utrulling henter du den tiltenkte tillitskonfigurasjonen fra administratoren i stedet for å godta en erstatningsrot som en feilside tilbyr. Valideringen forblir på mens du retter årsaken.

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

Hold det vellykkede TLS-trinnet intakt når det først passerer, fordi å rulle det tilbake senere skjuler hvilken endring som faktisk reparerte tunnelen.

Hvor de to blandes sammen

Begge feilene viser seg som en tilkobling som ikke kommer opp, og begge kommer etter at brukeren har endret noe urelatert. Det sammentreffet er det som får den feil reparasjonen til å se plausibel ut en stund.

To vaner holder dem fra hverandre. Fang klientloggen før du rører konfigurasjonen, slik at den første tilstanden bevares. Endre ett lag per forsøk, slik at neste resultat tilhører en kjent variabel. En portkontroll og en nettleser er delvise observasjoner og ikke hele sekvensen, og ingen av dem erstatter klientens egen rapport. Ingen av vanene koster noe, og begge forkorter undersøkelsen.

Sertifikatspørsmålet og tilgjengelighetsspørsmålet er dokumentert hver for seg av en grunn.

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

Når den konkrete rettelsen er på plass, prøv igjen med den faktiske SSTP-klienten og den ekte profilen, ikke med en nettleserfane.

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

Hvis økten kobler til og ressurser fortsatt feiler, er ikke tunnelen lenger den mistenkte: gå videre til ruting, DNS og tjenestetilgang. Det er en annen undersøkelse med andre bevis. Å beholde de fungerende TLS- og autentiseringstrinnene hindrer at det blir en gjentakelse av den første. Skriv trinnet som feilet i saken, ellers starter neste person på toppen igjen.