غلط سیکرٹ پاس ورڈ کے قاعدے کا نہیں، کنٹینر کا مسئلہ ہے
مسترد شدہ اسناد شاید گیٹ وے تک کبھی نہیں پہنچیں۔ پہلے ان پٹ کنٹینر، تصدیق کے مرحلے اور خود اکاؤنٹ کا موازنہ کریں۔
غلط سیکرٹ کا پیغام دیکھ کر عموماً ایک نتیجہ نکالا جاتا ہے: VPN کو رموزِ اوقاف پسند نہیں۔ یہ نتیجہ عموماً غلط ہوتا ہے، کیونکہ پیغام اکثر مقامی پروسیسنگ سے آتا ہے، اس سے پہلے کہ کوئی گیٹ وے اکاؤنٹ کو دیکھے۔ دو ڈیزائن ایک ہی پاس ورڈ پہنچاتے ہیں، ایک گرافیکل فیلڈ اور ایک اسناد فائل، اور وہ مختلف جگہوں پر ناکام ہوتے ہیں۔ ایسے پاس ورڈ کو آسان بنانے سے پہلے کنٹینرز کا موازنہ کریں جو شروع سے درست تھا۔
خرابی گیٹ وے سے پہلے آتی ہے
مقامی توثیق، مقفل سیکرٹ اسٹور، غائب ایجنٹ اور خراب اسناد فائل، یہ سب ایسی ناکامیاں پیدا کرتے ہیں جنہیں صارف ایک ہی مسترد ہونے کے طور پر محسوس کرتا ہے۔ ان میں سے کوئی تصدیق کے سرور سے متعلق نہیں۔ گیٹ وے کی اپنی مستردگی ایک الگ واقعہ ہے، اور یہ عموماً مختلف پیغام اور مختلف وقت کے ساتھ آتی ہے۔ یہ اس وقت ہوتی ہے جب سرنگ موجود ہو اور اسناد منتقل ہو چکی ہوں۔
تو پہلا سوال یہ نہیں کہ کون سے حروف جائز ہیں، بلکہ یہ کہ کوشش کہاں رکی۔ ایسا کلائنٹ جس نے کبھی کنکشن نہیں کھولا اسے کسی نے مسترد نہیں کیا۔ جو مرحلہ آپ نے دیکھا اسے لکھ لیں، کیونکہ ہر اگلا قدم اسی درجہ بندی پر منحصر ہے۔
یہ فرق یہ بھی بدلتا ہے کہ کون ٹھیک کرے۔ کنٹینر کا مسئلہ ڈیوائس اور اس کے مالک کا ہے، جبکہ اکاؤنٹ کی مستردگی اس شخص کی ہے جو تصدیق کا بیک اینڈ چلاتا ہے۔
حروف نہیں، کنٹینرز کا موازنہ کریں
GUI پاس ورڈ فیلڈ، کی چین کا اندراج، دو سطری اسناد فائل اور آٹومیشن سیکرٹ، سب ایک ہی قدر کو مختلف لفافوں میں لے جاتے ہیں۔ لفافے کے اپنے قواعد ہیں، اور عموماً یہی قواعد ٹوٹتے ہیں۔ قدر شاذ و نادر ہی مسئلہ ہوتی ہے؛ قدر کی ترسیل زیادہ تر مسئلہ ہوتی ہے۔ ان دو خیالات کو الگ رکھیں تو تشخیص مختصر ہو جاتی ہے۔
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
Community OpenVPN 2.6 کلائنٹ آپشنز auth-user-pass کے لیے وہ دو سطری فائل بیان کرتے ہیں، بشمول اس رویے کے جب پاس ورڈ کی سطر موجود نہ ہو: کلائنٹ اس کے بجائے پوچھتا ہے۔ یہی ایک تفصیل ان رپورٹوں کی ایک قسم کی وضاحت کرتی ہے کہ وہ وہ پاس ورڈ پوچھ رہا ہے جو میں پہلے دے چکا ہوں۔ یہ یہ بھی بتاتی ہے کہ خالی دوسری سطر ایک بامعنی حالت ہے، کوئی بے ضرر فارمیٹنگ انتخاب نہیں۔
اقتباسات پھر ایک الگ تہہ ہیں: عام اسناد فائل کے اندر اقتباسات بطور ڈیٹا محفوظ ہوتے ہیں، جبکہ شیل انہیں اس سے پہلے ہٹا دیتا ہے کہ پروگرام کچھ دیکھے۔ ایک ہی حرف ایک جگہ بے ضرر اور دوسری جگہ ساختی ہوتا ہے۔ کوئی جدول آپ کو نہیں بتا سکتا کہ آپ کے کلائنٹ نے کون سا کنٹینر استعمال کیا، اس لیے سطر منتخب کرنے سے پہلے کلائنٹ کی اپنی ترتیب پڑھیں۔
سطر کے وقفے بھی ساختی ہیں۔ سطروں سے منقسم فیلڈز والی فائل ایسی قدر نہیں لے جا سکتی جس میں نئی سطر ہو، اور یہ فارمیٹ کی حد ہے، پاس ورڈ کی مضبوطی کے بارے میں کوئی فیصلہ نہیں۔ بے ساختہ فائل میں فٹ کرنے کے لیے سیکرٹ کو تراشنے کے بجائے تعیناتی کے معاون ترسیل میکانزم کا استعمال کریں۔
اسناد فائل شیل کے نقصان کے بغیر بنائیں
سب سے محفوظ مقامی راستہ سیکرٹ کو شیل کی تاریخ اور پروسیس آرگیومنٹ فہرست سے باہر رکھتا ہے۔ دونوں فیلڈز انٹرایکٹو طریقے سے پڑھیں، پھر دونوں سطریں لکھیں جن کی کلائنٹ توقع کرتا ہے۔ باقی سب کچھ ایسی کنفیگریشن فائل میں رہ سکتا ہے جس کا جائزہ لینا آسان ہو۔
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsپہلے دو کمانڈ صارف نام اور پھر پاس ورڈ بغیر دکھائے پڑھتے ہیں، تیسرا دونوں سطریں لکھتا ہے، چوتھا فائل کو محدود کرتا ہے، اور آخری کلائنٹ کو اسی فائل کے ساتھ شروع کرتا ہے۔ نوٹ کریں کہ read -r بیک سلیش محفوظ رکھتا ہے؛ یہی وہ تفصیل ہے جو نظر انداز ہونے پر کام کرنے والے پاس ورڈ کو ناکام پاس ورڈ بنا دیتی ہے۔
فائل کو بغیر اقتباس والے متغیر یا شیل کی توسیعات سے بھرے here-document سے بنانے سے بچیں۔ دونوں حروف کو فائل تک پہنچنے سے پہلے بدل سکتے ہیں، اور نتیجے میں آنے والی ناکامی VPN کی مستردگی جیسی لگتی ہے کیونکہ ڈسک پر پاس ورڈ واقعی اس سے مختلف ہے جو آپ جانتے ہیں۔ اگر ایسا شبہ ہو تو سیکرٹ خود چھاپے بغیر فائل کی بائٹ لمبائی کا متوقع قدر سے موازنہ کریں۔ ایک یا دو بائٹ کا فرق اقتباس کی حادثے کی نشانی ہے۔
مرحلہ پہلی خرابی سے پڑھیں
ایک کوشش کا پہلا مخصوص پیغام محفوظ رکھیں، پھر اس کی درجہ بندی کریں۔ مقامی توثیق کی خرابی، غائب نجی کلید، دستیاب نہ ہونے والا سیکرٹ ایجنٹ اور گیٹ وے کی تصدیق کی ناکامی چار مختلف نتائج ہیں جن کے چار مختلف ذمہ دار ہیں۔ ان میں سے صرف ایک اکاؤنٹ سے متعلق ہے۔
اگر گیٹ وے واقعی درست طریقے سے پہنچائی گئی اسناد کو مسترد کر رہا ہے تو اکاؤنٹ، تصدیق کے بیک اینڈ اور کسی بھی مطلوبہ چیلنج کو منتظم کے ساتھ جانچیں۔ عام تصدیقی ناکامی کسی ممنوع حرف کا نام نہیں لیتی۔
منظور شدہ قدر کو حروف اور ہندسوں تک محدود کرنے کے بجائے درست میکانزم سے بحال کریں۔ پاس ورڈ کی پالیسی آپریٹر کی ہے، اور ایسا حل جو اسے خاموشی سے بے اثر کر دے، درستگی نہیں۔ یہ اصل نقص کو اگلے شخص سے چھپا بھی دیتا ہے، جو اسی خرابی سے کمزور پاس ورڈ اور بہتر خیال کے بغیر دوچار ہوگا۔