OpenVPN کے سروس بننے کے بعد client-config-dir نظر انداز ہو جاتا ہے

آپ کا ٹنل اوپر آتا ہے اور کلائنٹ جڑ جاتا ہے، لیکن مقررہ پتہ اور وہ دھکیلے گئے راستے جو آپ نے اسی ایک صارف کے لیے مقرر کیے تھے غائب ہیں۔ لاگ میں “file not found” نہیں لکھا، اور یہی لوگوں کو سرٹیفکیٹ دوبارہ بنانے بھیجتا ہے۔ ایسے بیشتر معاملات میں ڈیمون اسی شیل سے مختلف ڈائریکٹری میں چلتا ہے جس میں آپ نے جانچ کی تھی، اور client-config-dir کبھی ویسے حل نہیں ہوا جیسا آپ نے فرض کیا تھا۔ اصلاح راستے کی درستی ہے، اسناد کو ری سیٹ کرنا نہیں۔

ترتیبات کو چھونے سے پہلے یونٹ پڑھیں

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

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

خالی WorkingDirectory کا مطلب ہے کہ یونٹ / میں شروع ہوتا ہے، اس لیے اضافی client-config-dir ccd /ccd میں تلاش کیا جاتا ہے۔ وہ ڈائریکٹری تقریباً کبھی موجود نہیں ہوتی، اور ڈیمون اس کی عدم موجودگی کو مہلک نہیں سمجھتا۔

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

اضافی راستہ کس کے حساب سے حل ہوتا ہے

کلیدی لفظ اس لمحے عمل کی ورکنگ ڈائریکٹری کے حساب سے حل ہوتا ہے جب اختیار استعمال ہوتا ہے۔ اس کا مطلب “اس ترتیباتی فائل کے ساتھ جو میں نے --config کے ذریعے دی” نہیں ہے۔ OpenVPN خوشی سے مکمل راستے سے ترتیبات پڑھے گا اور پھر بھی اضافی قدریں کہیں اور حل کرے گا، اور یہیں اصل جال ہے۔ OpenVPN 2.6 کی دستی یہ قاعدہ --client-config-dir کے تحت اور پھر --cd کے تحت بیان کرتی ہے۔

cd کا کلیدی لفظ دوسری فائلیں پڑھنے سے پہلے وہ سیاق بدلتا ہے، اس لیے جو یونٹ cd /etc/openvpn/server مقرر کرتا ہے اور پھر client-config-dir ccd، وہ /etc/openvpn/server/ccd پر حل ہوتا ہے۔ اگر آپ cd شامل کریں تو ہدایات کی ترتیب دیکھیں اور یاد رکھیں کہ یہ اسی فائل کی ہر دوسری اضافی حوالے پر اثر ڈالتا ہے۔

راستے کو ڈیمون کے اکاؤنٹ کے طور پر چلیں

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

namei ہر جزو کی اجازت ترتیب سے چھاپتا ہے، جو ڈائریکٹریوں کو ایک ایک کر کے جانچنے سے تیز ہے:

namei -l /etc/openvpn/server/ccd/client1

پھر پڑھنے کو خود کے بجائے سروس اکاؤنٹ کے طور پر جانچیں:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

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

اندازہ لگانے کے بجائے تلاش کی تصدیق کریں

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

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

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

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

درست کریں، دوبارہ شروع کریں، تصدیق کریں

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

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

انسٹنس دوبارہ شروع کریں، ایک معلوم کلائنٹ کو دوبارہ جوڑیں اور اسے ملنے والا پتہ اس کی طرف دھکیلے گئے راستوں کے ساتھ پڑھیں۔ اگر پتہ اس کلائنٹ کی فائل میں موجود ifconfig-push سطر سے میل کھاتا ہے تو تلاش کام کر گئی۔ اگر کلائنٹ اب بھی عام تالاب میں گرتا ہے تو لاگ سطروں کی گنتی پر واپس جائیں: صفر درآمد کا مطلب ہے کہ راستہ یا شناخت غلط ہے، غلط مواد کے ساتھ ایک درآمد کا مطلب ہے کہ آپ اس فائل سے مختلف فائل میں ترمیم کر رہے ہیں جو ڈیمون پڑھتا ہے۔

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