การตรวจสอบ NVA ใน Azure: ทำไมคำตอบจึงผ่านไฟร์วอลล์อีกตัว

โฟลว์จากสาขาไปยัง Azure อาจถูกกำหนดเส้นทางอย่างถูกต้องทั้งสองทิศทางและยังคงล้มเหลว เพราะสองทิศทางใช้อุปกรณ์ต่างกัน คำขอออกจากสาขาผ่าน VPN ลงบน NVA A และไปถึงเวิร์กโหลด คำตอบออกจากเวิร์กโหลด ตรงกับเส้นทางที่ชี้ไปยัง NVA B และตายที่นั่น ทุกเส้นทางในภาพนั้นใช้ได้ แต่เซสชัน TCP ยังคงแตก

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

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

Route Server ตั้งโปรแกรมอะไรจริง ๆ

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

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

อ่านทั้งสองทิศทางก่อนออกแบบ

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

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

สถานะอาศัยอยู่ที่ไหน

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

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

โมเดล HA ที่รองรับและสิ่งที่แต่ละแบบสัญญา

Microsoft's guidance on เจตนาการกำหนดเส้นทางของ Virtual WAN อธิบายพฤติกรรมที่จำกัดสำหรับการเชื่อมต่อแบบสองบทบาทและ NVA ไฟร์วอลล์ ซึ่งการกำหนดเส้นทางโดยตรงสามารถข้ามการบังคับใช้แบบสมมาตรปกติของฮับ อ่านบันทึกเหล่านั้นเป็นข้อจำกัดของโทโพโลยีที่คุณเลือก ไม่ใช่ข้อห้ามของการออกแบบแอกทีฟ-แอกทีฟ คู่ผู้ขายที่ซิงโครไนซ์สถานะ หรือกำหนดเส้นทางต่อโฟลว์ สามารถรองรับได้ คู่ที่มีต้นทุนเท่ากันซึ่งไม่ทำทั้งสองอย่างนั้นไม่ได้รับการรองรับ

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

สิ่งที่ต้องทดสอบก่อนจะไว้วางใจ

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

เชื่อมโยงแต่ละโฟลว์กับอุปกรณ์ที่จัดการมัน การดักจับแพ็กเก็ตบน NVA ตัวเดียวแทบไม่บอกอะไรเลยหากคำตอบไม่เคยกลับไปที่นั่น

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