เลือกแหล่งลงทะเบียนที่มั่นคงสำหรับสมาชิก GET VPN

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

ที่อยู่ลงทะเบียนระบุสิ่งใด

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

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

การแยกสองสิ่งนี้ออกจากกันคือขั้นแรก เพราะความสับสนส่วนใหญ่ вокругการตั้งค่านี้มาจากความคาดหวังว่าการเปลี่ยนแปลงในระนาบควบคุมจะแก้โรคในระนาบข้อมูล

Loopback ดีได้เท่ากับเส้นทางของมัน

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

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

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

แยกการควบคุมและทราฟฟิกที่ได้รับการป้องกันออกจากกัน

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

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

นโยบายระนาบข้อมูลเป็นการออกแบบแยกต่างหาก การเปลี่ยนแหล่งที่มาของการลงทะเบียนทำให้การไหลที่ได้รับการป้องกัน ตัวเลือก และกฎการข้ามยังอยู่ที่เดิม

ตรวจสอบตัวตนตลอดช่วงการเปลี่ยนผ่าน

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

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

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

สิ่งที่แหล่งที่มั่นคงไม่ได้แก้

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

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

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