VPN অ্যাপ চালু হওয়ার আগেই কি kill switch ট্র্যাফিক আটকায়?

একটি kill switch তার অ্যাপ চালু হওয়ার আগের সময়টা ঢাকতে পারে, আবার নাও পারে, আর এই পার্থক্য ঠিক করে অপারেটিং সিস্টেমের নীতি, ক্লায়েন্টের মার্কেটিং পেজ নয়। অটো-লঞ্চ চেকবক্স প্রমাণ করে যে কিছু একটা চালু হওয়ার জন্য নির্ধারিত আছে। নেটওয়ার্ক ওঠার মুহূর্তে ব্লকিং নিয়ম বিদ্যমান আছে, তা এটি প্রমাণ করে না। এগুলো দুটি ঘটনা, আর এর মধ্যে কেবল একটি ট্র্যাফিক রক্ষা করে।

চেকলিস্টটি ক্রমানুসারে কাজ করুন, কারণ প্রতিটি ধাপ আপনি আসলে কী পরীক্ষা করছেন তা সংকুচিত করে।

ব্লকটি আসলে কোথা থেকে আসে

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

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

উইন্ডোকে সার্ভিস থেকে আলাদা করুন

বন্ধ উইন্ডো প্রমাণ নয় যে প্রয়োগ বন্ধ হয়েছে, আর খোলা উইন্ডো প্রমাণ নয় যে টানেল প্রস্তুত। অনেক ক্লায়েন্ট ইন্টারফেস, ডেমন ও ট্রে অ্যাপ্লিকেশন আলাদা রাখে। ট্রে হলো যা আপনি দেখেন; ডেমন হলো যা নিয়মগুলো ধরে রাখে।

উপাদানটি পরীক্ষা করুন, আইকন নয়।

স্টার্টআপের বিরতিটি নিরাপদে পরীক্ষা করুন

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

টানেল আগেই ওঠার পরে করা পরীক্ষা স্টার্টআপ সম্পর্কে কিছুই প্রমাণ করে না।

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

প্রতিটি প্ল্যাটফর্মের জন্য নীতি পড়ুন

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

যে প্রোফাইলে ইন্টারঅ্যাকটিভ পাসওয়ার্ড লাগে, তার স্টার্টআপ নির্ভরতা মেশিন টানেলের থেকে আলাদা।

কী রেকর্ড করবেন

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

ফাঁকটি যদি গুরুত্বপূর্ণ হয়, স্থায়ী সমাধান প্ল্যাটফর্ম নীতি, ছোট লঞ্চ বিলম্ব নয়।

মূল প্রশ্নের উত্তর এটাই, শর্ত হিসেবে বলা: kill switch কেবল তখনই অ্যাপ চালু হওয়ার আগে ট্র্যাফিক রক্ষা করে, যখন ব্লকটি এমন কিছু ইনস্টল করে যা অ্যাপের আগেই বিদ্যমান।