Vypršení časového limitu u SSTP nebo chyba certifikátu: jak je rozlišit

SSTP spojení selhává dvěma způsoby, které z pohledu uživatele vypadají stejně, a oprava každého leží v jiné vrstvě. Vypršení limitu znamená, že povinná výměna nikdy neskončila; chyba certifikátu znamená, že materiál identity dorazil a byl odmítnut. Když druhé považujete za první, jdete po firewallech a heslech, které nikdy nebyly problémem. Rozlišující důkaz je v logu samotného klienta, pokud si ho přečtete dřív, než cokoli změníte.

Dvě selhání, dvě různé výměny

SSTP nese tunel uvnitř relace ve tvaru HTTPS, proto přežívá sítě, které nepovolují nic než 443. Klient dokončí TLS handshake, odešle HTTP požadavek s metodou specifickou pro protokol a pak tunel běží uvnitř tohoto toku. Selhání v kterémkoli z těchto kroků spojení zastaví a jen ty pozdější zahrnují přihlašovací údaje.

Toto pořadí je diagnostika. Pokud TLS handshake nikdy neskončí, nebyly odeslány žádné přihlašovací údaje, takže reset hesla nepomůže. Pokud handshake skončí a pak uvízne, identita byla přijata a něco v cestě požadavku ji odmítlo. Pokud handshake selže s validační zprávou, server odpověděl a klientovi se nelíbilo, co slyšel. Tři výsledky, tři vrstvy.

Řádek v logu obvykle říká, ve kterém ze tří případů jste, proto se vyplatí ho zachytit před první změnou.

Vypršení limitu znamená, že fáze nikdy neskončila

Začněte překladem jmen a dostupností TCP, protože vypršení limitu tam vypadá stejně jako vypršení později. Kontrola portu, která hlásí, že 443 je otevřený, dokazuje jen to, že naslouchač přijal spojení, a nic víc.

Další podezřelý je cesta, ne hostitel. Proxy a firewally rozpoznávající aplikace někdy odmítnou metodu požadavku, kterou SSTP používá, nebo zahodí tok, který zůstává otevřený hodiny, a oba projevy vypadají z pohledu klienta jako vypršení limitu. Běžná stránka HTTPS z téhož hostitele se načte bezchybně, zatímco metoda tunelu je odmítnuta, proto procházení koncového bodu dokazuje tak málo. Otestujte to ze sítě bez proxy, abyste oba případy oddělili.

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

Vypršení limitu před jakoukoli odpovědí protějšku nic neříká o účtu a změna hesla v tu chvíli jen přidá proměnnou.

Chyba certifikátu znamená, že identita byla odmítnuta

Tady server skutečně odpověděl, takže síť funguje a otázka se přesouvá k identitě. Porovnejte název, kterým klient volá, s názvy, které certifikát skutečně tvrdí, a pak zkontrolujte data platnosti a vydavatelský řetězec.

Soukromá CA, které klient nevěří, vytváří stejnou třídu chyby jako propadlý certifikát, a stejně tak hodiny, které se rozcházejí o hodiny. Volání na surovou adresu vytváří nový nesoulad, protože certifikát tvrdí názvy, ne adresy. V řízeném nasazení si vyžádejte zamýšlenou konfiguraci důvěry od jejího správce, místo abyste přijali náhradní kořen nabízený chybovou stránkou. Validace zůstává zapnutá, dokud příčinu neopravíte.

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

Úspěšnou TLS fázi nechte po průchodu nedotčenou, protože její pozdější zrušení skryje, která změna tunel skutečně opravila.

Kde se obě pletou

Obě selhání vypadají jako spojení, které se nezvedne, a obě přicházejí poté, co uživatel změnil něco nesouvisejícího. Právě tahle shoda dělá špatnou opravu na chvíli uvěřitelnou.

Dva návyky je drží oddělené. Zachyťte log klienta dřív, než se dotknete konfigurace, aby první stav zůstal. Měňte jednu vrstvu na pokus, aby následující výsledek patřil známé proměnné. Kontrola portu i prohlížeč jsou částečná pozorování, ne celá posloupnost, a ani jedno nenahrazuje vlastní zprávu klienta. Ani jeden návyk nic nestojí a oba vyšetřování zkracují.

Otázka certifikátu a otázka dostupnosti jsou zdokumentovány odděleně z nějakého důvodu.

Otestujte znovu skutečným klientem a pak jděte dovnitř

Jakmile je konkrétní oprava na místě, zkuste to znovu se skutečným klientem SSTP a opravdovým profilem, ne s kartou prohlížeče.

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

Pokud se relace připojí a zdroje stále selhávají, tunel už není podezřelý: přejděte ke směrování, DNS a přístupu ke službám. To je jiné vyšetřování s jinými důkazy. Zachování funkčních fází TLS a ověřování brání tomu, aby se to stalo opakováním prvního. Zapište do tiketu fázi, která selhala, jinak příští člověk začne zase od začátku.