MODP3072 อยู่ตรงไหนใน AWS Site-to-Site VPN
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 แล้วยืนยันในการแลกเปลี่ยนที่มันควรปกป้อง การกำหนดเส้นทาง ตัวเลือกทราฟฟิก และสิทธิ์ของแอปพลิเคชันยังแยกกัน การจับคู่นี้ไม่ใช่การกำหนดค่าเกตเวย์ทั้งหมด และไม่ใช่คำแนะนำให้เปิดใช้อัลกอริทึมเพิ่มเติมเพื่อความหลากหลาย