OpenVPN کلائنٹ کی فراہمی ایسے مراحل کے ساتھ جو خرابی پر رک جائیں

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

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

فائل سسٹم چھونے سے پہلے ان پٹ درست کریں

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

خالی متغیرات کو جلدی مسترد کریں۔ غیر مقرر $DEVICE جو کسی چیز میں نہیں پھیلتا، install -m 400 $KEY /etc/openvpn/client/ حکم کو ڈائریکٹری کی طرف نشانہ بنائی نقل میں بدل دیتا ہے، اور ناکامی بعد میں ایسی سروس کے طور پر آتی ہے جو اپنی کلید نہیں پڑھ سکتی۔

پروفائل سیٹ کو اسٹیجنگ ڈائریکٹری میں جمع کریں

پہلے پورا سیٹ کسی نجی جگہ پر بنائیں: پروفائل، CA، کلائنٹ سرٹیفکیٹ، کلید اور کوئی بھی مددگار جسے پروفائل بلاتا ہے۔ install -m 400 -o root -g root سے نقل کریں تاکہ اجازتیں بعد میں نہیں بلکہ بناتے وقت طے ہوں۔ پھر پروفائل کے اندر کے حوالوں کی جانچ کریں، کیونکہ نسبتی ca یا key سطر سروس شروع ہوتے ہی یونٹ کی کام کرنے والی ڈائریکٹری کے حوالے سے حل ہوتی ہے۔ پورا سیٹ درست ثابت ہونے تک فعال ڈائریکٹری میں کچھ نہیں لکھا جانا چاہیے۔

اس دوڑ نے کیا پیدا کیا اس کا غیر خفیہ فنگر پرنٹ ریکارڈ کریں، مثلاً ورژن نشان کے پاس محفوظ sha256sum office.conf۔ یہی ایک قدر دوبارہ دوڑ کو اپ ڈیٹ اور کچھ نہ کرنے میں فرق کرنے دیتی ہے۔

جوہری طور پر بدلیں اور پچھلا سیٹ رکھیں

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

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

ایک مالک فعال کریں اور اسے ثابت کریں

ایک فعال کرنے کا راستہ چنیں، یا systemd مثال یا NetworkManager، اور اسے مستقل استعمال کریں۔ فعال یونٹ کے پاس غیر منظم openvpn عمل شروع کرنے سے دو سرنگیں، مسابقتی DNS اپ ڈیٹ اور اس بات کا واضح جواب نہیں ملتا کہ رکنے کا حکم کسے نشانہ بناتا ہے۔ فعال کرنے کے بعد systemctl is-active openvpn-client@office جانچیں، پھر دور دراز سابقے کا راستہ، پھر سرنگ کی نصب کردہ حل کنندہ کے لیے resolvectl status جانچیں۔ سرنگ جس ایک وسیلے کے لیے ہے اس تک پہنچ کر تمام کریں۔

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

دوبارہ دوڑ اور ریٹائرمنٹ الگ الگ ورک فلو ہیں

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

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

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