SSTP bak ein TLS-undersøkjande proxy: kvar økta bryt saman

Nettlesaren din lastar det interne nettet, proxy-sertifikatet er klarert, og likevel fell SSTP-klienten ut nær slutten av tilkoplinga. Mønsteret peikar på skilnaden mellom ein webførespurnad og ei tunnelert økt, ikkje på eit feil passord. Gå gjennom tilkoplinga frå TCP og oppover, og noter det første trinnet som sviktar. Trinnet, ikkje feilkoden, fortel deg om proxyen er årsaka.

Start der klienten stoppar

Klienten går gjennom ei fast rekkjefølgje: TCP-tilkopling til port 443, TLS-handtrykk, sertifikatvalidering, HTTP-utvekslinga til SSTP, PPP-forhandling og -autentisering, deretter IP-konfigurasjon. Ein feil i kvart trinn etterlèt eit anna avtrykk, og å blande dei sender deg til feil konfigurasjonsside.

Ein TCP-feil er ein tidsavbrot eller ein tilbakestilling før ein einaste TLS-byte viser seg. Ein TLS-feil er eit varsel eller eit handtrykk-tidsavbrot. Ein sertifikatfeil gjev ei åtvaring om kjeda eller namnet. Ein HTTP-feil kjem etter eit vellukka handtrykk, ofte som ein statuskode eller ei umiddelbar lukking. Ein PPP-feil kjem etter at tunnelen er teknisk oppretta, og difor ser han ut som eit autentiseringsproblem.

Les klientloggen for det siste vellukka trinnet i staden for den første feillinja. Feillinja rapporterer vanlegvis konsekvensen, medan trinngrensa nemner komponenten som avviste.

Kva SSTP krev at nettet ber

SSTP køyrer over TLS på TCP 443 og sender deretter ein HTTP-førespurnad kalla SSTP_DUPLEX_POST, definert i SSTP-spesifikasjonen, til ein sti av forma /sra_{GUID}/. Førespurnaden erklærer ei praktisk talt ubegrensa innhaldslengd og held straumen open i begge retningar gjennom heile økta. PPP-rammene flyttar seg inne i den straumen.

Difor kan ein proxy som handterer vanleg surfing framleis svikte. Ein GET eller POST med eit endeleg innhald kan bufreast, inspiserast og sendast vidare; ein duplexstraum med eit innhald som aldri tek slutt kan ikkje. Ein proxy som ventar på at innhaldet skal bli ferdig, ventar for alltid, og klienten får til slutt tidsavbrot.

Metodefiltrering og autentisering legg til eigne feilmodusar. Viss proxyen utfordrar førespurnaden om påloggingsinformasjon, svarar kanskje ikkje VPN-klienten sjølv om nettlesaren ville gjere det. Viss han fjernar eller skriv om metoden, avviser gatewayen førespurnaden før PPP byrjar.

Kvifor inspeksjon endrar identiteten

Ein TLS-undersøkjande proxy avsluttar TLS-tilkoplinga til klienten og opnar ei separat tilkopling til gatewayen. Klienten validerer difor sertifikatet til proxyen, ikkje gatewayen sitt, og gatewayen ser proxyen som motparten sin. Når organisasjonen distribuerer si eiga rot, kan både nettlesaren og VPN-klienten godta den kjeda, slik at handtrykket lukkast og problemet flyttar seg til neste trinn.

Vellukka validering tyder ikkje at proxyen kan bere økta. Han må framleis videresende ein ubegrensa toveg-POST utan bufring og halde begge tilkoplingane i live i timar. Mange inspeksjonsprodukt er bygde for førespurnad-svar-trafikk og handterer dette tilfellet dårleg eller ikkje i det heile.

Difor er det å leggje til ei ukjend rot eller slå av validering den feil reparasjonen. Det endrar kva sertifikat klienten godtek; det gjer ingenting med straumhandteringa som faktisk braut økta.

Identifiser utferdaren før du endrar innstillingar

Spør endepunktet kva sertifikat det presenterer og kven som signerte det. Kommandoane nedanfor viser kjeda og utferdaren utan å starte ei VPN-økt:

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

Viss utferdaren er ein offentleg CA, blir tilkoplinga truleg ikkje avlytta for denne verten, og feilen er ein annan stad. Viss utferdaren er organisasjonen si eiga CA, er inspeksjonen aktiv og gatewayen blir nådd gjennom ein proxy. Samanlikn fingeravtrykket med det nettverksteamet ventar før du konkluderer berre ut frå namnet.

Ein nettlesartest mot same vert beviser berre at proxyen godtek ein GET. Han seier ingenting om SSTP-metoden, URI-en til førespurnaden eller levetida til innhaldet, så ikkje bruk ei fungerande intranettside som bevis for at tunnelstien er støtta.

Vel den støtta stien

Still netteigaren eitt konkret spørsmål: tillèt proxyen ein ubufra duplex-POST til denne gatewayen på port 443? Eit ja fører til eit unntak i proxyen eller ei dokumentert omgåing for VPN-verten. Eit nei tyder at den inspiserte stien ikkje kan bere SSTP, og den støtta løysinga er ein annan sti eller protokoll, ikkje ein justering av klienten.

Alternativa omfattar vanlegvis ein uinspisert utgang for VPN-gatewayen, eit design med delt tunnel som berre sender bedriftstrafikk gjennom proxyen, eller ein alternativ protokoll som organisasjonen støttar på ein annan port. Kvart høyrer til nettverksdesignet, og kvart bør testast med same eining og profil slik at samanlikninga isolerer stien.

Dokumenter resultatet: utferdar, sviktande trinn, proxyregel og vald sti. Neste person som ser den same 98 prosents stillstanden, kan då sjekke eitt faktum i staden for å gjenta heile gjennomgangen.