ที่อยู่เซิร์ฟเวอร์ IKEv2 เทียบกับข้อมูลระบุตัวตน: สิ่งที่ไคลเอ็นต์ตรวจสอบจริง ๆ

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

ตรวจสอบตามลำดับนี้และหยุดที่รายการแรกที่ไม่ตรงกัน เนื่องจากการตรวจสอบในภายหลังจะถือว่ารายการก่อนหน้าผ่านไป

อันดับแรก ค่าใดคือที่อยู่

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

ในแง่ strongSwan ที่อยู่คือ right หรือ left และข้อมูลประจำตัวที่คาดหวังคือ rightid หรือ leftid และนั่นคือสิ่งที่เอกสารประกอบการกำหนดค่า IKEv2 อธิบายไว้ หากคุณเคยแก้ไขที่อยู่ คุณได้กำหนดค่าครึ่งหนึ่งของคู่แล้ว

ประการที่สอง สิ่งที่ใบรับรองสามารถพิสูจน์ได้

ข้อมูลระบุตัวตนมีประเภทหนึ่ง และใบรับรองต้องมีชื่อที่ตรงกัน ข้อมูลระบุตัวตน DNS เป็นไปตามรายการ dNSName ในส่วนขยายชื่อทางเลือกของหัวเรื่อง ข้อมูลระบุตัวตน IP จำเป็นต้องมีรายการ iPAddress ใบรับรองที่ออกให้สำหรับ vpn.example.com ไม่ได้พิสูจน์อะไรเลยเกี่ยวกับที่อยู่ตามตัวอักษร 203.0.113.10 และใบรับรองที่ออกให้สำหรับที่อยู่นั้นไม่ได้พิสูจน์อะไรเลยเกี่ยวกับชื่อ การออกใหม่โดยใช้ชื่ออื่นจึงไม่ใช่การแทนที่แบบดรอปอิน แม้ว่าคีย์เดิมและ CA จะถูกนำมาใช้ซ้ำก็ตาม

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

ประการที่สาม ลูกค้าแต่ละรายระบุความคาดหวังอย่างไร

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

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

ประการที่สี่ แยกการเข้าสู่ระบบของผู้ใช้ออกจากข้อมูลประจำตัวของเพียร์

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

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

ประการที่ห้า เปลี่ยนผ่านช่องทางที่ได้รับการยืนยัน

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

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