ตั้งค่า GatewaySubnet ใน Azure: จองพื้นที่ก่อนสร้างเกตเวย์

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

ลำดับนี้สำคัญเพราะ subnet ของเกตเวย์ไม่ใช่ subnet สำหรับงานที่ตั้งชื่อพิเศษ มันคือการจองที่อยู่สำหรับอินสแตนซ์เกตเวย์ที่จัดการให้ และ Azure จะปฏิเสธเกตเวย์หากการจองไม่ถูกต้อง

เริ่มจากพื้นที่ที่อยู่

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

ตัวอย่างเช่น 10.60.255.192/26 เหลือ 64 ที่อยู่ให้เกตเวย์ ขณะที่งานยังอยู่ใน 10.60.0.0/20 นี่คือตัวอย่างของการวางแผนที่อยู่ ไม่ใช่คำสัญญาเรื่องขนาด Microsoft ปัจจุบันกำหนดให้ใช้ /27 หรือใหญ่กว่าสำหรับเกตเวย์ VPN ที่ไม่ใช่ Basic โดยที่ใหญ่กว่าหมายถึงมีที่อยู่มากกว่า: /26 ให้ 64 ส่วน /28 ให้ 16 ปัดขึ้นเท่านั้น อย่าปัดลง ตราบใดที่แผนที่อยู่ยังเปลี่ยนแปลงได้

สร้าง subnet ด้วยชื่อที่แน่นอน

ในพอร์ทัล เพิ่ม subnet แล้วพิมพ์ชื่อ GatewaySubnet ให้ตรงทุกตัวอักษร G ใหญ่ และ S ใหญ่ โดยไม่มีช่องว่างหรือคำต่อท้าย Azure จับคู่สตริงนั้น ดังนั้น Gateway-Subnet หรือ gateway จะสร้าง subnet ที่บริการเกตเวย์จะไม่ใช้งาน

ขั้นตอนเดียวกันจาก CLI ซึ่งจดลงในการตรวจทานได้ง่ายกว่า:

az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26

ปล่อย subnet ให้ว่าง ไม่มี VM ไม่มีปลายทางส่วนตัว ไม่มีการมอบหมายบริการ หากมีสิ่งใดอาศัยอยู่แล้ว การปรับใช้จะล้มเหลวและข้อผิดพลาดแทบไม่ระบุทรัพยากรที่ขวางอยู่ ดังนั้นตรวจสอบรายการทรัพยากรของ subnet ก่อนเริ่ม

เก็บ subnet ที่จัดการให้ปลอดจากกฎของงาน

อย่าแนบกลุ่มความปลอดภัยของเครือข่ายกับ subnet นี้ Microsoft ระบุว่าไม่สนับสนุน อย่าเชื่อมตารางเส้นทางที่เส้นทางเริ่มต้นส่ง 0.0.0.0/0 ไปที่ใดที่หนึ่ง เพราะอาจทำให้เกตเวย์ทำงานผิดพลาด และเปิดการเผยแพร่เส้นทางของเกตเวย์ไว้

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

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

ตรวจสอบการพึ่งพาที่พอร์ทัลไม่แสดง

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

เอกสารอ้างอิงการตั้งค่าเกตเวย์ของ Azure คือหน้าที่ควรอ้างเมื่อมีคนถามว่าทำไม subnet จึงรับ VM ไม่ได้

หากมีเกตเวย์อยู่แล้ว

การเปลี่ยนขนาดหรือเปลี่ยน subnet ของเกตเวย์ไม่ใช่การแก้ไขมาสก์ ตรวจสอบขั้นตอนการเปลี่ยนแปลงที่รองรับสำหรับ SKU และรุ่นของเกตเวย์ก่อน แล้วระบุออบเจ็กต์ที่ขึ้นอยู่: การเชื่อมต่อ IP สาธารณะ การกำหนดเส้นทาง และข้อกำหนดการกู้คืนใด ๆ

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