วิธีย้อนกลับการกำหนดค่าเซิร์ฟเวอร์ VPN อย่างปลอดภัย

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

บันทึกจุดตรวจที่คุณคืนค่าได้จริง

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

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

แยกการเพิกถอนออกจากการกำหนดค่า

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

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

เข้าถึงโฮสต์เมื่ออุโมงค์ล้มเหลว

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

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

ใช้การแก้ไขเพียงครั้งเดียวและรู้ว่าเมื่อใดจึงมีผล

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

ตรวจสอบนิยามยูนิตก่อนเลือก: systemctl show -p ExecReload openvpn@server บอกคุณว่ามีฮุก reload อยู่หรือไม่ จากนั้นใช้การแก้ไขและอ่านบันทึกเหตุการณ์เพื่อหาข้อผิดพลาดใหม่ ๆ ก่อนอื่นใด

ตรวจสอบ บันทึก และสืบสวนภายหลัง

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

systemctl status openvpn@server --no-pager
journalctl -u openvpn@server -n 50 --no-pager

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