IKEv1 ร่วมกับ XAuth และ OTP: แต่ละพรอมต์กำลังขออะไร

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

จับคู่แต่ละพรอมต์กับชั้นที่ขอสิ่งนั้นก่อนติดตั้งไคลเอนต์อีกตัวหรือรีเซ็ตข้อมูลรับรอง

สามความลับ สามเจ้าของ

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

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

PSK: ของเพียร์ ไม่ใช่ของบุคคล

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

ข้อมูลรับรองของผู้ใช้ซ่อมความล้มเหลวในระยะแรกไม่ได้ การหมุนเวียนมันทำให้เสียข้อมูลรับรองเดียวที่หมุนเวียนได้อย่างปลอดภัย และตอกย้ำสมมติฐานที่ผิด

XAuth: การแลกเปลี่ยนผู้ใช้แบบเก่า

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

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

OTP: แล้วแต่แบ็กเอนด์จะขอ

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

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

จุดที่ขอบเขตของไคลเอนต์กัด

Fortinet ระบุว่า FortiClient 7.4.4 เป็นต้นไปไม่รองรับ IKEv1 สำหรับ IPsec VPN แล้ว ซึ่งเป็นขอบเขตของผลิตภัณฑ์และเวอร์ชัน ไม่ใช่การถอดออกทั้งหมด ตามที่บันทึกความเข้ากันได้ของ FortiClientบันทึกไว้ ไคลเอนต์อื่นก็ใช้แทนกันไม่ได้เช่นกัน OpenConnect และ openfortivpn พูดโปรโตคอลเกตเวย์เฉพาะ ไม่ใช่โปรไฟล์ IKEv1 ใดก็ได้ ตรวจสอบเวอร์ชัน IKE โหมด PSK การรองรับ XAuth และรูปแบบการโต้ตอบของไคลเอนต์ที่ติดตั้งไว้ทีละอย่าง ไคลเอนต์ที่เชื่อมต่อด้วยวิธีอื่นไม่ได้พิสูจน์ว่าข้อกำหนดเดิมเป็นจริง

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

วินิจฉัยโดยไม่ปิดปัจจัย

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

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