ทำไมอุโมงค์ IPsec ของคุณจึงทำงานได้จนถึงการเปลี่ยนคีย์ CHILD SA ครั้งแรก

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

เชื่อมต่อได้ไม่ได้หมายความว่าการตั้งค่า PFS ตรงกัน

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

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

ความไม่ตรงกันซ่อนอยู่ตรงไหนในสตริงข้อเสนอ

ใน strongSwan กลุ่มถูกต่อท้ายข้อเสนอของลูก ดังนั้นสตริงอย่าง aes256gcm16-prfsha256-ecp256 จึงดูเหมือนการเลือกอัลกอริทึมเข้ารหัส แต่ก็แบกข้อกำหนดเรื่องการแลกคีย์ไว้ด้วย ฝั่งที่เสนอเพียง aes256gcm16-prfsha256 ไม่มีข้อกำหนดนั้น และรายการทั้งสองตัดกันเรื่องการเข้ารหัสแต่ต่างกันเรื่องการแลกเปลี่ยน

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

อ่านความล้มเหลว ไม่ใช่ไฟล์ที่คุณแก้

หา notify ที่ทำให้การแลกเปลี่ยนจบลง การต่ออายุคีย์ลูกที่คืนค่า «ไม่มีข้อเสนอที่ยอมรับได้» ชี้ไปที่รายการข้อเสนอ คำขอต่ออายุที่ไม่เคยได้รับคำตอบชี้ไปที่เส้นทางหรือฝั่งที่หยุดฟัง สองกรณีนี้ต้องแก้ต่างกัน และถ้อยคำในบรรทัดล็อกแยกสองกรณีนั้น

ยืนยันคอนฟิกที่กำลังทำงาน ไม่ใช่ไฟล์บนดิสก์ ไฟล์ที่บันทึกไว้แต่ไม่ได้โหลด หรือการเชื่อมต่อที่อ่านซ้ำจาก include อื่น จะสร้างความไม่ตรงกันที่การแก้ไฟล์ที่มองเห็นไม่สามารถแก้ได้

สามเหตุการณ์ที่ทุกคนเรียกว่าการต่ออายุคีย์

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

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

การปิดการต่ออายุไม่ใช่การแก้ไข

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

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

พิสูจน์ด้วยการแลกเปลี่ยนที่ล้มเหลว

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

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