IKEv2 SA ของคุณขึ้นแล้วแต่ไม่มี SA ลูก: อ่านการแลกเปลี่ยน

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

สองความเชื่อมโยง สองงาน

SA ของ IKE พาช่องควบคุม ซึ่งได้แก่ อัตลักษณ์ กุญแจ และข้อเสนอสำหรับการแลกเปลี่ยนควบคุมเอง SA ลูกพาการป้องกัน ESP พร้อมอัลกอริทึมของตัวเองและตัวเลือกทราฟฟิกของตัวเอง การพิสูจน์ตัวตนและการสร้าง SA ลูกมักไปด้วยกัน เพราะ SA ลูกตัวแรกเจรจากันภายใน IKE_AUTH และการรวมกันนั้นเองที่ทำให้ผู้คนประหลาดใจกับการแยกจากกัน

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

ชั้นไหนปฏิเสธ

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

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

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

จากนั้นถามถึงเส้นทางข้อมูล

เมื่อมี SA ลูก ตัวนับจะตอบคำถามถัดไป ip -s xfrm state รายงานจำนวนแพ็กเก็ตและไบต์ต่อความเชื่อมโยง และ SA ลูกที่ไม่พาอะไรเลยในขณะที่คุณสร้างทราฟฟิกชี้ไปที่การจับคู่หรือการกำหนดเส้นทาง ไม่ใช่ไปยังความเชื่อมโยงที่หายไป swanctl --list-sas พิมพ์ตัวเลือกของ SA ลูกข้างตัวนับเหล่านั้น และนั่นคือสิ่งที่ยืนยันว่าแพ็กเก็ตอยู่ในชุดที่ยอมรับ

แยกการพิสูจน์ตัวตนที่สำเร็จและการแลกเปลี่ยน SA ลูกที่ล้มเหลวออกจากกันในรายงาน รายงานที่บอกว่าการพิสูจน์ตัวตนล้มเหลวจะส่งวิศวกรคนถัดไปไปที่ที่เก็บใบรับรอง และประโยคที่ถูกต้องนั้นสั้นกว่ามาก: SA ของ IKE ขึ้นมาแล้ว และ SA ลูกสำหรับเส้นทางนี้ไม่เคยถูกยอมรับ

เชื่อมสองปลายเข้าด้วยกัน

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

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