IKEv2 แลกเปลี่ยนสำเร็จ แต่การยืนยันตัวตนล้มเหลว: ควรดูตรงไหน

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

การตรวจสอบ 1: อ่านขั้นตอน ไม่ใช่อ่านข้อความ

การปฏิเสธอาจมาจากสามที่ คือไคลเอนต์ปฏิเสธตัวตนของเซิร์ฟเวอร์ เกตเวย์ปฏิเสธหลักฐานของไคลเอนต์ และบริการยืนยันตัวตนภายนอกปฏิเสธบัญชี

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

การตรวจสอบ 2: ตรวจสอบตัวตนใด

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

ในศัพท์ของ strongSwan นั่นคือ rightid บนไคลเอนต์และตัวตนของเกตเวย์เองอีกฝั่งหนึ่ง และความไม่ตรงกันจะล้มเหลวก่อนที่จะพูดถึง EAP ด้วยซ้ำ

เกตเวย์อาจปฏิเสธใบรับรองไคลเอนต์ หลักฐานกุญแจ หรือการยืนยันบัญชีแยกกัน และสามอย่างนี้ใช้แทนกันไม่ได้ การรีเซ็ตรหัสผ่านผู้ใช้ไม่ได้ต่ออายุใบรับรองอุปกรณ์ และการติดตั้งใบรับรองอุปกรณ์ใหม่ไม่ได้แก้ตัวตนเซิร์ฟเวอร์ที่ผิด สำหรับความล้มเหลวของใบรับรอง ให้ตรวจสอบนาฬิกาก่อน จากนั้นตรวจสอบห่วงโซ่ความเชื่อถือ แล้วจึงตรวจสอบตัวระบุที่คาดหวัง ไคลเอนต์ที่นาฬิกาคลาดเคลื่อนไม่กี่นาทีจะล้มเหลวในการตรวจสอบความถูกต้องซึ่งดูเหมือนความล้มเหลวของความเชื่อถือ swanctl --list-certs ที่ปลายทั้งสองข้างแสดงว่าฝ่ายแต่ละฝ่ายถืออะไรอยู่จริง

การตรวจสอบ 3: หากมี EAP เกี่ยวข้อง

ไคลเอนต์และเซิร์ฟเวอร์ต้องตกลงกันเรื่องวิธีการที่รองรับ และระบบหลังบ้านต้องยอมรับตัวตนที่ส่งมา

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

อย่าทดสอบปัญหาตัวตนด้วยการปิดการตรวจสอบตัวตน การทำเช่นนั้นเปลี่ยนความล้มเหลวที่วินิจฉัยได้ให้กลายเป็นวินิจฉัยไม่ได้ และทำให้การเชื่อมต่ออ่อนแอกว่าเดิม

การตรวจสอบ 4: เกิดอะไรขึ้นหลังเข้าสู่ระบบสำเร็จ

เมื่อ IKE_AUTH เสร็จสิ้น การเจรจา CHILD_SA จะกำหนดว่าจะติดตั้งตัวเลือกทราฟฟิกใด และตรงนั้นเองที่การเชื่อมต่ออาจสำเร็จแต่ยังส่งอะไรไม่ได้

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

การตรวจสอบ 5: สิ่งที่ควรส่งให้ฝ่ายสนับสนุน

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

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