OpenVPN ڈیوائس کا راستہ: کنفگ کا مالک یا اسٹارٹ اپ اسکرپٹ؟

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

دونوں امیدوار مختلف چیزیں رکھتے ہیں

معاون کنفگریشن ماخذ وہ سب کچھ ہے جسے ڈیوائس ان پٹ سمجھتی ہے: GUI فیلڈ، درآمد شدہ پروفائل، ہر کلائنٹ کے لیے دستاویزی ڈائریکٹری، سیٹنگز ڈیٹا بیس جسے مینجمنٹ پیکیج پڑھتا ہے۔ بنی ہوئی server.conf آؤٹ پٹ ہے۔ آؤٹ پٹ میں ترمیم اس وقت تک کام کرتی ہے جب تک جنریٹر دوبارہ نہ چلے، اور یہ محفوظ کرنے، ری بوٹ اور اپ گریڈ پر ہوتا ہے۔

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

ڈیوائس کیا دوبارہ بناتی ہے، اور کب

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

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

معاون مالک کو کیا ظاہر کرنا چاہیے

برانچ پریفکس کو ایک نہیں، تین بیانات چاہیے۔ کلائنٹ کو راستہ سیکھنا چاہیے، سرور کو جاننا چاہیے کہ کون سا تصدیق شدہ کلائنٹ پریفکس کا مالک ہے، اور برانچ کی طرف کو ٹریفک اسی ٹنل پتے پر واپس بھیجنا چاہیے جو اسے دیا گیا۔ OpenVPN کی اصطلاحات میں اس کا مطلب ہے پش کیا گیا route، کلائنٹ سے بندھا ہوا مماثل iroute، اور دوسری طرف واپسی کا راستہ۔

یہیں ڈیوائس UI گمراہ کرتے ہیں۔ «کلائنٹس کو سرور کے LAN تک رسائی دیں» کے لیبل والا چیک باکس سرور کے اپنے نیٹ ورک کی طرف ٹریفک بیان کرتا ہے۔ آپ کی برانچ مخالف سمت ہے: ایک کلائنٹ کے پیچھے کا نیٹ ورک، سرور کی طرف سے قابل رسائی۔ وہی لیبل اس کے لیے معاونت نہیں دلاتا، اور فائل میں درست ہدایت اس بات کا وعدہ نہیں کہ پیکیج اسے محفوظ رکھے گا۔

جب کوئی معاون کنٹرول نہ ہو

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

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

ارادے کو قابلِ آڈٹ بنائیں

معاہدہ ڈیوائس سے باہر درج کریں: مؤثر کلائنٹ شناخت، پریفکس، واپسی گیٹ وے، اور ہر ایک کو فراہم کرنے والا معاون فیلڈ۔ معاون طریقے سے کنفگریشن برآمد کریں تاکہ دوبارہ تعمیر کو حوالہ ملے، اور سروس کی تصدیق دوبارہ جڑنے، ری اسٹارٹ اور اپ گریڈ کے بعد کریں، صرف تبدیلی کے بعد نہیں۔

جب کچھ ٹوٹے تو بننے والے نتیجے کا اس ریکارڈ سے موازنہ کریں، بغیر سمجھائی گئی لائن بحال کر کے امید رکھنے کے بجائے۔OpenVPN 2.6 حوالہ وہ جگہ ہے جہاں UI سے بحث کرنے سے پہلے route اور iroute کے باہمی عمل کی تصدیق کریں۔

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