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

ایک لاگ اِن، دو RADIUS تبادلے

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

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

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

چیلنج دراصل کیا لے جاتا ہے

RADIUS تفصیل دفعہ 4.4 میں کوڈ 11 بیان کرتی ہے اور یہاں اہم دو خصوصیات کی اجازت دیتی ہے۔ Reply-Message صارف کے لیے متن رکھتا ہے، اور State ایک غیر واضح قدر رکھتا ہے جو سرور واپس چاہتا ہے۔ NAS کو State کی تشریح نہیں کرنی چاہیے، صرف اُسے بغیر تبدیلی واپس دینا چاہیے۔

پیروی درخواست نیا Identifier اور نیا Request Authenticator استعمال کرتی ہے، اور اُسے وہی State قدر اور صارف کا جواب لے جانا چاہیے۔ سرور اُسے اُسی State کے ذریعے منتظر چیلنج سے ملاتا ہے، اسی لیے خصوصیت دوبارہ بنانے یا گرا دینے والا گیٹ وے یہ رسم مکمل نہیں کر سکتا۔ ہر جواب پر response authenticator بھی درست ثابت ہونا چاہیے، ورنہ NAS کو پیکٹ گرا دینا چاہیے۔

دفعہ 4.4 وہ تفصیل شامل کرتی ہے جو بیشتر خاموش ناکامیوں کی وضاحت کرتی ہے: جو NAS چیلنجز کی حمایت نہیں کر سکتا وہ Access-Challenge کو انکار سمجھتا ہے۔ اگر آپ کے گیٹ وے کی VPN خدمت اُس حمایت سے پرانی ہے یا اُسے چھوڑ دیتی ہے، تو بیک اینڈ کی دوسرے عامل کی درخواست بغیر کسی اشارے کے فوراً «توثیق ناکام» بن جاتی ہے۔

زنجیر درخواست کہاں گم ہوتی ہے

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

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

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

ایک کوشش کا شروع سے آخر تک سراغ لگائیں

سرور کی طرف ڈیبگنگ روشن رکھتے ہوئے ایک بار دوبارہ پیدا کریں، اور ہر دوسرے سیشن کو گرفت کے دریچے سے باہر رکھیں:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

آؤٹ پٹ میں ایک سطر کی بجائے گفتگو کی شکل تلاش کریں۔ Identifier 3 کے ساتھ پہلی Access-Request، State لے جانے والی Access-Challenge، پھر Identifier 4 کے ساتھ دوسری Access-Request جو وہی State دہراتی ہے اور صارف کا جواب شامل کرتی ہے۔ اگر دوسری درخواست غائب ہو تو گیٹ وے نے کبھی پیروی نہیں کی۔ اگر State کے بغیر آئے تو سرور اُسے منتظر چیلنج سے نہیں ملا سکتا اور عام طور پر رد کر دیتا ہے۔

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

آپ کی مطلوبہ حتمی حالت مکمل اور مجاز گفتگو ہے جس کے بعد مطلوبہ خدمت تک رسائی ہو۔ RADIUS سرور سے آنے والا جواب اِس سے بہت کم ثابت کرتا ہے۔

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