SSTP hannert engem Proxy, deen TLS inspizéiert: wou d’Sessioun brécht

Äre Browser lued de Firmenintranet, d’Proxy-Zertifikat ass vertrauenswierdeg, an trotzdeem fällt de SSTP-Client no beim Enn vun der Verbindung aus. Dëst Muster weist op den Ënnerscheed tëscht enger Webufro an enger Sessioun am Tunnel, net op e falscht Passwuert. Gitt d’Verbindung vun TCP aus no uewen duerch a notéiert déi éischt Etapp, déi feelt. D’Etapp, net de Feiercode, seet Iech, ob de Proxy d’Ursaach ass.

Fänkt do un, wou de Client stoppt

De Client geet duerch eng fest Sequenz: TCP-Verbindung op Port 443, TLS-Handshake, Zertifikatsprüfung, den HTTP-Austausch vum SSTP, PPP-Verhandlung an -Authentifizéierung, dann IP-Konfiguratioun. E Feeler op all Etapp hannerléisst eng aner Spuer, a wann een se verwiesselt, kënnt een op déi falsch Konfiguratiounssäit.

En TCP-Feeler ass en Timeout oder en Reset, ier iergendeen TLS-Byte erschéngt. En TLS-Feeler ass eng Warnung oder en Handshake-Timeout. En Zertifikatsfeeler gëtt eng Warnung iwwer d’Kette oder den Numm. En HTTP-Feeler kënnt no engem erfollegräichen Handshake, dacks als Statuscode oder als direkt Zoumaachen. En PPP-Feeler kënnt, nodeems den Tunnel technesch opgebaut ass, dofir gesäit en aus wéi e Problem mat der Authentifizéierung.

Liest am Client-Log déi lescht erfollegräich Etapp amplaz déi éischt Feelerzeil. D’Feelerzeil melle meeschtens d’Konsequenz, wärend d’Etappegrenz de Komponent nennt, deen ofgelehnt huet.

Wat SSTP vum Netzwierk verlaangt ze droen

SSTP leeft iwwer TLS op TCP 443 a schéckt dann eng HTTP-Ufro mam Numm SSTP_DUPLEX_POST, déi an der SSTP-Spezifikatioun definéiert ass, op e Pad vun der Form /sra_{GUID}/. D’Ufro deklaréiert eng praktesch onlimitéiert Inhaltlängt an hält de Stroum wärend der ganzer Sessioun a béid Richtungen op. D’PPP-Framen beweege sech bannent dësem Stroum.

Dofir kann e Proxy, dee gewéinlech Surfen verschafft, nach ëmmer feelen. Eng GET oder POST mat engem endlechen Body kann gepuffert, gepréift an weidergeleet ginn; en Duplex-Stroum mat engem Body, deen ni ophält, net. E Proxy, deen op d’Enn vum Body waart, waart fir ëmmer, an de Client geet schlussendlech an en Timeout.

Methodfilterung an Authentifizéierung bréngen hir eege Feelermodi mat. Wann de Proxy fir d’Ufro Umeldungsdaten verlaangt, äntwert de VPN-Client vläicht net, och wann de Browser et géif. Wann en d’Method ewechhëlt oder ëmschreift, refuséiert de Gateway d’Ufro, ier PPP ufänkt.

Firwat d’Inspektioun d’Identitéit ännert

En TLS-inspizéierende Proxy beendet d’TLS-Verbindung vum Client an opent eng separat Verbindung zum Gateway. Dofir validéiert de Client d’Zertifikat vum Proxy, net dat vum Gateway, an de Gateway gesäit de Proxy als säi Partner. Wann d’Organisatioun hir eege Root verdeelt, kënnen de Browser an de VPN-Client béid déi Kette akzeptéieren, sou datt den Handshake geléngt an de Problem op déi nächst Etapp wiesselt.

Eng erfollegräich Validéierung heescht net, datt de Proxy d’Sessioun ka droen. En muss nach ëmmer en onlimitéierte bidirektionale POST ouni Pufferung weiderleeden an déi zwou Verbindungen iwwer Stonnen um Liewen halen. Vill Inspektiounsprodukter si fir Ufro-Äntwert-Verkeier gebaut a behiewen dëse Fall schlecht oder guer net.

Dofir ass eng onbekannt Root derbäizesetzen oder d’Prüfung auszeschalten déi falsch Reparatur. Et ännert, wéi en Zertifikat de Client akzeptéiert; et mécht näischt fir d’Stroumveraarbechtung, déi d’Sessioun tatsächlech gebrach huet.

Bestëmmt den Aussteller, ier Dir Astellunge ännert

Frot den Endpunkt, wéi en Zertifikat en présentéiert a wien et ënnerschriwwen huet. D’Befehler hei drënner weisen d’Kette an den Aussteller, ouni eng VPN-Sessioun ze starten:

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

Wann den Aussteller eng ëffentlech CA ass, gëtt d’Verbindung fir dëse Host wahrscheinlech net ofgefaangen an de Feeler ass soss anzwousch. Wann den Aussteller d’eegen CA vun der Organisatioun ass, ass d’Inspektioun aktiv an de Gateway gëtt iwwer e Proxy erreecht. Vergläicht de Fangerofdrock mat deem, deen den Netzwierkteam erwaart, ier Dir nëmmen aus dem Numm eng Schlussfolgerung zitt.

En Browsertest op dee selwechten Host beweise just, datt de Proxy eng GET akzeptéiert. En seet näischt iwwer d’SSTP-Method, d’Ufro-URI oder d’Liewensdauer vum Body, also betruecht eng funktionéierend Intranetsäit net als Beweis, datt de Tunnelpad ënnerstëtzt gëtt.

Wielt de ënnerstëtzte Pad

Stellt dem Netzwierkbesëtzer eng konkret Fro: erlaabt de Proxy en ongepufferte Duplex-POST op dëse Gateway op Port 443? En Jo féiert zu enger Ausnam am Proxy oder zu enger dokumentéierter Ëmgeeung fir de VPN-Host. En Neen heescht, datt den inspizéierte Pad SSTP net ka droen, an déi ënnerstëtzt Léisung ass en anere Pad oder Protokoll, net eng Upassung um Client.

D’Optioune beinhale meeschtens en net-inspizéierten Ausgang fir de VPN-Gateway, en Design mat gedeeltem Tunnel, deen nëmme Firmenverkeier duerch de Proxy schéckt, oder en alternatiivt Protokoll, dat d’Organisatioun op engem anere Port ënnerstëtzt. Jiddwereen gehéiert zum Netzwierkdesign, a jiddwereen sollt mam selwechten Apparat a Profil getest ginn, sou datt de Verglach de Pad isoléiert.

Dokumentéiert d’Resultat: Aussteller, feelend Etapp, Proxy-Regel an de gewielte Pad. Déi nächst Persoun, déi dee selwechte Stau bei 98 Prozent gesäit, kann dann eng Tatsaach iwwerpréiwen, amplaz de ganzen Duerchgang ze widderhuelen.