Налаштування 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 зараз вимагає /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.