Кеш зад 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 кеширане също ограничават съхраняването на отговори на удостоверени заявки и точно там персонализираната страница се превръща в изтичане на данни. Дръжте проксито ограничено до одобрени клиенти, вместо да излагате отворен релей.

Измерете попадението, не хронометъра

По-бърза втора заявка не доказва, че новият кеш е свършил нещо, защото браузърите и операционните системи кешират агресивно сами. Поискайте от проксито броячи за попадения и пропуски и наблюдавайте трафика на източника при контролирано повторение. Използвайте едно повторно изтегляне на известен обект, първо с включен кеш, после заобиколен, и сравнете байтовете, отдадени от източника, а не изминалото време. След това проверете границата на оторизация: ресурс, който изисква вход, не трябва да се сервира на друг клиент.

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