pfSense OpenVPN: دوسرے راؤٹر کے پیچھے موجود نیٹ ورک تک پہنچنا

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

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

ایک پیکٹ، تین روٹنگ فیصلے

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

ان میں سے کسی ایک کی ناکامی وہی صارف رپورٹ دیتی ہے۔ اسی لیے ڈیبگنگ کی ترتیب اوزاروں سے زیادہ اہم ہے۔

کلائنٹ کو سابقہ دیں، اندازہ نہیں

IPv4 سرنگ نیٹ ورک /30 سے بڑا ہونے والے pfSense SSL/TLS سرور پر، IPv4 Local network(s) فیلڈ جڑنے کے وقت کلائنٹس کو راستے تقسیم کرتی ہے۔ کلائنٹ خود کوئی بنا لے گا اس بھروسے کی بجائے نیچے والا سابقہ وہاں شامل کریں۔ پھر جڑنے کے بعد کلائنٹ کا اصل جدول پڑھیں، کیونکہ route-nopull والی پروفائل یا راستہ فلٹر سرور کی بھیجی ہوئی چیز کو نظرانداز کر سکتے ہیں۔ سرور مکمل طور پر درست ہو سکتا ہے جبکہ کلائنٹ کچھ بھی انسٹال نہ کرے۔

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

pfSense کو اندرونی راؤٹر کی طرف موڑیں

pfSense میں جامد راستے کو متعین اور قابلِ رسائی گیٹ وے درکار ہے، اور اس گیٹ وے کے لیے منتخب انٹرفیس وہی ہونا چاہیے جو واقعی وہاں پہنچتا ہے، جیسا کہ Netgate کی جامد راستوں کی رہنما بیان کرتی ہے۔ ایک مثال ترتیب میں ٹرانزٹ لنک فائر وال پر 192.168.77.1 اور اندرونی راؤٹر پر 192.168.77.2 ہے، اور سروس نیٹ ورک اس کے پیچھے 172.16.30.0/25 پر ہے۔ پھر راستہ سابقے اور اگلے ہاپ کا نام دیتا ہے، سروس کے پتے کا نہیں۔ دور دراز نیٹ ورک کا پتہ گیٹ وے کے طور پر استعمال کرنا ایسا راستہ بنانے کا عام طریقہ ہے جو درست دکھائی دیتا ہے اور کہیں فارورڈ نہیں کرتا۔

انٹرفیس کو نام دینا اس کے پیچھے موجود نیٹ ورک کی وضاحت نہیں کرتا۔ جامد راستہ ہی وہ وضاحت ہے۔

دور دراز جانب کو پول معلوم ہونا چاہیے

نیچے والے راؤٹر کو پول کے لیے واپسی کا راستہ درکار ہے، اس مثال میں 192.168.77.1 کے ذریعے 10.55.0.0/24، جب تک کوئی ڈیفالٹ راستہ یا متحرک پروٹوکول پہلے سے ایک نہ دے۔ سروس ہوسٹ کا اپنا گیٹ وے اسی راؤٹر کی طرف جانا چاہیے، جو عام طور پر درست ہوتا ہے جب راؤٹر اس کا ڈیفالٹ گیٹ وے ہو اور غلط ہوتا ہے جب ہوسٹ ہاتھ سے ترتیب دیا گیا ہو۔ فائر وال پر پالیسی روٹنگ بھی مخصوص ٹریفک کے لیے جدول کو نظرانداز کر سکتی ہے، اس لیے یہ نتیجہ اخذ کرنے سے پہلے کہ راستہ غلط ہے، جانچیں کہ کوئی قاعدہ مختلف گیٹ وے منتخب کرتا ہے یا نہیں۔

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

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

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