IKEv2 آدرس سرور در مقابل هویت: آنچه مشتری واقعاً بررسی می‌کند

دروازه ای که آدرس را تغییر می دهد می تواند به کار خود ادامه دهد در حالی که همان دروازه در پشت یک گواهی جدید متوقف می شود، و عکس آن نیز اتفاق می افتد. آدرس به مشتری می گوید که بسته ها را کجا ارسال کند، هویت احراز هویت شده به مشتری می گوید که آیا همتای پاسخ دهنده همان کسی است که باید به او اعتماد کند یا خیر. IKEv2 آن‌ها را به‌عنوان دو فیلد مجزا نگه می‌دارد، که زمانی مفید است که آنها را به عنوان یک رشته در نظر نگیرید. آنها همچنین در مکان های مختلف پیکربندی شده اند، بنابراین یکی می تواند درست باشد در حالی که دیگری اشتباه است.

آنها را به این ترتیب بررسی کنید و در اولین عدم تطابق متوقف شوید، زیرا بررسی های بعدی فرض می کنند که چک های قبلی پاس شده اند.

اول اینکه کدام مقدار آدرس است

آدرس اتصال هر چیزی است که کلاینت شماره گیری می کند: یک IP، یک نام DNS که به یک تبدیل می شود، یا یک صفحه جلویی با بار متعادل. این اطلاعات حمل و نقل است و هیچ چیز بیشتر. هویت در محموله ID IKEv2 سوار می شود و سپس با گواهی نامه همتا مطابقت می یابد. یک نام DNS در کادر آدرس به هویت مورد انتظار تبدیل نمی‌شود، و یک IP خام فقط به این دلیل که سوکت به آن متصل است، به هویت تبدیل نمی‌شود.

در شرایط strongSwan، آدرس right یا left است، و هویت مورد انتظار rightid یا leftid است، و این همان چیزی است که IKEv2 اسناد پیکربندی توضیح می‌دهد. اگر فقط آدرس را ویرایش کرده اید، نیمی از جفت را پیکربندی کرده اید.

دوم، آنچه گواهی می تواند ثابت کند

هویت دارای یک نوع است و گواهی باید دارای یک نام منطبق باشد. هویت DNS با یک ورودی dNSName در پسوند نام جایگزین موضوع ارضا می شود، یک هویت IP به یک ورودی iPAddress نیاز دارد. گواهی صادر شده برای vpn.example.com چیزی را در مورد آدرس تحت اللفظی 203.0.113.10 ثابت نمی کند، و گواهی صادر شده برای آن آدرس چیزی در مورد نام ثابت نمی کند. بنابراین، انتشار مجدد برای یک نام دیگر، حتی زمانی که کلید یکسان و CA مجدداً مورد استفاده قرار می‌گیرند، جایگزینی کشویی نیست.

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

سوم اینکه هر مشتری چگونه انتظارات خود را بیان می کند

Windows نام سرور یا آدرسی را که تایپ کرده‌اید می‌گیرد و نیاز به گواهی دارد که با آن مطابقت داشته باشد، بنابراین تایپ IP یک انتظار IP ایجاد می‌کند. کلاینت Android IKEv2 یکسان رفتار می کند و هر دو یک گواهی معتبر و مورد اعتماد عمومی را که میزبان متفاوتی را نام می برد، رد می کنند. یک نمایه ممکن است شروع به شکست کند فقط به این دلیل که شخصی نام میزبان را با آدرس آن در طول مهاجرت جایگزین کرده است. قبل از اینکه به محتوای گواهی نگاه کنید، به آنچه مشتری خواسته است نگاه کنید.

در strongSwan انتظار صریح است: rightid را روی هویتی که سرور واقعاً ارائه می‌کند، تنظیم کنید، که ممکن است با سمت راست متفاوت باشد. تنظیم آن بر روی %any هر چیزی را که همتا ارائه می‌دهد می‌پذیرد و دقیقاً چکی را که می‌خواهید نگه دارید حذف می‌کند.

چهارم، ورود کاربر را از هویت همتا جدا کنید

EAP احراز هویت و هویت سرور به سؤالات مختلفی پاسخ می دهد. هویت EAP مانند [email protected] می‌گوید کاربر کیست، پس از اینکه کلاینت تصمیم گرفت که سرور مناسب است. چرخاندن آن رمز عبور نمی‌تواند عدم تطابق هویت همتا را برطرف کند، زیرا اتصال هرگز به مرحله ورود کاربر نمی‌رسد.

یک گزارش بهداشتی باید هر دو را نام‌گذاری کند: هویتی که مشتری انتظار داشت، هویتی که سرور ارائه می‌کند و ورودی‌های SAN گواهی.

پنجم، آن را از طریق یک کانال تایید شده تغییر دهید

هنگامی که دروازه به طور قانونی حرکت می‌کند، ابتدا آدرس را به روز کنید و هویت را به حال خود رها کنید، زیرا این موردی است که IKEv2 به خوبی از عهده آن بر می‌آید. وقتی هویت خود تغییر می کند، آن را به عنوان یک رویداد اعتماد در نظر بگیرید و ارزش جدید را از منبعی که قبلاً به آن اعتماد دارید، دریافت کنید، نه از نقطه پایانی که در حال حاضر در حال شکست است. پیامی که از طریق اتصالی که می‌خواهید تأیید کنید، ارائه می‌شود، مدرکی در مورد آن اتصال نیست.

آدرس نهایی، هویت و فهرست SAN را با هم در یادداشت های نمایه ثبت کنید. نفر بعدی که گواهی را لمس می کند، می بیند که کدام یک از این سه مورد مجاز به حرکت هستند.