কিল সুইচ VPN সংযোগ বিচ্ছিন্ন হওয়ার পরেও ট্রাফিক ব্লক করে রাখে

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

কিল সুইচ কার্নেলের অবস্থা, কোনো সেটিং নয়

ডেস্কটপ ক্লায়েন্টরা টানেলের বাইরের ট্রাফিক অস্বীকার করে এমন ফিল্টার যোগ করে ব্লকিং বাস্তবায়ন করে। Windows-এ এগুলো connect-redirect ও ট্রান্সপোর্ট স্তরে WFP ফিল্টার, এবং এগুলোর কয়েকটি স্থায়ী: এগুলো Base Filtering Engine-এর নীতি ভাণ্ডারে রেকর্ড হয় এবং মেশিন বুট হওয়ার সময়, কোনো VPN সফটওয়্যার চালু হওয়ার আগেই পুনরুদ্ধার হয়। ক্লায়েন্টরা পরিষ্কার করার সময়ে ভিন্ন। কেউ বিচ্ছিন্ন হওয়ার সময় ফিল্টার সরায়, কেউ কেবল পরিষ্কার প্রস্থানে, আবার কেউ কেবল তখনই যখন কিল সুইচ টগল আগে বন্ধ করা হয়। ব্লক সক্রিয় থাকা অবস্থায় আনইনস্টল করুন, অথবা প্রসেসটি মেরে ফেলুন, ফিল্টারগুলো থেকে যায়।

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

কিছু মুছতে যাওয়ার আগে WFP অবস্থা পড়ুন

Windows আপনার প্রয়োজনীয় টুল দিয়েই আসে। একটি এলিভেটেড প্রম্পট চালান এবং প্ল্যাটফর্মের অবস্থা ডাম্প করুন; ডাম্পটি ওয়ার্কিং ডিরেক্টরিতে wfpstate.xml হিসেবে জমা হয়।

netsh wfp show state
netsh wfp show filters
Get-Service bfe

XML-এ চলে যাওয়া ভেন্ডরের নাম, একটি Block অ্যাকশন এবং স্তরটি খুঁজুন। connect-redirect ও ট্রান্সপোর্টের ফিল্টারগুলোই সাধারণ ট্রাফিক ভাঙে; receive-accept স্তরের ফিল্টার সাধারণত আপনার কারণ নয়। Base Filtering Engine একেবারেই চলছে না হলে অন্যত্র খুঁজুন, কারণ এসব ফিল্টার প্রয়োগ করতে আর কিছুই পারে না।

সাধারণ ফায়ারওয়াল দৃশ্যটিও ক্রস-চেক করুন, কারণ বেশিরভাগ মানুষ দুটির মধ্যে একটিই দেখেন:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

Linux নিয়মগুলো সেই সিনট্যাক্সেই পড়ুন যেটি দিয়ে মুছবেন

iptables -S নিয়মগুলো যোগ করার সময় ব্যবহৃত একই আকারে ছাপে, ফলে আউটপুট সরাসরি মোছার জন্য পুনরায় ব্যবহারযোগ্য হয়। iptables -L -v -n প্যাকেট কাউন্টার যোগ করে, আর সেই কাউন্টারগুলো জানায় একটি নিয়ম সত্যিই আপনার ব্যর্থ অনুরোধের সাথে মিলছে, নাকি কেবল চেইনে বসে আছে।

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

শুধু নিয়ম নয়, চেইন নীতিগুলোও পড়ুন: -P OUTPUT DROP কোনো নিয়ম না মিললেও ট্রাফিক ব্লক করে। IPv6 আলাদাভাবে দেখুন, কারণ যে ক্লায়েন্ট দুই পরিবারই ইনস্টল করে সে IPv4 নিয়ম চলে যাওয়ার পরেও IPv6 ব্লক রেখে যেতে পারে, আর তখন উপসর্গটি নির্ভর করে অ্যাপ্লিকেশন কোন পরিবার পছন্দ করে তার উপর। যেখানে nftables ব্যবহৃত হয় সেখানে nft list ruleset-ও চালান; দুটি টুল একটি সামঞ্জস্য স্তরের মাধ্যমে সহাবস্থান করে, আর একটি তালিকা জরুরিভাবে প্রতিটি নিয়ম দেখায় না যা একটি প্যাকেট ফেলতে পারে।

ব্যর্থতা ব্যাখ্যা করে এমন সবচেয়ে সংকীর্ণ বস্তুটি মুছুন

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

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

স্থায়ী ফিল্টার শেষ উপায়। এগুলো HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter-এর অধীনে থাকে, প্রতিটি ফিল্টারের জন্য GUID-চাবিকৃত একটি মান। আগে কী-টি এক্সপোর্ট করুন, যে GUID-গুলো সরাচ্ছেন তা লিখে রাখুন, কেবল চলে যাওয়া ক্লায়েন্টের মানগুলো মুছুন, তারপর রিবুট করুন যাতে ইঞ্জিন তার অবস্থা পুনর্গঠন করে। পুরো কী মুছবেন না এবং Base Filtering Engine বন্ধ করবেন না: Windows Firewall ও Defender এর উপর নির্ভর করে, আর আপনি একটি বিভ্রাটের বিনিময়ে আরও খারাপটি নিতেন।

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Linux-এ iptables -S যে লাইন ছাপে সেটি নিন এবং -A-এর জায়গায় -D বসান। চেইন ফ্লাশ করার চেয়ে শনাক্ত করা একটি নিয়ম মোছা ভালো, কারণ এটি আপনার নিজের নীতি অক্ষত রাখে।

sudo iptables -D OUTPUT -p udp -j REJECT

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

যে মালিক এটি ফিরিয়ে আনে তাকে খুঁজুন

তাৎক্ষণিক মেরামতের পর, অবস্থা পুনরুদ্ধার করতে পারে এমন কিছু খুঁজুন। Linux-এ দেখুন একটি পারসিস্টেন্স ইউনিট চালু আছে কি না, ক্লায়েন্টে লগইনে ফায়ারওয়াল পুনরুদ্ধারের সেটিং আছে কি না, এবং /etc-এর অধীনে সংরক্ষিত নিয়ম ফাইল আছে কি না। Windows-এ স্টার্টআপ এন্ট্রি, সার্ভিস ও নির্ধারিত টাস্ক আবার দেখুন, তারপর রিবুট করে আগের মতো একই কমান্ডে অবস্থা আবার পড়ুন।

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

একটি পিং নয়, বাস্তব ট্রাফিক দিয়ে যাচাই করুন

একটি নাম lookup, একটি TCP সংযোগ ও একটি নতুন ব্রাউজার সেশন পরীক্ষা করুন, তারপর রিবুট করে একই তিনটি যাচাই আবার করুন। HTTPS ব্যর্থ হওয়া সত্ত্বেও কাজ করা একটি পিং নেটওয়ার্ক নয়, ট্রান্সপোর্ট-স্তরের ফিল্টারের দিকে ইঙ্গিত করে, আর কেবল রিবুটের পর ফিরে আসা ব্লক এমন মালিকের দিকে ইঙ্গিত করে যা আপনি এখনও খুঁজে পাননি।

প্রমাণ রাখুন: এক্সপোর্ট করা BFE কী, অথবা পরিবর্তনের আগে ধরা iptables -S আউটপুট। এটিকে ঠিক করা বলার আগে নিশ্চিত করুন আপনি কোন স্তর থেকে বস্তুটি সরিয়েছেন, কোন মালিক এটি পুনরায় ইনস্টল করতে পারে, একটি পরিষ্কার রিবুটের পর অবস্থা, এবং কোনো VPN প্রসেস ছাড়াই সাধারণ ব্রাউজিং কাজ করে। ক্লিনআপ স্ক্রিপ্ট করলে iptables(8) ম্যান পেজে সঠিক মুছে ফেলা ও নীতি সিনট্যাক্স আছে।