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

بدلی کو ایک نہیں، دو حوالگیاں سمجھیں اور کام کے دوران انتظامی انٹرفیس تک مقامی راستہ رکھیں۔

پلگ کھولنے سے پہلے حوالگی لکھیں

LAN سابقہ، سرور کا پتہ اور اس کی تفویض کا طریقہ، وہ سننے والا اور ترسیل جو VPN واقعی استعمال کرتا ہے، اسے شائع کرنے والا اندرونی قاعدہ اور وہ نام جو کلائنٹس نے محفوظ کیا درج کریں۔ پھر لکھیں کہ آج کون سی مشین متحرک DNS ریکارڈ کو اپ ڈیٹ کرتی ہے: یہ راؤٹر، سرور خود یا کسی اور ہوسٹ پر الگ ایجنٹ ہو سکتا ہے۔ یہ تب کریں جب پرانے انتظامی صفحات ابھی لوڈ ہو رہے ہوں۔ اندرونی قاعدے کا اسکرین شاٹ یاد رکھے گئے پورٹ نمبر سے بہتر ہے۔

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

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

پہلے پتہ منتقل کریں، پھر فارورڈ

اگر نیا راؤٹر وہی LAN سابقہ رکھتا ہے تو سرور کو اس کی سابقہ مختص کردہ جگہ یا اس کے مساوی مستقل تفویض دیں۔ اگر سابقہ بدل جائے تو پہلے سرور کا پتہ اور اس کا نام لینے والا ہر سننے والا بندھن اپ ڈیٹ کریں، کیونکہ پرانے پتے کی طرف اشارہ کرنے والا فارورڈ ٹریفک کو خاموشی سے کہیں نہیں بھیجے گا۔

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

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

فیصلہ کریں کہ عوامی نام کون اپ ڈیٹ کرے گا

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

جب تعیناتی پتوں کے دونوں خاندان شائع کرتی ہے تو A اور AAAA دونوں ریکارڈ پڑھیں۔ ہر ایک کو ایسی خدمت کی طرف اشارہ کرنا ہے جو واقعی سن رہی ہو اور اپنی فائر وال راہ سے اجازت یافتہ ہو، اور چلتی ہوئی IPv4 نقشہ بندی IPv6 پہلو کے بارے میں کچھ نہیں کہتی۔ کلائنٹ پروفائل میں شناخت کی جانچ بھی رکھیں: بدلا ہوا عوامی پتہ ایسے سرٹیفکیٹ یا ہم منصب کلید کو قبول کرنے کی وجہ نہیں جو مطابقت نہ رکھتی ہو۔

باہر سے بدلی ثابت کریں

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

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

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

نئی نقشہ بندی اپنی بازیابی نوٹس کے ساتھ رکھیں

حتمی سرور تفویض، اندرونی قاعدہ اور اپ ڈیٹ مالک کا نام مقامی طور پر راؤٹر تک پہنچنے کی کارروائی کے ساتھ محفوظ کریں۔ اگلی بدلی traceroute سے نہیں، اسی صفحے سے شروع ہونی چاہیے۔

اگر اوپر کے سب کے بعد بھی سرنگ باہر سے ناکام ہو تو دیکھیں کہ راؤٹر جو عوامی پتہ بتاتا ہے وہ کلائنٹس کے حل کردہ پتے سے میل کھاتا ہے یا نہیں۔ وہی ایک موازنہ DNS مسئلے کو فارورڈنگ مسئلے سے الگ کرتا ہے، اور دوسری پورٹ فارورڈنگ رہنما پڑھنے سے کم وقت لیتا ہے۔

متعلقہ مضامین