client-config-dir ถูกเพิกเฉยหลังจาก OpenVPN กลายเป็นบริการ

อุโมงค์ของคุณขึ้นมาและไคลเอนต์เชื่อมต่อได้ แต่ที่อยู่คงที่และเส้นทางที่พุชซึ่งคุณกำหนดไว้สำหรับผู้ใช้คนเดียวนั้นหายไป บันทึกไม่ขึ้นว่า “file not found” และนั่นเองที่ทำให้คนไปสร้างใบรับรองใหม่ ในกรณีส่วนใหญ่เดมอนทำงานจากไดเรกทอรีอื่นที่ไม่ใช่เชลล์ที่คุณทดสอบ และ client-config-dir ไม่เคยถูกแก้ไขอย่างที่คุณคิด การแก้ไขคือการแก้พาธ ไม่ใช่การรีเซ็ตข้อมูลรับรอง

อ่าน unit ก่อนแตะการตั้งค่า

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

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

WorkingDirectory ที่ว่างเปล่าหมายความว่า unit เริ่มใน / ดังนั้น client-config-dir ccd แบบสัมพัทธ์จะถูกค้นหาใน /ccd ไดเรกทอรีนั้นแทบไม่เคยมีอยู่ และเดมอนไม่ถือว่าการไม่มีอยู่เป็นเรื่องร้ายแรง

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

พาธแบบสัมพัทธ์ถูกแก้เทียบกับอะไร

คำสำคัญถูกแก้เทียบกับไดเรกทอรีทำงานของโปรเซส ณ เวลาที่ใช้ตัวเลือกนั้น ไม่ได้หมายถึง “ข้างไฟล์ตั้งค่าที่ผมส่งไปด้วย --config” OpenVPN ยินดีอ่านการตั้งค่าจากพาธแบบเต็มและยังคงแก้ค่าสัมพัทธ์ที่อื่น ซึ่งนั่นคือกับดักตรงนี้ คู่มือ OpenVPN 2.6 ระบุกฎนี้ไว้ใต้ --client-config-dir และอีกครั้งใต้ --cd

คำสำคัญ cd เปลี่ยนบริบทนั้นก่อนไฟล์อื่นจะถูกอ่าน unit ที่ตั้ง cd /etc/openvpn/server แล้วตามด้วย client-config-dir ccd จึงถูกแก้เป็น /etc/openvpn/server/ccd ถ้าคุณเพิ่ม cd ให้ตรวจลำดับของคำสั่งและจำไว้ว่ามันกระทบทุกการอ้างอิงแบบสัมพัทธ์อื่นในไฟล์เดียวกัน

ไล่พาธในฐานะบัญชีของเดมอน

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

namei พิมพ์สิทธิ์ของแต่ละองค์ประกอบตามลำดับ ซึ่งเร็วกว่าการตรวจไดเรกทอรีทีละตัว:

namei -l /etc/openvpn/server/ccd/client1

จากนั้นทดสอบการอ่านในฐานะบัญชีบริการ ไม่ใช่ในฐานะตัวคุณเอง:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

ถ้า unit ใช้ chroot ไดเรกทอรีต้องอยู่ภายในคุก และพาธในการตั้งค่าจะถูกตีความหลังใช้ chroot ไฟล์ที่อยู่บนโฮสต์นอกคุกจะมองไม่เห็นจากภายใน

ยืนยันการค้นหาแทนการเดา

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

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

รันสิ่งนั้นในเบื้องหน้า บนพอร์ตว่าง แล้วเชื่อมต่อไคลเอนต์หนึ่งตัว นั่นเอาต์ systemd ออกจากภาพทั้งหมด ถ้าการแทนที่ปรากฏที่นี่แต่ไม่ปรากฏใต้บริการ ความต่างคือบริบทของ unit ไม่ใช่ไฟล์

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

แก้ไข รีสตาร์ต ตรวจสอบ

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

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

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

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