Де застосовувати NSG для трафіку VPN «сайт — сайт» в Azure

Тунель «сайт — сайт» працює, локальний клієнт досягає одних вузлів Azure, але не інших, і хтось підключив групу безпеки мережі до GatewaySubnet, щоб це виправити. Зупиніться. Azure не підтримує NSG на GatewaySubnet, і група не бачить внутрішній пакет так, як це робить правило робочого навантаження. Розмістіть політику в цільовій підмережі або на NIC, зіставте адресу джерела, що існує після розшифрування, і потім перевірте новим з'єднанням, а не старим.

Розмістіть NSG там, де Azure його оцінює

Підтримувана межа фільтрації робочого навантаження — цільова підмережа або цільовий мережевий інтерфейс. Підмережа шлюзу є інфраструктурою, і Azure документує, що NSG там не підтримуються і можуть погіршити роботу шлюзу.

Є й логічна проблема з розміщенням. NSG на GatewaySubnet оцінював би зовнішній обмін IPsec, адреси якого належать двом шлюзам. Вашому правилу застосунку потрібне приватне джерело всередині тунелю, а цей пакет існує лише після того, як шлюз його розшифрує. Підключіть групу до підмережі робочого навантаження, і правило побачить адресу, для якої його написано.

Перевірте поточні зв'язки, перш ніж щось змінювати, щоб знати, що ви переносите:

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

Знайдіть адресу джерела після розшифрування

Внутрішнє джерело — це приватна адреса локального клієнта або адреса, яку пристрій чи NAT VPN представляє після трансляції. Це не публічна адреса локального VPN-шлюзу, яка належить зовнішньому обміну.

Коли NAT є частиною проєкту, підтвердьте представлене джерело, а не припускайте його. Захоплення пакетів на віртуальній машині Azure або поле джерела в журналі з'єднань служби вирішує питання швидше, ніж читання локальної конфігурації. Потім напишіть правило для цієї адреси та реального цільового порту.

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

Використовуйте одне правило на службу, яку хочете відкрити, і тримайте список портів коротким. Правило, яке дозволяє всі порти з локального діапазону, робить NSG формальністю.

Перевірте типовий обсяг VirtualNetwork

Тег служби VirtualNetwork ширший за локальну віртуальну мережу. Його визначення охоплює підключені локальні адресні простори, мережі з пірингом та інші префікси, підключені через шлюз. Тому типове правило дозволу, обмежене VirtualNetwork, може вже дозволяти трафік тунелю, який оператор вважав зовнішнім.

Прочитайте типові правила, перш ніж додавати вузькі, і прочитайте кожне правило з вищим пріоритетом, яке може збігтися першим. Додавання явного дозволу не видаляє ширше правило, яке вже дозволяє потік. Там, де політика вимагає заборони, розмістіть її на пріоритеті, який справді оцінюється до дозволу.

Документація Microsoft щодо тегів служб перелічує, що охоплює тег VirtualNetwork, і це джерело, на яке посилаються, коли хтось твердить, що тег означає лише діапазон VNet.

Прочитайте чинні правила на обох межах

Коли застосовуються і NSG підмережі, і NSG мережевого інтерфейсу, потік має задовольняти обидва. Дозвіл в одному не скасовує заборону в іншому, і пакет насправді зустрічає сукупний вигляд.

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

Якщо задіяні правила адміністратора безпеки Azure Virtual Network Manager, перегляньте й цей шар. Адміністративне правило Always allow може доставляти трафік без оцінки NSG, а адміністративне Deny зупиняє його раніше, ніж NSG його побачать. Перевірка лише NSG для такої схеми неповна.

Пам'ятайте, що NSG зберігають стан. Редагування правила не обов'язково завершує наявне дозволене з'єднання, тому приймальний тест потребує нового потоку. Ця властивість корисна у виробництві та оманлива у вікні змін.

Перевірте новим з'єднанням

Відкрийте новий сеанс з локального клієнта на порт служби, потім повторіть із вузла, якому має бути відмовлено. Запустіть тест потоку й з боку віртуальної машини, щоб знати, що зворотний шлях цілий.

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

Дозвіл NSG — це одне рішення про доступ, а не маршрут і не слухач. Якщо правило дозволяє потік, а з'єднання все одно не встановлюється, перевірте маршрут клієнта у VPN, зворотний маршрут Azure і брандмауер вузла, перш ніж знову редагувати групу. Запишіть фактичну адресу джерела, зв'язки NSG і відповідне правило разом із затвердженою службою, бо наступна зміна пірингу або маршруту може змінити те, що охоплює тег VirtualNetwork.