VPN baten atzeko cachea: zer ezkutatzen duen oraindik HTTPSek

VPN zerbitzariaren ondoan cache bat tunelaren atzean dauden guztientzako banda zabalera doakoa dirudi. Ez da, puntu horretatik igarotzen diren byteak TLS saio batek babestuta jarraitzen duelako, eta saio horren muturrak nabigatzailea eta webgunea dira. VPN atebideak bere kanpoko zifratzea kentzen du, ez aplikazioarena. Erabaki zein objektu errepikatu berrerabili nahi duzun hardwarea gehitu aurretik.

TLS saioa nabigatzailearena da

Ohiko HTTPSn nabigatzaileak gakoak adosten ditu gunearekin, eta eskua eman ondorengo erregistro bakoitza mutur pare horretarako zifratzen da. VPN atebide batek sortu duen tunela deszifratzen du eta gero TLS erregistro opakuak birbidaltzen ditu. Helmugak, denbora eta bolumena ikus ditzake, ez eskaeraren lerroa edo erantzunaren gorputza. Hori da edozein cachek bizitu behar duen muga.

Hura hausten duen edozein diseinu TLS atzemateko diseinua da, eta bere ondorioak ditu ziurtagirien konfiantzan eta gailuen kudeaketan.

CONNECT tunela da, ez cachea

Aurrealdeko proxy esplizitu batek HTTP CONNECT eskaera jasotzen du normalean eta gero byteak bi noranzkoetan birbidaltzen ditu. Birbidaltzea da gakoa: proxyak ez du elkarrizketa zifratua aztertzen.

curl -sSI -x http://proxy.example:3128 https://example.com/

Erantzunaren goiburuak proxyak tunelari emandako tratamendutik datoz, ez orriaren cachean gordetako kopiatik. CONNECT arrakastatsuak bideak funtzionatzen duela esan nahi du, ez ezer berrerabiltzeko gorde denik. 443 portua cache batera zuzentzeak ez dio TLS hitz egiten irakatsiko, cacheak mezu irakurgarriak behar baititu. Bezeroaren konfigurazioak onartutako proxy esplizituaren ezarpena erabili behar du, azalpenik gabeko birbideratzea beharrean.

Kudeatzen duzuna gorde cachean, nabigatzen duzuna ez

Edukia zurea denenn, alderantzizko proxy batek TLS amaitu eta onartutako erantzunak nahita gorde ditzake. Edukia pakete biltegi batena denean, erabili proiektuak onartzen duen ispilua.

nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"

Lehenengo komandoak erakusten du cache eremu bat konfiguratuta dagoen eta non aplikatzen den, bigarrenak objektu bakar baterako jatorriaren cache zuzentarauak erakusten ditu. Partekatutako cache batek freskotasuna, cache kontrolak eta errepresentazioak bereizten dituzten eskaera atributuak errespetatu behar ditu; private eta no-store gauza desberdinak esan nahi dituzte eta ez litzateke bat ere kendu behar asmatze tasa igotzeko. HTTP cache arauek autentifikatutako eskaeren erantzunak gordetzea ere mugatzen dute, eta hantxe bihurtzen da orri pertsonalizatua datuen agerrarazpen. Mantendu proxya onartutako bezeroetara mugatuta, errele irekia erakutsi beharrean.

Neurtu asmatzea, ez kronometroa

Bigarren eskaera azkarragoak ez du frogatzen cache berriak zerbait egin duenik, nabigatzaileek eta sistema eragileek beren kabuz gogor cachean gordetzen baitute. Eskatu proxyari asmatze eta huts egite kontagailuak eta behatu jatorriaren trafikoa errepikapen kontrolatu batean. Erabili objektu ezagun baten deskarga errepikatu bat, cachea gaituta eta gero saihestuta, eta alderatu jatorriak zerbitzatutako byteak, igarotako denbora beharrean. Gero egiaztatu baimen muga: saioa hastea eskatzen duen baliabidea ez zaio beste bezero bati eman behar.

Idatz itzazu karga, cache gakoa eta berrerabilpena onartu zuen politika. Cachea optimizazio jantzia duen datuak partekatzeko erabakia da.