VPN منقطع ہونے کے بعد بھی حفاظتی سوئچ ٹریفک کو روکتا رہتا ہے

ٹنل ختم ہو گیا، نیٹ ورک کا آئیکن معمول کا لگتا ہے، اور کچھ لوڈ نہیں ہوتا۔ آپ نے VPN منقطع کیا، اسے ان انسٹال کیا یا دوبارہ بوٹ کیا، اور وہ بلاک جو رابطہ ٹوٹنے پر آپ کی حفاظت کرنا تھا اب بھی کھڑا ہے۔ کلائنٹ ونڈو اس کی وضاحت نہیں کر سکتی، کیونکہ آپ کو روکنے والا کلائنٹ نہیں: فیصلہ آپ کے نام پر کرنل میں لکھا گیا، اور اسے ہٹانے کے لیے کچھ نہیں چھوڑا گیا۔ Windows میں وہ حالت Windows Filtering Platform میں ہے؛ Linux میں یہ iptables یا nftables میں قواعد کا مجموعہ ہے، اکثر ایسی اسنیپ شاٹ کے ساتھ جو بوٹ پر دوبارہ لاگو ہوتی ہے۔ آگے وہ ترتیب ہے جو میں استعمال کرتا ہوں: حالت پڑھیں، ناکامی کی وضاحت کرنے والی سب سے تنگ چیز حذف کریں، پھر ہر وہ چیز تلاش کریں جو اسے بار بار واپس رکھتی ہے۔

حفاظتی سوئچ کرنل کی حالت ہے، کوئی سیٹنگ نہیں

ڈیسک ٹاپ کلائنٹ ٹنل سے باہر ٹریفک کو مسترد کرنے والے فلٹر شامل کر کے بلاکنگ نافذ کرتے ہیں۔ Windows میں وہ connect-redirect اور transport تہوں کے WFP فلٹر ہیں، اور کچھ مستقل ہیں: وہ Base Filtering Engine کی پالیسی اسٹور میں درج ہوتے ہیں اور مشین کے بوٹ پر بحال ہوتے ہیں، کسی بھی VPN سافٹ ویئر کے چلنے سے پہلے۔ کلائنٹ صفائی کے وقت میں مختلف ہیں۔ کچھ منقطع ہونے پر فلٹر ہٹاتے ہیں، کچھ صرف صاف اخراج پر، اور کچھ صرف اس وقت جب پہلے سوئچ بند کیا جائے۔ بلاک فعال ہونے کے دوران ان انسٹال کریں، یا پروسیس کو مار ڈالیں، اور فلٹر رہ جاتے ہیں۔

Linux میں متبادل آؤٹ پٹ راستے میں drop یا reject قاعدہ ہے، کبھی forwarding قاعدہ، کبھی بدلی ہوئی chain پالیسی۔ وہ قواعد انھیں شامل کرنے والے پروسیس سے زیادہ عرصہ زندہ رہتے ہیں کیونکہ وہ کرنل کی حالت ہیں: کلائنٹ کو مار ڈالیں، کریش کریں یا بجلی کاٹ دیں — کرنل پیکٹ گرتا رہتا ہے، اور اسے کالعدم کرنے کے لیے کچھ نہیں بچتا۔ مستقل مزاجی کا پیکیج موجودہ قواعد کے مجموعے کی اسنیپ شاٹ لے کر بوٹ پر بحال کر کے دوسری مستقل تہہ شامل کرتا ہے، اس لیے اگلی شروعات بلاک پہلے سے نصب حالت میں ہوتی ہے۔

کچھ بھی حذف کرنے سے پہلے WFP حالت پڑھیں

Windows میں ضروری اوزار موجود ہیں۔ ایڈمنسٹریٹر پرامپٹ چلائیں اور پلیٹ فارم کی حالت ڈمپ کریں؛ ڈمپ کام کی ڈائریکٹری میں wfpstate.xml کے طور پر آتا ہے۔

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

XML میں گئے ہوئے وینڈر کا نام، Block کارروائی اور تہہ تلاش کریں۔ عام ٹریفک توڑنے والے connect-redirect اور transport فلٹر ہیں؛ 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 پیکٹ کاؤنٹر شامل کرتا ہے، اور وہ کاؤنٹر بتاتے ہیں کہ قاعدہ واقعی آپ کی ناکام درخواستوں سے میل کھاتا ہے یا صرف chain میں بیٹھا ہے۔

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

صرف قواعد نہیں، chain پالیسیاں بھی پڑھیں: -P OUTPUT DROP کوئی قاعدہ نہ ملنے پر بھی ٹریفک روکتا ہے۔ IPv6 الگ جانچیں، کیونکہ دونوں خاندان نصب کرنے والا کلائنٹ IPv4 قواعد جانے کے بعد بھی IPv6 بلاک چھوڑ سکتا ہے، اور پھر علامت اس پر منحصر ہوتی ہے کہ ایپلیکیشن کس خاندان کو ترجیح دیتی ہے۔ جہاں nftables استعمال ہوتا ہے وہاں nft list ruleset بھی چلائیں؛ دونوں اوزار مطابقت کی تہہ کے ذریعے ساتھ رہتے ہیں، اور ایک فہرست ہر وہ قاعدہ نہیں دکھاتی جو پیکٹ گرا سکتا ہے۔

ناکامی کی وضاحت کرنے والی سب سے تنگ چیز حذف کریں

Windows میں پہلا قدم اب بھی وینڈر کا اپنا ہٹانے کا راستہ ہے: انسٹالر دوبارہ چلائیں اور repair یا uninstall استعمال کریں، یا اگر وینڈر شائع کرتا ہے تو صفائی کا اوزار چلائیں۔ بچی ہوئی سروسز اور شیڈول شدہ کام عام ہیں، اور لاگ اِن پر کلائنٹ شروع کرنے والا کام اگلے بوٹ پر اس کے فلٹر دوبارہ نصب کرتا ہے۔ کلائنٹ کی رجسٹری کلید پڑھتے وقت ناکام ہونے والی ان انسٹالیشن عام طور پر یہ ظاہر کرتی ہے کہ سروس یا کام اسے اب بھی پکڑے ہوئے ہے، یہ نہیں کہ رجسٹری خراب ہے۔

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 رکھیں۔ آپ کی نشاندہی کردہ ایک قاعدہ حذف کرنا پوری chain خالی کرنے سے بہتر ہے، کیونکہ آپ کی اپنی پالیسی برقرار رہتی ہے۔

sudo iptables -D OUTPUT -p udp -j REJECT

اگر drop صارف کی متعین chain میں ہے تو پہلے اس chain میں چھلانگ حذف کریں اور بعد میں -X سے chain ہٹائیں۔ drop قواعد موجود ہوتے ہوئے chain پالیسی کو ACCEPT کرنا صرف ان پیکٹوں کی مدد کرتا ہے جو پالیسی فیصلے تک پہنچتے ہیں۔ ہر ٹیبل خالی کرنا آخری تدبیر ہے: یہ دوسری وجوہات سے شامل کردہ قواعد بھی ہٹا دیتا ہے، اور ufw فعال ہونے پر سروس کو یہ باور کراتا ہے کہ وہ ایسی chain کا مالک ہے جو اب موجود نہیں۔

اسے واپس رکھنے والا مالک تلاش کریں

فوری مرمت کے بعد وہ چیز تلاش کریں جو حالت بحال کرے۔ Linux میں دیکھیں کہ مستقل مزاجی یونٹ فعال ہے یا نہیں، کلائنٹ میں لاگ اِن پر فائر وال بحال کرنے کی سیٹنگ ہے یا نہیں، اور /etc کے نیچے محفوظ قواعد فائل ہے یا نہیں۔ Windows میں اسٹارٹ اپ اندراجات، سروسز اور شیڈول شدہ کام دوبارہ جانچیں، پھر دوبارہ بوٹ کر کے پہلے کی طرح انہی کمانڈز سے حالت دوبارہ پڑھیں۔

اگر بلاک واپس آئے تو حذف کرنا حل نہیں تھا؛ مالک حل تھا۔ لکھیں کہ کون سا کلائنٹ یا سروس اسے نصب کرتا ہے اور وہیں خصوصیت بند کریں، ہر منقطع ہونے کے بعد فائر وال تہہ پر لڑنے کے بجائے۔

ایک ping نہیں، اصل ٹریفک سے تصدیق کریں

نام کی حل، TCP رابطہ اور نیا براؤزر سیشن جانچیں، پھر دوبارہ بوٹ کر کے وہی تین جانچیں دہرائیں۔ HTTPS ناکام ہوتے وقت ping چلے تو یہ نیٹ ورک کی طرف نہیں بلکہ transport تہہ کے فلٹر کی طرف اشارہ کرتا ہے، اور صرف دوبارہ بوٹ کے بعد واپس آنے والا بلاک اس مالک کی طرف اشارہ کرتا ہے جو آپ نے ابھی نہیں ڈھونڈا۔

شواہد رکھیں: ایکسپورٹ شدہ BFE کلید، یا تبدیلی سے پہلے لی گئی iptables -S آؤٹ پٹ۔ درست ہو گیا کہنے سے پہلے تصدیق کریں کہ چیز کس تہہ سے ہٹائی، اسے دوبارہ نصب کر سکنے والا مالک کون ہے، ایک صاف دوبارہ بوٹ کے بعد کی حالت، اور VPN پروسیس کے بغیر عام براؤزنگ کام کرتی ہے۔ iptables(8) کے مینوئل صفحے پر صفائی کو اسکرپٹ کرنے پر درست حذف اور پالیسی نحو موجود ہے۔