Azure VNet ที่เชื่อมต่อแบบ peering ต้องมี VPN gateway ของตัวเองหรือไม่

spoke VNet ใหม่เกิดขึ้น hub มีเกตเวย์ site-to-site ที่ทำงานอยู่แล้ว และคำถามที่ชัดเจนคือคุณต้องจ่ายเงินสำหรับเกตเวย์ที่สองหรือไม่ โดยปกติไม่ต้อง เพราะ gateway transit ให้ spoke ใช้เกตเวย์ของ hub ข้าม peering ได้ มีสามเงื่อนไขที่ตัดสินว่าจะทำงานได้หรือไม่ และไม่มีเงื่อนไขใดมองเห็นได้จากป้ายสถานะ peering การเชื่อมต่อ peering และสิทธิ์ในการใช้เกตเวย์ของผู้อื่นเป็นคนละการตั้งค่า ดังนั้น VM สองเครื่องที่ ping กันได้อยู่แล้วไม่ได้พิสูจน์อะไรเกี่ยวกับเส้นทาง VPN

เงื่อนไขแรก: เกตเวย์ และการไม่มีเกตเวย์ใน spoke

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

อย่าลบเกตเวย์ spoke ที่มีอยู่เพื่อให้ตัวเลือกปรากฏ จนกว่าคุณจะรู้ว่าอะไรพึ่งพามัน ลำดับการย้ายสำคัญกว่าช่องทำเครื่องหมาย

เงื่อนไขที่สอง: หนึ่งการตั้งค่าในแต่ละทิศทางของ peering

peering คือสองออบเจกต์ หนึ่งบนแต่ละ VNet และการตั้งค่า transit อยู่คนละด้านของคู่นั้น peering ของ hub ไปยัง spoke ต้องอนุญาตให้เกตเวย์ของ hub ให้บริการ spoke; peering ของ spoke ไปยัง hub ต้องยอมรับเกตเวย์ของ hub คู่มือ gateway transit ของ Microsoft ตั้งชื่อตามทิศทาง และนั่นคือวิธีเดียวที่จะรักษาให้ถูกต้อง:

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

เงื่อนไขที่สาม: พื้นที่แอดเดรสและขอบเขตสิทธิ์

transit ไม่สามารถทำให้คำนำหน้าปลายทางเดียวกันหมายถึงสองเครือข่ายได้ ดังนั้นช่วงของ hub, spoke และเครือข่ายภายในองค์กรต้องไม่ทับซ้อนกันก่อนที่สิ่งใดจะทำงาน VNet อาจอยู่ใน subscription หรือ tenant ที่ต่างกันก็ได้ นั่นไม่ใช่ข้อห้าม แต่ตัวตนที่สร้างหรืออัปเดต peering แต่ละรายการต้องมีสิทธิ์ที่จำเป็นบนเครือข่ายนั้น การเปลี่ยนแปลงข้าม subscription มักล้มเหลวเรื่องสิทธิ์ และข้อผิดพลาดนั้นอ่านผิดว่าเป็นปัญหาทอโปโลยีได้ง่าย

เขียนช่วงและเจ้าของไว้ก่อนการเปลี่ยนแปลง การเดาในสิ่งใดสิ่งหนึ่งจะสร้าง peering ที่เชื่อมต่อได้แต่ไม่กำหนดเส้นทางใดเลย

ตรวจสอบด้วยเส้นทางที่มีผล ไม่ใช่ด้วยสถานะ peering

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

ทดสอบบริการหนึ่งรายการจากเวิร์กโหลด spoke และติดตามการตอบกลับ การทดสอบจากเกตเวย์ VPN หรือจาก VM ของ hub ใช้ prefix ต้นทางและเส้นทางที่ต่างกัน

หากทอโปโลยีให้บริการลูกค้า point-to-site ด้วย ให้ตรวจสอบเส้นทางที่ติดตั้งไว้ของพวกเขาแยกต่างหาก แพ็กเกจไคลเอนต์ Windows อาจต้องสร้างใหม่หลังการเปลี่ยนแปลงทอโปโลยี และนั่นคืองานกำหนดเส้นทางฝั่งไคลเอนต์ ไม่ใช่หลักฐานว่าการแชร์เกตเวย์ล้มเหลว

สิ่งที่การแชร์เกตเวย์ไม่ได้ให้

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

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