Always-on VPN নাকি kill switch: আপনি আসলে কোনটি চালু করেছেন?
Always-on VPN টানেল আবার সংযোগ করে; kill switch ঠিক করে এটি ছাড়া কী বেরোতে পারে। লেবেল বিশ্বাস করার আগে পাঁচটি পরীক্ষা।
Always-on আর kill switch একই সেটিংস স্ক্রিনে দুই লাইন দূরে বসে, তাই মানুষ এদের একই ফিচারের দুই নাম ভাবে। তা নয়। Always-on পুনঃসংযোগ নীতি: বুটে টানেল চালু করে, ক্র্যাশ বা নেটওয়ার্ক বদলের পরে ফিরিয়ে আনে, আর ব্যর্থ হতে থাকলে বারবার চেষ্টা করে। Kill switch ট্র্যাফিক নীতি: টানেল বন্ধ থাকলে কোন প্যাকেট মেশিন ছাড়তে পারে তার নাম দেয়। দ্বিতীয়টি ছাড়া প্রথমটি চালু করা যায়, আর বেশিরভাগ প্ল্যাটফর্মে ডিফল্ট ফলাফল ফাঁকের সময়ও ট্র্যাফিক বেরোতে দেয়।
পরীক্ষা 1: ব্লকটি কি আলাদা সুইচ?
Android 10 ও পরের সংস্করণে সংরক্ষিত VPN প্রোফাইল গিয়ার আইকনের পেছনে দুইটি স্বতন্ত্র টগল খোলে: Always-on VPN এবং VPN ছাড়া সংযোগ ব্লক করুন। শুধু দ্বিতীয়টিই kill switch। শুধু always-on থাকলে টানেল ড্রপের পরে ফিরে আসে, কিন্তু মাঝপথে থাকা যেকোনো অ্যাপ ততক্ষণ Wi-Fi বা মোবাইল ডেটায় নেটওয়ার্কে পৌঁছায়।
পরিচালিত ডিভাইস নীতিতে একই ভাগ রাখে। setAlwaysOnVpnPackage() প্যাকেজের নাম আর lockdownEnabled ফ্ল্যাগ নেয়; প্যাকেজ সেট করে ফ্ল্যাগ মিথ্যা রাখা প্রশাসক স্থায়ী টানেল বানান, বন্ধ ডিভাইস নয়। কনসোলের ভাষা এই পার্থক্য প্রায়ই দেখায় না।
কনসোলের বদলে ডিভাইস থেকে অবস্থা পড়ুন: adb shell settings get global always_on_vpn_app আর adb shell settings get global always_on_vpn_lockdown। প্রথমটি null ফেরালে প্ল্যাটফর্ম পর্যায়ে কোনো প্যাকেজ চাপানো নেই; দ্বিতীয়টি 0 ফেরালে প্ল্যাটফর্ম কিছুই ব্লক করছে না। Android VPN গাইড এগুলোকে এক মোড নয়, আলাদা সক্ষমতা হিসেবে বর্ণনা করে।
পরীক্ষা 2: ব্লকটি কোন স্তরের?
লেবেল ক্লায়েন্টে থাকে, ব্লক সাধারণত ফায়ারওয়ালে, তাই একই শব্দ প্রতিটি প্ল্যাটফর্মে আলাদা অর্থ দেয়। নিচের সারিগুলো যেকোনোটিতে ভরসা করার আগে নিশ্চিত করার যোগ্য।
| Where you see the label | What the label promises | What actually blocks |
|---|---|---|
| Android VPN profile | Always-on VPN | Block connections without VPN |
| Android device policy | Always-on package | lockdownEnabled flag |
| Windows built-in VPN | Always On tunnel | Outbound firewall rules |
| WireGuard for Windows | Tunnel service | Block untunneled traffic option |
| wg-quick on Linux | Route via AllowedIPs | Your own nftables or iptables rules |
Windows হলো ব্লক না করা লেবেলের সবচেয়ে স্পষ্ট উদাহরণ। Always On সেখানে টানেলের স্থায়িত্ব বোঝায়: মেশিন প্রমাণীকরণের জন্য ডিভাইস টানেল, সাইন ইন করা অ্যাকাউন্টের জন্য ব্যবহারকারী টানেল, প্রোফাইল XML বা Add-VpnConnection দিয়ে কনফিগার করা। টানেল না থাকলে সেই প্রোফাইলে কিছুই বেরোনো প্যাকেট থামায় না, আর আউটবাউন্ড ফিল্টারিং ডিফল্টে চালু নয়, তাই Wi-Fi-তে থাকা ল্যাপটপ VPN বন্ধ থাকলেও কাজ করতে থাকে।
WireGuard একইভাবে ভাগ হয়, তবে ক্লায়েন্ট অনুসারে। Windows-এর WireGuard-এ প্রতি টানেলে একটি টানেলবিহীন ট্র্যাফিক ব্লক করুন অপশন আছে যা ফিল্টার নিয়ম বসায়; Linux টুলে এমন সুইচ নেই। wg-quick প্রতিটি AllowedIPs এন্ট্রির জন্য রুট আর fwmark নিয়ম যোগ করে, wg-quick down দুটোই সরায়, তাই ভৌত ডিফল্ট রুট মাঝে প্যাকেট না হারিয়ে আবার দায়িত্ব নেয়।
Apple প্ল্যাটফর্মে always-on তত্ত্বাবধানে থাকা ডিভাইসের জন্য ম্যানেজমেন্ট প্রোফাইল ফিচার হিসেবে আসে আর চেকবক্স নয়, অন-ডিমান্ড নিয়ম হিসেবে প্রকাশ পায়। পেলোড থেকে উত্তর দেওয়ার প্রশ্ন: ব্যর্থ টানেল ট্র্যাফিক অস্বীকার করে নাকি শুধু আরেক সংযোগ চায়। মেনুর শিরোনাম বলবে না।
পরীক্ষা 3: ফাঁক মাপুন, আইকন নয়
চারটি রূপান্তর জরুরি, আর তারা আলাদাভাবে ব্যর্থ হয়: কেউ লগইন করার আগে বুট, স্লিপ ও রিজিউম, Wi-Fi থেকে মোবাইল ডেটায় বদল, আর টানেল ইন্টারফেস অর্ধ-কনফিগার হয়ে থাকা ক্লায়েন্ট ক্র্যাশ। একটিতে পরিষ্কার পুনঃসংযোগ বাকি তিনটি সম্পর্কে কিছুই প্রমাণ করে না।
সবচেয়ে সস্তা পরীক্ষা টানেল ইচ্ছাকৃতভাবে বন্ধ করে তারপর বেরোনোর চেষ্টা করে। টানেল বন্ধ থাকলে curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com যদি 200 ফেরায়, নীতিটি fail-open; টাইমআউট বা প্রত্যাখ্যাত সংযোগ মানে এখনো কিছু ব্লক করছে। ip route get 1.1.1.1 প্যাকেট বহনকারী ইন্টারফেসের নাম দেয়, যা সাধারণত ট্রে আইকনের চেয়ে বেশি বলে, আর systemctl status wg-quick@wg0 দেখায় ইন্টারফেস পরিষ্কারভাবে সরানো হয়েছে কি না।
নেটওয়ার্ক বদলানোর সময়েই দ্বিতীয় উইন্ডোতে একই প্রোব চালান, শুধু স্থির হওয়ার পরে নয়। ড্রপ আর পুনঃচেষ্টার মধ্যের ব্যবধানই মূল অংশ, আর নাম রিজলভ করাই ট্র্যাফিক পালানোর দ্রুততম সূচক: টানেল বন্ধ থাকলে স্থানীয় রিজলভার উত্তর দিলে ব্লকটি সম্পূর্ণ নয়।
পরীক্ষা 4: লকডাউনের আগে ব্যতিক্রম ঠিক করুন
দুটি ব্যতিক্রম কাঠামোগত। ক্লায়েন্টকে নিজেই VPN সার্ভারে পৌঁছাতে হয়, তাই সব ফেলে দেওয়া নিয়ম সুরক্ষা ফিরিয়ে আনা পুনঃসংযোগও আটকায়। ক্যাপটিভ পোর্টালও ওঠা টানেল ছাড়া পাওয়া যায় না, তাই হোটেল Wi-Fi-তে লক করা ডিভাইসের পোর্টাল খোলার নথিভুক্ত উপায় দরকার, তাৎক্ষণিক নয়।
সর্বনিম্ন রূপ, এন্ডপয়েন্ট অনুমোদিত আর বাকি সব ফেলে দেওয়া:
table inet vpnlock {
chain output {
type filter hook output priority 0; policy drop;
oifname "lo" accept
ip daddr 203.0.113.10 udp dport 51820 accept
oifname "wg0" accept
}
}ওই এন্ডপয়েন্ট লাইনটিকে ধ্রুবক নয়, চলক হিসেবে ধরুন। প্রদানকারীরা ঠিকানা ঘোরায়, আর পুরোনো ব্যতিক্রমই কাজ করা kill switch-কে পুনঃসংযোগ করতে না পারা ডিভাইসে বদলে দেওয়ার সাধারণ কারণ। স্থানীয় প্রিন্টার, NAS শেয়ার আর ডেভেলপমেন্ট সেবা একই লিখিত তালিকায় থাকা উচিত, নাহলে একটি একটি করে সাপোর্ট টিকিটে ধরা পড়ে।
পরীক্ষা 5: সত্যিই কী প্রমাণ করলেন লিখে রাখুন
চার স্তম্ভের টেবিল রাখুন আর পরীক্ষা করে ভরুন: অবস্থা, প্রত্যাশিত আচরণ, পর্যবেক্ষিত আচরণ, প্রমাণ। সারিগুলো পরীক্ষা 3-এর রূপান্তর আর একটি ইচ্ছাকৃত ব্যর্থতা। কমান্ডের আউটপুটে ভরতে না পারা সারি পরীক্ষা না করা সারি, আর পুনঃসংযোগের সারি পাশ করে বুটের সারিতে ব্যর্থ ডিভাইস যথেষ্ট সাধারণ যে অতিরিক্ত দশ মিনিট মূল্যবান।
শেষ বলার আগে:
- ব্লকিং সেটিং পুনঃসংযোগ সেটিং থেকে আলাদা কি না নিশ্চিত করুন, আর ডিভাইসে এর মান পড়ুন।
- কোন স্তর ব্লক চালায় - ক্লায়েন্ট অপশন, ডিভাইস নীতি বা ফায়ারওয়াল - আর সেই স্তর কোথায় কনফিগার হয় জানুন।
- ব্লক প্রমাণ করা একটি প্রোব কমান্ড রাখুন, আর রূপান্তরের সময়ে চালান, পরে নয়।
- ব্যতিক্রমের তালিকা লিখুন, এন্ডপয়েন্টসহ, আর কে হালনাগাদ করে টুকে রাখুন।
- পরিচালিত হার্ডওয়্যারে চাপানো নীতি ছেড়ে দিন; ব্লক সরানো টানেল মেরামতের বদলে প্রয়োজনটাই বদলে দেয়।