SSTP pas një proxy që inspekton TLS: ku thyhet sesioni

Shfletuesi juaj ngarkon intranetin e korporatës, certifikata e proxy-t është e besuar, dhe megjithatë klienti SSTP bie afër fundit të lidhjes. Ky model tregon ndryshimin midis një kërkese web dhe një sesioni të tunelizuar, jo një fjalëkalim të gabuar. Kaloni lidhjen nga TCP lart dhe shënoni fazën e parë që dështon. Faza, jo kodi i gabimit, ju thotë nëse proxy-t është shkaku.

Filloni aty ku ndalon klienti

Klienti kalon në një sekuencë fikse: lidhje TCP në portën 443, shtrëngim duarsh TLS, validimi i certifikatës, shkëmbimi HTTP i SSTP, negociimi dhe vërtetimi PPP, pastaj konfigurimi IP. Një dështim në secilën fazë lë një gjurmë tjetër, dhe përzierja e tyre ju çon në faqen e gabuar të konfigurimit.

Një dështim TCP është një skadim kohe ose një rivendosje përpara se të shfaqet edhe një bajt TLS. Një dështim TLS është një alarm ose një skadim kohe i shtrëngimit të duarve. Një dështim certifikate prodhon një paralajmërim për zinxhirin ose emrin. Një dështim HTTP vjen pas një shtrëngimi të suksesshëm, shpesh si kod statusi ose mbyllje e menjëhershme. Një dështim PPP vjen pasi tuneli është krijuar teknikisht, prandaj duket si problem vërtetimi.

Lexoni regjistrin e klientit për fazën e fundit të suksesshme, jo rreshtin e parë të gabimit. Rreshti i gabimit zakonisht raporton pasojën, ndërsa kufiri i fazës emërton komponentin që refuzoi.

Çfarë kërkon SSTP nga rrjeti të mbajë

SSTP funksionon mbi TLS në TCP 443 dhe pastaj dërgon një kërkesë HTTP të quajtur SSTP_DUPLEX_POST, e përcaktuar në specifikimin e SSTP, drejt një rruge të formës /sra_{GUID}/. Kërkesa deklaron një gjatësi përmbajtjeje praktikisht të pakufizuar dhe e mban rrjedhën të hapur në të dy drejtimet gjatë gjithë jetës së sesionit. Kornizat PPP udhëtojnë brenda asaj rrjedhe.

Prandaj një proxy që trajton shfletimin e zakonshëm mund të dështojë gjithsesi. Një GET ose POST me trup të fundëm mund të buferizohet, inspektohet dhe përcillet; një rrjedhë duplex me trup që nuk mbaron kurrë nuk mundet. Një proxy që pret përfundimin e trupit pret përgjithmonë, dhe klienti përfundimisht skadon.

Filtrimi i metodave dhe vërtetimi shtojnë mënyrat e tyre të dështimit. Nëse proxy-t kërkon kredenciale për kërkesën, klienti VPN mund të mos përgjigjet edhe pse shfletuesi do të përgjigjej. Nëse e heq ose e rishkruan metodën, porta refuzon kërkesën para se të fillojë PPP.

Pse inspektimi ndryshon identitetin

Një proxy që inspekton TLS përfundon lidhjen TLS të klientit dhe hap një lidhje të veçantë drejt portës. Prandaj klienti validon certifikatën e proxy-t, jo atë të portës, dhe porta e shikon proxy-t si palën e vet. Kur organizata shpërndan rrënjën e vet, si shfletuesi ashtu edhe klienti VPN mund ta pranojnë atë zinxhir, kështu që shtrëngimi i duarve ka sukses dhe problemi kalon në fazën tjetër.

Validimi i suksesshëm nuk do të thotë që proxy-t mund ta mbajë sesionin. Ai ende duhet të përcjellë një POST dykahësh të pakufizuar pa buferizim dhe t'i mbajë të dyja lidhjet gjallë për orë të tëra. Shumë produkte inspektimi janë ndërtuar për trafik kërkese-përgjigje dhe e trajtojnë këtë rast keq ose aspak.

Prandaj shtimi i një rrënje të panjohur ose çaktivizimi i verifikimit është riparimi i gabuar. Ndryshon se cilën certifikatë pranon klienti; nuk bën asgjë për trajtimin e rrjedhës që në fakt e theu sesionin.

Identifikoni lëshuesin para se të ndryshoni cilësimet

Pyetni pikën fundore se cilën certifikatë paraqet dhe kush e nënshkroi. Komandat më poshtë tregojnë zinxhirin dhe lëshuesin pa nisur një sesion VPN:

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

Nëse lëshuesi është një CA publike, lidhja me gjasë nuk po përgjohet për këtë host dhe dështimi është diku tjetër. Nëse lëshuesi është CA e vetë organizatës, inspektimi është aktiv dhe porta arrihet përmes një proxy. Krahasoni gjurmën e gishtit me atë që ekipi i rrjetit pret përpara se të nxirrni përfundim vetëm nga emri.

Një test shfletuesi drejt të njëjtit host vërteton vetëm që proxy-t pranon një GET. Nuk thotë asgjë për metodën SSTP, URI-në e kërkesës ose jetëgjatësinë e trupit, prandaj mos e merrni një faqe intraneti që funksionon si provë se rruga e tunelit mbështetet.

Zgjidhni rrugën e mbështetur

Bëjini pronarit të rrjetit një pyetje konkrete: a lejon proxy-t një POST dykahësh pa buferizim drejt kësaj porte në portën 443? Po çon në një përjashtim në proxy ose në një anashkalim të dokumentuar për hostin VPN. Jo do të thotë se rruga e inspektuar nuk mund të mbajë SSTP, dhe rregullimi i mbështetur është një rrugë ose protokoll tjetër, jo një rregullim i klientit.

Opsionet zakonisht përfshijnë një dalje të painspektuar për portën VPN, një projekt tuneli të ndarë që dërgon vetëm trafikun e korporatës përmes proxy-t, ose një protokoll alternativ që organizata e mbështet në një portë tjetër. Secili i përket projektimit të rrjetit, dhe secili duhet të testohet me të njëjtin pajisje dhe profil që krahasimi ta izolojë rrugën.

Dokumentoni rezultatin: lëshuesi, faza që dështoi, rregulli i proxy-t dhe rruga e zgjedhur. Personi tjetër që sheh të njëjtën ngecje në 98 për qind do të mund të kontrollojë një fakt të vetëm në vend që të përsëritë gjithë ecjen.