IKEv2 NO_PROPOSAL_CHOSEN: ขั้นตอนใดปฏิเสธชุดนี้

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

ก่อนอื่น การแลกเปลี่ยนใดถูกปฏิเสธ

IKEv2 เจรจาความเชื่อมโยงสองประเภท IKE SA ปกป้องการเจรจาเอง และ CHILD SA ปกป้องทราฟฟิก แต่ละอย่างมีชุดข้อเสนอของตัวเอง และแต่ละอย่างล้มเหลวได้ด้วยการแจ้งเตือนเดียวกัน การปฏิเสธระหว่างการเจรจา IKE เริ่มต้นและการปฏิเสธระหว่างการเจรจา CHILD ต้องแก้ต่างกัน และบันทึกมักระบุชื่อการแลกเปลี่ยนหนึ่งหรือสองบรรทัดเหนือการแจ้งเตือนอ่านสองบรรทัดนั้นด้วยกัน ไม่อย่างนั้นคุณจะแก้ไขรายการข้อเสนอผิด

การแจ้งเตือนเพียงอย่างเดียวไม่ระบุการแลกเปลี่ยน บรรทัดเหนือขึ้นไประบุ SA ที่กำลังเจรจา และชื่อนั้นชี้ไปยังรายการข้อเสนอที่ต้องตรวจสอบ

เปรียบเทียบชุดทั้งหมด ไม่ใช่คำสำคัญเดี่ยว

ข้อเสนอคือการรวมกันของอัลกอริทึมการเข้ารหัส ความสมบูรณ์หรือ AEAD กลุ่มแลกเปลี่ยนคีย์ และฟังก์ชันสุ่มเทียมใด ๆ การเปรียบเทียบเพียงชื่อการเข้ารหัสเป็นข้อผิดพลาดทั่วไป เพราะคู่ค้าสองฝ่ายอาจเห็นตรงกันเรื่อง AES-256 แต่ยังไม่ตรงกันเรื่อง SHA-1 กับ SHA-256 เขียนชุดที่เสนอและชุดที่อนุญาตวางข้างกันในขั้นตอนที่ล้มเหลว แล้วมองหาส่วนตัดที่ว่างเปล่า

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

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

ชุด IKE และชุด ESP เป็นวัตถุที่แตกต่างกัน

การแก้ไขข้อเสนอ IKE จะไม่ซ่อมข้อเสนอ CHILD ที่ถูกปฏิเสธ และกลับกันก็เป็นจริงเช่นกัน ใน strongSwan สิ่งเหล่านี้เป็นการตั้งค่าแยกกัน โดยประมาณ proposals = aes256-sha256-modp2048 สำหรับ IKE SA และรายการ ESP แยกสำหรับ CHILD SA เปลี่ยนรายการที่ตรงกับการแลกเปลี่ยนที่ล้มเหลว แล้วอ่านบันทึกอีกครั้งแทนการสันนิษฐานว่าการแก้ไขได้ผล

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

อุโมงค์ที่ทำงานได้แต่ล้มเหลวเมื่อต่ออายุคีย์

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

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

ipsec statusall | grep -E "IKE:|ESP:"

เลือกส่วนตัด แล้วยืนยันทั้งสองเฟส

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

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