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

دائرہ کیا منتخب کرتا ہے

گیٹ وے صارف نام وصول کرتا ہے اور اسے کہاں جانچنا ہے یہ طے کرنا ہوتا ہے۔ دائرہ اُس نام کا حصہ، یا اُس کے ساتھ موجود خصوصیت ہے، جو ڈیٹا بیس منتخب کرتی ہے: کوئی ڈائریکٹری، RADIUS پول، یا مقامی اکاؤنٹ فائل۔ Microsoft کا NPS اِسے دائرے کا نام کہتا ہے اور اسی سے کنکشن درخواستیں روٹ کرتا ہے، جبکہ EAP نیٹ ورک رسائی شناخت کنندہ RFC 7542 میں at علامت کے بعد لاحقے کے طور پر وہی تصور رکھتا ہے۔ دونوں انتخاب کنندہ ہیں، اور کوئی بھی یہ فیصلہ نہیں کرتا کہ اسناد اچھی ہیں یا نہیں۔

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

دائرے کی ترکیب تعیناتی سے تعلق رکھتی ہے۔ کچھ خدمات غیر موزوں نام کے ساتھ خصوصیت چاہتی ہیں، کچھ user@domain چاہتی ہیں، اور چند ایک بیک سلیش والی شکل کی توقع کرتی ہیں جس کا ذکر زیادہ تر رہنما نہیں کرتے۔

وہ شکل استعمال کریں جس کی بیک اینڈ توقع کرتا ہے

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

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

براؤزر اور میل کلائنٹ کبھی کبھی پرانی شناخت محفوظ کر لیتے ہیں اور خاموشی سے دوبارہ بھیج دیتے ہیں۔ جب بتایا گیا صارف نام لکھے ہوئے سے مختلف ہو تو سب سے پہلے وہی کیش دیکھیں۔

درخواست کو پراکسی کے ذریعے تلاش کریں

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

grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'

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

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

کوشش کو افشا کیے بغیر ریکارڈ کریں

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

پھر صارفین کے لیے جیتنے والی شکل دستاویز کریں، کیونکہ اگلا شخص جو اسے غلط لکھے گا وہی ٹکٹ کھولے گا۔ پاس ورڈ ری سیٹ اُس درخواست کو ٹھیک نہیں کرتا جو غلط نام کی جگہ میں گرتی رہتی ہے۔ دائرہ روٹنگ کا فیصلہ ہے، اور روٹنگ کے فیصلے اُنہیں درست نام دے کر ٹھیک کیے جاتے ہیں۔

متعلقہ مضامین