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

บันทึกเส้นทางที่ปลายทั้งสองก่อน มุมมองจากไซต์เดียวไม่สามารถแสดงเส้นทางที่ไม่สมมาตรได้ นี่ก็เป็นขั้นตอนที่ถูกข้ามบ่อยที่สุดภายใต้แรงกดดันด้านเวลา

บันทึกเส้นทางของทั้งสองไซต์ก่อนการทดสอบ

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

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

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

สังเกตคำขอและคำตอบในแต่ละเฟส

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

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

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

จัดการสถานะเซสชันเมื่อเกตเวย์เปลี่ยน

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

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

ทดสอบแอปพลิเคชันที่ถือเซสชันยาว ไม่ใช่แค่คำขอใหม่

คืนเส้นทางหลักและตรวจสอบการกระพริบ

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

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

บทความที่เกี่ยวข้อง