OpenVPN auth-user-pass: فائل، stdin یا پرامپٹ؟ کیسے منتخب کریں

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

وہ تین شرائط جو اسے طے کرتی ہیں

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

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

• کنسول پر انسان، کوئی خودکاری نہیں: متعامل پرامپٹ۔
• بغیر نگرانی آغاز، راز محفوظ کیا جا سکتا ہے: موڈ 0600 والی اسناد کی فائل۔
• بغیر نگرانی آغاز، راز محفوظ نہیں کیا جا سکتا: عمل کی تبدیلی یا وہ fd جس میں راز کا ایجنٹ لکھتا ہے۔
• کلائنٹ کسی دوسرے عمل کی ملکیت ہے: انتظامی انٹرفیس۔

جب دو جواب موزوں ہوں تو وہ منتخب کریں جو راز کو argv اور shell کی تاریخ سے باہر رکھتا ہے۔ پروگرام کے آرگیومنٹ کے طور پر دیا گیا پاس ورڈ عمل کی فہرست کے ذریعے ہر مقامی صارف پڑھ سکتا ہے، اور اس انکشاف کو واپس لینا مشکل ہے۔

ہر ان پٹ راستہ درحقیقت کیا کرتا ہے

--auth-user-pass اکیلا کنسول پر صارف نام اور پاس ورڈ مانگتا ہے۔ فائل کا نام دینے پر کلائنٹ پہلی سطر کو صارف نام اور دوسری سطر کو پاس ورڈ سمجھتا ہے؛ کوئی چیز اقتباسات، تبصروں یا کلید-قدر نحو کی حمایت نہیں کرتی۔ یہی پورا فارمیٹ ہے، اس لیے جو بھی INI فائل کی توقع میں اسے ترمیم کرتا ہے وہ اسے توڑ دیتا ہے۔ اندرونی <auth-user-pass> بلاک وہی دو سطریں پروفائل کے اندر رکھتا ہے، جو پروفائل کو بذات خود راز بنا دیتا ہے اور اسے نجی کلید جیسے ہی سلوک کے طبقے میں رکھتا ہے۔

باقی دو راستے اسٹریم اور ساکٹ ہیں۔ OpenVPN کو صرف پڑھنے کے قابل فائل ڈسکرپٹر درکار ہے، اس لیے یہ عمل کی تبدیلی، پائپ کی حمایت یافتہ /dev/fd اندراج یا ایسی فائل کا نام قبول کرے گا جو درحقیقت FIFO ہے۔ انتظامی انٹرفیس فطرتاً مختلف ہے: کلائنٹ خود پڑھنے کے بجائے نگران عمل سے قدریں پوچھتا ہے۔ دوبارہ جڑنے پر یہ فرق اہم ہے: اسناد کی فائل، وہ FIFO جس میں راز کا مددگار دوبارہ لکھ سکتا ہے، اور انتظامی انٹرفیس انسان کے بغیر دوبارہ مہیا کر سکتے ہیں؛ عمل کی تبدیلی نہیں کر سکتی، کیونکہ ڈسکرپٹر پہلی قرأت ہی میں خرچ ہو جاتا ہے۔

فائل بالکل دو سطروں کی ہونی چاہیے

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

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

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

سرور کو قصوروار ٹھہرانے سے پہلے فائل جانچیں۔ openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 چلانے پر طبع ہوتا ہے کہ فائل کھلی یا نہیں اور بعد میں اسناد قبول ہوئیں یا نہیں، جو بتاتا ہے کہ آگے کون سی تہہ بدلنی ہے۔

اسٹریم، stdin اور ان سے پیدا ہونے والی غلطیاں

پاس ورڈ پائپ میں ڈالنا پہلی چیز ہے جو بیشتر لوگ آزماتے ہیں اور سب سے زیادہ حیرتوں والا راستہ ہے۔ عمل کی تبدیلی اس لیے کام کرتی ہے کہ کلائنٹ کو صرف پڑھنے کے قابل ڈسکرپٹر درکار ہے: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS")۔ /dev/stdin منتقل کرنا صرف تب کام کرتا ہے جب کلائنٹ کے پوچھنے کے لمحے stdin اب بھی کھلا اور پڑھنے کے قابل ہو، جو ایسی پائپ لائن میں درست نہیں جو اسے پہلے ہی استعمال کر چکی ہو۔

ERROR: could not read Auth username from stdin کی دو مختلف وجوہات ہیں۔ کچھ 2.3.x کلائنٹس پر پیغام stdin کے سلوک کی خرابی سے آیا تھا جسے بعد کی 2.3 ریلیزوں نے درست کیا، اس لیے اتنا پرانا کلائنٹ صرف اپ گریڈ سے بہتر ہوتا ہے۔ موجودہ کلائنٹ پر وہی الفاظ کا مطلب ہے کہ کلائنٹ نے کنسول ان پٹ مانگا اور stdin ٹرمینل نہیں تھا - بالکل وہی حالت جو systemd یونٹ، cron کام یا -t کے بغیر شروع کیے گئے کنٹینر میں ہوتی ہے۔

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

انتظامی انٹرفیس جب پرامپٹ کسی دوسرے عمل کی ملکیت ہو

جو کنٹرولر پہلے ہی ٹنل کی نگرانی کرتا ہے وہ اس کے سوالات کا بھی جواب دے سکتا ہے۔ کلائنٹ کو --management 127.0.0.1 7505 کے ساتھ شروع کریں، حالت کی سطریں پڑھیں، اور >PASSWORD:Need 'Auth' username/password پر توجہ دیں۔ کنٹرولر الگ الگ کمانڈ سطروں پر username "Auth" alice اور پھر password "Auth" ... کے ساتھ جواب دیتا ہے۔ 'Auth' ٹوکن درخواست سے شناخت کنندہ دہراتا ہے اور اسے میل کھانا چاہیے، ورنہ جواب نظر انداز ہو جاتا ہے اور کلائنٹ انتظار کرتا ہے۔

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

اسناد کے مسئلے جیسی لگنے والی ناکامیاں

کبھی مکمل نہ ہونے والا TLS ہاتھ ملانا، یا VERIFY ERROR: depth=0, error=certificate signature failure، اعتماد کا مسئلہ ہے اور کسی بھی صارف نام کے پڑھے جانے سے پہلے ہوتا ہے۔ UDP سننے والے کی طرف نشانہ proto tcp کلائنٹ بھی اسی جگہ ناکام ہوتا ہے: پیکٹ کبھی توثیق کے مرحلے تک نہیں پہنچتے، اس لیے ہر پاس ورڈ تعلق کی وجہ سے غلط لگتا ہے۔ اسناد بھیجنے سے پہلے سرٹیفکیٹ کی تصدیق فعال رکھیں؛ مانوس پرامپٹ اس بارے میں کچھ نہیں بتاتا کہ پاس ورڈ کون وصول کرتا ہے۔ اسناد کو چھونے سے پہلے سرٹیفکیٹ زنجیر، عام نام اور نقل و حمل جانچیں۔

پروفائل جوڑنے والی اسکرپٹ میں shell کی غلطیاں دوسرا جھوٹا سراغ ہیں۔ [ ! -f "$file" ] کے اندر غائب خالی جگہ command not found پیدا کرتی ہے، اسکرپٹ جلدی رک جاتی ہے، پروفائل کبھی دوبارہ نہیں بنتا، اور کلائنٹ پچھلے کے ساتھ شروع ہوتا ہے۔ وہ غلطی shell کی ہے، توثیق کی نہیں، اور پاس ورڈ کتنی بار بھی دوبارہ لکھیں وہ مٹتی نہیں۔

اس بہاؤ میں ہر پرامپٹ یہ اسناد نہیں ہے۔ نجی کلید کا پاس فریز، HTTP پراکسی لاگ ان اور خدمت کا پاس ورڈ مختلف مرحلوں میں مانگے جانے والے تین مختلف راز ہیں، اور کلید کا پاس فریز عام طور پر auth-user-pass کے بجائے کلائنٹ یا ایجنٹ سنبھالتا ہے۔ اگر پرامپٹ TLS سیشن قائم ہونے سے پہلے ظاہر ہو تو آپ غلط سوال کا جواب دے رہے ہیں اور کوئی اکاؤنٹ ری سیٹ مدد نہیں کرے گا۔ غلط پرامپٹ خارج ہونے کے بعد باقی جانچیں سب سے پہلی تہہ سے شروع ہوتی ہیں:

• آخری اسناد کی سطر نہیں، پہلی پروٹوکول غلطی پڑھیں: TLS، پھر توثیق، پھر push۔
• تصدیق کریں کہ فائل دو سطروں کی ہے، کیریج ریٹرن نہیں ہیں، اور مطلق راستے سے حوالہ دیا گیا ہے۔
• تصدیق کریں کہ پروفائل اور کمانڈ لائن ہدایت کے بارے میں اختلاف نہیں رکھتے۔
• "اسناد قبول ہوئیں" کو "ٹریفک بہہ رہا ہے" سے الگ کریں - روٹنگ اور DNS بعد کی تہہ ہیں۔

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