เส้นทางสำรอง VPN แบบลอยตัวไม่รับช่วง: รายการตรวจสอบการสลับ

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

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

ตั้งชื่อความล้มเหลวที่เส้นทางสำรองต้องครอบคลุม

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

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

เลิกขอให้ระยะทางตรวจจับอะไรก็ตาม

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

สำหรับเส้นทางคงที่ต้องมีตัวติดตามที่ชัดเจน:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

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

ติดตามว่าแพ็กเก็ตของโพรบเองไปที่ไหน

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

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

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

กำหนดความหมายของผลโพรบก่อนเพิ่มเป้าหมาย

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

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

ตรวจสอบเส้นทางขากลับและเรื่องราวของเซสชัน

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

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

ดำเนินลำดับการยอมรับ

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

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