کیوں OpenVPN کلائنٹس گیٹ وے کے IPsec سلیکٹرز سے محروم رہتے ہیں

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

گیٹ وے کا ping ایسا بہاؤ جانچتا ہے جو آپ کا کلائنٹ کبھی استعمال نہیں کرتا

کون سی پالیسی لاگو ہوگی یہ ماخذ پتہ طے کرتا ہے۔ گیٹ وے پر بننے والا پیکٹ اپنے مقامی LAN یا سرنگ کے آخری سرے کے پتے کے ساتھ باہر جاتا ہے، اور جو پالیسی اس سے مماثل ہے وہ ٹھیک اسی صورت کے لیے لکھی گئی تھی۔ کلائنٹ کا پیکٹ OpenVPN انٹرفیس پر کلائنٹ پول کے پتے کے ساتھ آتا ہے، جو بالکل الگ سلیکٹر ہے۔

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

وہ دور دراز سابقہ دھکیں جس کی ایپلیکیشن کو واقعی ضرورت ہے

منسلک کلائنٹس کے لیے 10.8.0.0/24 اور محفوظ دور دراز نیٹ ورک کے لیے 172.30.239.0/25 کی یہ مثالی جوڑی لیں۔ کلائنٹ کو اسی دوسرے سابقے کا راستہ چاہیے، گیٹ وے کے LAN کا نہیں اور کسی دوسرے سرنگ پتے کا بھی نہیں۔ پول میں دھکیلا گیا راستہ ہی کلائنٹ کو وہ ٹریفک گیٹ وے کے حوالے کرنے پر مجبور کرتا ہے۔ اس کے بغیر پیکٹ کبھی اس پالیسی فیصلے تک نہیں پہنچتا جسے آپ ڈیبگ کر رہے ہیں۔

جس Community سرور میں دھکے گئے راستے قبول ہوتے ہیں، وہاں ہدایت اصل ماسک لیتی ہے: push "route 172.30.239.0 255.255.255.128"۔ Access Server وہی منزل نصب شدہ ورژن کی نجی نیٹ ورک یا رسائی قواعد کی ترتیبات کے ذریعے مرتب کرتا ہے، اور روٹڈ یا مترجم موڈ دانستہ طور پر چنا جاتا ہے۔ مالک ترتیب کی بجائے پیدا شدہ فائر وال زنجیریں تبدیل کرنا ہی وہ راستہ ہے جس سے کام کرتا سیٹ اپ دوبارہ پیدا کرنا ناممکن ہو جاتا ہے۔

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

سلیکٹرز میں کلائنٹ پول شامل کریں

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

مرتب شدہ تجاویز کے ساتھ طے شدہ پالیسی بھی دیکھیں، مثلاً strongSwan پر ipsec statusall یا آپ کے نفاذ کے لیے مساوی اسٹیٹس کمانڈ سے۔ پالیسی پر مبنی IPsec میں عام راستہ کسی طبعی انٹرفیس کی طرف اشارہ کر سکتا ہے جبکہ مماثل ٹریفک اب بھی خفیہ ہوتی ہے، لہٰذا سرنگ ڈیوائس کا نہ ہونا کچھ ثابت نہیں کرتا۔ سلیکٹر جوڑوں کا موازنہ اپنے لکھے ہوئے پول اور سابقے سے کریں۔

گیٹ وے پر عمومی ماخذ NAT بھی مماثلت توڑ سکتا ہے۔ اگر پالیسی جانچ سے پہلے masquerade قاعدہ کلائنٹ کے ماخذ کو دوبارہ لکھے تو پیکٹ آپ کے لکھے سلیکٹر جیسا نہیں رہتا۔ وسیع masquerade قاعدہ دوسرے VPN کے لیے خراب حل ہونے کی ایک وجہ یہ ہے: یہ بدلتا ہے کہ کون سی پالیسی لاگو ہوگی اور دور کا فریق کون سا پتہ ریکارڈ کرے گا۔ جس ٹریفک کو آپ روٹ کرنا چاہتے ہیں اسے استثنیٰ دیں، یا دانستہ طور پر اس کا ترجمہ کریں اور سلیکٹرز اپ ڈیٹ کریں۔

دانستہ طور پر راستہ بندی یا ترجمہ منتخب کریں

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

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

فارورڈنگ اور جواب پر حلقہ بند کریں

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

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

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