--key-password ของ OpenConnect คือรหัสผ่านบัญชี VPN ของคุณหรือไม่?

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

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

ความลับสองอย่าง สองหน้าที่ต่างกัน

อ่านบทบาทเป็นการเข้าถึงไฟล์เทียบกับการอนุญาตให้เข้าสู่เครือข่าย รหัสผ่านของคีย์ถอดรหัสคีย์ส่วนตัว PEM ที่ระบุใน --sslkey เพื่อให้สามารถนำเสนอใบรับรองไคลเอนต์ TLS ได้ การถอดรหัสนั้นเกิดขึ้นในเครื่อง ภายในกระบวนการไคลเอนต์ และวลีรหัสผ่านเองไม่เคยเดินทางไปยังเกตเวย์ สิ่งที่เกตเวย์เห็นคือใบรับรองและลายเซ็นที่สร้างด้วยคีย์ คู่มือของ OpenConnect วาง --key-password ไว้ข้าง --certificate และ --sslkey และในบิลด์ที่ใช้คีย์ใน TPM ได้ ตัวเลือกเดียวกันจะถือรหัสผ่านของคีย์รากของที่เก็บแทน

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

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

เมื่อใดที่รหัสผ่านคีย์จำเป็นจริง ๆ

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

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

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

เก็บความลับทั้งสองออกจากประวัติเชลล์

อาร์กิวเมนต์บรรทัดคำสั่งอ่านได้โดยผู้ใช้ภายในเครื่องคนอื่นผ่านตารางโพรเซส และมักถูกบันทึกไว้ในประวัติเชลล์ สคริปต์ และบันทึกการสนับสนุน OpenConnect อ่านรหัสผ่านบัญชีจากอินพุตมาตรฐานได้ด้วย --passwd-on-stdin และวลีรหัสผ่านของคีย์อาจมาจากพรอมป์แบบโต้ตอบหรือเอเจนต์แทนอาร์กิวเมนต์ ไม่มีกลไกใดทำให้ความลับปลอดภัยได้ด้วยตัวเอง แต่ทั้งสองช่วยให้มันอยู่ห่างจากจุดที่เปิดเผยที่สุด

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

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

ปุ่มเดสก์ท็อปที่ตายแล้วเป็นความผิดพลาดอีกแบบ

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

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

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