EAP یا گواهی‌های مشتری؟ تصمیم‌گیری درباره احراز هویت IKEv2
دو اعتبارنامه، دو کار: یکی نقطه پایانی را اثبات می‌کند و دیگری کاربر را. پیش از بازنشانی گذرواژه یا صدور دوباره گواهی، مشخص کنید کدام مرحله شکست خورده است.
دروازه شما می‌تواند هویت خود را با گواهی اثبات کند و هویت شما را از طریق EAP، و این ترکیب رایج است نه متناقض. دو سازوکار به پرسش‌های متفاوتی پاسخ می‌دهند: آیا این نقطه پایانی همانی است که انتظار دارم، و آیا این کاربر یا دستگاه مجاز است. دیدن EAP در یک نمایه اعتبارسنجی سرور را خاموش نمی‌کند. خواندن نمایه به‌عنوان یک تنظیم واحد همان چیزی است که مردم را به بازنشانی اعتبارنامه نادرست می‌فرستد.
پیش از دست زدن به هر یک از دو شیء، مشخص کنید کدام ادعا شکست خورده است. مرحله شکست این را به شما می‌گوید، اگر به ترتیب بخوانید.
دو اعتبارنامه، دو ادعا
گواهی سرور یک نام را به یک کلید پیوند می‌دهد و مشتری آن پیوند را با انبار اعتماد خود بررسی می‌کند. گواهی مشتری یک هویت را به یک کلید پیوند می‌دهد و دروازه بررسی می‌کند که گواهی ارائه‌شده به چیزی زنجیره شود که به آن اعتماد دارد. EAP تبادل احراز هویت را حمل می‌کند که محتوای آن به روش انتخاب‌شده بستگی دارد. این‌ها سه ساختار با طول عمر متفاوت، مالکان متفاوت و شیوه‌های شکست متفاوت هستند.
عبارت عبوری که یک کلید خصوصی را باز می‌کند گذرواژه حساب نیست، حتی وقتی هر دو درخواست در فاصله چند ثانیه از هم ظاهر شوند. یکی محلی در انبار کلید دستگاه است و دیگری را سرور احراز هویت پشت دروازه اعتبارسنجی می‌کند.
EAP یک ظرف است، نه یک روش
EAP یک چارچوب است: دروازه و مشتری بر سر یک روش مذاکره می‌کنند و روش تعیین می‌کند که گذرواژه، توکن، تبادل درونی تونل‌شده یا گواهی دخیل باشد، همان‌طور که مستندات strongSwan درباره IKEv2 بیان می‌کند. به همین دلیل EAP-TLS از سمت مشتری هیچ شباهتی به EAP-MSCHAPv2 ندارد، هرچند هر دو در یک منو به‌عنوان EAP ظاهر می‌شوند. نمایه‌ای که فقط EAP را نام می‌برد به شما نگفته است که از کاربر چه پرسیده می‌شود.
روش و بک‌اند را با هم بخوانید. بک‌اند قالب حساب، رفتار قفل‌شدن و آنچه بازنشانی گذرواژه واقعاً تغییر می‌دهد را تعیین می‌کند و هیچ‌یک از این‌ها در نمایه مشتری دیده نمی‌شود.
استقرار مختلط عادی است
گواهی سرور به‌همراه EAP برای کاربر شکلی است که بیشتر دروازه‌های دسترسی از راه دور مستقر می‌کنند، زیرا به مشتری یک نقطه پایانی قابل بررسی و به اپراتور هویت هر کاربر در یک انبار حساب مرکزی می‌دهد. استقرارهای گواهی مشتری هم وجود دارند، معمولاً جایی که هویت دستگاه مهم‌تر از گذرواژه است. هر دو مشروع‌اند و اشتباه این است که فرض کنید آنچه هفته گذشته دیدید همان چیزی است که پیش روی شماست.
روش و قالب حساب مستند را از اپراتور بخواهید، به‌جای استنتاج آن از نام فیلدها در یک مشتری.
تصمیم‌گیری از روی مرحله شکست
مشاهدات را مرتب کنید. خطای اعتماد پیش از هر درخواست کاربر مشکل گواهی سرور است و هیچ گذرواژه‌ای آن را درست نمی‌کند. درخواستی که پس از آن رد شدن بیاید مشکل احراز هویت کاربر است، و روش EAP و بک‌اند مظنون‌اند. احراز هویت موفق که پس از آن شکست child-SA بیاید هیچ‌یک از این دو نیست.
دو تمایز دیگر مهم است. مشتری‌ای که گواهی سرور را رد می‌کند معمولاً عدم تطابق نام یا مرجع ناشناخته را گزارش می‌کند که پرسشی درباره انبار اعتماد است. دروازه‌ای که کاربر را رد می‌کند غالباً روش EAP و دسته دلیل را ثبت می‌کند که پرسشی درباره حساب یا سیاست است.
به‌کارگیری دو مدل
برای گواهی‌ها کار عبارت است از صدور، تمدید، ابطال و حذف دستگاه‌های گمشده و بر اساس زمانی که شما کنترل می‌کنید رخ می‌دهد. برای EAP کار عبارت است از چرخه عمر حساب، پشتیبانی روش روی هر سکوی مشتری و هر عامل دومی که بک‌اند لازم دارد. هیچ‌یک از دو مدل به‌طور انتزاعی ارزان‌تر نیست؛ تیم‌های متفاوتی را درگیر می‌کنند. بنویسید استقرار شما واقعاً از کدام استفاده می‌کند، چون اسکریپت‌های پشتیبانی بیشتر از پیکربندی متفاوت‌اند.
آن‌ها را در یادداشت‌هایتان جدا نگه دارید. انقضای گواهی شکستی در یک تاریخ ایجاد می‌کند، قفل شدن حساب شکستی پس از تغییر گذرواژه ایجاد می‌کند و عدم تطابق روش شکستی فقط روی یک سکو ایجاد می‌کند.
پس از پذیرفته شدن هویت
احراز هویت یک دروازه است. انجمن امنیتی فرزند، انتخاب‌گرهای ترافیک، DNS و مجوزهای خود برنامه دروازه‌های بعدی هستند و هرکدام با شرایط خودش شکست می‌خورد. هویت پذیرفته‌شده‌ای که به هیچ‌جا نمی‌رسد مشکل احراز هویت نیست.
روش، حساب یا گواهی استفاده‌شده و مرحله‌ای که شکست خورد را ثبت کنید. آن یادداشت حادثه بعدی را به یک جست‌وجو تبدیل می‌کند، نه یک آزمایش.