OpenVPN سرور کی ترتیب کو برانچ میں کاپی کرنا کیوں ناکام ہوتا ہے

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

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

ایک ہی فائل جیسی دو کرداریں

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

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

نجی کلید سب سے اہم حصہ ہے۔ کلائنٹ کو کبھی سرور کی نجی کلید نہیں اٹھانی چاہیے، اور اسے CA کی دستخطی کلید کی بھی ضرورت نہیں۔ CA سرٹیفکیٹ عوامی اعتماد کا مواد ہے؛ دستخطی کلید وہاں رہتی ہے جہاں سرٹیفکیٹ جاری ہوتے ہیں۔

برانچ پروفائل میں کیا ہونا چاہیے

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

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

آلات کے ورک فلو میں محتاط رہیں۔ pfSense کا Client Export پیکیج موزوں Remote Access سیاق و سباق کے لیے پروفائل بناتا ہے، اور اس کی سرور فہرست میں صرف وہی سرور ہوتے ہیں جو Remote Access موڈ میں ترتیب دیے گئے ہوں۔ دوسرے موڈ کا سائٹ-سے-سائٹ سرور نظر نہیں آتا، اور یہ عدم موجودگی معلومات ہے، سرور کے راز کاپی کرنے کی دعوت نہیں۔

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

ساتھی اور نیٹ ورک کی وابستگی الگ ہے

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

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

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

یہ ثابت کرنا کہ برانچ وہی ساتھی ہے جو آپ سمجھتے ہیں

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

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

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

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