EAP หรือใบรับรองไคลเอนต์? การตัดสินใจยืนยันตัวตน IKEv2

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

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

สองข้อมูลรับรอง สองข้อเรียกร้อง

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

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

EAP เป็นภาชนะ ไม่ใช่วิธี

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

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

การติดตั้งแบบผสมเป็นเรื่องปกติ

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

ถามผู้ดูแลเกี่ยวกับวิธีและรูปแบบบัญชีที่มีเอกสารระบุ แทนที่จะอนุมานจากชื่อฟิลด์ในไคลเอนต์

การตัดสินใจจากขั้นตอนที่ล้มเหลว

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

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

การดำเนินงานสองรูปแบบ

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

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

หลังจากตัวตนได้รับการยอมรับ

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

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