Cache pas një VPN: çfarë fsheh ende HTTPS
Një proxy në daljen e VPN nuk mund të lexojë ende HTTPS nga fillimi në fund. Zgjidhni një ngarkesë të ruajtshme dhe një kufi TLS të qëllimshëm përpara se të shtoni një server tjetër.
Një cache pranë serverit VPN tingëllon si gjerësi bande falas për të gjithë ata pas tunelit. Nuk është, sepse bajtët që kalojnë në atë pikë mbeten të mbrojtur nga një sesion TLS, skajet e të cilit janë shfletuesi dhe faqja. Porta VPN heq vetëm kriptimin e saj të jashtëm, jo atë të aplikacionit. Vendosni cilin objekt të përsëritur dëshironi të ripërdorni përpara se të shtoni harduer.
Sesioni TLS i përket shfletuesit
Në HTTPS të zakonshëm shfletuesi negocion çelësat me faqen, dhe çdo regjistrim pas shtrëngimit të duarve kriptohet për atë çift skajesh. Porta VPN dekripton tunelin që krijoi dhe më pas përcjell regjistrime TLS të patejdukshme. Sheh destinacionet, kohën dhe vëllimin, jo rreshtin e kërkesës ose trupin e përgjigjes. Ky është kufiri me të cilin duhet të jetojë çdo cache.
Çdo dizajn që e thyen është dizajn përgjimi TLS, me pasojat e veta në besimin e certifikatave dhe menaxhimin e pajisjeve.
CONNECT është tunel, jo cache
Një proxy përpara eksplicit zakonisht merr një kërkesë HTTP CONNECT dhe më pas përcjell bajtë në të dy drejtimet. Përcjellja është fjala kyçe: proxy nuk e analizon bisedën e kriptuar.
curl -sSI -x http://proxy.example:3128 https://example.com/Titujt e përgjigjes vijnë nga trajtimi i tunelit nga proxy, jo nga një kopje e ruajtur e faqes. Një CONNECT i suksesshëm do të thotë që rruga funksionon, jo se diçka u ruajt për ripërdorim. Drejtimi i portës 443 në një cache as nuk e mëson të flasë TLS, sepse cache kërkon mesazhe të lexueshme. Konfigurimi i klientit duhet të përdorë cilësimin e mbështetur të proxy eksplicit, jo një ridrejtim të pashpjeguar.
Ruaj në cache atë që operoni, jo atë që shfletoni
Kur përmbajtja është e juaja, një proxy i kundërt mund të përfundojë TLS dhe të ruajë qëllimisht përgjigje të miratuara. Kur i përket një depoje paketash, përdorni pasqyrën që mbështet projekti.
nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"Komanda e parë tregon nëse është konfiguruar një zonë cache dhe ku zbatohet, ndërsa e dyta tregon direktivat e vetë burimit për një objekt. Një cache e përbashkët duhet të respektojë freskinë, kontrollet e cache dhe atributet e kërkesës që dallojnë paraqitjet; private dhe no-store nënkuptojnë gjëra të ndryshme dhe asnjëra nuk duhet hequr për të rritur normën e gjuajtjeve. Rregullat e cache HTTP kufizojnë gjithashtu ruajtjen e përgjigjeve për kërkesa të vërtetuara, dhe pikërisht aty një faqe e personalizuar bëhet ekspozim i të dhënave. Mbajeni proxy të kufizuar te klientë të miratuar në vend që të ekspozoni një rele të hapur.
Mat gjuajtjen, jo kronometrin
Një kërkesë e dytë më e shpejtë nuk provon që cache i ri bëri diçka, sepse shfletuesit dhe sistemet operative ruajnë vetë në cache në mënyrë agresive. Kërko nga proxy numëruesit e gjuajtjeve dhe të humbjeve dhe vëzhgo trafikun e burimit gjatë një përsëritjeje të kontrolluar. Përdor një shkarkim të përsëritur të një objekti të njohur, fillimisht me cache të aktivizuar dhe më pas të anashkaluar, dhe krahaso bajtët e shërbyer nga burimi, jo kohën e kaluar. Pastaj kontrollo kufirin e autorizimit: një burim që kërkon hyrje nuk duhet t'i shërbehet një klienti tjetër.
Shëno ngarkesën, çelësin e cache dhe politikën që lejoi ripërdorimin. Një cache është një vendim për ndarjen e të dhënave me kostum optimizimi.