Access Server میں گیٹ وے صارف: کلائنٹ کی برانچ LAN کی روٹنگ

آپ OpenVPN کلائنٹ کے ٹنل پتے کو ping کر سکتے ہیں اور پھر بھی اس کے پیچھے LAN پر کسی میزبان تک نہیں پہنچ سکتے۔ Access Server کلائنٹ کو VPN پول سے پتہ دیتا ہے، اور پول کا پتہ ہی وہ واحد چیز ہے جو سرور اپنی سمجھتا ہے۔ برانچ کا سابقہ الگ حقیقت ہے جس کا اعلان کرنا ضروری ہے، اور اس کے بعد بھی برانچ کو بھیجنے والا اور مرکزی دفتر کو واپسی راستہ درکار ہے۔ غلط جگہ لکھا راستہ کچھ نہیں بدلتا۔

دو پتے، دو ملکیت کے دعوے

جب کلائنٹ جڑتا ہے تو Access Server اسے ترتیب شدہ VPN پول سے پتہ دیتا ہے، مثلاً 10.90.0.0/24۔ یہ تقسیم ایک میزبان کے لیے کرایہ ہے۔ کنکشن میں کچھ نہیں کہتا کہ وہی کلائنٹ 10.60.0.0/24 کے سامنے بھی ہے، اور سرور اندازہ نہیں لگائے گا: LAN سابقہ صرف اسی صورت میں مخصوص کلائنٹ کے ذریعے قابل رسائی ہے جب منتظم اعلان کرے۔

اسی لیے دوسری مشین پر جامد راستہ کام نہیں کرتا۔ راستہ کہتا ہے 10.60.0.0/24 کو اس پتے پر بھیجو، لیکن اگر پتہ اس کلائنٹ کا ہے جسے کبھی گیٹ وے کے طور پر نشان زد نہیں کیا گیا، تو سرور کے پاس وہ پیکٹ وہاں پہنچانے کی وجہ نہیں، اور کلائنٹ کا اسٹیک انہیں پھینک سکتا ہے۔ اعلان اور راستہ ایک ہی طریقہ کار کے دو نصف ہیں۔

گیٹ وے ترتیب کیا نصب کرتی ہے

Admin Web UI میں اعلان صارف کی خصوصیت ہے: connector صارف پر Configure VPN gateway فعال کریں اور اصل سابقہ Network on the VPN client side میں درج کریں۔ وہ صارف بھی دوسروں کی طرح تصدیق ہوتا ہے، اس لیے بغیر نگرانی والے آلے کے لیے موزوں اسناد کی پالیسی درکار ہے۔

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

تیار کردہ فائل میں چسپاں Community طرز کی ہدایت اس ماڈل میں شامل نہیں ہوتی۔ پروڈکٹ اپنے بھیجے گئے روٹنگ ٹیبل کی مالک ہے؛ ہاتھ سے ترمیم شدہ سطر نظر انداز ہوتی ہے۔

دونوں نیٹ ورکس کے واپسی راستے مکمل کریں

منصوبہ: مرکزی دفتر 10.40.0.0/24، برانچ 10.60.0.0/24، VPN پول 10.90.0.0/24، اور Access Server نجی پتے پر۔ روٹر کو برانچ سابقے اور پول کے راستے درکار ہیں۔ ان کے بغیر جواب ڈیفالٹ گیٹ وے سے نکلتا ہے، جس سے آدھا کھلا کنکشن بنتا ہے۔

برانچ میں connector کو وہ پیکٹ آگے بھیجنے ہوں گے جو اسے مخاطب نہیں: OS میں IP فارورڈنگ اور ٹنل و LAN انٹرفیس تک محدود اجازت؛ Linux پر net.ipv4.ip_forward=1 فارورڈ چین قواعد کے ساتھ، Windows پر routing and remote access۔ پھر میزبانوں کو واپسی راستہ درکار ہے: connector ان کا ڈیفالٹ گیٹ وے، یا موجودہ گیٹ وے خاص راستے رکھتا ہے۔

connector کا روٹنگ ٹیبل برانچ LAN کے ہر میزبان کو دوبارہ ترتیب نہیں دیتا۔ اگر میزبان کسی دوسرے روٹر کی طرف اشارہ کریں تو واپسی راستے وہیں ہیں، اور اسے ماننا ہوگا کہ نظر آنے والا ماخذ پتہ مقامی سب نیٹ کا پڑوسی نہیں۔

ناکامی کو راستہ سمجھیں

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

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

دو ڈیزائن زیادہ چاہتے ہیں۔ اوور لیپنگ سابقے منزل کو مبہم کرتے ہیں اور دوبارہ نمبر یا ترجمہ درکار ہے؛ کلسٹر Access Server میں ہر نوڈ کا connector تک کام کرنے والا راستہ ہونا چاہیے۔ تبدیلیاں معمول کے محفوظ کرنے کے راستے سے لاگو کریں، connector دوبارہ جوڑیں اور دونوں طرف سے تصدیق کریں۔

Access Server کا site-to-site ٹیوٹوریل وہی ترتیبات پروڈکٹ کی ترتیب سے دیتا ہے۔