SSTP-timeout eller certifikatfejl: sådan skelner du dem

En SSTP-forbindelse fejler på to måder, der fra brugerens stol ser ens ud, og reparationen for hver ligger på et forskelligt lag. En timeout betyder, at en påkrævet udveksling aldrig blev færdig; en certifikatfejl betyder, at identitetsmateriale ankom og blev afvist. Behandler du det andet som det første, sendes du mod firewalls og adgangskoder, som aldrig var problemet. Det afgørende bevis står i klientens egen log, hvis du læser den, før du ændrer noget.

To fejl, to forskellige udvekslinger

SSTP bærer en tunnel inde i en session med HTTPS-form, og derfor overlever den netværk, der ikke tillader andet end 443. Klienten fuldfører et TLS-håndtryk, sender en HTTP-anmodning med en protokolspecifik metode, og derefter kører tunnelen inde i den strøm. En fejl på et af disse trin stopper forbindelsen, og kun de senere involverer legitimationsoplysninger.

Den rækkefølge er diagnosen. Hvis TLS-håndtrykket aldrig fuldføres, blev ingen legitimationsoplysninger sendt, så en nulstilling af adgangskoden kan ikke hjælpe. Hvis håndtrykket fuldføres og derefter går i stå, blev identiteten accepteret, og noget i anmodningens vej afviste den. Hvis håndtrykket fejler med en valideringsmeddelelse, svarede serveren, og klienten brød sig ikke om det, den hørte. Tre udfald, tre lag.

Loglinjen angiver normalt, hvilken af de tre du er i, og derfor er det værd at fange den før den første ændring.

En timeout betyder, at et trin aldrig blev færdigt

Start med navneopløsning og TCP-rækkevidde, fordi en timeout der ser identisk ud med en timeout senere. En porttjekker, der rapporterer 443 åben, beviser, at en lytter har accepteret en forbindelse, og intet ud over det.

Den næste mistænkte er vejen frem for værten. Proxyer og applikationsbevidste firewalls afviser nogle gange den anmodningsmetode, SSTP bruger, eller dropper en strøm, der forbliver åben i timer, og begge adfærd ser ud som en timeout fra klienten. En almindelig HTTPS-side, der leveres af samme vært, indlæses perfekt, mens tunnelmetoden afvises, og derfor beviser det så lidt at browse til endepunktet. Test fra et netværk uden proxyen for at skelne de to tilfælde.

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

En timeout før noget svar fra modparten siger intet om kontoen, og at ændre adgangskoden på det tidspunkt tilføjer kun en variabel.

En certifikatfejl betyder, at identiteten blev afvist

Her svarede serveren faktisk, så netværket virker, og spørgsmålet flytter til identitet. Sammenlign det navn, klienten ringer til, med de navne, certifikatet faktisk hævder, og kontroller derefter gyldighedsdatoer og udstedelseskæden.

En privat CA, som klienten ikke stoler på, giver samme fejlklasse som et udløbet certifikat, og det gør et ur, der er timer forkert, også. At ringe til den rå adresse skaber en ny uoverensstemmelse, fordi et certifikat hævder navne frem for adresser. I en administreret udrulning skal du hente den tilsigtede tillidskonfiguration fra dens administrator i stedet for at acceptere en erstatningsrod, som en fejlside tilbyder. Validering forbliver slået til, mens du retter årsagen.

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-trin intakt, når det først består, fordi at rulle det tilbage senere skjuler, hvilken ændring der faktisk reparerede tunnelen.

Hvor de to blandes sammen

Begge fejl viser sig som en forbindelse, der ikke kommer op, og begge kommer, efter at brugeren har ændret noget urelateret. Det sammenfald er det, der får den forkerte reparation til at se plausibel ud et stykke tid.

To vaner holder dem adskilt. Fang klientloggen, før du rører konfigurationen, så den første tilstand bevares. Ændr ét lag ad gangen, så det næste resultat hører til en kendt variabel. En porttjekker og en browser er delvise observationer snarere end hele sekvensen, og ingen af dem erstatter klientens egen rapport. Ingen af vanerne koster noget, og begge forkorter undersøgelsen.

Certifikatspørgsmålet og rækkevidde-spørgsmålet er dokumenteret hver for sig af en grund.

Test igen med den rigtige klient, og gå så indad

Når den konkrete rettelse er på plads, prøv igen med den faktiske SSTP-klient og den rigtige profil, ikke med en browservane.

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

Hvis sessionen oprettes, og ressourcer stadig fejler, er tunnelen ikke længere den mistænkte: gå videre til routing, DNS og tjenesteadgang. Det er en anden undersøgelse med andre beviser. At bevare de fungerende TLS- og godkendelsestrin forhindrer, at det bliver en gentagelse af den første. Skriv det trin, der fejlede, i billetten, for ellers starter den næste person forfra igen.