EAP از طریق دروازه VPN: چه کسی روش را پایان می‌دهد

بلیت‌های پشتیبانی یک ورود ناموفق VPN و یک خط‌مشی RADIUS را که روش قوی‌تری می‌خواهد طوری توصیف می‌کنند که گویی یک مشکل‌اند، در حالی که نیستند. دروازه یا اعتبارنامه را می‌پذیرد و هدایت می‌کند، یا گفت‌وگوی EAP را میان کلاینت و سرور احراز هویت حمل می‌کند. اینکه کدام رخ می‌دهد تعیین می‌کند آیا تغییر سمت سرور می‌تواند چیزی را درست کند. پیش از ویرایش گروه سرور، تبادل را بخوانید.

دو مسیر احراز هویت که در گزارش یکسان به نظر می‌رسند

در مسیر نخست، دروازه VPN نام کاربری و گذرواژه را جمع می‌کند و یک RADIUS Access-Request با ویژگی گذرواژه می‌فرستد. سرور احراز هویت آن را با انبار اعتبارنامه خود مقایسه می‌کند و پاسخ پذیرش یا رد می‌دهد. کلاینت هرگز روش EAP را اجرا نمی‌کند، چون هیچ‌چیز از آن نخواسته است.

در مسیر دوم، کلاینت و سرور احراز هویت روش EAP را سرتاسر اجرا می‌کنند و دروازه ویژگی‌های EAP-Message را میان آن‌ها هدایت می‌کند. دروازه هنوز گفت‌وگوی بیرونی RADIUS را پایان می‌دهد، اما منطق روش در دو سر قرار دارد.

هر دو مسیر خطی در گزارش تولید می‌کنند که می‌گوید احراز هویت شکست خورد. تنها مسیر دوم می‌تواند از این تأثیر بپذیرد که سرور کدام روش EAP را ترجیح می‌دهد، و تنها مسیر اول از اینکه دروازه گذرواژه را چگونه می‌خواند. یکسان دانستن آن‌ها همان چیزی است که تیم‌ها یک روز را صرف تغییر گروه‌های سرور برای کلاینتی می‌کنند که هرگز قصد نداشت PEAP بگوید.

روش در واقع کجا اجرا می‌شود

RFC 3579 ترتیب عبور را تعریف می‌کند: NAS بسته‌های EAP را در ویژگی‌های RADIUS حمل می‌کند و به کد ویژه هر نوع EAP نیاز ندارد. به همین دلیل دروازه می‌تواند PEAP و EAP-TLS را بدون پیاده‌سازی هیچ‌یک پشتیبانی کند.

دروازه‌ای که گذرواژه می‌فرستد PEAP را حمل نمی‌کند، حتی اگر سامانه پشتیبان PEAP را از کلاینت دیگری بپذیرد. فعال‌کردن PEAP در خط‌مشی سرور روشی به کلاینتی که هرگز آن را پیشنهاد نکرده اضافه نمی‌کند.

تنظیمات احراز هویت PPP به سرویس PPP تعلق دارد. آن‌ها هر مسیر IPsec یا XAuth قدیمی را که از همان سرور AAA استفاده می‌کند بی‌صدا بازتنظیم نمی‌کنند، پس تغییری که برای یک نوع دسترسی کار می‌کند می‌تواند دیگری را دست‌نخورده بگذارد.

NAS باید از چه چیزی پشتیبانی کند

عبور، الزام را از کد روش به پشتیبانی حامل منتقل می‌کند. دروازه باید بتواند EAP را روی پروتکل VPN خود حمل کند و کلاینت RADIUS روی آن باید بتواند ویژگی‌های EAP-Message با اندازه‌های مربوط را بفرستد و بگیرد.

در IKEv2 روش EAP بخشی از یک جریان احراز هویت تعریف‌شده است و بررسی‌های هویت و اعتماد سرور از همان جریان می‌آید. برچسب PEAP که از استقرار 802.1X گرفته شده به‌طور خودکار منتقل نمی‌شود، چون مذاکره پیرامون آن متفاوت است.

سمت کلاینت هم الزاماتی دارد. باید برای روش پیکربندی شده باشد، به گواهی سروری که روش ارائه می‌دهد اعتماد کند و اعتبارنامه‌ای داشته باشد که روش بتواند به کار ببرد. روش مبتنی بر گواهی بدون گواهی کلاینت پیش از آنکه RADIUS چیزی ببیند شکست می‌خورد، که مشکلی در تأمین است نه خط‌مشی سرور.

پیش از تغییر خط‌مشی یک تلاش را بخوانید

یک تلاش تأییدشده را در دروازه و در سرور احراز هویت ثبت کنید. در درخواست RADIUS به‌دنبال ویژگی‌های EAP-Message بگردید. وجودشان می‌گوید مسیر عبور در کار است؛ نبودشان به تبادل اعتبارنامه اشاره دارد.

روی دروازه Linux، ثبت روی درگاه RADIUS نشان می‌دهد کدام ویژگی‌ها روی سیم هستند:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

سپس نقطه رد را مقایسه کنید. شکست در دروازه پیش از هر بسته RADIUS یعنی کلاینت و دروازه در روش توافق نداشتند. رد RADIUS همراه با ویژگی‌های EAP یعنی دو سر روش را اجرا کردند و یکی از آن‌ها نتیجه را رد کرد.

مهاجرت را یک تغییر سرتاسری برنامه‌ریزی کنید

تغییر روش یعنی تغییر هم‌زمان پیکربندی کلاینت، پشتیبانی حامل در دروازه، خط‌مشی روش در سرور و انبار اعتبارنامه. این کارها را به همین ترتیب انجام دهید و تا اثبات مسیر جدید یک مسیر کارآمد نگه دارید. تغییر تنها در سمت سرور حدس است و معمولاً کلاینت‌هایی را که کار می‌کردند می‌شکند. تغییر را روی یک هویت آزمایشی آماده کنید پیش از آنکه به گروه دست بزنید.

ترکیبی را که کار می‌کند ثبت کنید: پروتکل VPN، حامل EAP، روش همتا، روش سرور، نوع اعتبارنامه و بررسی هویت سرور.

ورود مدیریتی AAA را جدا از احراز هویت VPN نگه دارید مگر آنکه وظیفه صریحاً هر دو را شامل شود. تغییری که برای دسترسی از راه دور در نظر گرفته شده نباید توانایی شما را برای مدیریت دستگاهی که آن را پایان می‌دهد بگیرد.