SSTP bakom en TLS-inspekterande proxy: där sessionen bryts

Din webbläsare laddar det interna nätet, proxycertifikatet är betrott, och ändå faller SSTP-klienten ut nära slutet av anslutningen. Mönstret pekar på skillnaden mellan en webbförfrågan och en tunnelerad session, inte på ett felaktigt lösenord. Gå igenom anslutningen från TCP och uppåt och notera det första steget som misslyckas. Steget, inte felkoden, berättar om proxyn är orsaken.

Börja där klienten stannar

Klienten går igenom en fast sekvens: TCP-anslutning till port 443, TLS-handskakning, certifikatvalidering, SSTP:s HTTP-utbyte, PPP-förhandling och -autentisering, sedan IP-konfiguration. Ett fel i varje steg lämnar ett annat spår, och att blanda ihop dem leder dig till fel konfigurationssida.

Ett TCP-fel är en tidsgräns eller en återställning innan en enda TLS-byte visas. Ett TLS-fel är en varning eller en handskaknings-tidsgräns. Ett certifikatfel ger en varning om kedjan eller namnet. Ett HTTP-fel kommer efter en lyckad handskakning, ofta som statuskod eller omedelbar stängning. Ett PPP-fel kommer efter att tunneln är tekniskt upprättad, därför ser det ut som ett autentiseringsproblem.

Läs klientloggen efter det senaste lyckade steget i stället för den första felraden. Felraden rapporterar oftast konsekvensen, medan steggränsen namnger komponenten som vägrade.

Vad SSTP kräver att nätet bär

SSTP kör över TLS på TCP 443 och skickar sedan en HTTP-förfrågan som heter SSTP_DUPLEX_POST, definierad i SSTP-specifikationen, till en sökväg av formen /sra_{GUID}/. Förfrågan deklarerar en praktiskt taget obegränsad innehållslängd och håller strömmen öppen i båda riktningarna under hela sessionen. PPP-ramarna färdas inuti den strömmen.

Därför kan en proxy som hanterar vanligt surfande ändå misslyckas. En GET eller POST med ändligt innehåll kan buffras, inspekteras och vidarebefordras; en duplexström med ett innehåll som aldrig tar slut kan inte. En proxy som väntar på att innehållet ska bli klart väntar för evigt, och klienten får till slut en tidsgräns.

Metodfiltrering och autentisering lägger till egna fellägen. Om proxyn begär inloggningsuppgifter för förfrågan svarar VPN-klienten kanske inte, även om webbläsaren skulle göra det. Om den tar bort eller skriver om metoden avvisar gatewayen förfrågan innan PPP börjar.

Varför inspektion ändrar identiteten

En TLS-inspekterande proxy avslutar klientens TLS-anslutning och öppnar en separat anslutning till gatewayen. Klienten validerar därför proxyns certifikat, inte gatewayens, och gatewayen ser proxyn som sin motpart. När organisationen distribuerar sin egen rot kan både webbläsaren och VPN-klienten godta den kedjan, så handskakningen lyckas och problemet flyttar till nästa steg.

Lyckad validering betyder inte att proxyn kan bära sessionen. Den måste fortfarande vidarebefordra en obegränsad dubbelriktad POST utan buffring och hålla båda anslutningarna vid liv i timmar. Många inspektionsprodukter är byggda för förfrågan-svar-trafik och hanterar detta fall dåligt eller inte alls.

Därför är det att lägga till en okänd rot eller stänga av validering fel reparation. Det ändrar vilket certifikat klienten accepterar; det gör ingenting åt strömhanteringen som faktiskt bröt sessionen.

Identifiera utfärdaren innan du ändrar inställningar

Fråga ändpunkten vilket certifikat den presenterar och vem som signerade det. Kommandona nedan visar kedjan och utfärdaren utan att starta en VPN-session:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Om utfärdaren är en offentlig CA avlyssnas förmodligen inte anslutningen för den här värden, och felet finns någon annanstans. Om utfärdaren är organisationens egen CA är inspektionen aktiv och gatewayen nås via en proxy. Jämför fingeravtrycket med det som nätverksteamet förväntar sig innan du drar slutsatser enbart av namnet.

Ett webbläsartest mot samma värd bevisar bara att proxyn accepterar en GET. Det säger ingenting om SSTP-metoden, förfrågans URI eller innehållets livslängd, så behandla inte en fungerande intranetsida som bevis för att tunnelvägen stöds.

Välj den stödda vägen

Ställ nätägaren en konkret fråga: tillåter proxyn en obuffrad duplex-POST till denna gateway på port 443? Ett ja leder till ett undantag i proxyn eller en dokumenterad kringgång för VPN-värden. Ett nej betyder att den inspekterade vägen inte kan bära SSTP, och den stödda lösningen är en annan väg eller protokoll, inte en justering av klienten.

Alternativen omfattar vanligtvis en oinspekterad utgång för VPN-gatewayen, en design med delad tunnel som bara skickar företagstrafik genom proxyn, eller ett alternativt protokoll som organisationen stöder på en annan port. Var och en hör till nätverksdesignen, och var och en bör testas med samma enhet och profil så att jämförelsen isolerar vägen.

Dokumentera resultatet: utfärdare, misslyckat steg, proxyregel och vald väg. Nästa person som ser samma 98-procentiga stillestånd kan då kontrollera ett enda faktum i stället för att upprepa hela genomgången.