OpenVPN پروفائل لوڈ ہونے کے باوجود ca.crt نہیں ڈھونڈ پاتا

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

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

پروفائل کا راستہ بنیادی ڈائریکٹری نہیں ہے

/tmp میں شروع ہونے والے اور /etc/vpn/prod/tenant-a.ovpn پانے والے عمل کا تصور کریں۔ اس پروفائل کے اندر، ca ca.crt سطر ایک نسبتی راستہ بتاتی ہے۔ پروفائل ڈھونڈنے والی دلیل میں کچھ بھی اس نام کو دوبارہ نہیں لکھتا، اس لیے عمل /tmp/ca.crt تلاش کرتا ہے اور گمشدہ فائل کی اطلاع دیتا ہے۔

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

مینوئل کیا الگ کرتا ہے: --config اور --cd

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

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

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

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

سروس کہیں اور شروع ہوتی ہے

پروفائل ڈائریکٹری میں انٹرایکٹو شیل پیکیج شدہ unit کے بارے میں کچھ ثابت نہیں کرتا۔ مینیجر اپنی کام کرنے والی ڈائریکٹری مقرر کرتے ہیں، اور ریپر اسکرپٹ بائنری چلنے سے پہلے اسے دوبارہ بدل سکتی ہے۔ ناکام ہونے والا unit ہی واحد لانچ ہے جس پر غور کرنا قابلِ قدر ہے۔

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

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

تلاش کے بعد: اجازتیں، chroot اور سینڈ باکس

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

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

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

اپنے لانچ سے اصلاح ثابت کریں

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

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

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

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