SSTP agter ’n TLS-ondersoekende proxy: waar die sessie breek

Jou blaaier laai die korporatiewe intranet, die proxy-sertifikaat word vertrou, en die SSTP-kliënt val steeds naby die einde van die verbinding weg. Daardie patroon wys op die verskil tussen ’n webversoek en ’n getonnelde sessie, nie op ’n verkeerde wagwoord nie. Stap die verbinding van TCP opwaarts deur en let op die eerste fase wat misluk. Die fase, nie die foutkode nie, sê vir jou of die proxy die oorsaak is.

Begin waar die kliënt stop

Die kliënt deurloop ’n vaste reeks: TCP-verbinding na poort 443, TLS-handshake, sertifikaatvalidering, die SSTP HTTP-uitruiling, PPP-onderhandeling en -verifikasie, dan IP-konfigurasie. ’n Fout by elke fase laat ’n ander kenmerk, en om hulle te verwar stuur jou na die verkeerde konfigurasiebladsy.

’n TCP-fout is ’n tydsverloop of ’n herstel voordat enige TLS-greep verskyn. ’n TLS-fout is ’n waarskuwing of ’n handshake-tydsverloop. ’n Sertifikaatfout lewer ’n waarskuwing oor die ketting of die naam. ’n HTTP-fout kom ná ’n suksesvolle handshake, dikwels as ’n statuskode of ’n onmiddellike sluiting. ’n PPP-fout kom nadat die tonnel tegnies gevestig is, wat is waarom dit soos ’n verifikasieprobleem lyk.

Lees die kliëntlog vir die laaste suksesvolle fase eerder as die eerste foutreël. Die foutreël is gewoonlik die kliënt wat die gevolg rapporteer, terwyl die fasegrens die komponent noem wat geweier het.

Wat SSTP van die netwerk vra om te dra

SSTP loop oor TLS op TCP 443 en stuur dan ’n HTTP-versoek genaamd SSTP_DUPLEX_POST, soos gedefinieer in die SSTP-spesifikasie, na ’n pad van die vorm /sra_{GUID}/. Die versoek verklaar ’n effektief onbeperkte inhoudlengte en hou die stroom in beide rigtings oop vir die duur van die sessie. Die PPP-rame reis binne daardie stroom.

Dit is waarom ’n proxy wat gewone blaaiery hanteer, steeds kan misluk. ’n GET of ’n POST met ’n eindige inhoud kan gebuffer, ondersoek en aangestuur word; ’n dupleksstroom met ’n inhoud wat nooit eindig nie, kan nie. ’n Proxy wat wag vir die inhoud om te voltooi, wag vir ewig, en die kliënt val uiteindelik uit.

Metodefiltering en verifikasie voeg hul eie foutmodusse by. As die proxy die versoek om geloofsbriewe uitdaag, antwoord die VPN-kliënt dalk nie, selfs al sou die blaaier dit doen. As dit die metode stroop of herskryf, verwerp die gateway die versoek voordat PPP begin.

Waarom ondersoek die identiteit verander

’n TLS-ondersoekende proxy beëindig die kliënt se TLS-verbinding en open ’n aparte een na die gateway. Die kliënt valideer dus die proxy se sertifikaat, nie die gateway s’n nie, en die gateway sien die proxy as sy eweknie. Wanneer die organisasie sy eie wortel versprei, kan die blaaier en die VPN-kliënt albei daardie ketting aanvaar, so die handshake slaag en die probleem skuif na die volgende fase.

Suksesvolle validering beteken nie die proxy kan die sessie dra nie. Dit moet steeds ’n onbeperkte tweerigting-POST sonder buffering deurstuur, en dit moet albei verbindings vir ure aan die lewe hou. Baie ondersoekprodukte is vir versoek-responsverkeer gebou en hanteer hierdie geval swak of glad nie.

Dit is ook waarom om ’n onbekende wortel by te voeg of verifikasie af te skakel die verkeerde herstel is. Dit verander watter sertifikaat die kliënt aanvaar; dit doen niks aan die stroomhantering wat die sessie eintlik gebreek het nie.

Identifiseer die uitreiker voordat jy instellings verander

Vra die eindpunt watter sertifikaat dit aanbied en wie dit onderteken het. Die opdragte hieronder wys die ketting en die uitreiker sonder om ’n VPN-sessie te begin:

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

As die uitreiker ’n openbare CA is, word die verbinding vir hierdie gasheer waarskynlik nie onderskep nie en is die fout elders. As die uitreiker die organisasie se eie CA is, is ondersoek aktief en word die gateway deur ’n proxy bereik. Vergelyk die vingerafdruk met die een wat die netwerkspan verwag voordat jy net op grond van die naam ’n gevolgtrekking maak.

’n Blaaierteets na dieselfde gasheer bewys net dat die proxy ’n GET aanvaar. Dit sê niks oor die SSTP-metode, die versoek-URI of die leeftyd van die inhoud nie, so moenie ’n werkende intranetblad as bewys beskou dat die tonnelpad ondersteun word nie.

Kies die ondersteunde pad

Vra die netwerkeienaar een konkrete vraag: laat die proxy ’n ongebufferde dupleks-POST na hierdie gateway op poort 443 toe? ’n Ja lei na ’n proxy-uitsondering of ’n gedokumenteerde omleiding vir die VPN-gasheer. ’n Nee beteken die ondersoekte pad kan nie SSTP dra nie, en die ondersteunde oplossing is ’n ander pad of protokol eerder as ’n kliëntaanpassing.

Opsies sluit gewoonlik ’n nie-ondersoekte uitgang vir die VPN-gateway in, ’n split-tunnel-ontwerp wat net korporatiewe verkeer deur die proxy stuur, of ’n alternatiewe protokol wat die organisasie op ’n ander poort ondersteun. Elkeen hoort by die netwerkontwerp, en elkeen moet met dieselfde toestel en profiel getoets word sodat die vergelyking die pad isoleer.

Dokumenteer die uitkoms: uitreiker, mislukte fase, proxy-reël en gekose pad. Die volgende persoon wat dieselfde 98 persent-stilstand sien, kan dan een feit nagaan in plaas daarvan om die hele deurloop te herhaal.