ทำไมการแก้ไขไฟล์ .ovpn จึงเปิด MFA บนเซิร์ฟเวอร์ไม่ได้

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

พรอมต์พิสูจน์เพียงว่าไคลเอนต์ถาม ไม่มากไปกว่านั้น

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

การติดตั้งแอปยืนยันตัวตนบนโทรศัพท์ก็ไม่ได้สร้างความสัมพันธ์นั้นเช่นกัน โครงการ Google Authenticator PAM เป็นองค์ประกอบตรวจสอบ OTP ที่วางอยู่หลัง OpenVPN ได้ แต่ไม่ใช่วิธีการแปะการเข้าสู่ระบบบัญชี Google ลงบนโปรไฟล์ที่นำเข้า

การลงทะเบียนคือส่วนที่โปรไฟล์ทำไม่ได้

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

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

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

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

อ่านสแตก PAM เพื่อดูว่าจริง ๆ แล้วต้องมีอะไร

บรรทัดอย่าง account required pam_permit.so ไม่ได้ใช้คุณสมบัติของบัญชีและไม่ได้เพิ่มปัจจัย มันอนุญาตขั้นตอนการจัดการบัญชี PAM นั้น ซึ่งเป็นข้อความเกี่ยวกับขั้นตอน ไม่ใช่เกี่ยวกับผู้ใช้ของคุณ

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

ปรับการโต้ตอบของไคลเอนต์ให้เข้ากับการออกแบบของเซิร์ฟเวอร์

auth-user-pass

คำสั่งนั้นขอให้ป้อนชื่อผู้ใช้และรหัสผ่าน ไม่ได้กำหนดค่า PAM ไม่ได้สร้างบันทึกการลงทะเบียน และไม่ได้บอกเซิร์ฟเวอร์ว่าช่องรหัสผ่านมีค่า TOTP การรวมฝั่งเซิร์ฟเวอร์และไคลเอนต์ต้องตกลงกันเรื่องการโต้ตอบที่การติดตั้งรองรับจริง: การท้าทาย รูปแบบข้อมูลรับรองรวมที่จัดทำเอกสาร หรือโฟลว์เฉพาะผลิตภัณฑ์

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

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

การเชื่อมต่อใหม่ โทเค็น และการทดสอบที่ชี้ขาด

วางแผนว่าจะเกิดอะไรขึ้นหลังการเข้าสู่ระบบสำเร็จครั้งแรก รหัสที่เคยยอมรับอาจหมดอายุหรือถูกปฏิเสธว่าเป็นการเล่นซ้ำในการยืนยันตัวตนครั้งถัดไป auth-nocache ควบคุมการเก็บรักษาข้อมูลรับรองและไม่ได้ติดตั้ง MFA และ reneg-sec 0 ไม่ใช่คำจำกัดความของการรองรับ TOTP ไม่ว่าจะปรากฏในกระทู้ฟอรัมบ่อยเพียงใด

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

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