تنظیمات IKEv2 را برای بیش‌از یک کلاینت برنامه‌ریزی کنید
یک پروفایل دسکتاپِ کارآمد تنها یک کلاینت را آزموده است. قرارداد هویت را توافق کنید، یک اشتراک پشتیبانی‌شده انتخاب کنید و سپس نوسازی و خواب را برای هر سکو آزمون کنید.
یک پروفایل کارآمد روی یک دسکتاپ، آزمون موفق یک کلاینت است. این یک استقرار چند‌سکویی نیست، و برخورد با آن به‌عنوان چنین، الگوی پشتیبانی آشنایی پدید می‌آورد: Windows وصل می‌شود، تلفن در بررسی هویت شکست می‌خورد، و لپ‌تاپ مدیریت‌شده هر بار که بیدار می‌شود دوباره وصل می‌شود. تفاوت‌ها واقعی و عمدتاً قابل پیش‌بینی‌اند، به همین دلیل برنامه باید یک ماتریس باشد، نه یک تصویر از صفحه.
نخست قرارداد هویت را تعیین کنید
پیش از بحث دربارهٔ الگوریتم‌ها، هویت سرور، اعتماد به گواهی و روش احراز هویت کلاینت را مستند کنید. این سه تعیین می‌کنند که آیا کلاینت اصلاً می‌تواند احراز هویت شود، و همان بخش‌هایی هستند که سکوها به‌شکل متفاوت بیان می‌کنند.
بررسی کنید هر سکو شناسهٔ مورد انتظار را چگونه می‌نامد و نام‌های جایگزین موضوع را چگونه مدیریت می‌کند. پروفایلی که نام سرور را روی یک کلاینت می‌پذیرد، ممکن است همان گواهی را روی کلاینت دیگری رد کند، زیرا فیلد شناسه از مقدار متفاوتی پر می‌شود.
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
سپس اشتراک رمزنگاری را انتخاب کنید
پیشنهادهایی را که هر کلاینت پشتیبانی‌شده می‌تواند ارائه دهد مقایسه کنید و اشتراکی مدرن انتخاب کنید که دروازه نیز آن را مجاز می‌داند. فهرست قدیمی بیش‌از‌حد بزرگ را فعال نکنید تا یک دستگاه قدیمی وصل شود، چون آن فهرست به پیش‌فرض دروازه برای همهٔ بعدی‌ها تبدیل می‌شود. بنویسید چرا هر گزینهٔ قدیمی هنوز آنجاست. اگر هیچ‌کس نمی‌تواند دستگاهی را که به آن نیاز دارد نام ببرد، این یک نیازمندی نیست.
تنظیمات IKE و CHILD را در برنامه جدا نگه دارید. پیشنهادی که برای تبادل IKE پذیرفتنی است، به‌طور خودکار برای ترافیک محافظت‌شده پذیرفتنی نیست، و این دو جداگانه مذاکره می‌شوند. دروازه‌ای که پیشنهادی را در یک لایه می‌پذیرد، هنوز می‌تواند آن را در لایهٔ دیگر رد کند، و گزارش خطایی را نشان می‌دهد که چنان به نظر می‌رسد لایهٔ اول موفق بوده است.
اعتبارنامه‌ها را از طریق فرایندی بررسی‌شده تأمین کنید، و گذرواژهٔ کاربر، راز مشترک و کلید خصوصی کلاینت را در فیلدهای خودشان نگه دارید. آزمون و خطا روی جعبه‌هایی با نام‌های مشابه، همان راهی است که یک آزمون کارآمد به آزمونی غیرقابل‌تکرار تبدیل می‌شود.
چرخهٔ عمر را بیازمایید، نه حالت پایدار را
برای هر کلاینت، احراز هویت اولیه، برنامهٔ مورد نظر، حل DNS و پوشش خانواده‌های نشانی را بیازمایید. سپس بخش‌هایی را که تنها بعداً ظاهر می‌شوند تمرین کنید: نوسازی، خواب و یک تغییر عادی شبکه.
پشتیبانی MOBIKE و رفتار احراز هویت دوباره می‌توانند با نتیجهٔ پایدارِ همین حالا اندازه‌گرفته‌شده متفاوت باشند. رویداد و وضعیت انجمن را در همان لحظه ثبت کنید، نه فقط اینکه واسط در نهایت متصل به نظر می‌رسد.
تعیین کنید ترافیک مستقیم در زمانی که VPN در دسترس نیست چه کاری می‌تواند انجام دهد. این تصمیمی سیاستی جدا از اینکه کلاینت دوباره وصل می‌شود یا نه است، و بیشتر استقرارها به پرسش دوم پاسخ می‌دهند در حالی که اولی را نادیده می‌گیرند. پاسخ را در یادداشت‌های استقرار کنار نام پروفایل‌ها بنویسید. کسی در هنگام یک قطعی به آن نیاز پیدا می‌کند و وقتی برای بازسازی آن نخواهد داشت.
وقتی یک سکو اختلاف دارد از بررسی‌های هویت سرور استفاده کنید
وقتی پروفایلی روی یک سکو کار می‌کند و دیگری نامش را رد می‌کند، شناسه‌ای را که کلاینت واقعاً فرستاده با شناسه‌هایی که گواهی حمل می‌کند مقایسه کنید. این مقایسه بیشتر این موارد را سریع‌تر از تغییر فهرست‌های رمز حل می‌کند.
ماتریس آزمون‌شده را همراه با منبع پیکربندی و رویهٔ به‌روزرسانی نگه دارید. وقتی پشتیبانی از یک کلاینت قدیمی پایان می‌یابد، استثنای آن را عمداً بردارید، به‌جای اینکه تنظیمات سازگاری ضعیف‌تر را پنهان در دروازه بگذارید تا حسابرسی بعدی آن‌ها را پیدا کند. مستندات strongSwan دربارهٔ IKEv2 مرجعی سودمند برای چگونگی پیکربندی تبادل‌هاست.