دور دراز کے VPN کلائنٹ جڑتے ہیں، LAN سرور جواب دیتا ہے، اور جواب عام انٹرنیٹ راؤٹر سے باہر جا کر وہیں دم توڑ دیتا ہے۔ ایک سرور کو مستقل راستے سے درست کیا جا سکتا ہے، لیکن ان کا پورا ذیلی نیٹ ورک وہیں سنبھالنا بہتر ہے جہاں انہیں پہلے ہی اپنی نیٹ ورک ترتیب ملتی ہے۔ DHCPv4 کا اختیار 121 بالکل ایسا ہی منزل کا راستہ تقسیم کرتا ہے، اور یہی وہ حصہ ہے جس میں لوگ عام طور پر طے شدہ راستہ بھولتے ہی غلطی کرتے ہیں۔ علامت یک طرفہ ٹریفک ہے: درخواستیں آتی ہیں اور جوابات غائب ہو جاتے ہیں۔

پہلے تین پتوں کے نام لیں

ایک ٹھوس LAN لیں: 192.168.50.0/24، عام طے شدہ راؤٹر 192.168.50.1 پر اور الگ VPN گیٹ وے 192.168.50.2 پر۔ تصدیق شدہ دور دراز کلائنٹ 10.90.0.0/24 پر قابض ہوتے ہیں۔

ہر شریک میزبان کو درکار راستہ 10.90.0.0/24 via 192.168.50.2 ہے۔ منزل کلائنٹ پول ہے، اور اگلا قدم گیٹ وے کا LAN پتہ ہے، اس کا ٹنل پتہ نہیں۔

اسے بلا طبقہ مستقل راستے کے طور پر انکوڈ کریں

اختیار 121 سابقے اور اگلے قدم کے جوڑے لے کر چلتا ہے، اور RFC 3442 انکوڈنگ اور اس سے پیدا ہونے والا کلائنٹ رویہ دونوں متعین کرتا ہے۔ صرف اس مثالی LAN کی خدمت کرنے والے موجودہ dnsmasq کے لیے ترتیب کی شکل یہ ہے:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

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

طے شدہ راستہ نہ کھوئیں

یہی جال ہے۔ اختیار 121 حاصل کرنے والے کلائنٹ کو عام Router اختیار نظر انداز کرنا لازم ہے، اس لیے صرف VPN پول کا راستہ اعلان کرنا اس میزبان کو بالکل ہی طے شدہ راستے کے بغیر چھوڑ سکتا ہے. مشین اب بھی ترتیب شدہ دکھتی ہے اور خاموشی سے انٹرنیٹ کھو دیتی ہے۔ صارفین اسے نیٹ ورک ڈاؤن بتاتے ہیں جبکہ ہر انٹرفیس فعال ہوتا ہے۔

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

دیکھیں کلائنٹ کیا قبول کرے گا

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

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

لیز کی تصدیق کریں، پھر تلاش کی

DHCP کے مالک سے تبدیلی نافذ کرنے کو کہیں، پھر کلائنٹ پر لیز کی تجدید کریں۔ موجودہ لیز تجدید تک پرانی ترتیب رکھتی ہیں، اس لیے فوری نتائج کی ضمانت نہیں۔

Linux کلائنٹ پر اصل راستے پڑھیں اور دونوں اندراجوں کی تصدیق کریں:

ip -4 route
ip -4 route get 10.90.0.23

سیاق و سباق کی تلاش کو پول کا راستہ 192.168.50.2 کے ذریعے اور طے شدہ راستہ 192.168.50.1 کے ذریعے دکھانا چاہیے۔ اگر طے شدہ راستہ موجود نہ ہو تو آپ نے اوپر والا جال دہرا دیا ہے۔

پھر اصل تبادلے کی جانچ کریں

راستوں کی تقسیم پورا راستہ نہیں ہے۔ الگ گیٹ وے کو اب بھی فارورڈنگ، دور دراز ساتھیوں کی ملکیت اور سرور کی اجازت دینے والی رسائی پالیسی درکار ہے، اور DHCP کسی کی تصدیق نہیں کرتا۔

آخر میں، ہٹانے کا منصوبہ رکھیں۔ سیکھا گیا مستقل راستہ VPN کے گرنے پر خود واپس نہیں ہٹتا، اس لیے پرانا اگلا قدم سرنگ غائب ہونے کے بہت بعد تک اس سابقے کو سیاہ گڑھا بنا سکتا ہے۔

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