Azure peering หรือ VPN จาก VNet ถึง VNet? ตัดสินใจก่อนกำหนดเส้นทาง

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

สามเงื่อนไขที่กำหนดรูปแบบ

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

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

เงื่อนไข 1: คุณต้องการขอบเขต IPsec ที่เป็นของคุณหรือไม่

Peering ขนส่งทราฟฟิกบนโครงข่ายหลักส่วนตัวของ Azure และไม่ต้องใช้เกตเวย์ VPN สำหรับการเชื่อมต่อแบบ peered เอง นี่เป็นข้อความเกี่ยวกับการขนส่ง ไม่ใช่ข้อความเกี่ยวกับการเข้ารหัสที่คุณมอบให้ผู้ตรวจสอบได้ว่า «เราใช้ IPsec» ถ้าความต้องการระบุอุโมงค์ที่ลูกค้าตั้งค่า นโยบาย IKE ที่เฉพาะเจาะจง หรือขอบเขตที่สิ้นสุดบนอุปกรณ์ที่คุณควบคุม peering ไม่ตอบสนองสิ่งนั้น ไม่ว่าโครงข่ายหลักจะเป็นส่วนตัวเพียงใด

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

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

เงื่อนไข 2: โทโพโลยีเป็นแบบตรงหรือมีบางอย่างต้องส่งผ่าน

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

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

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

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

เงื่อนไข 3: ใครเป็นเจ้าของเส้นทางส่งผ่านและใบเรียกเก็บเงิน

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

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

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

ตรวจสอบทางเลือกกับข้ออ้างของมันเอง

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

ถ้าการตรวจขัดแย้งกับประโยค ให้แก้ประโยคก่อน ความสับสนส่วนใหญ่ในการออกแบบเหล่านี้มาจากส่วนผสมที่ไม่มีใครอธิบาย peering สำหรับซับเน็ตของภาระงาน VPN สำหรับบริการเก่าหนึ่งบริการ และตารางเส้นทางที่เลือกข้างใดข้างหนึ่งอย่างเงียบ ๆ