OpenVPN کی auth-user-pass-verify اسکرپٹ: درست ایگزٹ کوڈ

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

معاہدہ چھوٹا ہے: جمع شدہ اکاؤنٹ کی شناخت کریں، منظور شدہ تصدیق کنندہ سے مطلوبہ سوال پوچھیں اور اُس درخواست کے لیے صرف اُسی تصدیق کنندہ کا دستاویزی مثبت نتیجہ قبول کریں۔ باقی سب ڈھانچہ ہے۔

وہ تین حالتیں جو ہُک واپس کر سکتا ہے

auth-user-pass-verify کے لیے OpenVPN 2.6 کا دستی ایگزٹ کوڈ 0 کو قبولیت، 1 کو مسترد اور 2 کو مؤخر شدہ تصدیق کے طور پر متعین کرتا ہے۔ سرور صرف یہی تین جواب سمجھتا ہے، اور ہر ایک کا کنکشن پر مختلف اثر ہے۔ جو اسکرپٹ اپنے آخری حکم کی حالت کے ساتھ باہر نکلتی ہے، اُس نے درحقیقت لاگ کال یا صفائی کے مرحلے کو ووٹ ڈالنے دیا ہے۔ ہر شاخ میں حالت واضح طور پر لکھیں، اُن شاخوں سمیت جو کبھی تصدیق کنندہ تک نہیں پہنچیں۔

HTTP کی کامیابی اور تصدیق کی کامیابی الگ تہیں ہیں، اور اِن کو ملانا اِس ہُک کے غلط ہونے کا سب سے عام طریقہ ہے۔ 202 جواب کا مطلب ہے کہ درخواست پروسیسنگ کے لیے قبول ہوئی، یہ نہیں کہ پاس ورڈ کی تصدیق ہوئی۔ متوقع حالت، جواب کی شکل اور حتمی فیصلہ آپ کو دیے گئے API معاہدے سے طے کریں، اور قابلِ اعتماد لگنے کی وجہ سے کوئی فیلڈ نام نہ گھڑیں۔

اگر جواب واقعی بعد میں آئے تو وہی مؤخر شدہ راستہ ہے اور اُسے اِسی طرح بنانا ہوگا۔ جو مؤخر شدہ کوشش کبھی مکمل نہیں ہوتی وہ وقت کی حد ختم ہونے تک وسائل روکے رکھتی ہے۔

اسناد کی فائل کو ویسے ہی پڑھیں جیسے وہ لکھی ہے

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

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

طے کریں کہ ناقابلِ درجہ بندی جواب کا کیا مطلب ہے

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

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

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

فیصلے کی تصدیق کریں، چھپی ہوئی سطر کی نہیں

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

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

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