VPN কিল সুইচ কি রিবুটের পর টিকে থাকে? যাচাই করবেন কীভাবে

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

রিবুট তিনটি আলাদা প্রশ্ন তোলে

প্রশ্নটি ভাগ করুন। প্রথমত, নীতিটি কি ডিস্কে এমন আকারে আছে যা বুটের সময় কিছু একটা পড়ে? দ্বিতীয়ত, সেই পাঠক কি কোনো ট্র্যাফিক বেরোনোর আগেই চলে? তৃতীয়ত, নীতিটি কি আপনার দরকারের ট্র্যাফিক ঢাকে, অর্থাৎ প্রতিটি প্রসেস, উভয় অ্যাড্রেস পরিবার ও DNS। প্রথমটিতে “হ্যাঁ” আর দ্বিতীয়টিতে “না” ঠিক সেই ব্যর্থতাই তৈরি করে যা মানুষ এমন কিল সুইচ হিসেবে বর্ণনা করে যা রিবুটের পর টেকে না: চালুর সময় কয়েক সেকেন্ড ট্র্যাফিক বেরিয়ে যায়, আর কেউ খুঁজতে না গেলে তা লক্ষ্য করে না।

স্তরগুলো আলাদা রাখুন। সংরক্ষিত ফায়ারওয়াল নিয়মসমষ্টি, বুটে শুরু হওয়া একটি সার্ভিস এবং ক্লায়েন্টের একটি পছন্দ—এই তিনটি তিনটি ভিন্ন আয়ুযুক্ত তিনটি ভিন্ন বস্তু। পছন্দটি রিবুটের পর টেকে কারণ এটি কনফিগ ফাইলের একটি মান। নিয়মগুলোই একমাত্র জিনিস যা প্যাকেট ব্লক করে, এবং সেগুলো যে কার্নেল ধরে রেখেছিল তার সঙ্গে মিলিয়ে হারিয়ে যায়।

ব্লকটি পুনঃস্থাপন করে এমন বস্তু খুঁজুন

লিনাক্সে netfilter নিয়ম কার্নেলে বাস করে। আপনি ব্যবস্থা না করলে বুটের সময় কিছুই সেগুলো ফিরিয়ে লেখে না: iptables-save প্লাস netfilter-persistent, nftables.service লোড করে /etc/nftables.conf, অথবা একটি systemd ইউনিট যা আপনার নিজের স্ক্রিপ্ট চালায়। কী সক্রিয় আছে তা দেখুন, আপনি কী কনফিগার করেছিলেন তা মনে করার বদলে।

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

বুটের কয়েক সেকেন্ড পরে খালি নিয়মসমষ্টিই শিরোনামের প্রশ্নের উত্তর। উইন্ডোজে ক্লায়েন্ট সার্ভিসকে জিজ্ঞাসা করুন সে কীভাবে শুরু হয়, তারপর টানেল নিচে থাকা অবস্থায় প্ল্যাটফর্ম ফিল্টারের অবস্থা ডাম্প করুন।

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

দ্বিতীয় কমান্ডটি wfpstate.xml বর্তমান ডিরেক্টরিতে লেখে। ক্লায়েন্ট সংযোগ করার আগেই বিদ্যমান এমন ব্লক অ্যাকশনযুক্ত ফিল্টার খুঁজুন। Base Filtering Engine বুটের শুরুতে চালু হয় এবং স্থায়ী ফ্ল্যাগ দিয়ে যোগ করা ফিল্টার পুনঃস্থাপন করে, তাই কিছু কিল সুইচ কোনো ক্লায়েন্ট উইন্ডো থাকার আগেই ট্র্যাফিক ব্লক করে আর কিছু করে না। ম্যাকওএসে sudo pfctl -s info জানায় pf সক্রিয় কি না, sudo pfctl -s rules দেখায় কী লোড হয়েছে, আর VPN ক্লায়েন্টরা সাধারণত তাদের নিয়ম মূল নিয়মসমষ্টির বদলে একটি অ্যাঙ্করে যুক্ত করে। যে নিয়মটি utun3 নাম উল্লেখ করে তা পরের বুটের পর ভিন্ন ইন্টারফেস নির্দেশ করতে পারে, কারণ ওই নম্বরটি রানটাইমে দেওয়া হয়।

নেটওয়ার্ক ওঠা আর টানেল ওঠার মধ্যের ফাঁক লক্ষ্য করুন

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

systemd হোস্টে অনুমান না করে ক্রমটি পড়ুন। চালান systemctl cat VPN ও ফায়ারওয়াল ইউনিটে এবং দেখুন After= অথবা Before= কোনটি network-pre.target এবং network-online.target এর সঙ্গে মেলে, তা দেখুন। যে ফায়ারওয়াল ইউনিট network-online.target এর পরে ক্রমে আছে, সে ইন্টারফেসের কাছে হারে; আর যে ইউনিট network-pre.target এর আগে চাওয়া ও ক্রমে রাখা হয়েছে, সে জেতে। উইন্ডোজে সমতুল্য প্রশ্ন হলো সার্ভিসের স্টার্ট টাইপ ও তার নির্ভরতাগুলো, কারণ Manual-এ রাখা সার্ভিস বুট-কালীন প্রসেস ব্লক করতে পারে না। আপনার প্রয়োজনীয়তা যদি সাইন-ইনের আগের ট্র্যাফিকও ধরে, তবে কেবল ডিভাইস-স্তরের ব্যবস্থাই তা মেটায়: একটি Always On VPN ডিভাইস টানেল মেশিন সার্টিফিকেট দিয়ে প্রমাণীকরণ করে এবং ব্যবহারকারী লগইন করার আগেই সংযুক্ত হয়, এবং Microsoft ডিভাইস টানেলের কনফিগারেশন নথিভুক্ত করে ব্যবহারকারী টানেল থেকে আলাদাভাবে। অ্যান্ড্রয়েড অন্য পথ নেয়, সিস্টেম থেকেই সর্বদা-চালু VPN প্রয়োগ করে এবং তা ছাড়া সংযোগ ব্লক করে, অ্যাপ প্রসেস থেকে নয়।

পরীক্ষা চালান, তারপর দুই সময়রেখা মেলান

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

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

ফিরে আসার পথ না ভেঙে ফাঁকটি বন্ধ করুন

বুটে ব্লকটি না থাকলে দ্বিতীয় ক্লায়েন্ট নিয়ম যোগ না করে প্রয়োগটি এক স্তর নিচে নামান। নিয়মসমষ্টি সংরক্ষণ করুন এবং নেটওয়ার্ক ব্যবহারযোগ্য হওয়ার আগে ক্রমে থাকা একটি ইউনিট থেকে তা লোড করুন, এবং নিশ্চিত করুন সেই ইউনিটের এমন DNS লুকআপ বা নেটওয়ার্ক মাউন্ট দরকার নেই যা সে-ই রক্ষা করার কথা। পরিধি সময়ের মতোই গুরুত্বপূর্ণ: ব্যবহারকারী ID বা cgroup-এ মেলা নিয়ম প্রতিটি সিস্টেম ডেমনকে ব্লকের বাইরে রাখে, আর কেবল IPv4 সামলানো নিয়মসমষ্টি IPv6 ও DNS-কে পৌঁছানোযোগ্য রাখে।

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

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