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 ক্যাশিং নিয়ম প্রমাণিত অনুরোধের প্রতিক্রিয়া সংরক্ষণেও সীমা আরোপ করে, আর ঠিক সেখানেই ব্যক্তিগতকৃত পৃষ্ঠা ডেটা প্রকাশে পরিণত হয়। প্রক্সিকে খোলা রিলে হিসেবে প্রকাশ না করে অনুমোদিত ক্লায়েন্টেই সীমাবদ্ধ রাখুন।

হিট মাপুন, স্টপওয়াচ নয়

দ্রুততর দ্বিতীয় অনুরোধ প্রমাণ করে না নতুন ক্যাশ কিছু করেছে, কারণ ব্রাউজার ও অপারেটিং সিস্টেম নিজেরাই জোরালোভাবে ক্যাশ করে। প্রক্সির কাছে হিট ও মিস কাউন্টার চান এবং নিয়ন্ত্রিত পুনরাবৃত্তির সময় মূল সার্ভারের ট্রাফিক লক্ষ্য করুন। পরিচিত একটি বস্তুর একবার পুনরাবৃত্ত ডাউনলোড ব্যবহার করুন, ক্যাশ চালু করে তারপর বাইপাস করে, এবং অতিবাহিত সময় নয় বরং মূল সার্ভারের পরিবেশিত বাইট তুলনা করুন। তারপর অনুমোদন সীমানা যাচাই করুন: লগইন প্রয়োজন এমন সম্পদ অন্য ক্লায়েন্টকে দেওয়া যাবে না।

কাজের ভার, ক্যাশ কী এবং পুনরায় ব্যবহারের অনুমতি দেওয়া নীতি লিখে রাখুন। ক্যাশ হলো অপ্টিমাইজেশনের পোশাক পরা একটি ডেটা-শেয়ারিং সিদ্ধান্ত।