Cache di balik VPN: apa yang masih disembunyikan HTTPS
Proxy di pintu keluar VPN tetap tidak bisa membaca HTTPS ujung ke ujung. Pilih beban kerja yang bisa di-cache dan batas TLS yang disengaja sebelum menambah server lain.
Cache di samping server VPN terdengar seperti bandwidth gratis bagi semua orang di balik terowongan. Bukan, karena byte yang melewati titik itu tetap dilindungi sesi TLS yang ujungnya adalah peramban dan situs web. Gateway VPN melepas enkripsi luarnya sendiri, bukan enkripsi aplikasi. Putuskan objek berulang mana yang ingin Anda pakai ulang sebelum menambah perangkat keras.
Sesi TLS milik peramban
Dalam HTTPS biasa peramban menegosiasikan kunci dengan situs, dan setiap rekaman setelah jabat tangan dienkripsi untuk pasangan ujung itu. Gateway VPN mendekripsi terowongan yang dibuatnya lalu meneruskan rekaman TLS buram. Ia bisa melihat tujuan, waktu, dan volume, bukan baris permintaan atau isi respons. Itulah batas yang harus dijalani setiap cache.
Rancangan apa pun yang melanggarnya adalah rancangan intersepsi TLS, dengan konsekuensinya sendiri pada kepercayaan sertifikat dan pengelolaan perangkat.
CONNECT adalah terowongan, bukan cache
Proxy maju eksplisit biasanya menerima permintaan HTTP CONNECT lalu meneruskan byte ke kedua arah. Meneruskan adalah kata kuncinya: proxy tidak mengurai percakapan terenkripsi.
curl -sSI -x http://proxy.example:3128 https://example.com/Header respons berasal dari penanganan terowongan oleh proxy, bukan dari salinan halaman yang di-cache. CONNECT yang berhasil berarti jalurnya bekerja, bukan bahwa sesuatu tersimpan untuk dipakai ulang. Mengarahkan port 443 ke cache juga tidak mengajarnya berbicara TLS, karena cache memerlukan pesan yang bisa dibaca. Konfigurasi klien harus memakai setelan proxy eksplisit yang didukung, bukan pengalihan tanpa penjelasan.
Cache yang Anda operasikan, bukan yang Anda jelajahi
Saat konten milik Anda, proxy balik dapat mengakhiri TLS dan menyimpan respons yang disetujui secara sengaja. Saat konten milik repositori paket, gunakan cermin yang didukung proyek.
nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"Perintah pertama menunjukkan apakah zona cache dikonfigurasi dan di mana berlaku, sedangkan yang kedua menunjukkan direktif cache asal untuk satu objek. Cache bersama harus menghormati kesegaran, kontrol cache, dan atribut permintaan yang membedakan representasi; private dan no-store berarti hal berbeda dan keduanya tidak boleh dihapus demi menaikkan rasio hit. Aturan cache HTTP juga membatasi penyimpanan respons untuk permintaan terautentikasi, dan di situlah halaman yang dipersonalisasi menjadi kebocoran data. Batasi proxy ke klien yang disetujui alih-alih membuka relai terbuka.
Ukur hit, bukan stopwatch
Permintaan kedua yang lebih cepat tidak membuktikan cache baru melakukan sesuatu, karena peramban dan sistem operasi menyimpan cache secara agresif sendiri. Mintalah penghitung hit dan miss dari proxy dan pantau lalu lintas asal selama pengulangan terkendali. Gunakan satu unduhan berulang objek yang dikenal, dengan cache aktif lalu dilewati, dan bandingkan byte yang disajikan asal, bukan waktu yang berlalu. Lalu periksa batas otorisasi: sumber daya yang memerlukan login tidak boleh disajikan ke klien lain.
Catat beban kerja, kunci cache, dan kebijakan yang mengizinkan pemakaian ulang. Cache adalah keputusan berbagi data yang memakai kostum optimasi.