ถูกล็อกออกจากเซิร์ฟเวอร์ VPN ของคุณ: เก็บทางเข้าที่สองไว้
อุโมงค์ที่พังไม่ควรพรากความสามารถในการซ่อมเซิร์ฟเวอร์ไปด้วย วางแผน ทดสอบ และทบทวนเส้นทางบริหารจัดการที่เป็นอิสระก่อนที่คุณจะต้องใช้มัน
คุณเปิดคอนโซล เปลี่ยนกฎไฟร์วอลล์หนึ่งข้อ แล้วอุโมงค์ที่คุณเชื่อมต่ออยู่ก็หายไป การเปลี่ยนแปลงนั้นถูก การรีโหลดไม่ถูก และตอนนี้ทางเดียวกลับไปยังเครื่องคือทางที่คุณเพิ่งทำให้พัง ทางเข้าที่สองคือการตัดสินใจเชิงออกแบบ และมันต้องมีอยู่ก่อนเหตุขัดข้อง ไม่ใช่ระหว่างนั้น
ทบทวนสิ่งที่คุณยังมีอยู่
เริ่มจากหน้าจอคอนโซลตรงหน้าคุณและเขียนรายการเส้นทางที่ไม่ขึ้นกับอุโมงค์ คอนโซลเว็บของผู้ให้บริการที่มีเซสชันแบบอนุกรมหรือ VNC คือหนึ่ง อินเทอร์เฟซการจัดการบนเครือข่ายแยกคืออีกหนึ่ง การเข้าถึงทางกายภาพคือเส้นทางที่สาม และเป็นเส้นทางที่ผู้คนค้นพบว่าขาดหายในจังหวะที่แย่ที่สุด
| Path | Depends on | Usually fails when |
|---|---|---|
| Provider console | Account access and the provider's own API | Credentials live in a wiki only reachable over the tunnel |
| Management subnet | A second interface and its own routing | The bad change was a global route or firewall policy |
| Second tunnel | A different listener, port and credentials | Both listeners were changed in the same edit |
| Physical or local console | Being in the building | Nobody has been in the building for a year |
อ่านคอลัมน์ที่สามเป็นรายการความล้มเหลว ไม่ใช่เป็นนามธรรม เส้นทางสองในนั้นมักล้มเหลวด้วยเหตุผลเดียวกัน ตารางนี้คือวิธีที่คุณสังเกตเห็นสิ่งนั้นก่อนที่เหตุขัดข้องจะอธิบายให้คุณฟัง
ความเป็นอิสระคือคำถามเรื่องการพึ่งพา
บัญชีสำหรับกู้คืนไม่เป็นอิสระหากรหัสผ่านถูกเก็บไว้ในบริการที่คุณเข้าถึงผ่านอุโมงค์ VPN ที่สองบนโฮสต์เดียวกัน พอร์ตเดียวกัน และนโยบายไฟร์วอลล์เดียวกันก็ไม่เป็นอิสระเช่นกัน เพราะการเปลี่ยนแปลงที่ทำให้อันแรกพังก็ทำให้ทั้งสองพัง
ไล่ลงไปตามห่วงโซ่และระบุว่าขั้นตอนแต่ละขั้นต้องใช้อะไร การเข้าถึงเครือข่าย การแปลงชื่อ แหล่งยืนยันตัวตน และตัวบริการการจัดการเองคือการพึ่งพาที่แยกจากกันสี่อย่าง และเส้นทางที่ใช้ร่วมกันอย่างใดอย่างหนึ่งย่อมรับความล้มเหลวนั้นมา
เส้นทางที่ไม่เคยถูกทดสอบสมควรได้รับความสงสัยเป็นของตัวเอง คอนโซลที่ไม่ได้เปิดมาหลายเดือนอาจต้องรีเซ็ตรหัสผ่านทางอีเมล และกล่องจดหมายนั้นอาจโฮสต์อยู่บนเครื่องที่คุณเข้าถึงไม่ได้ ทดสอบเส้นทางขณะที่ทุกอย่างทำงาน และคุณจะพบสิ่งนี้ในบ่ายที่เงียบสงบ
ใช้ทางที่สองสำหรับการเปลี่ยนแปลงที่ควบคุมได้หนึ่งครั้ง
จากคอนโซล จับสแนปช็อตหรือคัดลอกการกำหนดค่าที่คุณกำลังจะแก้ไข เปลี่ยนเพียงหนึ่งสิ่ง รีโหลดบริการและอ่านผลลัพธ์ก่อนแตะสิ่งอื่น เพราะการเปลี่ยนแปลงสองอย่างพร้อมกันจะเปลี่ยนการกู้คืนให้เป็นการทดลอง
เปิดเซสชันกู้คืนไว้ขณะที่ทำสิ่งนี้ คุณค่าทั้งหมดของทางที่สองคือมันอยู่รอดจากสิ่งที่คุณกำลังเปลี่ยน ดังนั้นการปิดมันก่อนจะตัดคุณสมบัติเดียวที่ทำให้มันมีประโยชน์ออกไป
ตรวจสอบจากเส้นทางกู้คืน ไม่ใช่จากความจำ
การตรวจสอบที่สำคัญคือเส้นทางปกติกลับมาหรือไม่ และเซสชันกู้คืนคือที่ที่คุณยืนยันตามลำดับ:
systemctl status openvpn-server@server --no-pager ss -lntup | grep -E ':(1194|443)\b' nft list ruleset | sed -n '1,40p' journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30
อ่านสถานะบริการก่อน จากนั้นตัวรับฟัง จากนั้นกฎ จากนั้นบันทึกเหตุการณ์ บริการที่ทำงานโดยไม่มีตัวรับฟังชี้ไปที่การกำหนดค่าบริการ ขณะที่ตัวรับฟังที่ไม่มีกฎที่เข้าถึงได้ชี้ไปที่การกรอง ลำดับสำคัญเพราะแต่ละขั้นทำให้ขั้นถัดไปแคบลง และการข้ามไปที่บันทึกมักหมายถึงการอ่านข้อผิดพลาดที่บรรยายอาการ ไม่ใช่สาเหตุ
เอกสารของ systemctl ครอบคลุมพฤติกรรมสถานะและการรีสตาร์ตที่ใช้ที่นี่ รวมถึงวิธีที่การรีโหลดที่ล้มเหลวทำให้โปรเซสก่อนหน้ายังทำงานอยู่ การคืนสภาพเป็นฉบับที่สอดคล้องกันดีกว่าการเชื่อมต่อซ้ำแล้วซ้ำเล่าจากไคลเอนต์ที่ไม่สามารถซ่อมเซิร์ฟเวอร์ได้ หากเงื่อนไขการย้อนกลับที่คุณกำหนดไว้ก่อนการเปลี่ยนแปลงเป็นจริงแล้ว ให้คืนสภาพและหยุด
ทำให้บัญชีทรัพย์สินเป็นปัจจุบัน
ทบทวนรายการการเข้าถึงเมื่อคนหรือโครงสร้างพื้นฐานเปลี่ยน ทดสอบเส้นทางกู้คืนขณะที่ทุกอย่างทำงาน ปลดระวางบัญชีที่ไม่มีใครใช้ตั้งแต่การจัดองค์กรใหม่ครั้งล่าสุด บัญชีเก่าสองบัญชีและใบรับรองที่หมดอายุหนึ่งใบคือการทำความสะอาดเล็ก ๆ ในวันอังคารและเหตุขัดข้องในวันอาทิตย์
บันทึกว่าใครใช้แต่ละเส้นทางได้ อนุญาตอะไร และข้อมูลรับรองถูกหมุนเวียนอย่างไร เส้นทางกู้คืนที่ไม่มีเจ้าของจะกลายเป็นทางเข้าที่ถูกลืม ซึ่งเป็นความล้มเหลวอีกแบบหนึ่งจากการถูกล็อกอยู่ข้างนอก