SSTP efter in TLS-ûndersykjende proxy: wêr’t de sesje brekt

Jo browser lade it bedriuwsintranet, it proxy-sertifikaat is fertrouwen, en dochs falt de SSTP-klant tichtby it ein fan de ferbining fuort. Dat patroan wiist op it ferskil tusken in webferboat en in tunnelde sesje, net op in ferkeard wachtwurd. Rin de ferbining fan TCP ôf nei boppen troch en notearje de earste stap dy’t mislearret. De stap, net de flaterkoade, fertelt jo oft de proxy de oarsaak is.

Begjin wêr’t de klant stoppet

De klant giet troch in fêste folchoarder: TCP-ferbining nei poarte 443, TLS-hânskodding, sertifikaatfalidaasje, de HTTP-útwikseling fan SSTP, PPP-ûnderhanneling en -autentikaasje, en dan IP-konfiguraasje. In flater by elke stap lit in oar spoar nei, en se trochinoar helje bringt jo op de ferkearde konfiguraasjeside.

In TCP-flater is in time-out of in reset foardat der ek mar ien TLS-byte ferskynt. In TLS-flater is in warskôging of in hânskodding-time-out. In sertifikaatflater jout in warskôging oer de keatling of de namme. In HTTP-flater komt nei in slagge hânskodding, faak as statuskoade of as direkte sluting. In PPP-flater komt neidat de tunnel technysk oanlein is, dêrom liket it op in autentikaasjeprobleem.

Lês it kliïntloch foar de lêste slagge stap yn stee fan de earste flaterrigel. De flaterrigel is meastentiids de klant dy’t it gefolch rapportearret, wylst de stapgrins it ûnderdiel neamt dat wegere.

Wat SSTP it netwurk freegje te dragen

SSTP rint oer TLS op TCP 443 en stjoert dan in HTTP-ferboat mei de namme SSTP_DUPLEX_POST, definiearre yn de SSTP-spesifikaasje, nei in paad fan de foarm /sra_{GUID}/. It ferboat ferklearret in praktysk ûnbeheinde ynhâldlingte en hâldt de stream yn beide rjochtingen iepen foar de hiele sesje. De PPP-ramen reizgje yn dy stream.

Dêrom kin in proxy dy’t gewoan browsen ôfhannelet, dochs mislearje. In GET of POST mei in einige body kin buffere, ynspektearre en trochjûn wurde; in duplexstream mei in body dy’t nea einiget, kin dat net. In proxy dy’t wachtet oant de body klear is, wachtet foar altyd, en de klant rint úteinlik op in time-out.

Metoadefiltering en autentikaasje foegje har eigen flatermodi ta. As de proxy de ferboat om bewiisstikken freget, antwurdet de VPN-klant miskien net, ek al soe de browser dat dwaan. As er de metoade striekt of oerskriuwt, wegert de gateway it ferboat foardat PPP begjint.

Wêrom’t ynspeksje de identiteit feroaret

In TLS-ûndersykjende proxy beëiniget de TLS-ferbining fan de klant en iepenet in aparte ferbining nei de gateway. Dêrom falidearret de klant it sertifikaat fan de proxy, net dat fan de gateway, en de gateway sjocht de proxy as syn partner. As de organisaasje syn eigen woartel ferspriedt, kinne de browser en de VPN-klant beide dy keatling akseptearje, dus de hânskodding slagget en it probleem ferhuzet nei de folgjende stap.

In slagge falidaasje betsjut net dat de proxy de sesje drage kin. Hy moat noch in ûnbeheinde twarjochting-POST sûnder buffering trochjaan en beide ferbiningen oerenlang yn libben hâlde. In protte ynspeksjeprodukten binne boud foar ferboat-antwurdferkear en behannelje dit gefal min of hielendal net.

Dêrom is it tafoegjen fan in ûnbekende woartel of it útskeakeljen fan falidaasje de ferkearde reparaasje. It feroaret hokker sertifikaat de klant akseptearret; it docht neat oan ’e streambehanneling dy’t de sesje eins bruts.

Identifisearje de útjouwer foardat jo ynstellings feroarje

Freegje it einpunt hokker sertifikaat it presintearret en wa’t it ûndertekene hat. De opdrachten hjirûnder litte de keatling en de útjouwer sjen sûnder in VPN-sesje te starten:

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

As de útjouwer in iepenbiere CA is, wurdt de ferbining foar dizze host wierskynlik net ûnderskept en sit de flater earne oars. As de útjouwer de eigen CA fan ’e organisaasje is, is ynspeksje aktyf en wurdt de gateway fia in proxy berikt. Fergelykje de fingerprint mei dy’t it netwurkteam ferwachtet foardat jo allinnich op basis fan ’e namme in konklúzje lûke.

In browsertest nei deselde host bewiist allinnich dat de proxy in GET akseptearret. It seit neat oer de SSTP-metoade, de ferboat-URI of de libbensdoer fan ’e body, dus beskôgje in wurkjende intranetside net as bewiis dat it tunnelpaad stipe wurdt.

Kies it stipe paad

Freegje de netwurkeigner ien konkreet fraach: lit de proxy in net-bufferre duplex-POST nei dizze gateway op poarte 443 ta? In ja liedt ta in útsûndering yn ’e proxy of in dokumintearre omgong foar de VPN-host. In nee betsjut dat it ynspektearre paad SSTP net drage kin, en de stipe reparaasje is in oar paad of protokol, net in oanpassing fan ’e klant.

Opsjes omfetsje meastentiids in net-ynspektearre útgong foar de VPN-gateway, in ûntwerp fan in splitst tunnel dy’t allinnich bedriuwsferkear fia de proxy stjoert, of in alternatyf protokol dat de organisaasje op in oare poarte stipet. Elk heart by it netwurkûntwerp, en elk moat test wurde mei itselde apparaat en itselde profyl, sadat de fergeliking it paad isolearret.

Dokumintearje de útkomst: útjouwer, mislearre stap, proxy-regel en keazen paad. De folgjende persoan dy’t deselde 98-prosint stilstân sjocht, kin dan ien feit kontrolearje ynstee fan ’e hiele rin te werheljen.