جای MODP3072 در یک VPN از نوع Site-to-Site در AWS
MODP3072 همان گروه 15 IANA است، اما این گروه به یک فاز تعلق دارد. پیش از ویرایش تونل، نیازمندی را به فهرست‌های DH فاز 1 یا فاز 2 نگاشت کنید.
کسی برای شما نیازمندی‌ای می‌فرستد که در آن IKEv2، ESP و MODP3072 نوشته شده، و کنسول هیچ فیلدی با این نام ندارد. اشتباه این است که به دنبال چنین فیلدی بگردید. IKEv2 یک نسخه مذاکره است، ESP پروتکلی است که ترافیک محافظت‌شده شما را حمل می‌کند، و MODP3072 یک گروه تبادل کلید است، یعنی گروه 15 IANA. این سه واقعیت در سه جای متفاوت زندگی می‌کنند، و گروه دو بار ظاهر می‌شود.
این عبارت یک تنظیم واحد نیست
پیش از دست زدن به هر چیزی، نیازمندی را به فهرست‌های گزینه تبدیل کنید. جدول زیر کل نقشه تطبیق است.
| Agreed requirement | AWS option to review | Still a separate decision |
|---|---|---|
| IKEv2 | Allowed IKE versions | Encryption, integrity, key-exchange choices |
| MODP3072 for the IKE exchange | Phase 1 DH groups, group 15 | Phase 2 key-exchange and PFS policy |
| MODP3072 for the protected-traffic exchange | Phase 2 DH groups, group 15 | The initial IKE exchange group |
| A named encryption algorithm | That phase's encryption list | Integrity and DH-group agreement |
MODP3072 همان گروه 15 است و AWS در حال حاضر 15 را در فهرست گروه‌های DH فاز 1 و فاز 2 می‌پذیرد. پذیرفتن آن در هر دو جا به معنای الزامی کردن آن در هر دو جا نیست، و قطعاً به این معنا نیست که شریک شما هر دو را منظور داشته است.
فاز 1 و فاز 2 بر سر چیزهای متفاوتی مذاکره می‌کنند
فاز 1 انجمن امنیتی IKE را می‌سازد: اینکه دو دروازه چگونه احراز هویت می‌شوند، بر سر کلیدها توافق می‌کنند و گفت‌وگوی خودشان را محافظت می‌کنند. فاز 2 همان CHILD SA را می‌سازد که ترافیک واقعی شما را حمل می‌کند، و تبادل کلید آن می‌تواند تازه باشد نه به‌ارث‌رسیده.
همین تفکیک است که باعث می‌شود وقتی شریک از رازداری کامل رو به جلو حرف می‌زند، اهمیت داشته باشد. PFS ویژگی فاز 2 است، و گروهی در فهرست فاز 1 آن را فراهم نمی‌کند. بپرسید هر نیازمندی به کدام تبادل مربوط است، همراه با حالت رمزگذاری، اینکه یکپارچگی را رمز AEAD تأمین می‌کند یا نه، و انتظارات تجدید کلید در هر دو طرف.
از واژه AES یا از یک عدد DH یک مجموعه کامل قابل‌قبول استنتاج نکنید. سیاستی که از دو نیمه دو گفت‌وگو کنار هم گذاشته شده باشد، همان راهی است که یک تونل سرانجام چیزی را پیشنهاد می‌دهد که هیچ‌یک از دو تیم با آن موافق نبوده‌اند.
فهرست مجاز نتیجه مذاکره نیست
فهرست‌های گزینه توصیف می‌کنند که هر طرف حاضر است چه چیزی را بپذیرد. آنها گزارش نمی‌کنند که چه چیزی انتخاب شد. پیشنهادهای IKE و CHILD-SA را که واقعاً برای یک اتصال تازه انتخاب شده‌اند بخوانید، سپس تأیید کنید که نیازمندی برآورده شده است، نه اینکه فقط مجاز باشد. یک گزینه قوی در یک فهرست تنها ثابت می‌کند که در دسترس بوده است.
به تجدید هم توجه کنید. نخستین CHILD SA در IKEv2 و یک تبادل CHILD بعدی که PFS دارد می‌توانند شرایط سازگاری متفاوتی را آشکار کنند، زیرا تبادل دوم مواد کلید تازه با حضور گروه PFS می‌سازد. اگر آزمون پذیرش شما فقط یک دقیقه اول تونل را پوشش می‌دهد، بخشی را که برای شریک شما مهم است آزمون نکرده است.
مرجع گزینه‌های تونل AWS فاز 1 و فاز 2 را جداگانه فهرست می‌کند، و همین ساختار است که ارزش دارد پیش از رسیدن نیازمندی بعدی درونی‌اش کنید.
همان تونلی را تغییر دهید که واقعاً منظورتان است
یک اتصال VPN از نوع Site-to-Site دو تونل دارد با گزینه‌ها و وضعیت خودشان. پیش از بازبینی یا ویرایش هر چیزی، نشانی بیرونی تونل AWS را با همتای سمت دروازه مشتری تطبیق دهید و فرض نکنید که یک ذخیره هر دو را به‌روز می‌کند.
یک تغییر تأییدشده نیاز دارد که سمت دروازه مشتری برای همان سیاست آماده باشد و پنجره‌ای برای وقفه‌ای که تونل انتخاب‌شده خواهد داشت. اگر همتا در فازی که تغییر می‌دهید برای گروه 15 آماده نباشد، تونل به‌سادگی از بالا آمدن بازمی‌ایستد و کنسول به شما نمی‌گوید کدام طرف امتناع کرده است.
سیاست توافق‌شده را به‌صورت فاز، نسخه پروتکل، رمزگذاری، یکپارچگی و گروه DH ثبت کنید، سپس آن را در تبادلاتی که قرار است محافظت کند تأیید کنید. مسیریابی، انتخاب‌گرهای ترافیک و مجوزهای برنامه جدا می‌مانند؛ این نگاشت یک پیکربندی کامل دروازه نیست و توصیه‌ای برای فعال‌کردن الگوریتم‌های اضافی به‌دلیل تنوع هم نیست.