چرا 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 و سیاست بک‌اند است، نه هویت. تکرار بازنشانی گذرواژه نمی‌تواند مقداری را که در لایه پروتکل پیشین انتخاب شده ترمیم کند.