VPN لاگ اِن RADIUS اور آپ کے شناختی فراہم کنندہ تک کیسے پہنچتا ہے
VPN سائن اِن کو کلائنٹ سے گیٹ وے کی RADIUS درخواست، اس کے پیچھے شناختی فراہم کنندہ اور قبولیت کے بعد لاگو ہونے والی پالیسی تک ٹریس کریں۔
پچھلے ہفتے ایک صارف VPN میں سائن اِن کر سکا اور پھر بھی ایسے نیٹ ورک پر پہنچا جہاں کچھ حل نہیں ہو رہا تھا۔ کلائنٹ نے کہا منسلک ہے، گیٹ وے لاگ نے Access-Accept کہا، اور شناختی ٹیم نے کہا کہ اکاؤنٹ ٹھیک ہے۔ لاگ اِن کام کر چکا تھا؛ اس کے پیچھے کی اجازت نہیں۔ جب VPN سائن اِن ناکام ہوتا ہے، میں وہ راستہ چلتا ہوں جو درخواست واقعی لیتی ہے — کلائنٹ، گیٹ وے، RADIUS سرور، شناختی فراہم کنندہ — اور پہلے اس مرحلے پر رکتا ہوں جس کا جواب اگلے سے میل نہیں کھاتا۔
کلائنٹ کبھی RADIUS نہیں بولتا
لیپ ٹاپ کی ایپ جو بھی دکھائے، اس کا پہلا مرحلہ VPN پروٹوکول ہے: IKEv2, OpenVPN, WireGuard یا TLS پر مبنی کلائنٹ۔ RADIUS اس تبادلے میں ظاہر نہیں ہوتا۔ کلائنٹ گیٹ وے پر سرٹیفکیٹ، صارف نام اور پاس ورڈ، یا ٹنل سیٹ اپ میں لے جانے والے EAP طریقے سے تصدیق کرتا ہے۔
لاگ پڑھتے وقت یہ اہم ہے، کیونکہ صارف کو نظر آنے والی عام تصدیق کی خرابی گیٹ وے اس وقت پیدا کرتا ہے جب وہ پہلے ہی کسی اور چیز سے بات کر چکا ہوتا ہے۔ اگر کلائنٹ کبھی گیٹ وے تک نہ پہنچے تو ڈیبگ کرنے کے لیے کوئی RADIUS درخواست نہیں ہوتی، اور RADIUS سرور پر گزرا ایک گھنٹہ ضائع ہوتا ہے۔ بیک اینڈ کو چھونے سے پہلے تصدیق کریں کہ ٹنل بنا تھا۔
گیٹ وے ہی RADIUS کلائنٹ ہے
جیسے ہی ٹنل سیٹ اپ اس مقام تک پہنچتا ہے جہاں اسناد جانچنی ہوں، گیٹ وے نیٹ ورک رسائی سرور بن جاتا ہے۔ یہ Access-Request بناتا ہے: User-Name، پاس ورڈ یا EAP پے لوڈ، NAS-IP-Address یا NAS-Identifier، اور طریقہ مانگے تو Message-Authenticator۔ درخواست بطور ڈیفالٹ UDP 1812 پر جاتی ہے، اور حساب 1813 پر۔ پرانے تعیناتیاں اب بھی 1645 اور 1646 استعمال کرتی ہیں، اس لیے ایک جوڑے کے لیے لکھا گیا فائر وال قاعدہ بہت سی خاموش ناکامیوں کی وضاحت کرتا ہے۔
دونوں فریق ایک راز بانٹتے ہیں، اور وہ صارف کی اسناد نہیں ہے۔ یہ تبادلے پر دستخط کرتا ہے، اور ہر جواب اس کے خلاف جانچا جاتا ہے۔ دونوں طرف راز مختلف رکھیں اور سرور خراب راز کا جواب نہیں دیتا — وہ درخواست پھینک دیتا ہے یا جواب جانچ میں ناکام ہوتا ہے، اس لیے گیٹ وے وقت ختم ہونے کی اطلاع دیتا ہے۔ غلط راز اور مردہ سرور گیٹ وے سے ایک جیسے دکھتے ہیں, اس لیے ڈائریکٹری کو قصوروار ٹھہرانے سے پہلے میں کلائنٹ ٹول سے مرحلہ جانچتا ہوں۔
پروٹوکول چھوٹا اور پرانا ہے — RFC 2865 تصدیق کے تبادلے کی تعریف کرتا ہے — لیکن یہ جو خصوصیات لے کر چلتا ہے وہی زیادہ تر VPN پالیسی کی بنیاد ہیں۔
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'RADIUS سرور صرف شناختی فراہم کنندہ کا سامنے کا حصہ ہو سکتا ہے
لوگ RADIUS اور شناختی فراہم کنندہ کو ایک ہی ڈبے کی طرح بیان کرتے ہیں۔ اکثر ایسا نہیں ہوتا۔ RADIUS سرور Access-Request وصول کرتا ہے اور پھر جواب دینے سے پہلے کسی اور چیز سے پوچھتا ہے — LDAP یا Kerberos کے ذریعے Active Directory، مقامی صارف فائل یا بیرونی سروس۔ LDAP یا krb5 ماڈیول کے ساتھ FreeRADIUS، Windows NPS اور Cisco ISE سب اسی مقام پر کھڑے ہیں۔
یہ فرق طے کرتا ہے کہ کہاں دیکھیں۔ مسترد شدہ پاس ورڈ RADIUS کے آگے بھیجنے والا شناختی فراہم کنندہ کا جواب ہے۔ وقت ختم ہونا عام طور پر RADIUS سے ڈائریکٹری تک کا حصہ ہے: میعاد ختم شدہ بائنڈ اکاؤنٹ، ناقابل رسائی ڈائریکٹری، یا غلط بیک اینڈ کو بھیجی گئی درخواست۔ اگر صارف نام میں ڈومین لاحقہ ہو، تو سرور اس کی بنیاد پر روٹ کر سکتا ہے، اور CORP\alice اور [email protected] کے طور پر بھیجا گیا وہی اکاؤنٹ مختلف جگہوں پر پہنچ سکتا ہے۔ Windows NPS میں، Security لاگ اجازت کے لیے 6272 اور انکار کے لیے 6273 درج کرتا ہے، جو بتاتا ہے کہ فیصلہ NPS سے آیا تھا یا نہیں۔
ناکامی اسی مرحلے پر پڑھیں جس نے اسے پیدا کیا
ایک ہی منسلک نہیں ہو سکتا پیغام چار مختلف ناکامیوں کو ڈھکتا ہے۔ کچھ بھی بدلنے سے پہلے علامت کو اس مرحلے سے ملائیں جس نے اسے پیدا کیا۔
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
آخری سطر ہی وہ ہے جو لوگوں کو غلط ٹیم کے پاس بھیجتی ہے۔ Access-Accept کا مطلب ہے اسناد قبول ہوئیں؛ اس کا مطلب یہ نہیں کہ گیٹ وے نے صارف کو درست پول میں رکھا یا راستے دھکیلے۔ گروپ خصوصیات تبھی اہم ہیں جب گیٹ وے پالیسی انہیں پڑھے۔ میں نے درست لاگ اِن کو مہمان پول میں گرتے دیکھا ہے، کیونکہ RADIUS کی طرف گروپ میپنگ گیٹ وے کی جانچ والی خصوصیت سے مختلف خصوصیت کے لیے سیٹ تھی۔
ایک لاگ اِن کو شروع سے آخر تک ٹریس کریں
ایک ٹیسٹ اکاؤنٹ اور ایک گیٹ وے منتخب کریں، پھر وہی کوشش چاروں مقامات پر دیکھیں۔ RADIUS کی طرف ڈیبگ رن شروع کریں — freeradius -X درخواست اور اس کے چھونے والے ہر ماڈیول کو چھاپتا ہے — گیٹ وے کا تصدیقی لاگ ٹریس کریں، اور UDP تبادلے کے لیے tcpdump چلائیں۔ ایک بار جڑیں اور چاروں ٹریس ترتیب سے پڑھیں۔
آپ جو دیکھنا چاہتے ہیں وہ اتفاق ہے: گیٹ وے نے اس صارف کے بارے میں پوچھا جس کی آپ توقع کر رہے تھے، RADIUS سرور نے وہ بیک اینڈ چنا جس کی آپ توقع کر رہے تھے، اس بیک اینڈ نے فیصلہ واپس کیا، اور جواب کی خصوصیات گیٹ وے کی لاگو پالیسی سے میل کھاتی ہیں۔ ٹریس پہلی بار جہاں نہ ملیں وہی آپ کی خرابی کی لکیر ہے۔ اگر جواب میں کوئی گروپ خصوصیت نہیں، تو مسئلہ VPN پروفائل میں نہیں، RADIUS کی طرف ہے؛ اگر خصوصیت موجود ہے اور گیٹ وے اسے نظر انداز کرتا ہے، تو مسئلہ گیٹ وے پالیسی ہے۔
وہاں رہتے ہوئے ایک سیکیورٹی نوٹ۔ مشترکہ راز تبادلے کی حفاظت کرتا ہے، لیکن یہ زیادہ تر خصوصیات کو خفیہ نہیں کرتا۔ اگر گیٹ وے اور RADIUS سرور مختلف حصوں میں ہیں، تو وہ مرحلہ TLS پر RADIUS یا نجی راستے پر رکھیں۔ خفیہ صارف ٹنل بیک اینڈ لنک کے بارے میں کچھ نہیں کہتی۔
ٹکٹ بند کرنے سے پہلے چار چیزیں تصدیق کریں۔ گیٹ وے RADIUS سرور تک اس پورٹ پر پہنچ سکتا ہے جس کے لیے وہ واقعی ترتیب دیا گیا ہے۔ مشترکہ راز دونوں طرف میل کھاتا ہے۔ RADIUS سرور گیٹ وے کے بھیجے گئے صارف نام کی صحیح شکل حل کرتا ہے۔ قبولیت میں وہ خصوصیات ہیں جن کی گیٹ وے پالیسی کو ضرورت ہے۔ جب چاروں درست ہوں، تو پھر بھی ناکام ہونے والا لاگ اِن تصدیق کی نہیں، گیٹ وے پالیسی کی خرابی ہے۔