VPN تبدیلی کے بعد راؤٹر کا ایڈمن جواب دینا کیوں بند کر دیتا ہے

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

سب سے پہلے مارنے کے قابل یہ افسانہ ہے: چلتی سرنگ اندر واپس جانے کا راستہ نہیں ہے۔ یہ اپنے بھروسے کے سوالات والا نیا نیٹ ورک کنکشن ہے، اور یہ آپ کا پرانا انتظامی راستہ خاموشی سے ہٹا سکتی ہے جبکہ ایسا نیا راستہ کھولتی ہے جسے کسی نے نہیں دیکھا۔

سرنگ کبھی انتظامی راستہ نہیں تھی

فارورڈنگ اور ان پٹ الگ کام ہیں۔ "کیا کوئی کلائنٹ سرنگ کے ذریعے NAS تک پہنچ سکتا ہے؟" یہ راؤٹر سے گزرنے والے پیکٹوں کے بارے میں فارورڈنگ سوال ہے۔ "کیا میں راؤٹر کا SSH پورٹ کھول سکتا ہوں؟" یہ راؤٹر کو ہی مخاطب پیکٹوں کے بارے میں ان پٹ سوال ہے۔ فارورڈ شدہ ٹریفک کے لیے لکھا گیا اجازت کا اصول دوسرے سوال کے لیے کچھ نہیں کرتا، اور یہی سب سے عام وجہ ہے کہ ٹریفک بخوبی لے جانے والی سرنگ بھی آپ کا ایڈمن سیشن مسترد کر دیتی ہے۔

اُلٹی غلطی انٹرفیس کے نام پر بھروسا کرنا ہے۔ سرنگ ساتھی تک خفیہ کی جاتی ہے، اُس کے پیچھے کی ہر سروس تک نہیں، اور انٹرفیس لیبل میں VPN کا لفظ اس بارے میں کچھ نہیں کہتا کہ کن ذرائع کو لاگ اِن کرنے کی اجازت ہونی چاہیے۔

پہلی تہہ: کیا راؤٹر کے اپنے پتے تک راستہ ہے؟

کلائنٹ پر شروع کریں اور کرنل سے پوچھیں کہ پیکٹ کہاں جائے گا۔ Linux پر ip route get 10.6.0.1 منتخب راستہ، خارج ہونے والا انٹرفیس اور ماخذ پتہ چھاپتا ہے۔ اگر یہ آپ کے ISP کی طرف ڈیفالٹ راستہ بتائے، تو پیکٹ کبھی سرنگ میں داخل نہیں ہوتا، اور راؤٹر کا کوئی اصول اِسے بچا نہیں سکتا۔

سرنگ کی طرف سوال کا اپنا نسخہ ہے۔ WireGuard AllowedIPs کو کرپٹو کی راؤٹنگ جدول سمجھتا ہے: ہر سرے پر یہ اعلان کرتا ہے کہ ساتھی کون سے ماخذ پتے استعمال کر سکتا ہے اور کون سے منزل اُس ساتھی کو بھیجے جاتے ہیں۔ اگر کلائنٹ اندراج میں راؤٹر کا سرنگ پتہ شامل نہ ہو، تو کلائنٹ کا وہاں کوئی راستہ نہیں۔ اگر اُس کلائنٹ کے لیے سرور اندراج کلائنٹ کا سرنگ پتہ نہ ڈھکے، تو سرور کوئی بھی فائر وال اصول دیکھنے سے پہلے پیکٹ پھینک دیتا ہے۔

پالیسی ڈیبگ کرنے سے پہلے اُس درست پتے کی تصدیق کریں جہاں پہنچنا چاہتے ہیں۔ پرانا DNS ریکارڈ یا تبدیلی سے پہلے کا کیش شدہ ہمسایہ اندراج آپ کو ایسے پتے پر بھیجتا ہے جو راؤٹر کے پاس کبھی نہیں تھا۔

دوسری تہہ: ان پٹ پالیسی، فارورڈنگ پالیسی نہیں

فائر وال اصولوں کا جائزہ اُس انٹرفیس پر لگاتے ہیں جہاں پیکٹ آتا ہے۔ pfSense اور OPNsense میں انٹرفیس ٹیب اور اصولوں کی ترتیب طے کرتی ہے کہ فائر وال کی اپنی سروسز کی طرف ٹریفک کی اجازت ہے یا نہیں؛ وہ اصول جو LAN کلائنٹوں کو انٹرنیٹ پر جانے دیتا ہے وہ اصول نہیں جو سرنگ کے ساتھی کو ویب GUI کھولنے دیتا ہے۔ firewall4 والے OpenWrt میں ہر زون ان پٹ پالیسی رکھتا ہے، option input 'ACCEPT' یا 'REJECT'، اور جس زون کا ان پٹ REJECT ہو اُس میں سرنگ انٹرفیس انتظامی کنکشن مسترد کرتا ہے، تاہم اگر فارورڈنگ کی اجازت ہو تو ٹریفک اب بھی فارورڈ کرتا ہے۔

نیا راستہ چلانے کے لیے اینٹی لاک آؤٹ اصول بند نہ کریں۔ وہ اصول کسی خراب اصول کو LAN کے انتظامی پتے پر تالا لگانے سے روکتا ہے؛ یہ LAN سب نیٹ کی حفاظت کرتا ہے، ابھی بنائی گئی سرنگ سب نیٹ کی نہیں۔ منتظم کے ماخذ کے لیے ایک تنگ اصول شامل کریں اور حفاظتی جال کو کچھ نہ کہیں۔ pfSense کی ایڈمن رسائی کی دستاویز بتاتی ہے کہ وہ کنٹرول کہاں ہیں۔

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

تیسری تہہ: کیا اُس پتے پر کچھ سن رہا ہے؟

سروس چل رہی ہو اور پھر بھی ناقابل رسائی ہو کیونکہ وہ ایک ہی پتے سے بندھی ہے۔ OpenWrt کا uhttpd /etc/config/uhttpd میں واضح سماعت اندراجات رکھتا ہے، مثلاً list listen_http '0.0.0.0:80'؛ جو بلڈ صرف LAN پتے سے بندھا ہو وہ سرنگ پتے پر کچھ قبول نہیں کرتا، اور سماعت انٹرفیس کی ترتیب دکھانے والی مصنوعات بھی ویسا ہی برتاؤ کرتی ہیں۔ اوپر کی سماعت کمانڈز اِس کا براہِ راست جواب دیتی ہیں۔

پھر انکار کو خاموشی سے الگ کریں۔ nc -vz 10.6.0.1 443 کا مسترد کنکشن واپس کرنا مطلب پیکٹ راؤٹر تک پہنچا اور کسی نے اُسے مسترد کیا، یا بند پورٹ یا واضح مسترد اصول۔ ٹائم آؤٹ تک لٹکنا مطلب پیکٹ پھینکا گیا یا کبھی روٹ ہی نہیں ہوا۔ یہ فرق بتاتا ہے کہ آگے کون سی تہہ دیکھنی ہے، اور اِس میں پانچ سیکنڈ لگتے ہیں۔

VPN انٹرفیس ایک حد ہے، بحالی کا راستہ نہیں

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

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

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

نئے کنکشن سے بھی جانچیں۔ حالت رکھنے والا فائر وال موجودہ بہاؤ اپنی حالت جدول میں رکھتا ہے، اس لیے آپ کا پہلے سے کھلا SSH سیشن ایسی تبدیلی سے بچ سکتا ہے جو ہر نئے کنکشن کو روکتی ہے۔ اسی طرح لاک آؤٹ اگلی ری بوٹ یا لیپ ٹاپ کی اگلی نیند تک پوشیدہ رہتا ہے۔

پالیسی کو چھونے سے پہلے واپسی کا راستہ تیار کریں

پہلی تبدیلی سے پہلے چار چیزیں لکھیں: اگر سرنگ مر جائے تو آپ ڈیوائس تک کیسے پہنچیں گے، جیسے سیریل کنسول، فراہم کنندہ کا کنسول یا LAN میں کوئی مشین؛ موجودہ ترتیب کہاں برآمد ہوتی ہے؛ آپ کون سا ایک اصول یا راستہ بدلنے والے ہیں؛ اور اُس چیز کو ٹھیک ٹھیک کیسے واپس لائیں گے۔ OpenWrt پر sysupgrade -b /tmp/backup.tar.gz ترتیب پکڑتا ہے، اور تبدیلیاں uci commit تک زیرِ التوا رہتی ہیں، جو وقت پر دھیان دینے پر سستا پلٹاؤ دیتا ہے۔ pfSense ترتیب کی تاریخ رکھتا ہے، اور AutoConfigBackup صرف اُس وقت مدد کرتا ہے جب وہ پہلے سے فعال ہو۔ اگر راؤٹر fail-closed اصولوں کا مجموعہ چلاتا ہے، تو یقینی بنائیں کہ آپ کا منصوبہ بند دیکھ بھال کا راستہ اُس اصول کے روکے ہوئے ٹریفک کے اندر نہیں، اور یاد رکھیں کہ ری بوٹ مستقل اصولوں کو مٹانے کی بجائے دوبارہ لاگو کرتا ہے۔

ہر کوشش میں ایک حد بدلیں، پھر کھولے رکھے شیل کی بجائے نئے کنکشن سے جانچیں۔ اگر جانچ ناکام ہو تو اگلی تہہ چھونے سے پہلے وہی ایک تبدیلی واپس لیں۔ سرنگ پورے وقت اوپر رہ سکتی ہے، لیکن اُس کی سبز حالت کا نشان ثبوت نہیں کہ آپ اب بھی اندر جا سکتے ہیں۔

رخصت ہونے سے پہلے فوری جانچ:

• کیا آپ ایسے ماخذ سے راؤٹر تک پہنچ سکتے ہیں جو ابھی ترمیم شدہ اصول پر منحصر نہیں؟
• کیا سرنگ انٹرفیس کی ان پٹ پالیسی صرف منتظم کے ماخذ کو اجازت دیتی ہے؟
• کیا انتظامی سروس اُس پتے سے بندھی ہے جو سرنگ پر موجود ہے؟
• کیا آپ نے ایک مسترد ساتھی اور ایک نیا سیشن جانچا ہے؟
• کیا WAN انتظامی سطح اب بھی بند ہے؟