ไคลเอนต์ VPN ของคุณยังได้รับแพตช์ความปลอดภัยได้อยู่หรือไม่?

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

อ่านประกาศ ไม่ใช่นับเวอร์ชัน

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

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

ติดตามช่องทางที่บิลด์ของคุณมาถึง

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

ถามเมทาดาทาของแพ็กเกจว่าช่องทางใดเป็นเจ้าของไบนารี แทนที่จะเชื่อหน้าดาวน์โหลดที่คุณจำได้ สามคำสั่งนี้ระบุเจ้าของและเวอร์ชันที่เป็นตัวเลือกในการตั้งค่า Linux และ Flatpak ทั่วไป:

dpkg -S "$(command -v openvpn)"
apt policy openvpn
flatpak list --columns=application,version

ตรวจสอบว่ามีอะไรติดตั้งอยู่จริง

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

openvpn --version | head -3
wg --version
winget list --name OpenVPN

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

พิสูจน์ว่าการอัปเดตไม่ทำให้อุโมงค์เสีย

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

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

ip route get 203.0.113.10
openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'error|fatal'
systemctl status openvpn-client@client --no-pager

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

เมื่อแพลตฟอร์มหลุดจากการสนับสนุน

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

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