คีย์ลับใช้ไม่ได้ไม่ใช่ปัญหากฎรหัสผ่าน แต่เป็นปัญหาของคอนเทนเนอร์
ข้อมูลรับรองที่ถูกปฏิเสธอาจไม่เคยไปถึงเกตเวย์เลย เริ่มจากเทียบอินพุตคอนเทนเนอร์ ขั้นตอนพิสูจน์ตัวตน และบัญชี
เมื่อเห็นข้อความ "invalid secrets" คนมักสรุปอย่างเดียวว่า VPN ไม่ชอบเครื่องหมายวรรคตอน ข้อสรุปนั้นมักผิด เพราะข้อความนี้มักมาจากการจัดการในเครื่องก่อนที่เกตเวย์ใดจะได้ดูบัญชีเลย การออกแบบสองแบบส่งรหัสผ่านเดียวกัน คือช่องกราฟิกกับไฟล์ข้อมูลรับรอง และมันล้มเหลวคนละจุด เทียบคอนเทนเนอร์ก่อนจะไปลดความซับซ้อนของรหัสผ่านที่ถูกอยู่แล้ว
ข้อผิดพลาดเกิดก่อนถึงเกตเวย์
การตรวจสอบในเครื่อง คลังคีย์ที่ถูกล็อก เอเจนต์ที่ไม่มี และไฟล์ข้อมูลรับรองที่รูปแบบผิด ล้วนสร้างความล้มเหลวที่ผู้ใช้รับรู้เป็นการปฏิเสธครั้งเดียว ไม่มีข้อใดเกี่ยวข้องกับเซิร์ฟเวอร์พิสูจน์ตัวตน การปฏิเสธจากเกตเวย์เองเป็นเหตุการณ์อีกแบบ และมักมาพร้อมข้อความอื่นและจังหวะอื่น มันเกิดหลังอุโมงค์ถูกสร้างและข้อมูลรับรองถูกส่งไปแล้ว
ดังนั้นคำถามแรกไม่ใช่อักขระใดถูกกฎ แต่คือความพยายามหยุดที่จุดไหน ไคลเอนต์ที่ไม่เคยเปิดการเชื่อมต่อไม่เคยถูกใครปฏิเสธ จดบันทึกขั้นตอนที่คุณสังเกตเห็นไว้ เพราะทุกก้าวถัดไปขึ้นกับคำจำกัดความนั้น
ความต่างนี้ยังเปลี่ยนคนที่ต้องแก้ ปัญหาคอนเทนเนอร์เป็นของอุปกรณ์และเจ้าของ ส่วนการปฏิเสธบัญชีเป็นของคนที่ดูแลระบบพิสูจน์ตัวตน
เทียบคอนเทนเนอร์ ไม่ใช่อักขระ
ช่องรหัสผ่านแบบกราฟิก รายการในคีย์เชน ไฟล์ข้อมูลรับรองสองบรรทัด และซีเคร็ตของระบบอัตโนมัติ ล้วนบรรจุค่าเดียวกันในซองที่ต่างกัน ซองมีกฎของมันเอง และกฎเหล่านั้นคือสิ่งที่มักพัง ค่าแทบไม่เคยเป็นปัญหา การขนส่งค่าต่างหากที่เป็น เทียบสองแนวคิดนี้แยกกันแล้วการวินิจฉัยจะสั้นลง
| ค่าหยุดที่ไหน | สิ่งที่คุณเห็น | สิ่งที่คุณตรวจ | ใครเป็นเจ้าของการแก้ |
|---|---|---|---|
| ช่องกราฟิกหรือโปรไฟล์ที่ถูกจัดการ | ข้อความตรวจสอบก่อนการเชื่อมต่อจะเปิด | โหมดพิสูจน์ตัวตนที่เลือก และช่องนั้นเก็บรหัสลับหรือชื่อผู้ใช้ | เจ้าของอุปกรณ์หรือผู้เขียนโปรไฟล์ |
| คีย์เชนหรือเอเจนต์เก็บรหัสลับ | พรอมป์ที่ถามซ้ำ หรือเอเจนต์ขัดข้อง | เอเจนต์ถูกปลดล็อกหรือยัง และมีรายการสำหรับโปรไฟล์นี้หรือไม่ | ผู้ใช้ที่เป็นเจ้าของคีย์เชน |
| ไฟล์ข้อมูลรับรองสองบรรทัด | พรอมป์ที่ถามรหัสผ่านซึ่งให้ไปแล้ว | จำนวนบรรทัด ลำดับบรรทัด และมีบรรทัดใหม่ปิดท้ายหรือไม่ | คนที่สร้างไฟล์ |
| อาร์กิวเมนต์ของเชลล์หรือตัวแปรสภาพแวดล้อม | ใช้ได้เมื่อโต้ตอบ แต่ล้มเหลวในระบบอัตโนมัติ | เชลล์ขยาย ตัด หรือบันทึกค่านั้นหรือไม่ | คนที่เขียนระบบอัตโนมัติ |
Community OpenVPN 2.6 client options อธิบายไฟล์สองบรรทัดสำหรับ auth-user-pass รวมถึงพฤติกรรมเมื่อไม่มีบรรทัดรหัสผ่าน คือไคลเอนต์จะถามแทน รายละเอียดเดียวนี้ธิบายรายงานประเภท ถามรหัสผ่านที่ฉันให้ไปแล้ว ทำไม ยังบอกด้วยว่าบรรทัดที่สองที่ว่างเปล่าเป็นสถานะที่มีความหมาย ไม่ใช่ตัวเลือกการจัดรูปแบบที่ไม่มีผล
การใส่เครื่องหมายคำพูดเป็นอีกชั้นหนึ่ง ในไฟล์ข้อมูลรับรองธรรมดา เครื่องหมายคำพูดถูกเก็บเป็นข้อมูล ส่วนเชลล์จะลบมันออกก่อนโปรแกรมเห็นอะไร อักขระเดียวกันจึงไม่มีผลในที่หนึ่ง แต่เป็นโครงสร้างในอีกที่หนึ่ง ตารางบอกไม่ได้ว่าไคลเอนต์ของคุณใช้คอนเทนเนอร์ใด ดังนั้นอ่านคอนฟิกของไคลเอนต์เองก่อนเลือกแถว
การขึ้นบรรทัดใหม่ก็เป็นโครงสร้างเช่นกัน ไฟล์ที่แบ่งฟิลด์ด้วยบรรทัดไม่สามารถบรรจุค่าที่มีบรรทัดใหม่ได้ และนั่นเป็นข้อจำกัดของรูปแบบ ไม่ใช่คำตัดสินเรื่องความแข็งแรงของรหัสผ่าน ใช้กลไกการส่งมอบที่ระบบรองรับ แทนการตัดรหัสลับให้พอดีกับไฟล์ที่ทำเอง
สร้างไฟล์ข้อมูลรับรองโดยไม่ให้เชลล์ทำเสียหาย
เส้นทางในเครื่องที่ปลอดภัยที่สุดเก็บรหัสลับให้พ้นประวัติเชลล์และพ้นรายการอาร์กิวเมนต์ของโปรเซส อ่านทั้งสองฟิลด์แบบโต้ตอบ แล้วเขียนสองบรรทัดที่ไคลเอนต์คาดไว้ ส่วนที่เหลือเก็บในไฟล์คอนฟิกที่ตรวจสอบง่ายได้
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/creds
สองคำสั่งแรกอ่านชื่อผู้ใช้แล้วอ่านรหัสผ่านโดยไม่แสดงบนจอ คำสั่งที่สามเขียนทั้งสองบรรทัด คำสั่งที่สี่จำกัดสิทธิ์ไฟล์ และคำสั่งสุดท้ายเปิดไคลเอนต์ด้วยไฟล์นั้น สังเกตว่า read -r รักษาแบ็กสแลชไว้ ซึ่งเป็นรายละเอียดแบบที่ทำให้รหัสผ่านที่เคยใช้ได้กลายเป็นใช้ไม่ได้เมื่อละไว้
หลีกเลี่ยงการสร้างไฟล์ด้วยตัวแปรที่ไม่ได้ใส่เครื่องหมายคำพูด หรือ here-document ที่เต็มไปด้วยการขยายของเชลล์ ทั้งสองอย่างเปลี่ยนอักขระได้ก่อนถึงไฟล์ และความล้มเหลวที่ได้จะดูเหมือน VPN ปฏิเสธ เพราะรหัสผ่านบนดิสก์ต่างจากรหัสผ่านที่คุณรู้จริง ๆ หากสงสัย ให้เทียบความยาวไบต์ของไฟล์กับค่าที่คาดไว้ โดยไม่พิมพ์รหัสลับเอง ความต่างหนึ่งหรือสองไบต์คือลายเซ็นของอุบัติเหตุจากการใส่เครื่องหมายคำพูด
อ่านขั้นตอนจากข้อผิดพลาดแรก
เก็บข้อความเฉพาะเจาะจงข้อแรกจากการลองหนึ่งครั้ง แล้วจำแนกมัน ข้อผิดพลาดจากการตรวจสอบในเครื่อง กุญแจส่วนตัวที่หายไป เอเจนต์เก็บรหัสลับที่ใช้งานไม่ได้ และการพิสูจน์ตัวตนที่เกตเวย์ล้มเหลว เป็นสี่ผลลัพธ์ที่ต่างกันพร้อมเจ้าของต่างกัน มีเพียงหนึ่งเดียวที่เกี่ยวกับบัญชี
ถ้าเกตเวย์ปฏิเสธข้อมูลรับรองที่ส่งไปอย่างถูกต้องจริง ๆ ให้ ตรวจบัญชี ระบบพิสูจน์ตัวตนฝั่งหลังบ้าน และสิ่งท้าทายที่จำเป็นกับผู้ดูแลระบบ การพิสูจน์ตัวตนที่ล้มเหลวแบบกว้าง ๆ ไม่ได้ระบุอักขระต้องห้าม
คืนค่าที่ได้รับอนุมัติผ่านกลไกที่ถูกต้อง แทนที่จะลดมันเหลือเพียงตัวอักษรกับตัวเลข นโยบายรหัสผ่านเป็นของฝ่ายปฏิบัติการ และวิธีเลี่ยงที่เอาชนะนโยบายอย่างเงียบ ๆ ไม่ใช่การแก้ไข มันยังซ่อนข้อบกพร่องจริงจากคนถัดไป ซึ่งจะเจอข้อผิดพลาดเดียวกันด้วยรหัสผ่านที่อ่อนกว่าและไอเดียที่ไม่ดีขึ้น