SSTP är PPP över HTTPS, inte en webbsida på port 443

SSTP bär PPP inuti en HTTPS-anslutning, därför ser det ut som webbtrafik för allt i mitten. TLS och HTTP etablerar den yttre kanalen, sedan förbereder SSTP-kontrollmeddelanden tunneln och PPP levererar sessionens beteende. En webbläsare som laddar en sida på samma adress har bara slutfört en del av det första steget. Att behandla det som ett VPN-test är sättet en fungerande proxy får skulden för en protokollavvikelse.

Gå igenom de fyra stegen i ordning, och felet du ser hamnar i ett av dem.

Steg 1: TCP och TLS

Klienten öppnar en TCP-anslutning till port 443 och utför en TLS-handskakning. Certifikatkedjan måste matcha värdnamnet klienten konfigurerades med. En namnskillnad här ger ett fel innan något SSTP-meddelande utbyts, och SSTP-specifikationen förutsätter att denna yttre HTTPS-kanal redan finns. Inget i de senare stegen kan kompensera ett tillitsfel här.

En vanlig webbserver kan slutföra det här steget perfekt och ändå misslyckas i nästa. TLS-framgång är bevis om certifikatet, inte om protokollet bakom det.

Steg 2: HTTPS-begäran

SSTP gör sin begäran med en specifik metod, SSTP_DUPLEX_POST, och håller utbytet öppet i stället för att returnera ett dokument. En server eller proxy konfigurerad för vanliga sidbegäranden kan acceptera anslutningen och sedan avvisa metoden. Den avvisningen är kompatibilitetsproblemet folk oftast beskriver som att port 443 är blockerad.

Läs svarskoden och metoden i serverloggen. En avvisning i det här steget är ett annat problem än en TCP-timeout, och de två leder till olika åtgärder.

Steg 3: kontrollmeddelanden

När begäran har accepterats utbyter SSTP kontrollmeddelanden som förhandlar och förbereder tunneln. Det är protokollmeddelanden inne i HTTPS-kroppen, inte HTTP-begäranden, så en proxy som inspekterar och skriver om kroppar kan bryta dem medan sidbegäranden förblir orörda.

Det är här en djupinspektions-middlebox tjänar sitt rykte. Om sidor laddas men VPN misslyckas, kontrollera om kroppen ändras i stället för om porten är öppen.

Steg 4: PPP tar över

PPP ger sedan sessionens beteende: länkförhandling, autentisering och den nätverkslagerkonfiguration som följer. PPP-autentisering är skild från den TLS-kontroll klienten redan har klarat. Ett servercertifikat som klienten accepterar säger inget om huruvida användarens inloggningsuppgifter är giltiga eller kontot är auktoriserat.

Ett accepterat certifikat och en avvisad inloggning är inte motsägelsefulla. De är på varandra följande steg med oberoende utfall.

Autentisering har flera roller

Klienten validerar TLS-serverns identitet mot sitt tillitslager och det konfigurerade namnet. Sedan autentiserar PPP användaren eller maskinen, beroende på utrullning. Servern kan lägga till sin egen policy för vem som får ansluta och vad de får nå. Håll värdnamnet konsekvent med certifikatets identitet, eftersom en rå adress i stället gör en fungerande konfiguration till ett namnkontrollfel.

Skriv ned vilket steg som rapporterade felet. Certifikat, metod, kontrollmeddelande, PPP-autentisering, sedan rutter: fem ställen, fem åtgärder.

Vad ett webbläsartest kan och inte kan visa

Att ladda en sida på adressen bevisar DNS-uppslagning, TCP-nåbarhet och att något lyssnar och talar HTTP. Det bevisar inte att metoden accepteras, att kontrollutbytet överlever eller att PPP-autentisering är konfigurerad. Använd en klient som implementerar SSTP i stället för att konvertera en annan profil genom att ändra porten.

När sessionen är uppe avgör rutter, DNS och vidarebefordran på serversidan fortfarande vad användaren kan nå. Tunneln är en väg, inte ett tillstånd.