টানেলের বাইরে রাখা অ্যাপটিকে আপনার কিল সুইচ কি ব্লক করবে?

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

দুটি নীতি, একটি মেশিন

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

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

নিয়মের আগে অ্যাপের তালিকা লিখুন

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

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

একটি নয়, দুটি তালিকা দরকার: টানেলকে কী বহন করতে হবে, আর কী কোনো কারণে তার বাইরে যেতে পারবে না। যে অ্যাপ্লিকেশন দুটোতেই থাকে, সেটি বাস্তবায়নের খুঁটিনাটি নয়, শর্তের সংঘাত, এবং ক্লায়েন্ট কনফিগার করার আগেই তা মিটিয়ে ফেলতে হবে।

বিভ্রাটের সময় ক্লায়েন্ট কী করে

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

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

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

তিনটি মুহূর্ত: টানেল চালু, টানেল বন্ধ, পুনঃসংযোগ

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

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

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

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