Кеш зад VPN: што сè уште крие HTTPS од вас

Кеш до VPN серверот звучи како бесплатен пропусен опсег за сите зад тунелот. Не е, бидејќи бајтите што минуваат низ таа точка остануваат заштитени со TLS сесија чии краеви се прелистувачот и веб-страницата. VPN портата го отстранува само сопственото надворешно шифрирање, не тоа на апликацијата. Одлучете кој објект што се повторува сакате да го користите повторно пред да додадете хардвер.

TLS сесијата му припаѓа на прелистувачот

Во обичен HTTPS прелистувачот договара клучеви со страницата, и секој запис по ракувањето е шифриран за тој пар краеви. VPN портата го дешифрира тунелот што го создала и потоа проследува непрозирни TLS записи. Гледа одредишта, време и волумен, не линијата на барањето или телото на одговорот. Тоа е границата со која мора да живее секој кеш.

Секој дизајн што ја крши е дизајн на пресретнување TLS, со сопствени последици за довербата во сертификатите и управувањето со уреди.

CONNECT е тунел, не кеш

Експлицитен напреден прокси обично прима HTTP CONNECT барање и потоа пренесува бајти во двете насоки. Пренесувањето е клучниот збор: проксито не го анализира шифрираниот разговор.

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

Заглавијата на одговорот доаѓаат од ракувањето на проксито со тунелот, не од кеширана копија на страницата. Успешен CONNECT значи дека патеката работи, не дека нешто е зачувано за повторна употреба. Насочување на портата 443 кон кеш исто така не го учи да зборува TLS, бидејќи кеширањето бара читливи пораки. Конфигурацијата на клиентот мора да ја користи поддржаната експлицитна поставка за прокси, а не необјаснето пренасочување.

Кеширајте го она што го управувате, не тоа што го прелистувате

Кога содржината е ваша, обратното прокси може да го заврши TLS и намерно да зачувува одобрени одговори. Кога им припаѓа на складиште за пакети, користете го огледалото што проектот го поддржува.

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

Првата команда покажува дали е конфигурирана кеш зона и каде се применува, а втората ги покажува сопствените кеш директиви на изворот за еден објект. Споделениот кеш мора да ја почитува свежината, кеш контролите и атрибутите на барањето што ги разликуваат претставите; private и no-store значат различни работи и ниту едно не треба да се отстрани за да се зголеми стапката на погодоци. HTTP кеш правилата исто така го ограничуваат зачувувањето одговори на автентицирани барања, и токму таму персонализирана страница станува изложување на податоци. Држете го проксито ограничено на одобрени клиенти наместо да изложувате отворен реле.

Мерете го погодокот, не стоперицата

Побрзо второ барање не докажува дека новиот кеш направил нешто, бидејќи прелистувачите и оперативните системи агресивно кешираат сами. Побарајте од проксито бројачи на погодоци и промашувања и набљудувајте го сообраќајот на изворот при контролирано повторување. Користете едно повторено преземање на познат објект, прво со вклучен кеш, потоа заобиколен, и споредете ги бајтите што ги послужил изворот, а не изминатото време. Потоа проверете ја границата на авторизација: ресурс што бара најава не смее да се послужи на друг клиент.

Запишете го оптоварувањето, клучот на кешот и политиката што дозволи повторна употреба. Кешот е одлука за споделување податоци во костим за оптимизација.