איפה MODP3072 נכנס ב-VPN Site-to-Site של AWS
MODP3072 הוא קבוצה 15 של IANA, אבל הקבוצה שייכת לשלב. יש למפות את הדרישה לרשימות ה-DH של Phase 1 או Phase 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 של Phase 1 וגם בזו של Phase 2. לקבל אותה בשני המקומות אינו אותו דבר כמו לדרוש אותה בשניהם, וזה בוודאי לא אומר שהשותף שלך התכוון לשניהם.
Phase 1 ו-Phase 2 מנהלים משא ומתן על דברים שונים
Phase 1 בונה את אגודת האבטחה של IKE: איך שתי השערים מאמתים זה את זה, מסכימים על מפתחות ומגנים על השיחה שלהם. Phase 2 בונה את ה-CHILD SA שנושא את התעבורה בפועל, והחלפת המפתחות שלו יכולה להיות חדשה ולא בירושה.
ההפרדה הזו היא הסיבה שיש משמעות לכך ששותף מדבר על סודיות קדימה מושלמת. PFS הוא מאפיין של Phase 2, וקבוצה ברשימת Phase 1 אינה מספקת אותו. שאל לאיזו החלפה חלה כל דרישה, יחד עם מצב ההצפנה, אם השלמות מסופקת על ידי צופן AEAD, ומה הציפיות לחידוש מפתחות בשני הצדדים.
אל תסיק חבילה קבילה שלמה מהמילה AES או ממספר DH אחד. מדיניות שמורכבת משני חצאים של שתי שיחות היא הדרך שבה מנהרה מגיעה להציע משהו שאף צוות לא הסכים לו.
רשימה מורשית אינה תוצאה של משא ומתן
רשימות האפשרויות מתארות מה כל צד מוכן לקבל. הן אינן מדווחות מה נבחר. קרא את הצעות IKE וה-CHILD-SA שנבחרו בפועל לחיבור חדש, ואז אשר שהדרישה מתמלאת ולא רק מורשית. אפשרות חזקה ברשימה מוכיחה רק שהייתה זמינה.
שווה לב גם לחידוש. ה-CHILD SA הראשון ב-IKEv2 והחלפת CHILD מאוחרת יותר עם PFS יכולות לחשוף תנאי תאימות שונים, משום שההחלפה השנייה יוצרת חומר מפתח חדש עם קבוצת ה-PFS בפעולה. אם מבחן הקבלה שלך מכסה רק את הדקה הראשונה של מנהרה, הוא לא בדק את החלק שאכפת לשותף שלך.
מסמך האפשרויות של המנהרה ב-AWS מפרט את Phase 1 ו-Phase 2 בנפרד, וזה המבנה ששווה להפנים לפני שהדרישה הבאה תגיע.
שנה את המנהרה שאתה באמת מתכוון אליה
לחיבור VPN Site-to-Site יש שתי מנהרות עם אפשרויות משלהן ומצב משלהן. לפני שאתה בודק או עורך משהו, התאם את הכתובת החיצונית של מנהרת AWS לעמית בצד שער הלקוח ואל תניח ששמירה אחת מעדכנת את שתיהן.
שינוי מאושר דורש שצד שער הלקוח יהיה מוכן לאותה מדיניות וחלון זמן להפרעה שהמנהרה הנבחרת תגרום. אם העמית אינו מוכן לקבוצה 15 בשלב שאתה משנה, המנהרה פשוט תפסיק לעלות, והקונסולה לא תספר לך איזה צד סירב.
תעד את המדיניות המוסכמת כשלב, גרסת פרוטוקול, הצפנה, שלמות וקבוצת DH, ואז אמת אותה בהחלפות שהיא אמורה להגן עליהן. ניתוב, בוררי תעבורה והרשאות אפליקציה נשארים בנפרד; המיפוי הזה אינו תצורת שער מלאה, והוא אינו המלצה להפעיל אלגוריתמים נוספים לשם גיוון.