OPNsense کے پیچھے OpenVPN کلائنٹس کے مستقل پتے

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

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

چپکنے والا لیز مستقل پتہ نہیں ہے

pool فائل پتہ-سے-کلائنٹ نقشے لکھتی ہے اور جب کوئی معلوم کلائنٹ دوبارہ جڑتا ہے تو وہ واپس دیتی ہے۔ یہ سہولت ہے، معاہدہ نہیں: فائل دوبارہ بنائی جا سکتی ہے، کلائنٹ کی شناخت بدلنے پر نقشہ غائب ہو جاتا ہے، اور ایک ہی pool بانٹنے والے دو سرور اس پر متفق نہیں ہوں گے۔ کلائنٹ کے لیے مخصوص override مختلف طریقے سے کام کرتا ہے، کیونکہ پتہ تاریخ سے نہیں، ترتیبات سے آتا ہے۔ یہ آلے کے دوبارہ آغاز اور دوبارہ تنصیب کو بھی برداشت کرتا ہے، بشرطیکہ override باقی ترتیبات کے ساتھ بیک اپ ہو۔

متحرک متبادل، یعنی client-connect اسکرپٹ اور متحرک اپ ڈیٹس کے ذریعے VPN کو DNS سے جوڑنا، کام کرتا ہے اور ایسا resolver چاہتا ہے جو اپ ڈیٹس قبول کرے، ساتھ ہر کنکشن پر اسکرپٹ۔ آلے پر آپ وینڈر کے فراہم کردہ پیکجوں تک محدود ہیں، اور عام طور پر وہیں وہ منصوبہ رک جاتا ہے۔

وہ /30 حساب جس سے کوئی لطف نہیں اٹھاتا

طے شدہ net30 ٹوپولوجی میں ہر کلائنٹ کو اپنا /30 ملتا ہے: پہلا قابل استعمال پتہ سرور کی طرف جاتا ہے، دوسرا کلائنٹ کو۔ اس لیے override سرور کے متحرک ٹنل نیٹ ورک سے باہر ہونے چاہئیں، جس کا مطلب ہے کہ پہلے وہ نیٹ ورک وسیع کیا جائے۔ 10.8.0.0/24 پر سرور 10.8.0.0/23 پر جا سکتا ہے، پرانی حد کا آدھا حصہ متحرک کلائنٹس کے لیے اور دوسرا آدھا override کے لیے چھوڑ کر۔ اصل /24 کو اضافی IPv4 مقامی نیٹ ورک کے طور پر شامل کریں تاکہ دونوں حصوں کی ٹریفک ٹنل میں روٹ ہو۔

ہر override پتہ /30 حد پر پڑنا چاہیے، اس لیے آخری آکٹیٹ چار کا ضرب ہے۔ 10.8.1.0 پر /30 کلائنٹ کو 10.8.1.2 دیتا ہے، اور DNS ریکارڈ وہی پتہ رکھتا ہے۔ اس کے بجائے 10.8.1.3 چننے سے ایسا کلائنٹ بنتا ہے جو جڑتا ہے مگر ٹریفک نہیں گزار سکتا، کیونکہ پتہ ایسے سب نیٹ کا ہے جو ٹوپولوجی نے اسے کبھی نہیں دیا۔

منصوبہ سنبھالنا آسان رہتا ہے اگر override وسیع حد کے اوپر سے نیچے کی طرف تقسیم ہوں، تاکہ متحرک pool مقررہ جزیروں کے گرد نہیں، خالی جگہ میں پھیلے۔

مقامی نیٹ ورک اور وہ زون جس سے کلائنٹ پوچھتے ہیں

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

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

نئے کنکشن پر کیا جانچیں

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

کسی دوسرے عام نام کے تحت دوبارہ جاری سرٹیفکیٹ اپنے override سے میل کھانا بند کر دیتا ہے اور کلائنٹ کو متحرک pool میں واپس لے آتا ہے۔ کسی بھی شناخت کی تبدیلی کے بعد اس کی توقع رکھیں۔