ফেইল-ওপেন বনাম ফেইল-ক্লোজড: VPN কিল সুইচ কী নির্ধারণ করে
দুটি পরিভাষাই বলে টানেল চলে যাওয়ার পরে ট্র্যাফিকের কী হয়, এনক্রিপশন কত শক্তিশালী তা নয়। আপনি যে পরিধি বেছে নেন, সেটিই ঠিক করে ট্র্যাফিক সত্যিই ফাঁস হবে কি না।
কথাটি একটি ভুল ধারণা: ফেইল-ক্লোজড নিরাপদ সেটিং আর ফেইল-ওপেন অবহেলার সেটিং। দুটিই বর্ণনা করে টানেল চলে যাওয়ার পর ট্র্যাফিকের কী হয়, এবং কোনোটিই সেই টানেল কত ভালোভাবে এনক্রিপ্ট করে তা বদলায় না। বিস্তৃত ব্যতিক্রম-তালিকাসহ ফেইল-ক্লোজড নীতি এমন একটি ডিভাইসে ফেইল-ওপেন নীতির চেয়ে বেশি ফাঁস করতে পারে যা কখনো অফিস নেটওয়ার্ক ছাড়ে না। যে ফলাফলটি ট্র্যাফিকের মালিককে ব্যাখ্যা করতে পারবেন, সেটিই বেছে নিন।
লেবেল ফলাফল বোঝায়, শক্তি নয়
পরিভাষাটি নিয়ন্ত্রণ ব্যবস্থা থেকে এসেছে: কোনো উপাদান ব্যর্থ হলে ফেইল-ওপেন কাজ চালু রাখে, ফেইল-ক্লোজড তা বন্ধ করে। VPN-এ প্রয়োগ করলে ব্যর্থ উপাদানটি হলো টানেল, আর প্রশ্ন হলো অন্য কোনো পথে ট্র্যাফিক চালিয়ে যাওয়ার অনুমতি আছে কি না। সাইফার নির্বাচন, কী-এর দৈর্ঘ্য ও প্রোটোকল আলাদা সিদ্ধান্ত।
বিভ্রান্তিটি টেকে কারণ কিল সুইচ নিরাপত্তা-বৈশিষ্ট্যের মতো শোনায়, আর বিক্রেতারা এটি সেভাবেই বাজারজাত করে। যান্ত্রিকভাবে এটি একটি রাউটিং ও ফায়ারওয়াল নিয়ম, যা টানেলের বহন করার কথা থাকা ট্র্যাফিক ব্লক করে, যা ক্লায়েন্টে, অপারেটিং সিস্টেমে বা গেটওয়েতে প্রয়োগ করা হয়। যে স্তর এটি কার্যকর করে সে-ই এর পরিধিও নির্ধারণ করে, আর এক স্তরের নিয়ম অন্য স্তরকে ঢাকতে পারে না। গেটওয়ের নিয়ম এমন ল্যাপটপকে রক্ষা করতে পারে না যা ইতিমধ্যে অন্য নেটওয়ার্কে চলে গেছে।
প্রতিটি ফলাফল কেমন দেখায়
একই নীতি কোন ব্যর্থতার মুখোমুখি হচ্ছেন তার ওপর নির্ভর করে খুব ভিন্নভাবে আচরণ করতে পারে, তাই লেবেল নয়, ঘটনাগুলোর তুলনা করুন।
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
শেষ সারিটি তাদের ধরে যারা ভাবে কিল সুইচ একটিমাত্র সুইচ। IPv4 রাউট টেবিলের জন্য লেখা নিয়ম IPv6 ডিফল্ট রাউটকে অক্ষত রাখে, আর অ্যাপ্লিকেশনটি আনন্দের সঙ্গে সেটি ব্যবহার করতে পারে।
পরিধিই ঠিক করে ফাঁস হবে কি না
কোন মোড তা জিজ্ঞাসা করার আগে জিজ্ঞাসা করুন নীতিটি কী ঢাকে। প্রতি-অ্যাপ্লিকেশন নিয়ম একটি অ্যাপ রক্ষা করে আর কিছুই না, ডিভাইস-ব্যাপী নিয়ম ব্যতিক্রমগুলো ছাড়া সব রক্ষা করে, আর গেটওয়ে নিয়ম কেবল সেই গেটওয়েতে পৌঁছানো ট্র্যাফিক রক্ষা করে। DNS-এর নিজস্ব সিদ্ধান্ত দরকার, কারণ স্থানীয় রিজলভারে পাঠানো কোয়েরি পেলোড ব্লক থাকলেও নাম প্রকাশ করতে পারে।
স্থানীয়-নেটওয়ার্ক ব্যতিক্রম প্রিন্টার, কাস্টিং ও ক্যাপটিভ পোর্টালের জন্য থাকে, আর প্রতিটি ব্লকে একটি ফুটো। নীতির পাশেই সেগুলো নথিভুক্ত করুন, কারণ কনফিগারেশন যে উত্তরাধিকার পাবে সে অন্যথায় ফেইল-ক্লোজডকে পরম বলে পড়বে।
পুনঃসংযোগ ও ব্লকিংও আলাদা নিয়ন্ত্রণ। ক্লায়েন্ট কখনো ব্লক না করেই স্বয়ংক্রিয়ভাবে পুনঃসংযোগ করতে পারে, বা পুনঃসংযোগ ছাড়াই ব্লক করতে পারে, আর এই সমন্বয়ই ঠিক করে বিভ্রাটের সময় ব্যবহারকারী কী অনুভব করে।
রূপান্তরের সময়ই তা প্রমাণ করুন
স্থিতিশীল অবস্থা পরীক্ষা করে কিছুই প্রমাণ হয় না। ইচ্ছাকৃতভাবে টানেল ফেলে দিন এবং যে অ্যাপ্লিকেশনটি সুরক্ষিত থাকার কথা সেটি চেষ্টা করুন, তারপর দেখুন এটি নেটওয়ার্কে পৌঁছেছে কি না। ক্লায়েন্টের সূচককে ফলাফলের সঙ্গে মিলিয়ে দেখুন, কারণ যে সূচক এখনো সংযুক্ত বলে, সেটিই ঠিক সেই অবস্থা যার জন্য নীতিটি আছে। সুরক্ষিত অ্যাপ্লিকেশনটি সফল হলে মোডের নাম কোনো ব্যাপার নয়; আপনার ফাঁস আছে।
সাইন-ইনের আগে কোল্ড বুট থেকে পুনরাবৃত্তি করুন, Wi-Fi থেকে সেলুলারে যাওয়ার সময়, এবং সুরক্ষিত অ্যাপ ব্যাকগ্রাউন্ডে রেখে। ব্লক যদি ক্লায়েন্ট প্রসেস কার্যকর করে, তবে সেই প্রসেস পরিষ্কারভাবে বন্ধ না হয়ে নিহত হলে কী হয় তাও পরীক্ষা করুন।
সবশেষে, পরিষ্কার করার পথটি দেখুন। কোনো ক্লায়েন্টের নিয়ম সক্রিয় থাকা অবস্থায় আনইনস্টল করা হলে, অপারেটিং সিস্টেমের ফায়ারওয়াল নিষ্ক্রিয় করার বদলে বিক্রেতার নথিভুক্ত অপসারণ পদ্ধতি ব্যবহার করুন, কারণ ফায়ারওয়াল নিষ্ক্রিয় করা অসম্পর্কিত সুরক্ষা সরায় কিন্তু অবশিষ্ট নিয়মের মালিক কে, তার উত্তর দেয় না।