Кеш за 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 також обмежують збереження відповідей на автентифіковані запити, і саме там персоналізована сторінка стає витоком даних. Тримайте проксі обмеженим схваленими клієнтами, а не відкритим ретранслятором.

Вимірюйте влучання, а не секундомір

Швидший другий запит не доводить, що новий кеш щось зробив, бо браузери й операційні системи агресивно кешують самі. Попросіть у проксі лічильники влучань і промахів і спостерігайте за трафіком джерела під час контрольованого повтору. Використайте одне повторне завантаження відомого об'єкта — спершу з увімкненим кешем, потім в обхід — і порівняйте байти, віддані джерелом, а не минулий час. Потім перевірте межу авторизації: ресурс, що вимагає входу, не має віддаватися іншому клієнту.

Запишіть навантаження, ключ кешу й політику, що дозволила повторне використання. Кеш — це рішення про обмін даними в костюмі оптимізації.