TLS ikuskatzen duen proxy baten atzean SSTP: non hausten den saioa

Zure arakatzaileak korporazioaren intraneta kargatzen du, proxyaren ziurtagiria fidagarria da, eta hala ere SSTP bezeroa konexioaren amaieratik gertu erortzen da. Eredu horrek web-eskaera baten eta tunel-saio baten arteko aldea adierazten du, ez pasahitz okerra. Ibili konexioa TCPtik gora eta idatzi huts egiten duen lehen fasea. Faseak, ez errore-kodeak, esaten dizu proxyak errua duen.

Hasi bezeroa gelditzen den lekuan

Bezeroak sekuentzia finko bat igarotzen du: TCP konexioa 443 portura, TLS eskua, ziurtagiriaren balidazioa, SSTPren HTTP trukea, PPP negoziazioa eta autentifikazioa, eta gero IP konfigurazioa. Fase bakoitzean hutsegiteak aztarna desberdina uzten du, eta horiek nahasteak konfigurazio-orri okerrean jarriko zaitu.

TCP hutsegitea denbora-muga edo berrezarpena da, TLS byte bat agertu aurretik. TLS hutsegitea abisu edo esku-denboramuga da. Ziurtagiri hutsegiteak kateari edo izenari buruzko abisua sortzen du. HTTP hutsegitea eskua arrakastatsuaren ondoren iristen da, sarritan egoera-kode gisa edo berehalako itxiera gisa. PPP hutsegitea tunela teknikoki ezarri ondoren iristen da, eta horregatik autentifikazio-arazo bat dirudi.

Irakurri bezeroaren erregistroa azken fase arrakastatsuaren bila, lehen errore-lerroaren ordez. Errore-lerroak normalean ondorioa jakinarazten du, eta fasearen mugak uko egin zuen osagaia izendatzen du.

Zer eskatzen dio SSTPk sareari garraia dezan

SSTP TLS gainean ibiltzen da TCP 443n, eta gero SSTP_DUPLEX_POST izeneko HTTP eskaera bat bidaltzen du, SSTP zehaztapenetan definituta, /sra_{GUID}/ formako bide batera. Eskaerak funtsean mugagabea den eduki-luzera adierazten du eta korrontea bi norabideetan irekita mantentzen du saioaren bizitza osoan. PPP markoak korronte horren barruan bidaiatzen dute.

Horregatik, nabigazio arrunta kudeatzen duen proxy batek oraindik huts egin dezake. Gorputz finitua duen GET edo POST bat bufferatu, ikuskatu eta birbidali daiteke; inoiz amaitzen ez den gorputza duen korronte duplexa, ordea, ez. Gorputza amaitzeko itxaroten duen proxyak betiko itxaroten du, eta bezeroak azkenean denbora-muga gainditzen du.

Metodoen iragazketak eta autentifikazioak beren hutsegite-moduak gehitzen dituzte. Proxyak eskaerari kredentzialak eskatzen badizkio, VPN bezeroak agian ez dio erantzungo, arakatzaileak egingo lukeen arren. Metodoa kentzen edo berridazten badu, atebideak eskaera ukatzen du PPP hasi aurretik.

Zergatik aldatzen du ikuskatzeak identitatea

TLS ikuskatzen duen proxyak bezeroaren TLS konexioa amaitzen du eta atebidearekiko konexio bereizi bat irekitzen du. Beraz, bezeroak proxyaren ziurtagiria balidatzen du, ez atebidearena, eta atebideak proxyari bere parekotzat jotzen du. Erakundeak bere erroa banatzen duenean, arakatzaileak eta VPN bezeroak kate hori onar dezakete, beraz eskua arrakastatsu gertatzen da eta arazoa hurrengo fasera mugitzen da.

Balidazio arrakastatsuak ez du esan nahi proxyak saioa garraia dezakeenik. Oraindik bufferrik gabe POST bidirekzional mugagabea birbidali behar du eta bi konexioak orduz bizirik mantendu. Ikuskatze-produktu asko eskaera-erantzun trafikorako eraikiak daude eta kasu hau gaizki edo batere ez dute kudeatzen.

Horregatik, erro ezezagun bat gehitzea edo egiaztapena desgaitzea konponketa okerra da. Bezeroak zein ziurtagiri onartzen duen aldatzen du; saioa benetan hautsi zuen korronte-kudeaketari ez dio ezer egiten.

Identifikatu jaulkitzailea ezarpenak aldatu aurretik

Galdetu amaiera-puntuari zein ziurtagiri aurkezten duen eta nork sinatu zuen. Beheko komandoek katea eta jaulkitzailea erakusten dituzte VPN saioa hasi gabe:

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

Jaulkitzailea CA publikoa bada, konexioa ziurrenik ez da host honetarako atzematen eta hutsegitea beste nonbait dago. Jaulkitzailea erakundearen beraren CA bada, ikuskatzea aktibo dago eta atebidea proxy baten bidez iristen da. Alderatu hatz-marka sare-taldeak espero duenarekin, izenaren arabera soilik ondorioztatu aurretik.

Host beraren aurkako arakatzaile-proba batek soilik frogatzen du proxyak GET bat onartzen duela. Ez du ezer esaten SSTP metodoaz, eskaeraren URIaz edo gorputzaren bizitzaz, beraz ez hartu funtzionatzen duen intranet-orri bat tunel-bidea onartuta dagoenaren froga gisa.

Aukeratu onartutako bidea

Galdetu sarearen jabeari galdera zehatz bat: proxyak bufferrik gabeko POST duplexa baimentzen al du atebide honetara 443 portuan? Bai batek proxyaren salbuespen bat edo VPN hostarentzako dokumentatutako saihesbide bat dakar. Ez batek esan nahi du ikuskatutako bideak ezin duela SSTP garraiatu, eta onartutako konponbidea beste bide edo protokolo bat da, ez bezeroaren doikuntza bat.

Aukeren artean normalean VPN atebiderako irteera ez-ikuskatua, proxyaren bidez korporazio-trafikoa soilik bidaltzen duen tunel zatituaren diseinua, edo erakundeak beste portu batean onartzen duen protokolo alternatiboa daude. Bakoitza sare-diseinuaren parte da, eta bakoitza gailu eta profil berarekin probatu beharko litzateke, konparazioak bidea isolatu dezan.

Dokumentatu emaitza: jaulkitzailea, huts egindako fasea, proxyaren araua eta aukeratutako bidea. Hurrengo pertsonak 98 ehunekoan geldialdi bera ikusten duenean, gertaera bakarra egiazta dezake ibilbide osoa errepikatu beharrean.