SSTP misslyckas där webbläsarens HTTPS lyckas: varför
SSTP körs inuti TLS på port 443, men det är inte en webbförfrågan. Testa TCP, TLS-identitet, SSTP-utbytet och PPP-autentisering som separata steg.
Webbläsaren öppnar VPN-värdnamnet via HTTPS utan klagomål, och SSTP-klienten vägrar fortfarande ansluta. Det finns inget motsägelsefullt i paret. SSTP använder TLS som yttre transport och kör sedan sin egen förfrågan och PPP-nyttolast inuti den anslutningen, så en lyckad sidladdning bevisar bara en smal sak: värden svarar på en GET på port 443. Klienten ställer en annan fråga, och servern kanske besvarar den dåligt.
Sidan laddas och tunneln inte
Folk tar till webbläsartestet eftersom det är snabbt, och behandlar sedan resultatet som bevis för att servern är nåbar och konfigurerad. Det är bevis om en GET till den sökväg adressfältet öppnade, inget mer. VPN-samtalet börjar efter samma TLS-handskakning, men skickar en metod och en sökväg som en webbsida aldrig använder. Ett 200 för webbläsaren säger därför inget om huruvida SSTP-slutpunkten finns.
Separera de två observationerna och sökningen blir kortare. Transport och certifikatkedja fungerar, och något i protokollutbytet ovanför gör det inte. Det är en annan undersökning än en trasig port eller ett utgånget certifikat, och den kräver andra bevis.
Vad SSTP-klienten faktiskt skickar
Klienten skickar en HTTP-förfrågan med metoden SSTP_DUPLEX_POST till sökvägen /sra_{GUID}/ och håller sedan anslutningens kropp öppen som en dubbelriktad ström som bär PPP-ramar. En korrekt server svarar HTTP/1.1 200 och slutar bete sig som en webbserver. Allt annat är en signatur: 405 eller 404 betyder att slutpunkten inte finns, 301 eller 302 betyder att något omdirigerar förfrågan, och en omedelbar FIN betyder att en proxy eller server stängde strömmen.
Därför måste målet vara en SSTP-server och inte en webbserver med ett påskruvat TLS-certifikat. Metoden, sökvägen och den långvariga kroppen är protokollkrav, så en omvänd proxy kan inte lägga till dem enbart med konfiguration. En proxy som vidarebefordrar vanlig HTTPS perfekt kan ändå avvisa en metod den inte känner igen.
Där en proxy eller webbserver bryter strömmen
En mellanhand inspekterar HTTP-förfrågningsraden innan den vidarebefordrar något, och en anpassad metod med en ovanlig sökväg kan fallera på dess regler. Vissa enheter serverar en normal sida medan de avvisar eller avbryter tunneln, så klienten rapporterar en anslutning som börjar och sedan dör i stället för en ren avvisning. Andra accepterar förfrågan och tillämpar sedan en kropps- eller inaktivitetstimeout som PPP-keepalives inte överlever. Båda ser likadana ut från klientsidan, därför är steget som misslyckades viktigare än feltexten.
Att dela port 443 mellan en webbplats och SSTP är ett routingval, inte ett löfte att varje hopp hanterar båda samtalen likadant. Om en lastbalanserare, brandvägg eller TLS-terminator finns i vägen, lägg den på listan över misstänkta innan du rör VPN-konfigurationen.
Testa stegen var för sig
Kör kontrollerna i ordning och stanna vid första felet, eftersom varje steg utesluter ett annat lager. TLS-proben nedan skiljer certifikatets identitet från allt SSTP gör. Ersätt värdnamnet med din slutpunkt och läs subject och kedja som den skriver ut.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comKartlägg sedan de återstående bevisen mot stegen i stället för att gissa från klientfelet. Tabellen nedan är checklistan för ärendet, med signaturen som skiljer ett fel från nästa.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Notera det sista steget som lyckades i ärendet i stället för att skriva "kan inte ansluta". MS-SSTP-specifikationen dokumenterar förfrågan och PPP-utbytet som följer på TLS-handskakningen, och är referensen till varför ett webbläsartest inte kan ersätta något av dem.
Identitet först, sedan PPP
TLS-identitet och PPP-autentisering är sekventiella, inte alternativa, och att blanda ihop dem skickar folk till fel serverinställning. Klienten validerar först serverns certifikat och dess avsedda syfte, sedan förhandlar PPP sin egen tillstånd och autentiserar användaren med en challenge-responsmetod eller EAP. Ett certifikatproblem ger ett annat fel än ett avvisat lösenord, och inget av felen beskriver steget det andra täcker.
Att byta ut värdnamnet mot en adress, eller klicka förbi certifikatvarningen, tar bort kontrollen som skulle ha identifierat det felande steget i stället för att åtgärda det. Behåll varningen och läs den. Nollställ inte heller ett PPP-lösenord när HTTP-utbytet aldrig nådde SSTP-beteendet, eftersom inloggningsuppgifterna aldrig efterfrågades.