آپ کے LAN سے متصادم VPN پول کو کوئی راستہ درست نہیں کرتا

ایپ کہتی ہے کہ ٹنل صحت مند ہے، پھر بھی جن منزلوں کی آپ کو ضرورت ہے ان میں سے آدھی کبھی جواب نہیں دیتیں۔ پہلا ردِعمل راستہ شامل کرنا یا میٹرک کم کرنا ہے، اور یہی ردِعمل وہ افسانہ ہے جسے پہلے مارنا چاہیے۔ جب کلائنٹ کا اپنا LAN اور ٹنل کا پول ایک ہی سابقہ کا دعویٰ کرتے ہیں، روٹنگ جدول دو متضاد حقائق تھامے رکھتا ہے، اور نہ ڈیفالٹ راستہ نہ میٹرک انہیں حل کرتا ہے۔ درستی پتوں کے تعین کا فیصلہ ہے، اور راستوں کی تدوین اس کا متبادل نہیں بن سکتی۔

اضافی راستہ ایک سابقہ کیوں تقسیم نہیں کر سکتا

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

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

سسٹم سے ایک پتے کے بارے میں پوچھیں اور دیکھیں کہ کون سا انٹرفیس بتاتا ہے۔ Linux، macOS اور Windows ہر ایک صرف پڑھنے والی تلاش سے جواب دیتے ہیں، جو کچھ بھی بھیجے بغیر منتخب انٹرفیس اور اگلا ہاپ بتاتی ہے۔ جب ٹنل کے قائم ہونے پر جواب جسمانی اڈاپٹر کی طرف اشارہ کرے، کرنل پتے کو ٹنل کے اٹھا سکنے والی چیز نہیں، لنک پر موجود سمجھتا ہے۔

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

وہ پول پڑھیں جو کلائنٹ کو واقعی ملا

وہ پڑھیں جو کلائنٹ کو ملا، فراہم کنندہ کا مارکیٹنگ صفحہ نہیں۔ OpenVPN کلائنٹ کے لاگ کی تفصیل بڑھائیں تو سرور کے دھکیلے راستے اس میں نظر آئیں گے، جو ٹنل کے سابقے کھولتے ہیں؛ دیگر جگہوں پر پول کنکشن کی تفصیلات میں یا خود اڈاپٹر پر نظر آتا ہے۔ فراہم کنندہ سے اس کے استعمال کردہ تمام نجی حدود کی مکمل فہرست مانگیں، کیونکہ آج کا ایک /24 کل دو ہو سکتا ہے۔ عام RFC 1918 بلاکس سے بچنا اس مختص سے بچنے کے برابر نہیں جو واقعی آپ کو دیا گیا ہے۔

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

دوبارہ نمبر دینا ہی وہ درستی ہے جو آپ کر سکتے ہیں

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

1. پہلے فہرست: روٹر کا اپنا پتہ، DHCP حد، محفوظات، پورٹ فارورڈنگ، اور ہر وہ آلہ جس کا پتہ ہاتھ سے لکھا گیا ہے۔
2. پھر دیکھ بھال کی ونڈو کے اندر روٹر کا LAN سابقہ اور DHCP حد ایک ساتھ بدلیں، اور تار والے لیز بے تار سے پہلے تجدید کریں۔
3. اس کے بعد مستقل پتے درست کریں: پرنٹر، نیٹ ورک اسٹوریج، اور ہر وہ چیز جس کا گیٹ وے سختی سے لکھا ہو۔
4. آخر میں، VPN کلائنٹ دوبارہ جوڑیں اور تصدیق کریں کہ ٹنل کا پتہ اب LAN سے نہیں ٹکراتا۔

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

عرف کیا کر سکتا ہے اور کیا نہیں

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

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

جن سابقوں پر آپ متفق ہوئے انہیں وہاں لکھیں جہاں لوگ واقعی دیکھتے ہیں: نیٹ ورک نوٹس، روٹر کا اپنا تبصرہ خانہ، تعارف کا صفحہ۔ کوئی پھر 192.168.1.0/24 منتخب کرے گا، اور تصادم اس کے ساتھ واپس آئے گا۔