کیا VPN کا حفاظتی سوئچ دوبارہ آغاز کے بعد قائم رہتا ہے؟ اسے کیسے جانچیں

دوبارہ آغاز کرنا وہ سب سے عام طریقہ ہے جس سے لوگ حفاظتی سوئچ جانچتے ہیں، اور یہی وہ جانچ ہے جو سب سے زیادہ جھوٹ بولتی ہے۔ کلائنٹ میں چیک باکس محض ایک ترجیح ہے؛ اصل بات یہ ہے کہ نیٹ ورک اسٹیک کے اوپر آنے کے لمحے اور ٹنل کے واقعی قائم ہونے کے لمحے کے درمیان کوئی چیز بلاک نافذ کرتی ہے یا نہیں۔ Windows پر وہ چیز عام طور پر Windows Filtering Platform میں ایک فلٹر ہوتی ہے، Linux پر کسی یونٹ کے لوڈ کردہ قواعد کا مجموعہ، macOS پر pf اینکر، Android پر خود نظام کے ہمیشہ آن اور لاک ڈاؤن جھنڈے۔ یہ انتظامات دوبارہ آغاز کے دوران بہت مختلف برتاؤ کرتے ہیں، اور صرف پلیٹ فارم سطح کے انتظامات ہی کسی کے لاگ اِن کرنے سے پہلے اپنی جگہ پر ہوتے ہیں۔

دوبارہ آغاز تین الگ سوالات پوچھتا ہے

سوال کو تقسیم کریں۔ پہلا، کیا پالیسی ڈسک پر ایسی شکل میں موجود ہے جسے بُوٹ کے وقت کوئی چیز پڑھتی ہے؟ دوسرا، کیا وہ قاری کسی بھی ٹریفک کے باہر جانے سے پہلے چلتا ہے؟ تیسرا، کیا پالیسی اُس ٹریفک کو ڈھانپتی ہے جس کی آپ کو پرواہ ہے، یعنی ہر عمل، دونوں ایڈریس خاندان اور DNS۔ پہلے پر ہاں اور دوسرے پر نہیں کہنا بالکل وہی ناکامی پیدا کرتا ہے جسے لوگ ایسے حفاظتی سوئچ کے طور پر بتاتے ہیں جو دوبارہ آغاز کے بعد قائم نہیں رہتا: شروع میں چند سیکنڈ ٹریفک باہر نکل جاتی ہے، اور کوئی جانچنے نہ جائے تو کسی کو پتہ نہیں چلتا۔

تہوں کو الگ رکھیں۔ محفوظ شدہ فائر وال قواعد کا مجموعہ، بُوٹ پر شروع ہونے والی سروس اور کلائنٹ کی ترجیح تین مختلف اشیاء ہیں جن کی تین مختلف عمریں ہیں۔ ترجیح دوبارہ آغاز سے بچ جاتی ہے کیونکہ یہ کنفیگ فائل میں ایک قدر ہے۔ قواعد ہی واحد چیز ہیں جو پیکٹ روکتی ہیں، اور وہ اُس کرنل کے ساتھ غائب ہو جاتی ہیں جس نے انہیں تھاما ہوا تھا۔

وہ چیز تلاش کریں جو بلاک کو بحال کرتی ہے

Linux پر 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

بُوٹ کے چند سیکنڈ بعد خالی قواعد کا مجموعہ ہی عنوان کے سوال کا جواب ہے۔ Windows پر کلائنٹ سروس سے پوچھیں کہ یہ کیسے شروع ہوتی ہے، پھر ٹنل کے نیچے ہونے پر پلیٹ فارم فلٹر کی حالت ڈمپ کریں۔

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

دوسرا حکم wfpstate.xml کو موجودہ ڈائریکٹری میں لکھتا ہے۔ کلائنٹ کے جڑنے سے پہلے موجود بلاک عمل والے فلٹر تلاش کریں۔ Base Filtering Engine بُوٹ کے آغاز میں ہی شروع ہوتا ہے اور مستقل جھنڈے کے ساتھ شامل کردہ فلٹر بحال کرتا ہے، اسی لیے کچھ حفاظتی سوئچ کسی کلائنٹ ونڈو کے وجود سے پہلے ہی ٹریفک روک دیتے ہیں اور کچھ نہیں۔ macOS پر sudo pfctl -s info بتاتا ہے کہ pf فعال ہے یا نہیں، sudo pfctl -s rules دکھاتا ہے کہ کیا لوڈ ہے، اور VPN کلائنٹ عام طور پر اپنے قواعد مرکزی مجموعے کی بجائے اینکر سے جوڑتے ہیں۔ جو قاعدہ utun3 کا نام لیتا ہے وہ اگلے بُوٹ کے بعد کسی اور انٹرفیس کی طرف اشارہ کر سکتا ہے، کیونکہ وہ نمبر رن ٹائم میں دیا جاتا ہے۔

نیٹ ورک کے اوپر آنے اور ٹنل کے اوپر آنے کے درمیان خلا پر نظر رکھیں

خطرناک وقفہ پورا دوبارہ آغاز نہیں، وہ خلا ہے۔ انٹرفیس کو ایک لمحے میں لیز اور ڈیفالٹ روٹ ملتا ہے، VPN سروس دوسرے لمحے شروع ہوتی ہے، اور ٹنل مزید بعد میں تصدیق کرتا ہے، کبھی کبھی صرف اُس وقت جب صارف لاگ اِن کرے اور اسناد کا ایجنٹ چلے۔ اگر بلاک سب سے آخر میں لاگو ہو تو خلا میں موجود سب کچھ کھلے طور پر باہر چلا جاتا ہے۔

systemd میزبانوں پر اندازہ لگانے کی بجائے ترتیب پڑھیں۔ VPN اور فائر وال یونٹوں پر systemctl cat چلائیں اور After= اور Before= کے حوالے سے network-pre.target یا network-online.target تلاش کریں۔ network-online.target کے بعد ترتیب دیا گیا فائر وال یونٹ انٹرفیس سے ہار جاتا ہے؛ جو network-pre.target کا تقاضا کرتا ہے اور اس سے پہلے ترتیب دیا گیا ہے وہ جیت جاتا ہے۔ Windows پر مساوی سوالات سروس کی اسٹارٹ قسم اور اس کے انحصار ہیں، کیونکہ Manual پر رکھی گئی سروس بُوٹ کے وقت کے عمل کو نہیں روک سکتی۔ اگر آپ کی ضرورت میں لاگ اِن سے پہلے کی ٹریفک بھی شامل ہے تو صرف ڈیوائس سطح کا انتظام ہی اسے پورا کرتا ہے: Always On VPN ڈیوائس ٹنل مشین سرٹیفکیٹ سے تصدیق کرتا ہے اور صارف کے لاگ اِن کرنے سے پہلے جڑتا ہے، اور Microsoft ڈیوائس ٹنل کی کنفیگریشن کی دستاویز کرتا ہے صارف ٹنل سے الگ۔ Android دوسرا راستہ لیتا ہے، ہمیشہ آن VPN نافذ کرتا ہے اور اس کے بغیر رابطوں کو ایپ عمل سے نہیں بلکہ نظام سے روکتا ہے۔

جانچ چلائیں، پھر دو وقت کی لکیریں موازنہ کریں

ایسی منزل کے ساتھ دوبارہ آغاز کریں جس کا نقصان نہ ہو اگر وہ لیک ہو جائے، اور حالت کو خلا کے بعد نہیں بلکہ خلا کے دوران قید کریں۔ سب سے صاف طریقہ بُوٹ کے وقت کا پروب ہے: کوئی oneshot یونٹ یا شیڈول شدہ کام جو پلیٹ فارم کی اجازت کے مطابق جلد شروع ہوتا ہے، ڈیفالٹ روٹ اور فائر وال کی حالت ریکارڈ کرتا ہے، مختصر وقت کی حد کے ساتھ ایک درخواست آزماتا ہے اور مقامی فائل میں ایک سطر شامل کرتا ہے۔ اُس ریکارڈ کا موازنہ journalctl -b -u یا نظام لاگ سے ملنے والے VPN سروس کے آغاز کے وقت سے کریں۔

پھر عام جانچ چلائیں: ٹنل اوپر، رابطہ منقطع کریں، دیکھیں کہ براہ راست ٹریفک بلاک ہوتی ہے یا نہیں، بحال کریں۔ دوسرے میں کامیاب اور پہلے میں ناکام ہونا عام نتیجہ ہے، اور اس کا مطلب یہ ہے کہ نفاذ کلائنٹ کی طرف ہے، کلائنٹ کے جڑنے پر لاگو ہوتا ہے، بُوٹ پر نہیں۔ میں نے آخری جس مشین کا آڈٹ کیا، اُس میں بلاک NetworkManager کی ڈسپیچر اسکرپٹ سے آیا تھا: موجود اور درست اور انٹرفیس کے اوپر آنے سے پہلے کے سیکنڈوں کے لیے بیکار۔ دونوں نتائج لکھیں، کیونکہ دوبارہ آغاز میں قائم رہنا تبھی معنی رکھتا ہے جب آپ بتائیں کہ کون سی تہہ کس لمحے سے قائم رہی۔

واپسی کا راستہ توڑے بغیر خلا بند کریں

اگر بُوٹ پر بلاک نہیں ہے تو دوسرا کلائنٹ قاعدہ شامل کرنے کی بجائے نفاذ کو ایک تہہ نیچے لے جائیں۔ قواعد کا مجموعہ محفوظ کریں اور نیٹ ورک کے قابل استعمال ہونے سے پہلے ترتیب دیے گئے یونٹ سے اسے لوڈ کریں، اور یقینی بنائیں کہ اُس یونٹ کو ایسی DNS تلاش یا نیٹ ورک ماؤنٹ درکار نہیں جسے اسے بچانا ہے۔ دائرہ وقت جتنا ہی اہم ہے: صارف ID یا cgroup سے مماثل قواعد ہر نظام ڈیمان کو بلاک سے باہر رکھتے ہیں، اور صرف IPv4 سنبھالنے والا مجموعہ IPv6 اور DNS کو قابل رسائی رکھتا ہے۔

اپنے لیے واپسی کا راستہ چھوڑیں۔ جو مشین بُوٹ پر سب کچھ بلاک کرے اور پھر تصدیق نہ کر سکے اُس کے پاس نیٹ ورک ہی نہیں ہوتا، اور حل بلاک مٹانا نہیں بلکہ اسناد یا ترتیب درست کرنا ہے۔ مقامی کنسول کا دستاویزی طریقہ کار اور ٹنل کو واقعی جس چیز کی ضرورت ہے اُس کے لیے تنگ، دانستہ استثنا رکھیں، مثلاً سرور کا پتہ اور ٹنل سے پہلے استعمال ہونے والا حل کنندہ۔

اس انتظام پر بھروسہ کرنے سے پہلے چار چیزیں ترتیب سے تصدیق کریں۔ پالیسی وہاں محفوظ ہے جہاں سے بُوٹ پڑھتا ہے۔ وہ قاری انٹرفیس کے قابل استعمال ہونے سے پہلے چلتا ہے۔ بلاک دونوں ایڈریس خاندان اور DNS ڈھانپتا ہے۔ بلاک فعال ہونے کے دوران بھی VPN تصدیق کر سکتا ہے۔ جب چاروں موجود ہوں، دوبارہ آغاز کچھ نہیں بدلتا۔