openvpn ไบนารีตัวไหนกำลังทำงานอยู่? ตรวจสอบเส้นทางที่ใช้เรียก

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

เริ่มจากเส้นทางที่เซอร์วิสเรียกใช้

เทอร์มินัลและยูนิต systemd ไม่ได้แปลงไฟล์ปฏิบัติการด้วยวิธีเดียวกัน shell ค้นหาใน PATH ส่วนยูนิตระบุเส้นทาง และการแทนที่ด้วย drop-in ก็เปลี่ยนเส้นทางนั้นได้โดยไม่ต้องแตะไฟล์ที่คุณกำลังอ่าน ความต่างข้อนี้อธิบายความสับสนส่วนใหญ่ในงานนี้ และยังกำหนดว่าการซ่อมของคุณต้องเล็งไปที่ไฟล์ไหน

ถามยูนิตว่าเรียกอะไร รวมถึง drop-in ที่แก้ไขมัน แล้วอ่านบรรทัด ExecStart ที่ได้ แทนที่จะอ่านส่วนที่คุณคิดว่าเป็นทางการ จากนั้นตามเส้นทางนั้นผ่านลิงก์สัญลักษณ์ใด ๆ ไปจนถึงไฟล์สุดท้าย ตัวห่อที่ลงท้ายด้วย exec ไปยังไดเรกทอรีที่ซ่อนอยู่เป็นรูปแบบที่พบบ่อยจากการแก้แบบเก่าเหล่านี้

จดเส้นทางที่แปลงแล้วไว้ก่อนจะแก้อะไร

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

เทียบชื่อคำสั่งกับเส้นทางของเซอร์วิส

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

สิ่งสำคัญคือต้องรู้ว่าเจ้าของรายใดเรียกโปรเซสที่ให้บริการทราฟฟิก ถ้ายูนิตเรียก /usr/local/sbin/openvpn-wrapper ขณะที่ shell ของคุณแปลง /usr/sbin/openvpn การซ่อมไฟล์ที่สองก็ไม่เปลี่ยนอะไรในเซอร์วิส

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

ให้ฐานข้อมูลแพ็กเกจเป็นคนพูดเรื่องไฟล์ของแพ็กเกจ

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

รันการตรวจสอบและอ่านผลลัพธ์ แทนที่จะถือว่าผลว่างเปล่าเป็นหลักฐานของอะไรก็ตาม

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

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

บันทึกสถานะก่อนซ่อม

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

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

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

ตรวจสอบการเรียกใช้ แล้วปลดตัวห่อออก

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

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

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