status=200/CHDIR: systemd نے کبھی OpenVPN شروع نہیں کیا
CHDIR ناکامی کا مطلب یہ ہے کہ systemd کسی ڈائریکٹری میں داخل نہیں ہو سکا، نہ یہ کہ OpenVPN کوئی پروفائل نہیں پڑھ سکا۔ VPN کنفیگریشن کو چھونے سے پہلے یونٹ پڑھیں۔
سروس ناکام ہوتی ہے، لاگز میں spawn اور ڈائریکٹری کا ذکر ہوتا ہے، اور پہلا ردِعمل VPN کنفیگریشن جانچنا ہوتا ہے۔ اُس فائل میں ابھی کچھ نہیں پڑھا گیا۔ systemd نے عمل کی تیاری کے دوران، ایگزیکیوٹیبل چلنے سے پہلے ناکامی کا سامنا کیا، لہٰذا کوئی پارسر، کوئی سرٹیفکیٹ اور کوئی دور دراز ہوسٹ مشورہ نہیں کیا گیا۔ اسٹیٹس کوڈ کو OpenVPN کے بجائے systemd کے بارے میں بیان کے طور پر پڑھنا ہی اسے مختصر تفتیش بنا دیتا ہے۔
ایپلی کیشن سے پہلے اسٹیٹس کوڈ پڑھیں
سروس کے نام کے بعد آنے والا عددی کوڈ اُس مرحلے کا نام دیتا ہے جو ناکام ہوا۔ ڈائریکٹری کی ناکامی CHDIR اسٹیٹس کے طور پر رپورٹ ہوتی ہے، جبکہ وہ ایگزیکیوٹیبل جو چل نہ سکا بالکل الگ کوڈ ہے۔ دونوں خلاصے کی ایک سطر میں ایک جیسے لگتے ہیں اور اپنی وجوہات میں کچھ مشترک نہیں رکھتے۔
یہ فرق اہم ہے کیونکہ درستی مختلف فائلوں میں ہے۔ CHDIR ناکامی کا تعلق راستے اور سروس کے اُسے دیکھنے کے انداز سے ہے۔ Exec ناکامی کا تعلق بائنری، اُس کے ترجمان یا کسی غیر متعلق mount سے ہے۔ VPN کا دور دراز مقام، سائفر فہرست یا سرٹیفکیٹ کا راستہ بدلنا دونوں میں سے کسی کو حل نہیں کر سکتا۔
تصدیق کریں کہ ناکامی آغاز پر ہے نہ کہ کامیاب چلنے کے بعد۔ اگر سروس کل کام کر رہی تھی اور اب اُسی مرحلے پر ناکام ہوتی ہے، تو ڈائریکٹری، اُس کی اجازتوں یا خود یونٹ میں کچھ بدلا ہے، اور وہی تبدیلی وہ ثبوت ہے جسے تلاش کرنا ہے۔
یونٹ سے پوچھیں کہ وہ کہاں ہونا چاہتا ہے
موثر یونٹ پڑھیں نہ کہ وہ فائل جسے آپ نصب شدہ سمجھتے ہیں، کیونکہ drop-in فائلیں مرکزی یونٹ میں ترمیم کیے بغیر ورکنگ ڈائریکٹری کو نظر انداز کر سکتی ہیں۔ show کی آؤٹ پٹ سوال کا براہِ راست جواب دیتی ہے:
systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30
upstream سرور ٹیمپلیٹ کے لیے ورکنگ ڈائریکٹری سرور کی کنفیگریشن ڈائریکٹری ہے اور انسٹینس کا نام اُس کے اندر پروفائل منتخب کرتا ہے۔ لہٰذا branch نامی انسٹینس اُسی ڈائریکٹری میں اپنی فائل کی توقع کرتا ہے، اور کہیں اور رکھا گیا پروفائل ورکنگ ڈائریکٹری کی شرط بالکل پوری نہیں کرتا۔
یونٹ جو مانگتا ہے اُس کا موازنہ اُس سے کریں جو موجود ہے۔ پہلے موجود رہا راستہ، اب کہیں اور اشارہ کرنے والا سمبولک لنک، یا ایسا انسٹینس نام جو اب کسی ڈائریکٹری سے مطابقت نہیں رکھتا، سب عام تبدیلیاں ہیں جو بالکل یہی ناکامی پیدا کرتی ہیں۔
راستہ اُس طرح جانچیں جیسے سروس دیکھتی ہے
آپ کا شیل اور سروس فائل سسٹم کا ایک ہی منظر نہیں رکھتے۔ ترتیب دی گئی روٹ ڈائریکٹری یا روٹ امیج یونٹ کے اندر مطلق راستے کا مطلب بدل دیتی ہے، اور وہ راستہ جو ہوسٹ پر واضح طور پر موجود ہے اُس نام کی جگہ میں غائب ہو سکتا ہے۔ دستی آزمائش پر بھروسہ کرنے سے پہلے یونٹ کی ترتیبات پڑھیں۔
اجازتیں مسئلہ مزید بڑھاتی ہیں۔ سروس ایک مخصوص صارف کے طور پر چلتی ہے، اور اُس صارف کو ہر والدین ڈائریکٹری سے گزر کر ہدف تک پہنچنا چاہیے، نہ صرف ہدف خود پڑھنا۔ ایسی ڈائریکٹری جو root پڑھ سکے مگر سروس کا صارف اُس سے گزر نہ سکے، ایسی ناکامی پیدا کرتی ہے جو غائب راستے جیسی لگتی ہے۔
namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths
سخت گیر ترتیبات بھی اِس منظر کا حصہ ہیں۔ وہ یونٹ جو گھریلو ڈائریکٹریاں چھپاتا ہے یا فائل سسٹم کا کوئی حصہ صرف پڑھنے کے قابل بناتا ہے بالکل وہی کرتا ہے جس کے لیے اُسے ترتیب دیا گیا، اور ورکنگ ڈائریکٹری کو کہیں ایسا ہونا چاہیے جہاں sandbox اب بھی اُسے ظاہر کرتا ہو۔
مالک درست کریں، پھر کسی اور خرابی کی توقع کریں
ترتیب یا یونٹ کو اُس شخص کے ذریعے درست کریں جس کے پاس وہ کنفیگریشن ہے۔ پروفائل کو متوقع ڈائریکٹری میں منتقل کرنا اُس وقت جائز درستی ہے جب ترتیب غلط ہو، مگر یہ ایسی ڈائریکٹری کی وضاحت نہیں کرتا جس میں داخل نہ ہو سکیں، لہٰذا اُسے عمومی جواب نہ سمجھیں۔
کنفیگریشن کے درخت پر اجازتیں بڑھانے یا sandbox ہٹانے کی چھوٹی راہ کی مزاحمت کریں۔ دونوں علامت کو مٹا دیتے ہیں جبکہ وہ تحفظات ہٹا دیتے ہیں جو جان بوجھ کر وہاں رکھے گئے تھے، اور اگلی ناکامی کی تشریح مشکل ہو گی۔
انسٹینس دوبارہ شروع کریں اور کامیابی فرض کرنے کے بجائے اگلا واقعہ پڑھیں۔ اگلی ممکنہ خرابی یہ ہے کہ OpenVPN اپنی کنفیگریشن فائل نہیں کھول سکتا، جو پیش رفت ہے: ورکنگ ڈائریکٹری میں داخل ہو گئے اور پارسر اب چل رہا ہے۔ وہاں سے یونٹ کی اصل فائل میپنگ کی پیروی کریں، نیٹ ورک کے مسائل حل کرنے کی طرف واپس نہ جائیں۔
systemd کا اجرائی حوالہ بیان کرتا ہے کہ ورکنگ ڈائریکٹری کو روٹ ڈائریکٹریوں اور sandbox کے ساتھ کیسے سمجھا جاتا ہے۔ یاد رکھنے والا نمونہ سادہ ہے: ہر اسٹیٹس کوڈ الگ مرحلے کا نام دیتا ہے، اور صرف خود ایپلی کیشن کی خرابیاں ایپلی کیشن بیان کرتی ہیں۔