Можно ли применить NSG к подсети ПОСЛЕ того, как управляемый экземпляр Azure SQL развернут в подсети? - PullRequest
0 голосов
/ 22 октября 2018

Можно ли применить NSG к подсети ПОСЛЕ того, как SQL MI развернут в подсети?

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance-vnet-configuration

При сохранении появляется следующая ошибка:

«Не удалось сохранить подсеть« managed-sql-dev-corp ».Ошибка: 'Обнаружены конфликты с NetworkIntentPolicy.Подробности. Подсеть или виртуальная сеть не могут иметь ресурсы или свойства, которые противоречат политике сетевых намерений. »

« Политика сетевых намерений »создана службой Azure или одной из моих собственных политик?

1 Ответ

0 голосов
/ 29 октября 2018

После развертывания Управляемого экземпляра в действительной сети / подсети будут применены некоторые «Политики намерений», которые не позволяют вам создавать некоторые конфигурации, которые могут сделать недействительной подсеть.

Например, Управляемый экземпляр может бытьразвернут только в подсети, которая не содержит других виртуальных машин.После развертывания управляемого экземпляра будет настроено целевое правило, которое не позволяет создавать виртуальные машины в этой подсети и делает подсеть недействительной после развертывания.Без этих правил вы сможете заблокировать доступ к управляемому экземпляру.Он не может блокировать все, но эта политика намерений является первой линией защиты, которую использует управляемый экземпляр для предотвращения переконфигурации подсети.

Ниже приведен пример исходящих правил, которые можно использовать в NSG.

enter image description here

  • Правило allow_management_inbound позволяет трафику управления достигать экземпляра.
  • Правило allow_misubnet_inbound разрешает связь между виртуальными машинами, которые образуют кластер управляемого экземпляра.
  • Правило allow_health_probe разрешает проверку работоспособности с хоста виртуальных машин.Без этого сервисная структура будет думать, что узлы неработоспособны, и блокирует доступ.
  • Правило allow_tds_inbound является необязательным, но без него вы не можете получить доступ к управляемому экземпляру.Рекомендуется максимально сузить диапазон IP-адресов.

Приоритетные номера не должны быть такими, как изображено, но верхние 3 правила должны иметь более высокий приоритет, чем любые правила запрета.

Для соответствия Политике намерений сети управляемого экземпляра, у NSG должны быть правила, пронумерованные на рисунке 100 и 200 вверху списка.

enter image description here

  • Правило allow_management_outbound позволяет трафику управления достигать управляемого экземпляра служб, зависит от.
  • Правило allow_misubnet_outbound разрешает связь между виртуальными машинами, образующими кластер управляемого экземпляра.

Приоритетчисла не должны быть такими, как изображено, но верхние 2 правила должны иметь более высокий приоритет, чем любые правила запрета.

Дополнительные функции управляемого экземпляра могут потребовать открытия дополнительных портов.Это будет определено в документации по конкретным функциям.

...