OpenVPN سروس نجی کلید کا پاس ورڈ پوچھتے وقت رک جاتی ہے: اسے کیسے ٹھیک کریں
سروس کے پاس ٹرمینل نہیں ہوتا، اس لیے خفیہ کردہ کلید کو askpass اور پڑھنے کے قابل فائل درکار ہے۔ کلید کا پاس فریز سرور لاگ اِن سے الگ رکھیں اور unit جانچیں۔
OpenVPN مقامی مشین پر نجی کلید کا پاس فریز پوچھتا ہے، اس لیے کام کرنے والی لاگ اِن فائل کبھی اس کا جواب نہیں دیتی۔ سروس میں ٹائپ کرنے کے لیے ٹرمینل نہیں ہوتا، اور آغاز یا تو رک جاتا ہے یا جرنل میں ایسی اندراج کے ساتھ ناکام ہوتا ہے جو سبب نہیں بلکہ اِن پٹ کا نام لیتی ہے۔ یہاں دو راز ہیں، اور unit دوبارہ شروع کرنے سے پہلے ہر ایک کو اپنا پڑھنے کے قابل ذریعہ چاہیے۔ نیچے دیا گیا طریقہ انہیں الگ کرتا ہے، پھر وہ شناخت جانچتا ہے جو واقعی ہر فائل کھولتی ہے۔
دونوں درخواستوں میں فرق کریں
کلید کا پاس فریز مقامی نجی کلید کو ڈکرپٹ کرتا ہے؛ اکاؤنٹ کی اسناد سرور کے ساتھ سیشن کی تصدیق کرتی ہیں۔ یہ مختلف جگہوں سے آتے ہیں، مختلف لمحوں میں ناکام ہوتے ہیں اور مختلف پیغام دیتے ہیں۔ انہیں خلط ملط کرنا لوگوں کو پاس ورڈ ری سیٹ ڈھونڈنے بھیجتا ہے جبکہ اکاؤنٹ شامل ہی نہیں تھا۔ کوئی بھی اختیار بدلنے سے پہلے درخواست کا متن پڑھیں، کیونکہ کون سا راز غائب ہے اس کا واحد قابلِ اعتماد اشارہ الفاظ ہی ہیں۔
Community OpenVPN 2.x میں askpass ایسی فائل بتاتا ہے جس کی پہلی سطر میں کلید کا پاس فریز ہوتا ہے، اور auth-user-pass ایسی فائل بتاتا ہے جس میں ایک سطر میں صارف نام اور اگلی میں پاس ورڈ ہوتا ہے۔ دونوں میں سے کوئی فائل دوسرے اختیار کو پورا نہیں کر سکتی۔ ڈیسک ٹاپ ایپ یا NetworkManager پروفائل دونوں کو اپنے راز کے ذخیرے میں رکھ سکتے ہیں، جسے کمانڈ لائن کلائنٹ کبھی نہیں پڑھتا، اس لیے کوئی بھی راستہ لکھنے سے پہلے نوٹ کریں کہ آپ کون سا کلائنٹ ترتیب دے رہے ہیں۔
دونوں اختیارات کو پڑھنے کے قابل فائلوں کی طرف موڑیں
دونوں اِن پٹ درکار پروفائل آخرکار تین فائل حوالوں پر پہنچتا ہے: خفیہ کردہ کلید، اسے کھولنے والا پاس فریز اور لاگ اِن جوڑی۔ انہیں CA اور شناخت کی جانچ کو چھوئے بغیر شامل کریں، کیونکہ وہ طے کرتے ہیں کہ سرور کون ہے اور اس مسئلے کا حصہ نہیں ہیں۔ اگر تعیناتی اکاؤنٹ اسناد بالکل استعمال نہ کرے، تو auth-user-pass شامل کرنے سے ایسا اِن پٹ بنتا ہے جو کوئی فراہم نہیں کر سکتا۔
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authبغیر دلیل والے اختیارات راستے والے اختیارات سے مختلف برتاؤ کرتے ہیں، اور سروس میں یہ فرق اہم ہے۔ بغیر دلیل کا askpass اب بھی کنسول پڑھتا ہے، اور صرف صارف نام والی auth-user-pass فائل اب بھی پاس ورڈ کی درخواست کو انتظار میں چھوڑ دیتی ہے۔ کلائنٹ کے ڈیمن بننے کے بعد وہ ٹرمینل سے اِن پٹ مانگ ہی نہیں سکتا، اس لیے اس طرح ترتیب دی گئی سروس نہیں اٹھتی۔
مطلق راستے کام کرنے والی ڈائریکٹری کا سوال ہٹا دیتے ہیں مگر رسائی نہیں دیتے۔ پھر ملکیت، موڈ اور گزر شامل ہوتے ہیں، اور تینوں اسی اکاؤنٹ کے مقابل جانچے جاتے ہیں جس کے تحت عمل چلتا ہے۔
پروفائل سے پہلے unit کی ترتیب پڑھیں
کون سی ترتیب مثال لوڈ کرے گی یہ unit طے کرتا ہے، وہ فائل نہیں جو آپ ترمیم کر رہے تھے۔ اس کی کمانڈ لائن اور تمام drop-in پڑھیں، پھر کام کرنے والی ڈائریکٹری کے ذریعے اُس پروفائل تک جائیں جو واقعی استعمال ہو رہا ہے۔ کسی دوسری .ovpn فائل میں شامل کیا گیا پاس فریز حوالہ اس مثال کے لیے کچھ نہیں بدلتا۔
تین صرف پڑھنے والے احکام اس کا بیشتر حصہ بتا دیتے ہیں۔ پہلا unit اور تمام drop-in چھاپتا ہے، دوسرا عمل کو باندھنے والی شناخت اور سینڈ باکس ترتیبات، اور تیسرا یہ کہ پچھلے آغاز نے واقعی کس بات کی شکایت کی۔ میزبان پر موجود مثال کا نام استعمال کریں:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome اور پروفائل کے اپنے user، group اور chroot اختیارات پر توجہ دیں۔ گھر کی ڈائریکٹری کے نیچے کی فائل آپ کے شیل میں پڑھی جا سکتی ہے اور گھر کی ڈائریکٹریاں چھپائے جانے پر سروس کے اندر نظر نہیں آتی۔ systemd جس اکاؤنٹ سے شروع ہوتا ہے وہ ہمیشہ وہی اکاؤنٹ نہیں ہوتا جو آخر میں کلید کھولتا ہے۔
ثابت کریں کہ رن ٹائم شناخت دونوں فائلیں کھول سکتی ہے
صرف موڈ پڑھنا کافی نہیں، کیونکہ راستے کی ہر ڈائریکٹری اسی شناخت کے لیے گزری جا سکتی ہونی چاہیے۔ راستہ جزو بجزو چلیں، پھر اُس اکاؤنٹ کے طور پر کھولنے کی جانچ کریں جو عمل استعمال کرتا ہے۔ root کی ملکیت والی اور موڈ 600 والی فائل صرف اُس وقت تک چلتی ہے جب تک عمل root ہے، اور بہت سے پروفائلز کی استحقاق کمی کے بعد یہ درست نہیں رہتا۔ دو احکام گزر اور کھولنا دونوں ڈھانپتے ہیں:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableپہلا حکم ہر جزو کا موڈ چھاپتا ہے اور وہاں ناکام ہوتا ہے جہاں اکاؤنٹ گزر نہیں سکتا؛ دوسرا واحد اہم سوال کا جواب دیتا ہے، یعنی کیا رن ٹائم شناخت فائل کو پڑھنے کے لیے کھول سکتی ہے۔ دونوں میں سے کوئی فائل کا مواد نہیں چھاپتا، اور فائل میں پاس فریز ہونے پر یہی اصل بات ہے۔ لاگ اِن فائل کے لیے بھی جانچ دہرائیں، کیونکہ دونوں اکثر مختلف ملکیت کے ساتھ محفوظ ہوتی ہیں۔
اگر عمل chroot یا محدود namespace استعمال کرتا ہے، تو وہی جانچ اُس منظر کے اندر سے چلائیں، ورنہ جواب غلط فائل سسٹم بیان کرتا ہے۔ چھپی ہوئی گھر کی ڈائریکٹری کے نیچے رکھا پاس فریز اُس جانچ کی عام مثال ہے جو unit سے باہر پاس ہوتی ہے اور اندر ناکام ہوتی ہے۔
پہلا آغاز جانچیں، پھر دوبارہ رابطہ
مثال ایک بار شروع کریں اور آخری نہیں بلکہ پہلی ناکامی پڑھیں۔ غائب اِن پٹ فائل، ناکام کلید ڈکرپشن اور سرور کی طرف سے AUTH_FAILED تین مختلف واقعات ہیں، تین مختلف مرمتوں کے ساتھ۔ اجازت کی وارننگ ٹھیک کرنا اس بات کا کچھ ثابت نہیں کرتا کہ کلید کھلی تھی۔
جرنل کی سطر بتاتی ہے کہ تین میں سے کون سی حالت ہے۔ مرمت اس سے نکلتی ہے کہ کون سا اِن پٹ ناکام ہوا:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
پھر وہ زندگی کا چکر جانچیں جو آپ کو واقعی درکار ہے: بوٹ پر آغاز اور کوئی بھی معاون دوبارہ رابطہ، صرف اپنے شیل سے ہاتھ سے شروع کرنا نہیں۔ auth-nocache کے ساتھ اِن پٹ پہلے استعمال کے بعد پھینک دیے جاتے ہیں، اس لیے بعد کے دوبارہ رابطے کو اب بھی پڑھنے کے قابل ذریعہ چاہیے۔ ڈیسک ٹاپ لاگ اِن پر کھلنے والا کی رنگ اُس سروس کے لیے دستیاب نہیں ہوتا جو کسی کے لاگ اِن سے پہلے شروع ہوئی ہو، اور ہاتھ کی جانچ پاس ہو کر ری بوٹ ناکام ہونے کی یہی عام وجہ ہے۔ اگر پہلا آغاز کامیاب ہو اور بعد کا دوبارہ رابطہ ناکام، تو اجازتیں دوبارہ بدلنے سے پہلے دوبارہ رابطے کے واقعے کے لیے جرنل پڑھیں۔
کلید کے ساتھ پاس فریز رکھنا خفیہ کاری کا فائدہ کم کرتا ہے، اس لیے اُس فائل اور اس کے بیک اپ کو محدود رکھیں۔ کلید کا پاس فریز ہٹانا غائب اِن پٹ کی مرمت نہیں بلکہ الگ اسناد کا فیصلہ ہے۔ انسانی منظوری یا انٹرایکٹو MFA پر منحصر تعیناتی کو اپنا معاون ایجنٹ یا انتظامی انضمام درکار ہے؛ مستقل محفوظ کیا گیا یک بارہ کوڈ مساوی متبادل نہیں ہے۔