FortiGate Azure รีคีย์: ข้อเสนอ peer SA ไม่ตรงกับนโยบายภายใน

อุโมงค์ขึ้นมา การรับส่งข้อมูลไหล แล้วภายหลังบันทึกบอกว่า peer SA proposal not match local policy. คนส่วนใหญ่อ่านบรรทัดนั้นเป็นหลักฐานว่าการกำหนดค่าทั้งสองไม่เคยตรงกันเลย ปกติแล้วมันหมายถึงสิ่งที่แคบกว่า: ทั้งสองตรงกันสำหรับ CHILD SA แรก และเลิกตรงกันในการต่ออายุครั้งแรก เพราะสมาคมแรกไม่เคยต้องใช้การแลกเปลี่ยนที่สมาคมหลัง ๆ ทำ การแยกแยะนี้เป็นตัวกำหนดว่าคุณควรดูที่ใด

CHILD SA แรกสืบทอด สมาคมหลัง ๆ เจรจา

ใน IKEv2 นั้น CHILD SA เริ่มต้นถูกสร้างขึ้นระหว่าง IKE_AUTH และกุญแจของมันได้มาจากวัสดุกุญแจของ IKE SA ในขณะนั้นไม่มีการแลกเปลี่ยน Diffie-Hellman แยกต่างหาก กลุ่ม PFS ที่ peer ฝ่ายหนึ่งยอมรับไม่ได้จึงยังไม่ถูกทดสอบ อุโมงค์ดูปกติเพราะข้อกำหนดที่คุณจะล้มเหลวในภายหลังไม่เคยถูกทดสอบเลย

การรีคีย์ CHILD_SA เป็นลำดับข้อความที่แตกต่างออกไป เมื่อกำหนดค่า PFS แล้ว peer จะทำการแลกเปลี่ยนกุญแจใหม่และต้องตกลงกันในกลุ่มที่ทั้งสองฝ่ายยอมรับ รวมถึงข้อเสนอ ESP สำหรับสมาคมใหม่ นั่นคือช่วงเวลาที่ความไม่ตรงกันปรากฏชัด และเป็นเหตุผลที่ข้อผิดพลาดระบุชื่อข้อเสนอไม่ใช่เส้นทาง

ดังนั้น “เมื่อวานมันทำงานได้” ไม่ได้บอกอะไรคุณเกี่ยวกับข้อเสนอเลย มันบอกว่าการแลกเปลี่ยนเริ่มต้นสำเร็จ ซึ่งคุณรู้อยู่แล้ว

อ่านการแลกเปลี่ยนที่ล้มเหลว ไม่ใช่ ping แรก

ก่อนจะเปลี่ยนอะไร ให้รวบรวมการพิสูจน์ตัวตน IKE ที่สำเร็จ CHILD SA เริ่มต้น และการแทนที่ที่ล้มเหลวจากทั้งสองฝั่ง จากนั้นเรียกการดำเนินการให้ถูกต้อง: การรีคีย์ IKE SA การพิสูจน์ตัวตน IKE ใหม่ และการรีคีย์ CHILD SA เป็นสามเหตุการณ์ที่ต่างกัน และ “ระยะที่ 2” ครอบคลุมทั้งหมดในการพูดคุยทั่วไป

เปรียบเทียบฟิลด์ด้านล่างสำหรับการเชื่อมต่อที่ล้มเหลว ไม่ใช่สำหรับอุโมงค์โดยทั่วไป

บน FortiGate ให้เปิดข้อเสนอระยะ-2 การตั้งค่า PFS และกลุ่ม DH ที่ยอมรับสำหรับอุโมงค์นั้น อ่านค่าที่โหลดไว้แทนการอนุมานจากการเชื่อมต่อที่สร้างไว้ก่อนหน้า ภาพหน้าจอของหน้า GUI เป็นหลักฐานที่อ่อนกว่าการกำหนดค่าที่กำลังทำงาน เพราะทั้งสองอาจไม่ตรงกันหลังการอัปเกรด ส่งออกส่วนที่คุณแก้ไขและเก็บไว้กับตั๋ว

นโยบายเริ่มต้นของ Azure ก็ยังเป็นนโยบาย

การไม่มีนโยบายกำหนดเองแนบอยู่กับการเชื่อมต่อไม่ได้หมายความว่า Azure ไม่ได้ใช้นโยบายใดเลย การเชื่อมต่อจะถอยกลับไปใช้ชุดข้อเสนอเริ่มต้นของเกตเวย์ ซึ่งอาจกว้างหรือแคบกว่าสิ่งที่ FortiGate ของคุณเสนอ หากชุดทั้งสองทับซ้อนกันสำหรับ IKE แต่ไม่ทับซ้อนสำหรับ ESP ที่มี PFS คุณจะได้รูปแบบความล้มเหลวนี้พอดี

มุมมองแบบอ่านอย่างเดียวนี้แสดงนโยบายที่แนบอยู่จริง โดยไม่เปิดเผยความลับ:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

ใช้ชื่อทรัพยากรจริงของคุณ เมื่อต้องการนโยบายที่ชัดเจน ให้ตั้งค่าบนทรัพยากรการเชื่อมต่อ มันไม่ใช่สวิตช์ทั้งเกตเวย์ และไม่ได้ใช้อย่างเงียบ ๆ กับอุโมงค์อื่นบนเกตเวย์เดียวกัน

ในพอร์ทัล หน้า Configuration ของการเชื่อมต่อนั้นคือที่ซึ่งนโยบาย IPsec/IKE กำหนดเองไปอยู่ คู่มือของ Microsoft เกี่ยวกับ นโยบายกำหนดเอง แสดงรายการพารามิเตอร์ที่รองรับและข้อกำหนด SKU Azure ใช้ชุดค่าผสมที่สมบูรณ์หนึ่งชุดต่อการเชื่อมต่อ ดังนั้นคุณระบุฟิลด์ IKE และฟิลด์ IPsec ด้วยกัน ไม่ใช่ทีละอย่าง

PFS เป็นข้อกำหนด ไม่ใช่สวิตช์ที่จะพลิก

หากเส้นฐานความปลอดภัยของคุณต้องการ PFS ทางออกคือกลุ่มที่ peer ทั้งสองฝ่ายยอมรับทั้งสองด้าน ซึ่งแสดงออกผ่านนโยบายที่ตรงกัน การปิด PFS เพื่อให้ข้อผิดพลาดหายไปจะเปลี่ยนคุณสมบัติความปลอดภัยที่คุณพยายามรักษาไว้ และโดยปกติมันจะกลับมาในภายหลังเป็นความไม่ตรงกันอีกรูปแบบหนึ่ง

กับดักหนึ่งที่เฉพาะกับ Azure: เมื่อคุณเลือก GCM สำหรับ ESP การเลือกการเข้ารหัสและความสมบูรณ์ต้องระบุอัลกอริทึม GCM และความยาวกุญแจเดียวกัน การผสมไซเฟอร์ GCM กับอัลกอริทึมความสมบูรณ์แยกต่างหากจะสร้างชุดค่าผสมที่บริการปฏิเสธ และดูเหมือนความไม่ตรงกันระหว่าง peer จนกว่าคุณจะอ่านนโยบายอย่างละเอียด

เลือกชุดค่าผสมที่แข็งแกร่งที่สุดที่ทั้งสองฝ่ายรองรับและข้อกำหนดของคุณอนุญาต แล้วบันทึกไว้ในบันทึกการเปลี่ยนแปลง คนถัดไปจะเปรียบเทียบกับบันทึกนั้น ไม่ใช่กับความทรงจำเรื่องอุโมงค์ที่เคยทำงาน ใส่กลุ่ม PFS และข้อเสนอ ESP ลงไป ไม่ใช่แค่ชื่อนโยบาย เมื่อมีคนถามภายหลังว่าทำไมการตรวจสอบล้มเหลวหรือทำไมการรีคีย์ช้า บรรทัดนั้นตอบทั้งสองคำถาม

ตรวจสอบการแลกเปลี่ยนที่ล้มเหลว

วางแผนการเปลี่ยนแปลงพร้อมเส้นทางการกู้คืน เพราะการแก้ไขนโยบายอาจขัดจังหวะอุโมงค์ที่คุณพยายามแก้ไข หลังจากข้อมูลกลับมา ให้รอหรือกระตุ้นการต่ออายุ CHILD_SA และยืนยันว่าสมาคมใหม่ถูกสร้างด้วยกลุ่ม PFS ที่ตั้งใจไว้ จากนั้นยืนยันว่าข้อมูลแอปพลิเคชันยังคงไหลผ่านมัน

มีเบาะแสลวงสองอย่างที่ควรกล่าวถึง อายุการใช้งาน SA เป็นข้อกำหนดภายใน ค่าที่ไม่เท่ากันจึงเป็นเรื่องปกติ และการเปลี่ยนค่าจะเลื่อนเวลาที่ปัญหาเกิดขึ้นเท่านั้น DPD ตรวจจับว่า peer ยังมีชีวิตอยู่หรือไม่ การเพิ่มเวลาหมดอายุไม่ได้ทำให้การเลือก ESP หรือ PFS ตรงกัน

บันทึกผลลัพธ์ที่เจรจาได้และเหตุการณ์ถัดไปหลังการเปลี่ยนแปลง หากการเชื่อมต่อล้มเหลวก่อนการพิสูจน์ตัวตน IKE จะเสร็จสิ้นตอนนี้ คุณกำลังดูการตั้งค่า IKE ที่เพิ่งแก้ไข ไม่ใช่ความล้มเหลวของการต่ออายุ CHILD ดั้งเดิม