IKEv1 با XAuth و OTP: هر اعلان چه می‌خواهد
یک PSK گروهی، یک تبادل XAuth کاربر و یک چالش OTP سه ورودی متفاوت‌اند. پیش از نصب کلاینت دیگر، هر اعلان را به صاحبش نسبت دهید.
IKEv1 با PSK، XAuth و OTP یک گذرواژه پیچیده نمی‌خواهد. این پروتکل یک کلید مشترک میان همتاها، یک تبادل کاربر و یک عامل دوم را لایه‌لایه می‌کند که بک‌اند تصمیم می‌گیرد چگونه آن را بخواهد. هر لایه صاحب خودش و پیام خطای خودش را دارد. اشتباه گرفتن آن‌ها باعث می‌شود مردم کد یک‌بارمصرف را در فیلدی بازنویسی کنند که یک راز گروهی را نگه می‌دارد.
پیش از نصب کلاینت دیگر یا بازنشانی یک اعتبارنامه، هر اعلان را به لایه‌ای که آن را می‌خواهد نسبت دهید.
سه راز، سه صاحب
کلید مشترک از پیش تعیین‌شده به رابطه همتاها تعلق دارد و یک بار توسط کسی که هر دو سر را دارد تنظیم می‌شود. اعتبارنامه کاربر به بک‌اند احراز هویت تعلق دارد و در هر ورود بررسی می‌شود. عامل دوم به یک سامانه توکن تعلق دارد که پاسخش در هر تلاش تغییر می‌کند. هیچ‌کدام جایگزین دیگری نیست، و استقرارهایی که آن‌ها را یک گذرواژه می‌بینند در لایه‌ای شکست می‌خورند که کسی مستندش نکرده است.
سه ستون بنویسید: صاحب، عمر و پیام خطایی که هرکدام تولید می‌کند. همان جدول ابزار عیب‌یابی است، نه نام فیلدهای کلاینت.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: همتا، نه شخص
کلید مشترک از پیش تعیین‌شده در این چیدمان قدیمی جفت دروازه را احراز می‌کند، پس ورود کاربر هرگز جایگزین آن نمی‌شود. همچنین مقداری است که بیشترین احتمال خطا را دارد، به‌گونه‌ای که به‌جای یک فیلد، خطای مذاکره عمومی تولید می‌کند. وقتی تونل پیش از ظهور هر فیلد کاربر شکست می‌خورد، مظنون‌ها کلید یا پیشنهادها هستند.
اعتبارنامه کاربر نمی‌تواند خرابی فاز یک را ترمیم کند. چرخاندن آن تنها اعتبارنامه‌ای را هدر می‌دهد که می‌توانید با خیال راحت بچرخانید و نظریه غلط را تقویت می‌کند.
XAuth: تبادل کاربر قدیمی
XAuth یک تبادل احراز هویت کاربر روی احراز هویت همتای IKEv1 اضافه می‌کند و دروازه تعیین می‌کند کدام بک‌اند آن را اعتبارسنجی می‌کند. بسته به آن بک‌اند، تبادل ممکن است گذرواژه دایرکتوری، اعتبارنامه RADIUS یا پاسخ توکن را بپذیرد. واژه XAuth نام انتقال تبادل است، نه نوع اعتبارنامه.
بررسی کنید پروفایل دروازه به کدام بک‌اند اشاره می‌کند. این به شما می‌گوید از کاربر چه خواسته می‌شود و بازنشانی گذرواژه در واقع چه چیزی را تغییر می‌دهد، و هیچ‌کدام در پروفایل کلاینت دیده نمی‌شود.
OTP: هر چیزی که بک‌اند بخواهد
برخی استقرارها پس از گذرواژه یک کد یک‌بارمصرف جداگانه می‌خواهند، و برخی دیگر قالبی ترکیبی با جداکننده مستند تعریف می‌کنند. هر دو وجود دارند و پروفایل پیش روی شما تعیین می‌کند کدام. ساختن یک الحاق چون در جای دیگری کار کرده، رایج‌ترین راه سوزاندن توکن ثبت‌نام است. مستندات خود دروازه تنها منبعی است که این را روشن می‌کند.
از قالب مستند با کلاینتی استفاده کنید که بتواند تبادلی را که دروازه ارائه می‌دهد کامل کند.
کجا مرز کلاینت گاز می‌گیرد
Fortinet مستند می‌کند که FortiClient 7.4.4 و نسخه‌های بعدی دیگر از IKEv1 برای VPNهای IPsec پشتیبانی نمی‌کنند، که مرزی مربوط به محصول و نسخه است نه حذف همگانی، چنان‌که یادداشت سازگاری FortiClient ثبت می‌کند. کلاینت‌های دیگر هم قابل تعویض نیستند: OpenConnect و openfortivpn پروتکل‌های مشخص دروازه را صحبت می‌کنند، نه پروفایل‌های دلخواه IKEv1. نسخه IKE، حالت PSK، پشتیبانی XAuth و مدل تعامل کلاینت نصب‌شده را جداگانه بررسی کنید. کلاینتی که با روش دیگری وصل می‌شود نیاز اصلی را اثبات نکرده است.
IKEv1 منسوخ است، پس استقرار جدید روی کلاینت قدیمی بدون پشتیبانی راه‌حلی کوتاه‌عمر است. از صاحب دروازه یک مسیر مهاجرت پشتیبانی‌شده بخواهید، از جمله اینکه عامل دوم آنجا چگونه مدیریت می‌شود.
عیب‌یابی بدون خاموش کردن عامل
مراحل را در گزارش جدا کنید: مذاکره همتاها، تبادل کاربر، نتیجه عامل دوم، سپس تخصیص نشانی و مسیر. به‌جای آزمودن کد در هر فیلد، مؤلفه و مرحله را ثبت کنید. خاموش کردن عامل تا یک آزمون قبول شود، تونلی می‌سازد که هیچ چیز درباره استقرار اثبات نمی‌کند.
رازهای ثبت‌نام و کلید مشترک را در انبار محافظت‌شده و مطابق فرایند سازمان نگه دارید. کد یک‌بارمصرف در یک فایل پایا عاملی است که دیگر عامل نیست.