چگونه ورود به 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 را دریافت می‌کند و سپس پیش از پاسخ دادن از چیز دیگری می‌پرسد — Active Directory از طریق LDAP یا Kerberos، یک فایل کاربر محلی یا سرویسی خارجی. FreeRADIUS با ماژول LDAP یا krb5، Windows NPS و Cisco ISE همگی در این موقعیت قرار دارند.
این تمایز تعیین می‌کند کجا را نگاه کنید. گذرواژه ردشده پاسخی از ارائه‌دهنده هویت است که RADIUS آن را بازپخش می‌کند. پایان مهلت معمولاً بخش RADIUS تا دایرکتوری است: حساب bind منقضی، دایرکتوری دسترسی‌ناپذیر یا درخواستی که به بک‌اند اشتباه فرستاده شده. اگر نام کاربری پسوند دامنه داشته باشد، سرور ممکن است بر اساس آن مسیریابی کند و همان حساب که به‌صورت 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 بک‌اندی را انتخاب کرد که انتظار داشتید، آن بک‌اند تصمیمی برگرداند و ویژگی‌های پاسخ با سیاستی که دروازه اعمال می‌کند می‌خواند. نخستین جایی که ردها اختلاف پیدا می‌کنند خط خطای شماست. اگر پاسخ هیچ ویژگی گروهی ندارد، مشکل در سمت RADIUS است نه در پروفایل VPN؛ اگر ویژگی هست و دروازه آن را نادیده می‌گیرد، مشکل سیاست دروازه است.
یک نکته امنیتی تا آنجا هستید. راز مشترک تبادل را محافظت می‌کند، اما بیشتر ویژگی‌ها را رمزنگاری نمی‌کند. اگر دروازه و سرور RADIUS در بخش‌های متفاوتی هستند، آن گام را روی RADIUS از طریق TLS یا مسیری خصوصی بگذارید. تونل رمزنگاری‌شده کاربر درباره پیوند بک‌اند چیزی نمی‌گوید.
پیش از بستن تیکت، چهار چیز را تأیید کنید. دروازه می‌تواند به سرور RADIUS روی پورتی که واقعاً برای آن پیکربندی شده برسد. راز مشترک در دو طرف یکسان است. سرور RADIUS شکل دقیق نام کاربری‌ای را که دروازه می‌فرستد حل می‌کند. پذیرش ویژگی‌هایی را که سیاست دروازه نیاز دارد حمل می‌کند. وقتی هر چهار مورد برقرار باشد، ورودی که هنوز شکست می‌خورد مشکل سیاست دروازه است نه احراز هویت.