OpenVPN โดยไม่มีใบรับรองไคลเอนต์: นโยบายฝั่งเซิร์ฟเวอร์ ไม่ใช่โปรไฟล์

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

โปรไฟล์ไม่ใช่นโยบาย

Community OpenVPN 2.6 มาพร้อมใบรับรองไคลเอนต์แบบบังคับ เพราะ verify-client-cert มีค่าเริ่มต้นเป็น require การตั้งค่าให้เป็น none คือสิ่งที่หยุดการเรียกร้องใบรับรองและมอบการพิสูจน์ตัวตนของไคลเอนต์ให้กับการจัดวางชื่อผู้ใช้และรหัสผ่านที่เซิร์ฟเวอร์ใช้งานอยู่แล้ว คู่มือเก่าจะเอื้อมไปหา client-cert-not-required ซึ่งเป็นรูปแบบการเขียนแบบเก่าของแนวคิดเดียวกัน ดังนั้นให้ใช้คำสั่งที่เวอร์ชันที่ติดตั้งของคุณบันทึกไว้ ไม่ว่าจะทางใด การเปลี่ยนแปลงเกิดขึ้นที่เซิร์ฟเวอร์ และไม่มีโปรไฟล์ไคลเอนต์ใดทำได้

ส่วนย่อยด้านล่างคือการเปลี่ยนแปลงทั้งหมดฝั่งเซิร์ฟเวอร์ และโดยลำพังมันไม่ใช่การกำหนดค่าการพิสูจน์ตัวตนที่ใช้งานได้ verify-client-cert none ลบข้อกำหนดใบรับรอง ขณะที่ username-as-common-name ทำให้ชื่อบัญชีเป็นตัวตนที่การเรียกกลับภายหลังและไฟล์ของไคลเอนต์แต่ละรายเห็น ไม่มีบรรทัดใดตรวจสอบรหัสผ่าน ดังนั้นจึงยังต้องมีตัวตรวจสอบอยู่

verify-client-cert none
username-as-common-name

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

อะไรยังคงพิสูจน์ฝั่งเซิร์ฟเวอร์

การทิ้งใบรับรองไคลเอนต์ไม่ใช่การทิ้ง TLS เซิร์ฟเวอร์ยังคงเก็บใบรับรองและคีย์ของตน และไคลเอนต์ยังคงเก็บความเชื่อถือ CA และการตรวจสอบชื่อโฮสต์ที่ป้องกันไม่ให้คุยกับผู้แอบอ้าง การลบ remote-cert-tls server หรือชุด CA เพราะไคลเอนต์ไม่มีใบรับรองแล้วเป็นการอ่านผิดที่พบบ่อยและร้ายแรง และ เอกสารอ้างอิง 2.6 ระบุชัดเจนว่าทั้งสองทิศทางเป็นอิสระต่อกัน ฝ่ายหนึ่งพิสูจน์เซิร์ฟเวอร์ต่อไคลเอนต์ อีกฝ่ายพิสูจน์ไคลเอนต์ต่อเซิร์ฟเวอร์

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

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

ตัวตรวจสอบต้องทำอะไร

เมื่อข้อกำหนดใบรับรองถูกถอดออก ทุกอย่างขึ้นอยู่กับตัวตรวจสอบ: ปลั๊กอิน หรือสคริปต์ที่ขับเคลื่อนโดย auth-user-pass-verify มันต้องปฏิเสธข้อมูลรับรองที่ไม่ถูกต้อง ปฏิเสธบัญชีที่ถูกปิดใช้งานหรือไม่เข้าเกณฑ์ และล้มเหลวแบบปิดเมื่อเข้าถึงแบ็กเอนด์ไม่ได้ username-as-common-name มักถูกเปิดใช้งานควบคู่ และมันเปลี่ยนตัวตนที่การเรียกกลับภายหลังและไฟล์กำหนดค่าของไคลเอนต์แต่ละรายเห็น มันไม่ได้ตรวจสอบรหัสผ่าน และไม่ได้ทำให้บัญชีที่ไม่เข้าเกณฑ์เข้าเกณฑ์ งานเหล่านี้แยกกัน และการผสมปนเปกันคือวิธีที่การย้ายระบบผ่านการทดสอบเส้นทางที่มีความสุขและล้มเหลวในเหตุการณ์จริงครั้งแรก

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

เปลี่ยนนโยบาย โปรไฟล์ และการแมปไปพร้อมกัน

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

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

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