راه‌اندازی GatewaySubnet در Azure: پیش از ساخت دروازه، آن را رزرو کنید

شبکهٔ مجازی را در پورتال باز کنید و پیش از دست زدن به تیغهٔ زیرشبکه به فضای نشانی نگاه کنید. اگر آن /24 از قبل به زیرشبکه‌های بار کاری تقسیم شده و چیزی آزاد نمانده باشد، جایی برای رزرو /27 نیست و در پایان یا باید دوباره تقسیم کنید یا VNet را گسترش دهید، که تغییری دیگر با بازبینی دیگر است. اول فضا را مشخص کنید، بعد زیرشبکه را بسازید.

این ترتیب مهم است چون زیرشبکهٔ دروازه یک زیرشبکهٔ بار کاری با نام ویژه نیست. این رزرو نشانی برای نمونه‌های مدیریت‌شدهٔ دروازه است و Azure اگر رزرو اشتباه باشد دروازه را رد می‌کند.

با فضای نشانی شروع کنید

پیش از تایپ هر چیز، پیشوند VNet، زیرشبکه‌های بار کاری و رزرو دروازه را در یک خط بنویسید. یک VNet روی 10.60.0.0/16 جا دارد؛ محدوده‌ای در انتها انتخاب کنید تا رشد بار کاری پیوسته بماند.

برای نمونه، 10.60.255.192/26 برای دروازه 64 نشانی باقی می‌گذارد و بارهای کاری در 10.60.0.0/20 می‌مانند. این نمونه‌ای از برنامه‌ریزی نشانی است، نه وعدهٔ اندازه. Microsoft اکنون برای دروازه‌های VPN غیر Basic، /27 یا بزرگ‌تر را الزامی می‌داند، که بزرگ‌تر یعنی نشانی بیشتر: /26 برابر 64 می‌دهد و /28 برابر 16. تا وقتی طرح نشانی هنوز در حال تغییر است، به بالا گرد کنید، هرگز به پایین.

زیرشبکه را با نام دقیق بسازید

در پورتال یک زیرشبکه اضافه کنید و نام GatewaySubnet را دقیقاً بنویسید، G بزرگ و S بزرگ، بدون فاصله یا پسوند. Azure همان رشته را تطبیق می‌دهد، پس Gateway-Subnet یا gateway زیرشبکه‌ای می‌سازد که سرویس دروازه از آن استفاده نمی‌کند.

همین گام از CLI، که نوشتنش در یک بازبینی آسان‌تر است:

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

زیرشبکه را خالی بگذارید. نه VM، نه endpoint خصوصی، نه واگذاری سرویس. اگر چیزی از قبل آنجا هست، استقرار شکست می‌خورد و خطا به‌ندرت منبعی را که سر راه است نام می‌برد، پس پیش از شروع فهرست منابع زیرشبکه را بررسی کنید.

زیرشبکهٔ مدیریت‌شده را از قواعد بار کاری خالی نگه دارید

به این زیرشبکه گروه امنیتی شبکه وصل نکنید؛ Microsoft آن را پشتیبانی‌نشده اعلام می‌کند. جدول مسیری را که مسیر پیش‌فرضش 0.0.0.0/0 را جایی می‌فرستد مرتبط نکنید، چون می‌تواند کار دروازه را مختل کند، و انتشار مسیرهای دروازه را فعال نگه دارید.

محدودیت‌های دسترسی را که واقعاً می‌خواستید روی زیرشبکهٔ بار کاری یا در مرز بازرسی بگذارید. رفتار با GatewaySubnet مانند یک زیرشبکهٔ عادی همان اشتباهی است که دروازه‌ای می‌سازد که پاک مستقر می‌شود و بعد هیچ ترافیکی را عبور نمی‌دهد.

تونل اجباری طراحی مستند خودش را دارد. یک مسیر پیش‌فرض بداهه روی زیرشبکهٔ دروازه آن نیست.

وابستگی‌هایی را که پورتال نشان نمی‌دهد بررسی کنید

پیش از زدن دکمهٔ ساخت، فهرست را مرور کنید: نام دقیق، پیشوند درون فضای VNet، نبود هم‌پوشانی با محدوده‌های محلی، نبود منابع بار کاری درون آن، نبود NSG و نبود جدول مسیری با مسیر پیش‌فرض. هر یک از این‌ها استقراری واقعی را شکسته است. سپس طراحی گسترده‌تر را تأیید کنید: دروازهٔ شبکهٔ محلی برای سمت محلی، فضاهای نشانی که انتظار دارید مسیریابی شوند، و اینکه حالت فعال-فعال یا هم‌زیستی برنامه‌ریزی شده است یا نه. این انتخاب‌ها گفت‌وگوی اندازه را تغییر می‌دهند و حل آن‌ها همین حالا بسیار ارزان‌تر است.

مرجع تنظیمات دروازهٔ Azure صفحه‌ای است که وقتی کسی می‌پرسد چرا زیرشبکه نمی‌تواند یک VM را در خود جای دهد به آن استناد می‌کنید.

اگر دروازه از قبل وجود دارد

تغییر اندازه یا جایگزینی زیرشبکهٔ دروازه ویرایش ماسک نیست. نخست رویهٔ تغییر پشتیبانی‌شده برای SKU و نسل دروازه را بررسی کنید و اشیای وابسته را فهرست کنید: اتصال‌ها، IPهای عمومی، مسیریابی و هر الزام بازیابی.

اگر رویه نیازمند بازسازی دروازه است، آن را به‌عنوان مهاجرت سرویس با یک پنجره و بازگشت برنامه‌ریزی کنید. رزروی را که انتخاب کردید، دلیل اندازه و قواعدی را که عمداً وصل نکردید ثبت کنید تا بازبین بعدی زیرشبکهٔ خالی را با افزودن NSG درست نکند.