SSTP malantaŭ TLS-inspektanta prokurilo: kie la seanco rompiĝas

Via retumilo ŝargas la komunan intranet, la atestilo de la prokurilo estas fidata, kaj tamen la kliento SSTP ankoraŭ falas proksime de la fino de la konekto. Tiu ŝablono montras la diferencon inter rete peto kaj tunela seanco, ne malĝustan pasvorton. Trairu la konekton de TCP supre kaj notu la unuan etapon, kiu malsukcesas. La etapo, ne la erarkodo, diras al vi, ĉu la prokurilo estas la kaŭzo.

Komencu tie, kie la kliento haltas

La kliento trapasas fiksan sinsekvon: TCP-konekto al pordo 443, TLS-manpremo, atestila validigo, la HTTP-interŝanĝo de SSTP, PPP-intertraktado kaj aŭtentikigo, poste IP-agordo. Malsukceso ĉe ĉiu etapo lasas malsaman spuron, kaj ilin konfuzi kondukas vin al la malĝusta agorda paĝo.

TCP-malsukceso estas tempolimo aŭ restarigo antaŭ ol aperas iu ajn TLS-bajto. TLS-malsukceso estas averto aŭ manprema tempolimo. Atestila malsukceso produktas averton pri la ĉeno aŭ la nomo. HTTP-malsukceso venas post sukcesa manpremo, ofte kiel stata kodo aŭ tuja fermo. PPP-malsukceso venas post kiam la tunelo estas teknike starigita, kio klarigas, kial ĝi aspektas kiel aŭtentikiga problemo.

Legu la klientan protokolon por la lasta sukcesa etapo anstataŭ la unua erarlinio. La erarlinio kutime raportas la sekvon, dum la etapa limo nomas la komponanton, kiu rifuzis.

Kion SSTP petas la reton porti

SSTP funkcias super TLS sur TCP 443 kaj poste sendas HTTP-peton nomatan SSTP_DUPLEX_POST, difinitan en la SSTP-specifikaĵo, al vojo de la formo /sra_{GUID}/. La peto deklaras praktike senliman enhavan longon kaj tenas la fluon malfermita en ambaŭ direktoj dum la tuta seanco. La PPP-kadroj vojaĝas interne de tiu fluo.

Tial prokurilo, kiu traktas ordinarajn retumadon, povas tamen malsukcesi. GET aŭ POST kun finhava korpo povas esti bufrita, inspektita kaj plusendita; dupleksa fluo kun korpo, kiu neniam finiĝas, ne povas. Prokurilo, kiu atendas la finiĝon de la korpo, atendas eterne, kaj la kliento fine tempolimas.

Metodofiltrado kaj aŭtentikigo aldonas proprajn malsukcesajn reĝimojn. Se la prokurilo defias la peton por akreditaĵoj, la VPN-kliento eble ne respondos, kvankam la retumilo respondus. Se ĝi forigas aŭ reverkas la metodon, la enirejo rifuzas la peton antaŭ ol PPP komenciĝas.

Kial inspektado ŝanĝas la identecon

TLS-inspektanta prokurilo finigas la TLS-konekton de la kliento kaj malfermas apartan konekton al la enirejo. Tial la kliento validigas la atestilon de la prokurilo, ne tiun de la enirejo, kaj la enirejo vidas la prokurilon kiel sian partneron. Kiam la organizo distribuas sian propran radikon, kaj la retumilo kaj la VPN-kliento povas akcepti tiun ĉenon, do la manpremo sukcesas kaj la problemo transiras al la sekva etapo.

Sukcesa validigo ne signifas, ke la prokurilo povas porti la seancon. Ĝi ankoraŭ devas plusendi senliman dudirektan POST sen bufrado kaj teni ambaŭ konektojn vivaj dum horoj. Multaj inspektaj produktoj estas konstruitaj por peto-responda trafiko kaj traktas ĉi tiun kazon malbone aŭ tute ne.

Tial aldoni nekonatan radikon aŭ malŝalti validigon estas la malĝusta riparo. Ĝi ŝanĝas, kiun atestilon la kliento akceptas; ĝi faras nenion pri la fluotraktado, kiu fakte rompis la seancon.

Identigu la eldonanton antaŭ ol ŝanĝi agordojn

Demandu la finpunkton, kiun atestilon ĝi prezentas kaj kiu subskribis ĝin. La subaj komandoj montras la ĉenon kaj la eldonanton sen komenci VPN-seancon:

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

Se la eldonanto estas publika CA, la konekto verŝajne ne estas interkaptita por ĉi tiu gastiganto kaj la malsukceso estas aliloke. Se la eldonanto estas la propra CA de la organizo, inspektado estas aktiva kaj la enirejo atingeblas per prokurilo. Komparu la fingrospuron kun tiu, kiun la reta teamo atendas, antaŭ ol konkludi nur laŭ la nomo.

Retumila testo al la sama gastiganto pruvas nur, ke la prokurilo akceptas GET. Ĝi diras nenion pri la SSTP-metodo, la peto-URI aŭ la vivo de la korpo, do ne konsideru funkciantan intranet-paĝon pruvo, ke la tunela vojo estas subtenata.

Elektu la subtenatan vojon

Demandu la posedanton de la reto unu konkretan demandon: ĉu la prokurilo permesas nebufritan dupleksan POST al ĉi tiu enirejo sur pordo 443? Jes kondukas al escepto en la prokurilo aŭ al dokumentita ĉirkaŭvojo por la VPN-gastiganto. Ne signifas, ke la inspektita vojo ne povas porti SSTP, kaj la subtenata riparo estas alia vojo aŭ protokolo, ne ŝanĝeto de la kliento.

La opcioj kutime inkluzivas neinspektitan eliron por la VPN-enirejo, splittunelan dezajnon, kiu sendas nur komunan trafikon tra la prokurilo, aŭ alternativan protokolon, kiun la organizo subtenas sur alia pordo. Ĉiu apartenas al la reta dezajno, kaj ĉiu devus esti testita kun la sama aparato kaj profilo, por ke la komparo izolu la vojon.

Dokumentu la rezulton: eldonanto, malsukcesa etapo, prokurila regulo kaj elektita vojo. La sekva persono, kiu vidos la saman 98-procentan halton, povos kontroli unu fakton anstataŭ ripeti la tutan trairadon.