VPN کلائنٹ موڈ میں روٹر: LAN ڈیوائسز کیوں غائب ہو جاتی ہیں
روٹر کے VPN کلائنٹ موڈ میں جانے کے بعد LAN ڈیوائسز غائب ہو جاتی ہیں: پہلے فارورڈ راستے کی جانچ کی خصوصیت، پھر وہ LAN رینج آزمائیں جو فرم ویئر نے آپ کے نیچے بدلی۔
یہ عقیدہ کہ کلائنٹ موڈ خود LAN رسائی کو ختم کر دیتا ہے، لوگوں کو غلط سیٹنگز مینو میں بھیجتا ہے، اور اصل وجوہات عام طور پر دو ہوتی ہیں۔ ٹنل LAN پل کو نہیں ہٹاتا اور نہ وائرڈ و وائرلیس کلائنٹس کو ایک دوسرے تک پہنچنے سے روکتا ہے۔ مقامی رسائی کو یا تو روٹر کے فارورڈ راستے میں بیٹھی جانچ کی خصوصیت توڑتی ہے، یا وہ LAN پتہ رینج جو فرم ویئر بدلنے پر کھسک گئی۔ دونوں ایک ہی شکایت پیدا کرتے ہیں، اور VPN پروفائل دوبارہ انسٹال کرنے سے کوئی بھی ٹھیک نہیں ہوتا۔
افسانہ، اور کلائنٹ موڈ واقعی کیا بدلتا ہے
کلائنٹ موڈ ایک ٹنل انٹرفیس اور اس سے گزرنے والا ڈیفالٹ راستہ شامل کرتا ہے، پھر LAN ٹریفک کو اس ٹنل میں فارورڈ کرتا ہے۔ وائرڈ پورٹس اور وائرلیس ریڈیوز کے درمیان پل برقرار رہتا ہے، اور مقامی سوئچنگ بھی۔ جو بدلتا ہے وہ پالیسی ہے: کون سی ٹریفک فارورڈ ہوتی ہے، کہاں اس کا ترجمہ ہوتا ہے اور کلائنٹس کو کون سا حل کنندہ ملتا ہے۔
یہ فرق اہم ہے کیونکہ خراب LAN کا عام مطلب یہ ہوتا ہے کہ ان تین پالیسیوں میں سے ایک بدلی ہے، یہ نہیں کہ روٹر سوئچ رہنا چھوڑ گیا۔ جو روٹر اب بھی اپنے انتظامی صفحے کا جواب دیتا ہے وہ LAN انٹرفیس کے زندہ ہونے کا ثبوت ہے۔ جو روٹر کسی چیز کا جواب نہیں دیتا اس کا کوئی اور مسئلہ ہے، جیسے بدلا ہوا LAN پتہ یا غلط سب نیٹ پر کلائنٹ۔
اس لیے مفید پہلا قدم یہ جاننا ہے کہ کون سی تہہ ٹوٹی، نہ کہ اس تہہ کو بدلنا جس پر آپ کو شک ہے۔
کسی سیٹنگ کو چھونے سے پہلے تین ہدف آزمائیں
وائرڈ کلائنٹ سے تین ہدف الگ الگ آزمائیں اور ہر نتیجہ لکھیں: روٹر کا اپنا LAN پتہ، اسی سوئچ پر دوسری ڈیوائس IP کے حساب سے، اور کوئی چیز جو صرف ٹنل سے پہنچ سکے۔ یہ اسی ترتیب سے کریں، کیونکہ ہر نتیجہ الگ تہہ کو خارج کرتا ہے۔ پہلے دور میں ناموں کی بجائے پتے استعمال کریں، کیونکہ نام کی ناکامی DNS کو کنیکٹیویٹی کے سوال میں ملا دیتی ہے۔
جوابات کا نمونہ ہی تشخیص ہے۔ مقامی ڈیوائسز جواب نہ دیں مگر روٹر جواب دے تو یہ روٹنگ کی بجائے مقامی سوئچنگ یا فلٹرنگ خصوصیت کی طرف اشارہ کرتا ہے۔ ٹنل کی طرف جواب نہ دے مگر مقامی ڈیوائسز جواب دیں تو یہ ٹنل راستے یا دور دراز فائر وال کی طرف اشارہ کرتا ہے۔ پتوں سے سب جواب دیں مگر نام ناکام ہوں تو یہ حل کنندہ کا سوال ہے، اور راستے کی تدوین اسے ٹھیک نہیں کرے گی۔
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
ٹیسٹ نتائج کے پاس جدول رکھیں۔ یہ مبہم شکایت کو ایک ایسی سطر میں بدلتا ہے جس پر آپ عمل کر سکیں۔
فارورڈ راستے کے اندر حفاظتی تہہ
صارفین کے روٹروں میں فارورڈ ہونے والی ٹریفک کی نگرانی کرنے والی جانچ کی خصوصیت عام ہو رہی ہے، اور یہ اسی راستے میں چلتی ہے جو LAN سے ٹنل تک پیکٹ لے کر جاتا ہے۔ جب وہ جانچ ٹنل ٹریفک کی درجہ بندی نہیں کر سکتی، تو ٹنل خود چلتا رہتا ہے اور روٹر صحت مند کنکشن کی اطلاع دیتا ہے مگر فارورڈنگ رک سکتی ہے۔ VPN لاگ میں یہ نظر نہیں آتا، کیونکہ VPN واقعی جڑا تھا۔
تشخیص ایک کنٹرول شدہ تجربہ ہے، مستقل تبدیلی نہیں۔ موجودہ سیٹنگ نوٹ کریں، ایک ٹیسٹ کی مدت کے لیے خصوصیت بند کریں، ٹنل دوبارہ چلائیں اور پتے سے ایک مقامی ہوسٹ آزمائیں۔ واپس آنے والی فارورڈنگ ہی وہ ثبوت ہے جو آپ کو درکار تھا، اور پھر سودا اندازے کی بجائے فیصلہ بن جاتا ہے۔ کچھ نہ بدلے تو فوراً دوبارہ آن کریں اور پتہ کے سبب کی طرف جائیں۔
ٹنل کے چلنے کے لیے ادائیگی والی حفاظتی خصوصیت بند چھوڑنا ایسا سودا ہے جو سوچ سمجھ کر کرنا اور لکھنا چاہیے۔ یہ بھی پوچھنے کے قابل ہے کہ کیا ٹنل کسی اور ڈیوائس پر ہونا چاہیے، کیونکہ سب کچھ جانچنے والا روٹر اور سب کچھ فارورڈ کرنے والا روٹر دو مختلف کام ہیں۔
دوسرا سبب: LAN رینج کھسک گئی
فرم ویئر اپ ڈیٹ باقاعدگی سے LAN پتہ کارخانہ دار کے ڈیفالٹ پر واپس لاتے ہیں، اور کچھ روٹروں میں واضح موڈ سوئچ ہوتا ہے جو طے کرتا ہے کہ LAN نجی رینج رکھے گا یا اوپر والی ڈیوائس سے ورثے میں لے گا۔ جو کلائنٹ 192.168.8.x کی توقع کرتا ہے وہ 10.64.0.x پر آ سکتا ہے، اور پھر ٹنل بالکل صحت مند ہونے کے باوجود ہوسٹ تک SSH سیشن کی مدت ختم ہو جاتی ہے۔
ipconfig /all
ip addr show
ip route get 192.168.8.20روٹر صفحہ کھولنے سے پہلے لیز سے سابقہ اور گیٹ وے پڑھیں۔ پہلی دو کمانڈیں دکھاتی ہیں کہ کلائنٹ کو واقعی کیا ملا، اور تیسری دکھاتی ہے کہ مقامی پتے کے لیے کلائنٹ کون سا انٹرفیس استعمال کرے گا، اور اسی طرح باقی راستہ یا پرانا سب نیٹ خود کو ظاہر کرتا ہے۔ پھر اس کا موازنہ LAN صفحہ اور روٹر کے موڈ سے کریں۔
اگر رینج واپس نہ آ سکے تو ہر اس چیز کو اپ ڈیٹ کریں جو اس کا نام لیتی ہے: DHCP ریزرویشن، پرانے سب نیٹ کی طرف کوئی بھی مستقل راستہ، اور ہر فائر وال قاعدہ جو پچھلا سابقہ رکھتا ہے۔ ٹنل کے دور دراز سب نیٹ سے ٹکرانے والی رینج بدتر قسم ہے، کیونکہ مقامی ڈیوائسز قابل رسائی رہتی ہیں جبکہ دور دراز منزلیں خاموشی سے LAN میں غلط بھیجی جاتی ہیں۔
دوبارہ جڑیں اور پیکٹ ترتیب سے دوبارہ آزمائیں
دو تبدیلیوں میں سے کسی کے بعد ٹنل دوبارہ جوڑیں اور ٹیسٹ پیکٹ ترتیب سے دہرائیں: روٹر، مقامی ہوسٹ، دور دراز ہوسٹ، پھر نام، پھر ایپلیکیشن۔ پہلے ایپلیکیشن جانچنے سے چھپ جاتا ہے کہ کون سی تہہ اب بھی ٹوٹی ہے، اور کیش شدہ نام پر براؤزر کی دوبارہ کوشش روٹنگ ناکامی جیسی لگ سکتی ہے۔
VPN پروفائل کے پاس فرم ویئر ورژن، LAN سابقہ اور جانچ کی خصوصیت کی حالت لکھیں۔ تینوں ایسی ترتیب ہیں جنہیں اگلا اپ ڈیٹ اوور رائٹ کر سکتا ہے، اور دو سطروں کے نوٹس ابھی گزاری گئی گھنٹی بچاتے ہیں۔