Где применять 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.