SSTP-timeout eller certifikatfel: så skiljer du dem åt

En SSTP-anslutning misslyckas på två sätt som ser likadana ut från användarens stol, och reparationen för vartdera ligger på ett annat lager. En timeout betyder att ett nödvändigt utbyte aldrig slutfördes; ett certifikatfel betyder att identitetsmaterial anlände och avvisades. Behandlar du det andra som det första hamnar du hos brandväggar och lösenord som aldrig var problemet. Det avgörande beviset finns i klientens egen logg, om du läser den innan du ändrar något.

Två fel, två olika utbyten

SSTP bär en tunnel inuti en session med HTTPS-form, därför överlever den nätverk som inte tillåter något annat än 443. Klienten slutför en TLS-handskakning, skickar en HTTP-begäran med en protokollspecifik metod, och sedan går tunneln inuti den strömmen. Ett fel i något av dessa steg stoppar anslutningen, och bara de senare inbegriper inloggningsuppgifter.

Den ordningen är diagnosen. Om TLS-handskakningen aldrig slutförs skickades inga inloggningsuppgifter, så en återställning av lösenordet kan inte hjälpa. Om handskakningen slutförs och sedan hakar upp sig godtogs identiteten och något i begärans väg avvisade den. Om handskakningen misslyckas med ett valideringsmeddelande svarade servern och klienten tyckte inte om det den hörde. Tre utfall, tre lager.

Loggraden anger vanligtvis vilken av de tre du är i, därför är det värt att fånga den före den första ändringen.

En timeout betyder att ett steg aldrig slutfördes

Börja med namnmatchning och TCP-nåbarhet, eftersom en timeout där ser identisk ut med en timeout senare. En portkontroll som rapporterar 443 öppen bevisar att en lyssnare accepterade en anslutning, och inget mer än så.

Nästa misstänkta är vägen och inte värden. Proxyservrar och applikationsmedvetna brandväggar avvisar ibland den begäransmetod som SSTP använder, eller släpper en ström som förblir öppen i timmar, och båda beteendena ser ut som en timeout från klientens sida. En vanlig HTTPS-sida som samma värd levererar laddas perfekt medan tunnelmetoden avvisas, därför bevisar det så lite att bläddra till slutpunkten. Testa från ett nätverk utan proxyn för att skilja de två fallen.

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

En timeout före något svar från motparten säger inget om kontot, och att byta lösenordet i det läget lägger bara till en variabel.

Ett certifikatfel betyder att identiteten avvisades

Här svarade servern faktiskt, så nätverket fungerar och frågan flyttar till identiteten. Jämför namnet klienten slår med de namn certifikatet verkligen hävdar, och kontrollera sedan giltighetsdatum och utfärdarkedjan.

En privat CA som klienten inte litar på ger samma felklass som ett utgånget certifikat, och detsamma gäller en klocka som går timmar fel. Att slå det rå adressen skapar en ny avvikelse, eftersom ett certifikat hävdar namn och inte adresser. I en hanterad utrullning hämtar du den avsedda förtroendekonfigurationen från dess administratör i stället för att acceptera en ersättningsrot som en felsida erbjuder. Valideringen förblir på medan du åtgärdar orsaken.

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

Håll det lyckade TLS-steget intakt när det väl passerat, eftersom att rulla tillbaka det senare döljer vilken ändring som faktiskt reparerade tunneln.

Där de två blandas ihop

Båda felen visar sig som en anslutning som inte kommer upp, och båda kommer efter att användaren ändrat något orelaterat. Det sammanträffandet är det som gör den felaktiga reparationen trovärdig ett tag.

Två vanor håller dem åtskilda. Fånga klientloggen innan du rör konfigurationen, så att det första tillståndet bevaras. Ändra ett lager per försök, så att nästa resultat hör till en känd variabel. En portkontroll och en webbläsare är delobservationer och inte hela sekvensen, och ingen av dem ersätter klientens egen rapport. Ingen av vanorna kostar något, och båda förkortar undersökningen.

Certifikatfrågan och nåbarhetsfrågan är dokumenterade separat av en anledning.

Testa igen med den riktiga klienten och gå sedan inåt

När den konkreta rättelsen är på plats, försök igen med den faktiska SSTP-klienten och den riktiga profilen, inte med en webbläsarflik.

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

Om sessionen ansluter och resurser fortfarande misslyckas är tunneln inte längre den misstänkta: gå vidare till routning, DNS och tjänsteåtkomst. Det är en annan undersökning med andra bevis. Att behålla de fungerande TLS- och autentiseringsstegen hindrar att det blir en upprepning av den första. Skriv in steget som misslyckades i ärendet, annars börjar nästa person om från toppen.