SSTP achter een TLS-inspecterende proxy: waar de sessie breekt

Uw browser laadt het bedrijfsintranet, het proxycertificaat is vertrouwd, en toch valt de SSTP-client weg vlak bij het einde van de verbinding. Dat patroon wijst op het verschil tussen een webaanvraag en een getunnelde sessie, niet op een verkeerd wachtwoord. Loop de verbinding van TCP omhoog door en noteer de eerste fase die faalt. De fase, niet de foutcode, vertelt u of de proxy de oorzaak is.

Begin waar de client stopt

De client doorloopt een vaste reeks: TCP-verbinding naar poort 443, TLS-handshake, certificaatvalidatie, de HTTP-uitwisseling van SSTP, PPP-onderhandeling en -authenticatie, en dan IP-configuratie. Een fout in elke fase laat een ander spoor achter, en ze door elkaar halen brengt u op de verkeerde configuratiepagina.

Een TCP-fout is een time-out of een reset voordat er ook maar één TLS-byte verschijnt. Een TLS-fout is een waarschuwing of een handshake-time-out. Een certificaatfout geeft een waarschuwing over de keten of de naam. Een HTTP-fout komt na een geslaagde handshake, vaak als statuscode of onmiddellijke sluiting. Een PPP-fout komt nadat de tunnel technisch is opgezet, waardoor hij op een authenticatieprobleem lijkt.

Lees in het clientlog de laatste geslaagde fase in plaats van de eerste foutregel. De foutregel meldt meestal het gevolg, terwijl de fasegrens het onderdeel noemt dat weigerde.

Wat SSTP het netwerk vraagt te dragen

SSTP draait over TLS op TCP 443 en stuurt dan een HTTP-verzoek met de naam SSTP_DUPLEX_POST, gedefinieerd in de SSTP-specificatie, naar een pad van de vorm /sra_{GUID}/. Het verzoek kondigt een praktisch onbeperkte inhoudslengte aan en houdt de stream in beide richtingen open voor de hele sessie. De PPP-frames reizen binnen die stream.

Daarom kan een proxy die gewoon browsen afhandelt, toch falen. Een GET of POST met een eindige body kan worden gebufferd, geïnspecteerd en doorgestuurd; een duplexstream met een body die nooit eindigt niet. Een proxy die wacht tot de body klaar is, wacht voor altijd, en de client loopt uiteindelijk in een time-out.

Methodfiltering en authenticatie voegen hun eigen faalmodi toe. Als de proxy om inloggegevens vraagt, antwoordt de VPN-client misschien niet, terwijl de browser dat wel zou doen. Als hij de methode verwijdert of herschrijft, weigert de gateway het verzoek voordat PPP begint.

Waarom inspectie de identiteit verandert

Een TLS-inspecterende proxy beëindigt de TLS-verbinding van de client en opent een aparte verbinding naar de gateway. De client valideert dus het certificaat van de proxy, niet dat van de gateway, en de gateway ziet de proxy als zijn tegenpartij. Wanneer de organisatie haar eigen root uitrolt, kunnen zowel de browser als de VPN-client die keten accepteren, zodat de handshake slaagt en het probleem naar de volgende fase verschuift.

Een geslaagde validatie betekent niet dat de proxy de sessie kan dragen. Hij moet nog steeds een onbeperkte tweerichtings-POST zonder buffering doorgeven en beide verbindingen urenlang in leven houden. Veel inspectieproducten zijn gebouwd voor verzoek-antwoordverkeer en behandelen dit geval slecht of helemaal niet.

Daarom is het toevoegen van een onbekende root of het uitschakelen van verificatie de verkeerde reparatie. Het verandert welk certificaat de client accepteert; het doet niets aan de streamafhandeling die de sessie echt brak.

Stel de uitgever vast voordat u instellingen wijzigt

Vraag het eindpunt welk certificaat het presenteert en wie het heeft ondertekend. De opdrachten hieronder tonen de keten en de uitgever zonder een VPN-sessie te starten:

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

Als de uitgever een openbare CA is, wordt de verbinding voor deze host waarschijnlijk niet onderschept en ligt de fout elders. Als de uitgever de eigen CA van de organisatie is, is inspectie actief en wordt de gateway via een proxy bereikt. Vergelijk de vingerafdruk met degene die het netwerkteam verwacht voordat u alleen op de naam afgaat.

Een browsertest naar dezelfde host bewijst alleen dat de proxy een GET accepteert. Hij zegt niets over de SSTP-methode, de URI van het verzoek of de levensduur van de body, dus beschouw een werkende intranetpagina niet als bewijs dat het tunnelpad wordt ondersteund.

Kies het ondersteunde pad

Stel de netwerkeigenaar één concrete vraag: staat de proxy een ongebufferde duplex-POST naar deze gateway op poort 443 toe? Een ja leidt tot een uitzondering in de proxy of een gedocumenteerde omzeiling voor de VPN-host. Een nee betekent dat het geïnspecteerde pad SSTP niet kan dragen, en de ondersteunde oplossing is een ander pad of protocol, niet een aanpassing van de client.

Opties omvatten meestal een niet-geïnspecteerde uitgang voor de VPN-gateway, een split-tunnelontwerp dat alleen bedrijfsverkeer door de proxy stuurt, of een alternatief protocol dat de organisatie op een andere poort ondersteunt. Elk hoort bij het netwerkontwerp, en elk zou met hetzelfde apparaat en profiel moeten worden getest zodat de vergelijking het pad isoleert.

Documenteer de uitkomst: uitgever, mislukte fase, proxyregel en gekozen pad. De volgende persoon die dezelfde stilstand op 98 procent ziet, kan dan één feit controleren in plaats van de hele doorloop te herhalen.