VPN সাইডকারের জন্য কিল সুইচ: বেরোনোর সময় ট্রাফিক আটকান

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

নেমস্পেস ভাগ করা কেন কিল সুইচ নয়

নেমস্পেস ভাগ করার অর্থ অ্যাপটি VPN কন্টেইনারের ইন্টারফেস, ঠিকানা ও রুট টেবিল ব্যবহার করে। এটি ভাগ করা নেমস্পেস অক্ষত থাকা পর্যন্ত অ্যাপের নেটওয়ার্কে স্বাধীন পথ সরিয়ে দেয়, এবং টানেল সরে গেলে ওই নেমস্পেস কী করবে সে সম্পর্কে কিছুই বলে না।

Compose-এর নির্ভরতা শর্ত অ্যাপের শুরু নির্ভরতা সুস্থ হওয়া পর্যন্ত বিলম্বিত করতে পারে। এটি সময়ের একটি মুহূর্ত কভার করে এবং পরে কোনো ব্যর্থতা কভার করে না, তাই এটি শুরুর ক্রমের একটি সরঞ্জাম, অবিরাম এগ্রেস ফায়ারওয়াল নয়।

কন্টেইনার বেরোনোর সময়ে আসলে কী ঘটে

তিনটি ঘটনা আলাদা করুন। কন্টেইনারের ভেতরের VPN প্রক্রিয়া মারা যেতে পারে যখন কন্টেইনার চলতে থাকে। কন্টেইনার থামতে পারে বা সরিয়ে ফেলা যায়, যা নেমস্পেস ধ্বংস করে। কন্টেইনার আবার তৈরি হতে পারে, যা নতুন নেমস্পেস ও নতুন নিয়ম তৈরি করে।

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

একটি স্পষ্ট এগ্রেস নীতি তৈরি করুন

নীতিটি ভাগ করা নেমস্পেসের ভেতরে লিখুন যাতে তা অ্যাপের প্যাকেটে প্রযোজ্য হয়। আকার হলো সংকীর্ণ ব্যতিক্রমসহ ডিফল্ট বর্জন: loopback, টানেলের ইন্টারফেস, এবং টানেল পরিবহনের প্রয়োজনীয় নির্দিষ্ট এন্ডপয়েন্ট ঠিকানা ও পোর্ট।

এন্ডপয়েন্ট ব্যতিক্রম টানেল ওঠার আগেই থাকতে হবে, নইলে VPN ক্লায়েন্ট তার সার্ভারে পৌঁছাতে পারবে না। এজন্যই নিয়মসমষ্টি ভৌত ইন্টারফেসকে সাধারণভাবে অনুমতি দেওয়ার বদলে বাহ্যিক পরিবহনকে স্পষ্টভাবে অনুমতি দেয়। নেমস্পেসে IPv6 সংযোগ থাকলে IPv6 নিয়মও যোগ করুন, কারণ কেবল IPv4 নীতি অন্য পরিবারটিকে খোলা রেখে দেয়।

DNS-ও নীতির অংশ। যদি অ্যাপ কেবল টানেলের ভেতরে প্রবেশযোগ্য একটি রিজলভারের মাধ্যমে নাম সমাধান করে, তবে বর্জন নিয়ম টানেল বন্ধ থাকলে সমাধান ভেঙে দেবে, এবং এটি কিল সুইচের জন্য সঠিক আচরণ। আপনি ঠিক এটাই চান কি না সচেতনভাবে সিদ্ধান্ত নিন।

জীবনচক্র পরীক্ষা করুন, কেবল বিচ্ছিন্নতা নয়

টানেল সুস্থ থাকার সময় একটি নতুন নিরীহ অনুরোধ পাঠান, তারপর VPN প্রক্রিয়া মেরে ফেলুন এবং আরেকটি পাঠান। কন্টেইনার থামার পরে, পুনরায় চালুর পরে এবং আবার তৈরি হওয়ার পরে পুনরাবৃত্তি করুন। নতুন অনুরোধ গুরুত্বপূর্ণ কারণ বিদ্যমান সংযোগ নতুন আটকানো নিয়ম পরিবর্তন থেকে টিকে যেতে পারে।

আটকানোর প্রক্রিয়া হিসেবে স্বাস্থ্য পরীক্ষা বা এগ্রেস IP অনুসন্ধানের ওপর নির্ভর করবেন না। পরীক্ষা অবস্থা পর্যবেক্ষণ করে এবং তা জানায়; নীতি ট্রাফিক নিয়ন্ত্রণ করে। দুটোই একই মোতায়েনের অংশ, এবং তারা একে অপরের বিকল্প নয়।

নিয়ম লিপিবদ্ধ করুন যাতে পরীক্ষা একটি হালনাগাদের পরেও টেকে

প্রতিটি ব্যর্থতা ক্ষেত্রে প্রত্যাশিত ফলাফল মোতায়েন নথিতে লিখুন, তা বাস্তবায়নকারী নিয়মগুলোর সঙ্গে। ওই লিপি ইমেজ হালনাগাদ বা রানটাইম উন্নয়নের পরে একই পরীক্ষা চালাতে দেয়, যখন নেমস্পেসের আচরণ বা ডিফল্ট রুট কেউ compose ফাইল সম্পাদনা না করেই বদলে যেতে পারে।

VPN এন্ডপয়েন্টের প্রয়োজনীয় বাহ্যিক পথকে অ্যাপের সীমাহীন এগ্রেস থেকে আলাদা রাখুন, এবং DNS ও IPv6-কে অভিপ্রেত কভারেজের ভেতরে রাখুন। যদি নীতি সুবিধার জন্য সম্পূর্ণ ভৌত ইন্টারফেস অনুমতি দেয়, তবে কিল সুইচ চলে গেছে। Docker-এর নেটওয়ার্ক নথি যে ভাগ করা নেমস্পেস বিন্যাসের ওপর নীতি দাঁড়িয়ে আছে তা বর্ণনা করে, এবং রানটাইমের আচরণ নিয়ে সন্দেহ হলে সেটাই দেখার সূত্র।