RADIUS VPN صارف نام کے بجائے IP پتہ کیوں دیکھتا ہے

Windows IKEv2 کلائنٹ جڑتا ہے، اور RADIUS درخواست وہاں پتے کے ساتھ آتی ہے جہاں اکاؤنٹ کا نام ہونا چاہیے۔ ابھی کچھ بھی ناکام نہیں ہوا، اور الجھن والا حصہ یہی ہے: گیٹ وے وہ شناخت رپورٹ کر رہا ہے جو کلائنٹ نے IKE سطح پر پیش کی۔ آپ کے بیک اینڈ کو جو صارف نام چاہیے وہ ابھی نہ ہونے والے الگ EAP تبادلے سے آ سکتا ہے۔ اکاؤنٹ بدلنے سے پہلے فیصلہ کریں کہ یہ کون مانگے گا۔

ایک کنکشن میں دو شناختیں سفر کرتی ہیں

ایک کنکشن میں دو نام ظاہر ہو سکتے ہیں۔ IKE شناخت ٹنل سیٹ اپ کے دوران ساتھی کی شناخت کرتی ہے، اور eap-radius پلگ ان شروع میں اسے RADIUS User-Name میں نقل کرتا ہے۔ EAP شناخت ایک مختلف قدر ہے، جو صارف کی تصدیق کے لیے استعمال ہوتی ہے، اور اگر کوئی نہ مانگے تو یہ کبھی نہ بھیجی جا سکتی ہے۔

اسی لیے RADIUS لاگ پتہ دکھا سکتا ہے جبکہ اکاؤنٹ موجود ہو اور پاس ورڈ درست ہو۔ بیک اینڈ سے غلط سطح کے بارے میں پوچھا جا رہا ہے۔ RADIUS خصوصیت صرف منتخب نام کے لیے محرک ہے۔

گیٹ وے سے EAP شناخت مانگنے کو کہیں

ایک معاون ترتیب میں گیٹ وے تصدیق RADIUS کے حوالے کرنے سے پہلے EAP شناخت مانگتا ہے۔ کنکشن کے دور دراز تصدیق والے حصے میں، طریقہ eap-radius پر سیٹ کریں اور EAP شناخت واضح طور پر مانگیں۔ نیچے دیا گیا ٹکڑا اپنی الگ فائل میں نہیں، موجودہ کنکشن بلاک کے اندر آتا ہے۔ کسی دوسری تعیناتی سے نحو نقل کرنے سے پہلے کنکشن اور کنفیگریشن بیک اینڈ کی تصدیق کریں۔

remote {
    auth = eap-radius
    eap_id = %any
}

اس سے بیک اینڈ کو IKE پتے کے بجائے وہ شناخت ملتی ہے جو کلائنٹ EAP تبادلے میں دیتا ہے۔ کنکشن میں اور کچھ نہیں بدلتا۔

یا RADIUS کو EAP تبادلہ شروع کرنے دیں

دوسری ترتیب پہلا قدم RADIUS کی طرف رکھتی ہے۔ پلگ ان ابتدائی شناخت کے جواب کا انتظار کرنے کے بجائے EAP-Start اشارہ بھیج سکتا ہے، جو سرور کو تبادلہ چلانے دیتا ہے۔ یہ پلگ ان سطح کی کنفیگریشن ہے، اس لیے پلگ ان استعمال کرنے والے ہر کنکشن پر اثر ڈالتی ہے۔

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

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

ایک کوشش کو دونوں لاگوں میں ٹریس کریں

ایک ہی کوشش کو دونوں لاگوں میں جوڑیں۔ IKE شناخت دیکھیں، پھر کہ EAP-Identity تبادلہ ہوتا ہے یا نہیں، پھر کہ تصدیق کے قدم کو کون سا نام ملتا ہے۔ EAP تبادلے سے پہلے پتہ مسترد کرنے والا بیک اینڈ آپ کی مطلوبہ شناخت کے کبھی دکھائی دینے سے پہلے عمل روک سکتا ہے۔

journalctl -u strongswan -f

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

اگر درست کیا گیا بہاؤ صحیح اکاؤنٹ تک پہنچے اور پھر بھی مسترد ہو، تو اگلا ثبوت شناخت نہیں، EAP طریقہ اور بیک اینڈ پالیسی ہے۔ پاس ورڈ ری سیٹ کو دہرانا پہلے کی پروٹوکول سطح پر منتخب قدر کو ٹھیک نہیں کر سکتا۔