ทดสอบการกู้คืนเซิร์ฟเวอร์ VPN หลังรีบูต: ควรตรวจอะไรก่อน

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

เจ้าของสี่แบบ การทดสอบสี่แบบ

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

เจ้าของแต่ละรายเก็บการกำหนดค่าของตนไว้ที่ต่างกัน เซิร์ฟเวอร์ OpenVPN ที่จัดการโดย systemd อ่านการกำหนดค่าเมื่อเริ่มต้น ดังนั้นสิ่งที่อยู่ในไฟล์ตอนบูตคือสิ่งที่รัน อินเทอร์เฟซ wg-quick ดึงที่อยู่ เส้นทาง และ DNS จากไฟล์เดียวกัน ซึ่งหมายความว่าอินเทอร์เฟซที่ยกขึ้นด้วยมือจากเชลล์และไม่เคยเปิดใช้เป็นยูนิตจะไม่กลับมา คอนเทนเนอร์นำจุดเริ่มต้นกลับมา แต่ไม่นำการเปลี่ยนแปลงไฟร์วอลล์ของโฮสต์กลับมา เว้นแต่การเปลี่ยนแปลงนั้นอยู่ภายนอกคอนเทนเนอร์

เส้นฐานก่อน ไม่อย่างนั้นผลลัพธ์ไม่มีความหมาย

บันทึกสถานะที่ทำงานอยู่ขณะที่ยังทำงาน: ที่อยู่บนอุโมงค์ เส้นทางสำหรับซับเน็ตไคลเอนต์ กฎ NAT หรือการส่งต่อ ซ็อกเก็ตที่รอฟัง และ sysctl การส่งต่อ ip addr show wg0, ip route, nft list ruleset หรือ iptables-save, ss -lunp และ sysctl net.ipv4.ip_forward เพียงพอในโฮสต์ส่วนใหญ่

บันทึกว่าบริการถูกกำหนดค่าให้เริ่มอย่างไร ไม่ใช่แค่ว่ากำลังทำงาน systemctl is-enabled wg-quick@wg0 และ systemctl is-active wg-quick@wg0 ตอบคำถามต่างกัน และสถานะที่เปิดใช้งานคือสิ่งที่สำคัญตอนบูต ตามที่อธิบายใน systemctl(1) สำหรับ OpenVPN ให้ตรวจว่าโฮสต์ใช้เทมเพลตใด เพราะ openvpn@server และ openvpn-server@server เป็นยูนิตต่างกันที่มีค่าเริ่มต้นต่างกัน

ทำรีบูตและอ่านความล้มเหลวแรก

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

เดมอนอาจทำงานอยู่ขณะที่อุโมงค์ใช้งานไม่ได้ และนี่คือการผ่านแบบผิดที่พบบ่อยที่สุด การเริ่มต้นอาจเสร็จก่อนที่เครือข่ายจะออนไลน์ถ้ายูนิต รอเฉพาะ network.target แทน network-online.target ไฟล์ที่อ้างอิงเช่นใบรับรอง กุญแจ หรือ CRL อาจอ่านไม่ได้ในขณะนั้นเพราะเมานต์หรือเส้นทางความลับยังไม่พร้อม ปัญหาทั้งสองไม่ปรากฏใน systemctl status จนกว่าคุณจะอ่านเจอร์นัลของยูนิต

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

สามเงื่อนไขที่กำหนดการแก้ไขของคุณ

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

แก้ไขในที่ที่การตั้งค่าเป็นเจ้าของ ใส่การส่งต่อใน sysctl drop-in ใส่กฎ NAT ในชุดกฎที่โหลดตอนบูต เปิดใช้ยูนิตแทนการเริ่ม และเก็บความลับบนเส้นทางที่มีอยู่ก่อนยูนิตเริ่ม การเพิ่มการหน่วงเวลาให้ยูนิตซ่อนการพึ่งพาแทนที่จะประกาศมัน

บันทึกผลลัพธ์ใน runbook

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

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