IKEv2 ไม่ใช่การจับมือครั้งเดียว: IKE SA การพิสูจน์ตัวตน แล้วจึงเป็น CHILD SA

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

ความเชื่อผิด: ถ้าเกตเวย์ตอบกลับ แสดงว่าเชื่อมต่อแล้ว

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

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

IKE_SA_INIT: ตกลงพารามิเตอร์ ไม่ใช่ตัวตน

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

IKE SA ที่สร้างขึ้น ณ จุดนี้ปกป้องการแลกเปลี่ยนการจัดการทั้งหมดที่ตามมา นั่นคืองานของมัน และเป็นงานที่ต่างจากการปกป้องแพ็กเก็ตของคุณ

IKE_AUTH: พิสูจน์ตัวตน แล้วสร้าง CHILD SA แรก

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

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

สอง SA สองงาน

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

บน strongSwan เอกสารอ้างอิงการกำหนดค่า IKEv2 และ swanctl --list-sas แสดงทั้งสองระดับ และ ip xfrm state ร่วมกับ ip xfrm policy แสดงสิ่งที่เคอร์เนลติดตั้งจริง การเปรียบเทียบสองมุมมองนี้เป็นวิธีที่เร็วที่สุดในการดูว่าการเจรจาจบลงแล้วหรือเพียงดูเหมือนจบลง หากดีมอนแสดง CHILD SA ที่เคอร์เนลไม่มีสถานะ การติดตั้งล้มเหลวอย่างเงียบ ๆ หากเคอร์เนลถือสถานะที่ดีมอนไม่รู้ คุณกำลังดูเศษของการพยายามครั้งก่อน

อะไรต้องเป็นจริงต่อไปหลังอุโมงค์ขึ้น

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

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