OpenVPN کی متعدد --up اسکرپٹس سے متعلق تنبیہ: صرف ایک چلتا ہے

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

اسی لیے یہ تنبیہ توجہ کے قابل ہے، اگرچہ مہلک نہیں: یہ جس چیز کی پیش گوئی کرتی ہے وہ DNS کی تازہ کاری یا راستے کی تبدیلی ہے جو خاموشی سے ہونا بند ہو گئی۔

تنبیہ ترتیب کے بارے میں نہیں ہے

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

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

اصل آغاز میں دونوں تعریفیں تلاش کریں

اس پروفائل سے نہیں جو آپ نے ترمیم کیا، بلکہ اس سے شروع کریں جو ڈیمون نے واقعی حاصل کیا۔ ps -ef اور یونٹ کی ExecStart کمانڈ لائن دکھاتی ہیں، جس میں کنٹینر کے دخلی نقطے یا ریپر سے --up شامل ہو سکتا ہے؛ تقسیم کی init فائل بھی یہی کر سکتی ہے۔ systemctl cat openvpn-server@server ظاہر کرتا ہے کہ سروس خود کیا شامل کرتی ہے، اور ترتیبات کی ڈائریکٹری پر تکرار والا grep فائل سطح کی تعریفیں تلاش کرتا ہے۔ نقول عموماً مختلف تہوں سے آتی ہیں، اور اسی لیے ایک فائل میں ترمیم کچھ نہیں بدلتی۔

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

صرف ایک hook کام کا مالک ہو

پائیدار حل ایک ہی منتظم ہے جو دونوں کارروائیاں سوچے سمجھے ترتیب سے چلاتا ہے۔ set -eu کے ساتھ مختصر shell اسکرپٹ مطلوبہ انضمام اور پھر مقامی کارروائی کو پکارتا ہے اور "$@" منتقل کرتا ہے تاکہ دلائل کی حدیں باقی رہیں؛ اس طرح طرز عمل ایک ہی قابل جانچ جگہ پر رہتا ہے۔ دلائل منتقل کرنا انہیں صرف محفوظ رکھتا ہے؛ یہ ثابت نہیں کرتا کہ دونوں مددگار ایک ہی انٹرفیس کی توقع رکھتے ہیں، لہٰذا ہر ایک کا معاہدہ پڑھیں۔ فیصلہ کریں کہ ناکامی کو کیا کرنا چاہیے اور کیا جزوی تبدیلیاں واپس لینی ہیں۔

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

صفائی متعلقہ down مرحلے کی ہے۔ DNS دوبارہ لکھنے یا راستے شامل کرنے والی up کارروائی کو دستاویزی واپسی درکار ہے، اور صرف آغاز سنبھالنے والا منتظم آدھا ڈیزائن ہے۔

خاموشی نہیں، انضمام کی تصدیق کریں

نقلی تنبیہ ہٹانا آسان حصہ ہے؛ انضمام کو اب بھی کام کرنا ہے۔ جڑنے کے بعد resolvectl status سے یا /etc/resolv.conf پڑھ کر حل کنندہ کی حالت جانچیں، اور ip route سے راستوں کی تصدیق کریں۔ پھر منقطع ہو کر دوبارہ جڑیں، کیونکہ جلد بازی میں جڑا hook پچھلے سیشن سے کچھ چھوڑ دیتا ہے۔ journalctl -u openvpn-server@server -b دکھاتا ہے کہ آپ کا منتظم چلا اور کیا چھاپا۔

hook کے استحقاق جہاں ہونے چاہئیں وہیں رکھیں۔ script-security بڑھانا یا ڈیمون کو زیادہ حقوق کے ساتھ چلانا بدلے ہوئے hook کا حل نہیں ہے؛ یہ بڑھاتا ہے کہ ہر آئندہ اسکرپٹ، حتیٰ کہ وہ بھی جس کا نام کوئی حملہ آور رکھے، کیا کر سکتا ہے۔

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