SSTP bak en TLS-undersøkende proxy: hvor økten bryter sammen

Nettleseren din laster det interne nettverket, proxy-sertifikatet er betrodd, og likevel faller SSTP-klienten ut nær slutten av tilkoblingen. Mønsteret peker på forskjellen mellom en webforespørsel og en tunnelert økt, ikke på et feil passord. Gå gjennom tilkoblingen fra TCP og oppover, og noter det første trinnet som feiler. Trinnet, ikke feilkoden, forteller deg om proxyen er årsaken.

Start der klienten stopper

Klienten går gjennom en fast rekkefølge: TCP-tilkobling til port 443, TLS-håndtrykk, sertifikatvalidering, SSTPs HTTP-utveksling, PPP-forhandling og -autentisering, deretter IP-konfigurasjon. En feil i hvert trinn etterlater et annet avtrykk, og å blande dem sender deg til feil konfigurasjonsside.

En TCP-feil er en tidsavbrudd eller en tilbakestilling før en eneste TLS-byte vises. En TLS-feil er et varsel eller en håndtrykk-tidsavbrudd. En sertifikatfeil gir en advarsel om kjeden eller navnet. En HTTP-feil kommer etter et vellykket håndtrykk, ofte som en statuskode eller en umiddelbar lukking. En PPP-feil kommer etter at tunnelen er teknisk opprettet, derfor ser den ut som et autentiseringsproblem.

Les klientloggen for det siste vellykkede trinnet i stedet for den første feillinjen. Feillinjen rapporterer vanligvis konsekvensen, mens trinngrensen navngir komponenten som avviste.

Hva SSTP krever at nettverket bærer

SSTP kjører over TLS på TCP 443 og sender deretter en HTTP-forespørsel kalt SSTP_DUPLEX_POST, definert i SSTP-spesifikasjonen, til en sti av formen /sra_{GUID}/. Forespørselen erklærer en praktisk talt ubegrenset innholdslengde og holder strømmen åpen i begge retninger gjennom hele økten. PPP-rammene beveger seg inne i den strømmen.

Derfor kan en proxy som håndterer vanlig surfing fortsatt feile. En GET eller POST med et endelig innhold kan bufres, inspiseres og videresendes; en duplexstrøm med et innhold som aldri tar slutt kan ikke. En proxy som venter på at innholdet skal bli ferdig, venter for alltid, og klienten får til slutt tidsavbrudd.

Metodefiltrering og autentisering legger til egne feilmoduser. Hvis proxyen utfordrer forespørselen om påloggingsinformasjon, svarer kanskje ikke VPN-klienten selv om nettleseren ville gjort det. Hvis den fjerner eller skriver om metoden, avviser gatewayen forespørselen før PPP begynner.

Hvorfor inspeksjon endrer identiteten

En TLS-undersøkende proxy avslutter klientens TLS-tilkobling og åpner en separat tilkobling til gatewayen. Klienten validerer derfor proxyens sertifikat, ikke gatewayens, og gatewayen ser proxyen som sin motpart. Når organisasjonen distribuerer sin egen rot, kan både nettleseren og VPN-klienten godta den kjeden, slik at håndtrykket lykkes og problemet flytter seg til neste trinn.

Vellykket validering betyr ikke at proxyen kan bære økten. Den må fortsatt videresende en ubegrenset toveis-POST uten bufring og holde begge tilkoblingene i live i timer. Mange inspeksjonsprodukter er bygget for forespørsel-svar-trafikk og håndterer dette tilfellet dårlig eller ikke i det hele tatt.

Derfor er det å legge til en ukjent rot eller slå av validering den feil reparasjonen. Det endrer hvilket sertifikat klienten godtar; det gjør ingenting med strømhåndteringen som faktisk brøt økten.

Identifiser utstederen før du endrer innstillinger

Spør endepunktet hvilket sertifikat det presenterer og hvem som signerte det. Kommandoene nedenfor viser kjeden og utstederen uten å starte en VPN-økt:

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

Hvis utstederen er en offentlig CA, blir tilkoblingen sannsynligvis ikke avlyttet for denne verten, og feilen er et annet sted. Hvis utstederen er organisasjonens egen CA, er inspeksjonen aktiv og gatewayen nås gjennom en proxy. Sammenlign fingeravtrykket med det nettverksteamet forventer før du konkluderer bare ut fra navnet.

En nettlesertest mot samme vert beviser bare at proxyen godtar en GET. Den sier ingenting om SSTP-metoden, forespørselens URI eller innholdets levetid, så ikke bruk en fungerende intranettside som bevis for at tunnelstien støttes.

Velg den støttede stien

Still nettverkseieren ett konkret spørsmål: tillater proxyen en ubufret duplex-POST til denne gatewayen på port 443? Et ja fører til et unntak i proxyen eller en dokumentert omgåelse for VPN-verten. Et nei betyr at den inspiserte stien ikke kan bære SSTP, og den støttede løsningen er en annen sti eller protokoll, ikke en justering av klienten.

Alternativene inkluderer vanligvis en uinspisert utgang for VPN-gatewayen, et design med delt tunnel som bare sender bedriftstrafikk gjennom proxyen, eller en alternativ protokoll som organisasjonen støtter på en annen port. Hver hører til nettverksdesignet, og hver bør testes med samme enhet og profil slik at sammenligningen isolerer stien.

Dokumenter resultatet: utsteder, feilende trinn, proxyregel og valgt sti. Neste person som ser den samme 98 prosents stillstanden, kan da sjekke ett faktum i stedet for å gjenta hele gjennomgangen.