Откройте виртуальную сеть на портале и посмотрите на адресное пространство, прежде чем трогать колонку подсети. Если эта /24 уже разделена на подсети рабочих нагрузок и ничего свободного не осталось, места для резервирования /27 нет, и в итоге вы либо перераспределите, либо расширите VNet, а это другое изменение с другим рассмотрением. Сначала определите пространство, потом создавайте подсеть.

Этот порядок важен, потому что подсеть шлюза — не подсеть рабочей нагрузки со специальным именем. Это резервирование адресов для управляемых экземпляров шлюза, и Azure откажет в шлюзе, если резервирование неверно.

Начните с адресного пространства

Запишите префикс VNet, подсети рабочих нагрузок и резервирование шлюза в одну строку, прежде чем что-то вводить. У 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. Округляйте вверх и никогда вниз, пока план адресов ещё меняется.

Создайте подсеть с точным именем

На портале добавьте подсеть и введите имя 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, без частной конечной точки, без делегирования службы. Если там уже что-то живёт, развёртывание завершится ошибкой, а ошибка редко называет мешающий ресурс, поэтому перед началом проверьте список ресурсов подсети.

Держите управляемую подсеть свободной от правил рабочих нагрузок

Не привязывайте к этой подсети группу безопасности сети; Microsoft помечает это как неподдерживаемое. Не связывайте таблицу маршрутов, маршрут по умолчанию которой отправляет 0.0.0.0/0 куда-либо, потому что это может нарушить работу шлюза, и держите распространение маршрутов шлюза включённым.

Ограничения доступа, которые вам действительно были нужны, разместите на подсети рабочей нагрузки или на границе проверки. Отношение к GatewaySubnet как к обычной подсети — это ошибка, из-за которой шлюз развёртывается чисто, а затем не пропускает никакой трафик.

Принудительное туннелирование имеет собственный задокументированный проект. Импровизированный маршрут по умолчанию на подсети шлюза — это не он.

Проверьте зависимости, которые портал не показывает

Прежде чем нажать «создать», пройдите по списку: точное имя, префикс внутри пространства VNet, отсутствие пересечений с локальными диапазонами, отсутствие ресурсов рабочих нагрузок внутри, отсутствие NSG и отсутствие таблицы маршрутов с маршрутом по умолчанию. Каждый из этих пунктов ломал реальное развёртывание. Затем подтвердите более широкий проект: локальный сетевой шлюз для локальной стороны, адресные пространства, которые вы собираетесь маршрутизировать, и планируется ли активный-активный режим или сосуществование. Эти решения меняют разговор о размере, и гораздо дешевле закрыть их сейчас.

Справочник по параметрам шлюза Azure — это страница, на которую ссылаются, когда спрашивают, почему подсеть не может вместить VM.

Если шлюз уже существует

Изменение размера или замена подсети шлюза не является правкой маски. Сначала проверьте поддерживаемую процедуру изменения для SKU и поколения шлюза и перечислите зависимые объекты: подключения, публичные IP-адреса, маршрутизацию и любые требования к восстановлению.

Если процедура требует пересоздания шлюза, планируйте это как миграцию службы с окном и откатом. Запишите выбранное резервирование, причину размера и правила, которые вы намеренно не привязали, чтобы следующий рецензент не починил пустую подсеть, добавив NSG.

Похожие статьи