SSTP bag en TLS-undersøgende proxy: hvor sessionen bryder sammen

Din browser indlæser det interne netværk, proxycertifikatet er betroet, og alligevel falder SSTP-klienten nær slutningen af forbindelsen. Mønstret peger på forskellen mellem en webforespørgsel og en tunneleret session, ikke på en forkert adgangskode. Gå forbindelsen igennem fra TCP og opefter, og noter den første fase, der fejler. Fasens navn, ikke fejlkoden, fortæller, om proxyen er årsagen.

Begynd dér, hvor klienten stopper

Klienten gennemløber en fast rækkefølge: TCP-forbindelse til port 443, TLS-håndtryk, certifikatvalidering, SSTP’s HTTP-udveksling, PPP-forhandling og -godkendelse og derefter IP-konfiguration. En fejl i hver fase efterlader et forskelligt aftryk, og hvis de blandes sammen, ender du på den forkerte konfigurationsside.

En TCP-fejl er en timeout eller en nulstilling, før der vises en eneste TLS-byte. En TLS-fejl er en alarm eller en håndtryk-timeout. En certifikatfejl giver en advarsel om kæden eller navnet. En HTTP-fejl kommer efter et vellykket håndtryk, ofte som en statuskode eller en øjeblikkelig lukning. En PPP-fejl kommer, efter at tunnelen teknisk set er oprettet, og derfor ligner den et godkendelsesproblem.

Læs klientloggen efter den sidste vellykkede fase i stedet for den første fejlstreng. Fejlstrengen er som regel klienten, der rapporterer konsekvensen, mens fasegrænsen navngiver den komponent, der afviste.

Hvad SSTP kræver, at netværket bærer

SSTP kører over TLS på TCP 443 og sender derefter en HTTP-anmodning kaldet SSTP_DUPLEX_POST, defineret i SSTP-specifikationen, til en sti af formen /sra_{GUID}/. Anmodningen erklærer en reelt ubegrænset indholdslængde og holder strømmen åben i begge retninger i hele sessionens levetid. PPP-rammerne bevæger sig inde i den strøm.

Det er derfor, en proxy, der håndterer almindelig browsing, stadig kan fejle. En GET eller POST med et endeligt indhold kan buffres, inspiceres og videresendes; en duplexstrøm med et indhold, der aldrig slutter, kan ikke. En proxy, der venter på, at indholdet bliver færdigt, venter for evigt, og klienten får til sidst timeout.

Metodefiltrering og godkendelse tilføjer deres egne fejltilstande. Hvis proxyen udfordrer anmodningen med legitimationsoplysninger, svarer VPN-klienten måske ikke, selvom browseren ville gøre det. Hvis den fjerner eller omskriver metoden, afviser gatewayen anmodningen, før PPP begynder.

Hvorfor inspektion ændrer identiteten

En TLS-undersøgende proxy afslutter klientens TLS-forbindelse og åbner en separat forbindelse til gatewayen. Klienten validerer derfor proxyens certifikat, ikke gatewayens, og gatewayen ser proxyen som sin modpart. Når organisationen udruller sin egen rod, kan både browseren og VPN-klienten acceptere den kæde, så håndtrykket lykkes, og problemet flytter til næste fase.

Vellykket validering betyder ikke, at proxyen kan bære sessionen. Den skal stadig videresende en ubegrænset tovejs-POST uden buffring og holde begge forbindelser i live i timer. Mange inspektionsprodukter er bygget til anmodning-svar-trafik og håndterer dette tilfælde dårligt eller slet ikke.

Det er også derfor, at tilføjelse af en ukendt rod eller deaktivering af validering er den forkerte reparation. Det ændrer, hvilket certifikat klienten accepterer; det gør intet ved den strømhåndtering, der faktisk brød sessionen.

Identificér udstederen, før du ændrer indstillinger

Spørg endepunktet, hvilket certifikat det præsenterer, og hvem der har signeret det. Kommandoerne nedenfor viser kæden og udstederen uden at starte en VPN-session:

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

Hvis udstederen er en offentlig CA, bliver forbindelsen sandsynligvis ikke opsnappet for denne vært, og fejlen er et andet sted. Hvis udstederen er organisationens egen CA, er inspektionen aktiv, og gatewayen nås gennem en proxy. Sammenlign fingeraftrykket med det, netværksteamet forventer, før du konkluderer ud fra navnet alene.

En browsertest mod samme vært beviser kun, at proxyen accepterer en GET. Den siger intet om SSTP-metoden, anmodningens URI eller indholdets levetid, så en fungerende intranetside er ikke bevis for, at tunnelstien understøttes.

Vælg den understøttede sti

Stil netværksejeren et konkret spørgsmål: tillader proxyen en ubuffret duplex-POST til denne gateway på port 443? Et ja fører til en undtagelse i proxyen eller en dokumenteret omgåelse for VPN-værten. Et nej betyder, at den inspicerede sti ikke kan bære SSTP, og den understøttede løsning er en anden sti eller protokol, ikke en justering af klienten.

Mulighederne omfatter normalt en uinspiceret udgang for VPN-gatewayen, et design med delt tunnel, der kun sender virksomhedstrafik gennem proxyen, eller en alternativ protokol, som organisationen understøtter på en anden port. Hver hører til netværksdesignet, og hver bør testes med samme enhed og profil, så sammenligningen isolerer stien.

Dokumentér resultatet: udsteder, fejlende fase, proxyregel og valgt sti. Den næste person, der ser den samme 98 procents stilstand, kan så tjekke én kendsgerning i stedet for at gentage hele gennemgangen.