openvpn3 session-start ไม่สนใจไฟล์ข้อมูลรับรองของคุณ

เชื่อมต่อด้วยไคลเอนต์ 2.x แล้วโปรไฟล์ทำงานได้ ส่งไฟล์เดียวกันให้ไคลเอนต์ 3.x แล้วมันหยุดที่พรอมต์รหัสผ่าน ส่ง --auth-user-pass creds.txt ให้ openvpn3 session-start แล้วผลลัพธ์ก็เหมือนเดิม เพราะไคลเอนต์ใหม่ไม่มีขั้นตอนที่อ่านไฟล์ การปฏิเสธนี้ตั้งใจ: ข้อมูลรับรองเป็นของเซสชัน และเซสชันสร้างโดยบริการ ไม่ใช่โดยโปรเซสในเทอร์มินัลของคุณ เลือกระหว่างพรอมต์แบบโต้ตอบกับตัวช่วย autoload และรู้ว่าแต่ละอย่างเก็บอะไร

ทำไมไฟล์ที่บันทึกไว้จึงไม่มีที่ไป

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

รูปแบบเก่าควรถูกเอ่ยชื่อเพื่อให้เลิกใช้ได้ง่ายขึ้น: โปรไฟล์อ้างถึงไฟล์ข้อมูลรับรอง และเดมอนอ่านมันเมื่อทันเนลเริ่มทำงาน ในโมเดลใหม่ ข้อมูลรับรองเป็นของเซสชันและถูกส่งเมื่อเซสชันนั้นเริ่มต้น openvpn3 session-start --config work.ovpn จะถามหาข้อมูลเหล่านั้น และ --auth-user-pass creds.txt ถูกปฏิเสธเพราะไม่มีอะไรในเส้นทางนั้นที่จะเปิดไฟล์ สูตร 2.x ทุกสูตรที่คุณพบถือว่ามีขั้นตอนที่ไม่มีอยู่อีกแล้ว

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

เส้นทางพรอมต์และเซสชันที่มันทิ้งไว้

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

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

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

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

ระบบอัตโนมัติโดยไม่มีคนอยู่หน้าแป้นพิมพ์

ในที่ที่เครื่องต้องเชื่อมต่อโดยไม่มีคน โปรเจกต์มี openvpn3-autoload ให้ มันอ่านไดเรกทอรีของโปรไฟล์และตัวอธิบายที่จับคู่กันสำหรับแต่ละโปรไฟล์ และตัวอธิบายจะให้ข้อมูลรับรองเป็นข้อความธรรมดา ตัวช่วยเป็นไบนารีแยกต่างหาก ปกติอยู่ที่ /usr/sbin/openvpn3-autoload ไม่ใช่แฟล็กของ session-start การตั้งค่ามันหมายถึงการสร้างไดเรกทอรี คัดลอกโปรไฟล์ด้วยชื่อที่ตัวอธิบายคาดหวัง และเขียนตัวอธิบาย

การตั้งค่าต่อผู้ใช้มีลักษณะเช่นนี้ รันในฐานะบัญชีที่จะเป็นเจ้าของเซสชัน โหมดของไดเรกทอรีกันผู้ใช้ภายในเครื่องคนอื่นออกไป:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

ตัวอธิบายระบุข้อมูลรับรองและขอเริ่มต้นอัตโนมัติ เก็บค่าของรหัสผ่านไว้นอกการควบคุมเวอร์ชัน:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

จากนั้นเรียกตัวช่วยหนึ่งครั้งและยืนยันว่าเซสชันปรากฏขึ้น คำสั่งที่สองคือการตรวจสอบ ไม่ใช่ขั้นตอนการตั้งค่าอีกขั้น

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

เมื่อบูต ยูนิตที่แพ็กเกจมาในชื่อ openvpn3-autoload.service ใช้ไดเรกทอรีทั้งระบบ /etc/openvpn3/autoload ไม่ใช่ไดเรกทอรีต่อผู้ใช้ ตำแหน่งนั้นต้องใช้ความเป็นเจ้าของของ root และโหมดที่เข้มงวดกว่า และตัวอธิบายยังคงเก็บรหัสผ่านเป็นข้อความธรรมดา การแลกเปลี่ยนชัดเจน: ตอนนี้รหัสผ่านอยู่บนดิสก์ จึงควรถือไดเรกทอรีนั้นเป็นความลับ ยกเว้นจากการสำรองข้อมูลนอกโฮสต์ และเลือกเส้นทางแบบโต้ตอบทุกครั้งที่มีคนอยู่

ความล้มเหลวของบัสที่ดูเหมือนความล้มเหลวของรหัสผ่าน

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

คำสั่งด้านล่างแยกสองอย่างนี้ออกจากกัน คำสั่งแรกบอกว่าแบ็กเอนด์กำลังทำงานหรือไม่ คำสั่งที่สองแสดงข้อผิดพลาดของบัสล่าสุด:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

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

เมื่อยังใช้ไคลเอนต์รุ่นเก่าอยู่

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

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