Сценарий с одним регионом— приватный канал и DNS в виртуальной глобальной сети Azure

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

Сценарий

Рис. 1. Сценарий с одним регионом для виртуальной глобальной сети с приватным каналом и Azure DNS — задача

Скачайте файл Visio этой архитектуры. В этом разделе описывается сценарий и формулируется задача из в обзоре нерабочего примера. Архитектура основана на начальной топологии сети со следующими дополнениями:

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

Успешный результат

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

Препятствие

Для разрешения полного доменного имени (FQDN) учетной записи хранилища в частный IP-адрес частной конечной точки требуется запись DNS в конфигурации DNS. Как описано в обзоре, задача в этом сценарии двуединая:

1. Невозможно связать частную зону DNS, которая содержит необходимые записи DNS учетной записи хранения, с виртуальным концентратором.
2. Вы можете связать частную зону DNS с сетью рабочей нагрузки, поэтому она может показаться жизнеспособной, но архитектура baseline предусматривает, что каждая подключенная виртуальная сеть имеет DNS-серверы, настроенные для использования Брандмауэр Azure DNS-прокси.

Поскольку вы не можете связать частную зону DNS с виртуальным концентратором и виртуальная сеть настроена для использования прокси-сервера DNS Брандмауэр Azure, Azure DNS не может разрешить полное доменное имя учетной записи хранения в частный IP-адрес. Результатом является то, что клиент получает общедоступный IP-адрес.

Потоки DNS и HTTP

Давайте рассмотрим DNS и результирующий поток HTTP-запросов, чтобы визуализировать препятствия.

Рис. 2. Сценарий с одним регионом для виртуальной глобальной сети с приватным каналом и Azure DNS — задача

Скачайте файл Visio для этой архитектуры.

Поток DNS

1. DNS-запрос stgworkload00.blob.core.windows.net от клиента отправляется на настроенный DNS-сервер, который является брандмауэром Azure в одноранговом региональном концентраторе.
2. Прокси-сервер брандмауэра Azure передает запрос на Azure DNS. Поскольку невозможно связать частную зону DNS с виртуальным концентратором, Azure DNS не знает, как разрешить полное доменное имя (FQDN) в IP-адрес частной конечной точки. Azure DNS разрешает FQDN в общедоступный IP-адрес учетной записи хранения и возвращает значение.

ПОТОК HTTP

1. Используя результат DNS (общедоступный IP-адрес учетной записи хранения), клиент отправляет HTTP-запрос на stgworkload00.blob.core.windows.net.

2. Запрос отправляется на общедоступный IP-адрес учетной записи хранения. Этот запрос имеет ошибку по многим причинам:

   • Группа безопасности сети в подсети рабочей нагрузки может не разрешать этот трафик, привязанный к Интернету.
   • Брандмауэр Azure, который фильтрует исходящий трафик, привязанный к Интернету, скорее всего, не имеет правила приложения для поддержки этого потока.
   • Даже если группа безопасности сети и Брандмауэр Azure имеют разрешения на этот поток запросов, учетная запись хранилища настроена на блокировку всех подключений из общедоступных сетей.

   Эта попытка нарушает цель предоставления доступа только через частную конечную точку.

Решение. Установка расширения виртуального концентратора для DNS

Рекомендуемое решение для DNS в средах Виртуальная глобальная сеть заключается в реализации расширения концентратора virtual hub для DNS. Этот шаблон подробно описан в связанной архитектуре и предоставляет основу для рабочего сценария с одним регионом, показанного здесь. Расширение виртуального концентратора DNS позволяет командам по управлению нагрузкой использовать частные зоны DNS в рамках начальной топологии концентратора Виртуальная глобальная сеть.

Расширение DNS реализуется в виде периферийных виртуальных сетей, одноранговых подключений к своему региональному виртуальному концентратору. Частные DNS-зоны могут быть связаны с этой виртуальной сетью. Виртуальная сеть также содержит частный сопоставитель Azure DNS, который позволяет службам за пределами этой виртуальной сети, например Брандмауэр Azure, запрашивать и получать значения из всех связанных частных зон DNS. Ниже приведены компоненты типичного расширения виртуального концентратора для DNS, а также некоторые необходимые изменения конфигурации:

• Новая виртуальная сеть типа "спица", имеющая пиринговое соединение с виртуальным концентратором в регионе. Этот спок настраивается как любой другой спок, то есть серверы DNS по умолчанию и правила маршрутизации принуждают использовать брандмауэр Azure в региональном узле.
• Ресурс частного разрешающего сервера DNS развертывается с входящей конечной точкой в периферийной виртуальной сети.
• Создается ресурс зоны частного DNS с именем privatelink.blob.core.windows.net.
  • Эта зона содержит запись A, которая сопоставляет полное доменное имя (FQDN) учетной записи хранения с частным IP-адресом частной конечной точки для этой учетной записи хранения.
  • Частная зона DNS связана с периферийной виртуальной сетью.
  • Если позволяет управление доступом на основе ролей Azure (Azure RBAC), можно использовать автоматическую регистрацию или записи, управляемые службой, для поддержания этих записей DNS. В противном случае их необходимо поддерживать вручную.
• В региональном центре DNS-сервер брандмауэра Azure изменяется, чтобы указывать на входящую конечную точку частного DNS резолвера.

На следующей схеме показана архитектура, а также потоки DNS и HTTP.

Рис. 3. Рабочее решение для сценария с одним регионом для виртуальной глобальной сети с приватным каналом и DNS

Скачайте файл Visio для этой архитектуры.

Поток DNS для расширения виртуального концентратора

1. Dns-запрос stgworkload00.blob.core.windows.net от клиента отправляется на настроенный DNS-сервер, который является брандмауэром Azure в одноранговом региональном концентраторе — 10.100.0.132 в этом случае.

   Рис. 4. Настройка DNS-серверов для виртуальной сети нагрузки

2. Брандмауэр Azure перенаправляет запрос к региональному частному резолверу Azure DNS в расширении концентратора сети — 10.200.1.4 в этом случае, что является частным IP-адресом входящей конечной точки частного резолвера DNS.

   

   Скриншот политики брандмауэра Azure, где включена функция DNS-прокси, а DNS-серверы настроены как Custom. Точки входа указывают на частный IP-адрес входной конечной точки приватного резолвера DNS.

   Рис. 5. Настройка DNS в политике брандмауэра Azure

3. Частный резольвер DNS осуществляет проксирование запроса к Azure DNS. Так как частная зона DNS связана с виртуальной сетью, содержащей конечную точку входящего трафика, Azure DNS может использовать записи в связанных частных зонах DNS.

   Рис. 6. Ссылки виртуальной сети частной зоны DNS

4. Azure DNS обращается к связанной частной зоне DNS и разрешает полное доменное имя stgworkload00.blob.core.windows.net до 10.1.2.4, которое является IP-адресом частной конечной точки для учетной записи хранения. Этот ответ предоставляется DNS брандмауэра Azure, который затем возвращает частный IP-адрес учетной записи хранения клиенту.

   Рис. 7. Частная зона DNS с записью A для частной конечной точки учетной записи хранения

ПОТОК HTTP

1. С результатом DNS (частный IP-адрес из учетной записи хранилища) клиент отправляет HTTP-запрос на stgworkload00.blob.core.windows.net.
2. Запрос отправляется на частный IP-адрес (10.1.2.4) учетной записи хранения. Этот запрос успешно маршрутизируется при условии отсутствия конфликтующих ограничений на локальные группы безопасности сети (NSG) в подсети клиента или в подсети частной конечной точки. Важно понимать, что, хотя брандмауэр Azure обеспечивает защиту частного трафика, запрос не направляется через брандмауэр Azure, так как частная конечная точка находится в той же виртуальной сети, что и клиент. Это поведение по умолчанию может измениться, если вводятся определяемые пользователем маршруты или сетевые виртуальные устройства (NVA), но в этом сценарии предполагается стандартная модель маршрутизации виртуальной сети. Для этого сценария не требуются разрешения Брандмауэр Azure.
3. Частное подключение к аккаунту хранения устанавливается через службу Приватный канал. Учетная запись хранения разрешает доступ только к частной сети и принимает HTTP-запрос.

Расширение виртуального концентратора для учета факторов DNS

При реализации расширения для вашего предприятия рассмотрите следующее руководство.

• Развертывание расширения DNS не является задачей для группы рабочей нагрузки. Эта задача является корпоративной сетевой функцией и должна быть решением о реализации, принятого с этими лицами.
• Расширение DNS и частные зоны DNS должны существовать перед добавлением любой службы PaaS, для которой планируется настроить записи DNS частной конечной точки.
• Расширение виртуального концентратора является региональным ресурсом; избегайте межрегионального трафика и создавайте расширение концентратора для каждого регионального концентратора, в котором предполагается разрешение DNS частных конечных точек.

Спицевая виртуальная сеть

• Следуя принципу единой ответственности, виртуальная сеть для расширения DNS должна содержать только ресурсы, необходимые для разрешения DNS, и не должны предоставляться другим ресурсам.
• Виртуальная сеть для расширения DNS должна соответствовать тем же рекомендациям по настройке в разделе "Добавление периферийных сетей".

Частный резолвер DNS Azure

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

• Каждый регион должен иметь одно расширение DNS виртуального концентратора с одним частным сопоставителем DNS.

• Для этого сценария для частного сопоставителя DNS требуется только конечная точка входящего трафика, а для этого сценария нет исходящих конечных точек. Задайте частный IP-адрес входящей конечной точки в качестве пользовательской службы DNS в политике Брандмауэр Azure (см. рисунок 5).

• Для повышения устойчивости и увеличенной способности обработки нагрузки разверните две входящие точки DNS Private Resolver для каждого региона. Каждая конечная точка входящего трафика имеет один частный IP-адрес. Настройте оба частных IP-адреса в параметрах DNS Брандмауэр Azure для обеспечения избыточности разрешения.

  Рис. 8. Входящие конечные точки для частного сопоставителя DNS

• Учитывайте ограничения виртуальной сети для частного DNS-резолвера.

• Используйте выделенную подсеть входящего конечного узла размером /28 или больше в зависимости от требований сопоставителя; не передавайте её другим ресурсам.

• Группа безопасности в подсети для входящей конечной точки частного резольвера DNS должна разрешать только UDP-трафик с регионального узла до порта 53. Блокировать весь другой входящий и исходящий трафик.

Частная зона DNS

Поскольку Azure DNS Private Resolver перенаправляет запросы в Azure DNS, он может использовать все частные зоны DNS, связанные с виртуальной сетью на входящей подсети.

• Свяжите частную зону DNS с виртуальной сетью расширения виртуального концентратора.
• Следуйте инструкциям по управлению частными зонами DNS для частных конечных точек.
• Если вы ожидаете, что владельцы ресурсов PaaS будут управлять своими записями, настройте Azure RBAC соответствующим образом или реализуйте решение, такое как Приватный канал и интеграция DNS на масштабируемой основе.

Рекомендации по сценариям

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

учетная запись хранения

• Задайте доступ к общедоступной сети: отключен в разделе "Сетевое подключение ", чтобы обеспечить доступ к учетной записи хранения только через частные конечные точки.
• Добавьте частную конечную точку в подсеть, выделенную для частных конечных точек, в виртуальной сети рабочей нагрузки.
• Отправьте диагностику Azure в рабочую область Log Analytics рабочей нагрузки. Журналы доступа можно использовать для устранения неполадок конфигурации.

Безопасность частной конечной точки

Требование этого решения предусматривает ограничение доступа к аккаунту хранения. После удаления общедоступного доступа к интернету к ресурсу PaaS следует решить проблему безопасности частной сети.

Если брандмауэр Azure обеспечивает защиту частного трафика в топологии центра и луча виртуальной сети WAN, брандмауэр Azure по умолчанию запрещает подключение от луча к лучу. Этот параметр по умолчанию предотвращает доступ рабочих нагрузок в других периферийных сетях к частным конечным точкам (и другим ресурсам) в виртуальной сети рабочей нагрузки. Трафик полностью в виртуальной сети не направляется через брандмауэр Azure. Чтобы управлять доступом в виртуальной сети и добавлять более детальную защиту, рассмотрите следующие рекомендации группы безопасности сети (NSG).

• Создайте группу безопасности приложений (ASG) для группировки ресурсов, имеющих аналогичные потребности в входящего или исходящего доступа. В этом сценарии используйте ASG для клиентских виртуальных машин, которым нужен доступ к хранилищу, и для учетных записей хранения, к которым осуществляется доступ. См. настройку группы безопасности приложений (ASG) с частной конечной точкой.
• Убедитесь, что подсеть, содержащая виртуальную машину рабочей нагрузки, имеет группу безопасности сети (NSG).
• Убедитесь, что подсеть, содержащая частные конечные точки, имеет сетевую группу безопасности (NSG).

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

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

• Правила исходящего трафика:
  • Разрешить вычислению ASG получить доступ к ASG учетной записи хранения.
  • Разрешить доступ ASG к частному IP-адресу регионального узла брандмауэра Azure для UDP на порту 53.

Рис. 9. Правила NSG для подсети рабочей нагрузки

Правила NSG для подсети, содержащей частные конечные точки

Считается, что наилучшей практикой является располагать частные конечные точки в пределах небольшой выделенной подсети в пределах потребляющей виртуальной сети. Одна из причин заключается в том, что можно применять определяемые пользователем маршруты и политики сети группы безопасности сети для частных конечных точек для добавления контроля трафика и безопасности.

Этот сценарий позволяет применять строго ограничивающую группу безопасности сети.

• Правила для входящего трафика:
  • Разрешить вычислительной группе АСГ доступ к учетной записи хранения.
  • Запретить весь остальной трафик
• Правила исходящего трафика:
  • Запретить весь трафик

*Рис. 10. Правила NSG для подсети частной конечной точки

Безопасность частной конечной точки в действии

На следующем рисунке показано, как описанные рекомендации могут обеспечить глубокую безопасность на уровне обороны. На диаграмме показана вторая виртуальная сеть типа "spoke" со второй виртуальной машиной. Эта рабочая нагрузка не может получить доступ к закрытому конечному узлу.

Рис. 11. Рабочее решение для сценария с одним регионом для виртуальной глобальной сети с приватным каналом и DNS

Скачайте файл Visio для этой архитектуры.

Поток DNS

Поток DNS точно такой же, как и в потоке решения.

Главное заключается в том, что полное доменное имя сопоставляется с частным IP-адресом, а не с общедоступным IP-адресом. Это разрешение означает, что все периферийные узлы всегда получают частный IP-адрес этой службы. В этом сценарии все периферийные узлы разрешают частную конечную точку службы PaaS на свой частный IP-адрес. Хотя это позволяет совместно использовать службу в нескольких рабочих нагрузках, эта статья не предоставляет шаблон проектирования нескольких рабочих нагрузок. На данный момент основное внимание уделяется иллюстрированному здесь сценарию с одной рабочей нагрузкой.

ПОТОК HTTP

1. При наличии результата DNS и частного IP-адреса учетной записи хранения клиент отправляет HTTP-запрос на stgworkload00.blob.core.windows.net.
2. Запрос отправляется на частный IP-адрес учетной записи хранения. Этот запрос ожидаемо завершается ошибкой по многим причинам:
   • Брандмауэр Azure настроен для защиты частного трафика, поэтому он обрабатывает запрос. Если брандмауэр Azure не имеет правила сети или приложения, чтобы разрешить поток, брандмауэр Azure блокирует запрос.
   • Вам не нужно использовать брандмауэр Azure в центре для защиты частного трафика. Например, если сеть поддерживает частный, межрегионный трафик, группа безопасности сети в подсети частной конечной точки по-прежнему настроена для блокировки всего трафика, отличного от вычислительных источников ASG в виртуальной сети, на котором размещена рабочая нагрузка.

Сводка

В этой статье описывается сценарий, в котором клиент виртуальной машины подключается к учетной записи хранения Azure через частную конечную точку учетной записи хранения. Конечная точка находится в той же виртуальной сети, что и клиент. Все остальные доступ к учетной записи хранения заблокированы. Для этого сценария требуется запись DNS в работе с DNS, которая переводит полное доменное имя (FQDN) учетной записи хранения на частный IP-адрес частной конечной точки.

Начальная топология сети для этого сценария представляет две проблемы:

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

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

Связанные ресурсы

• Что собой представляет частная конечная точка?
• Конфигурация DNS частной конечной точки Azure
• Приватный канал и интеграция DNS на уровне масштабирования
• Приватный канал Azure в центральной и периферийной сети
• DNS для локальных ресурсов и ресурсов Azure
• Подключение сетей к Azure Monitor с помощью Приватного канала Azure
• Частный резолвер DNS Azure
• Более безопасный доступ к мультитенантным веб-приложениям из локальной сети
• Базовые зонально-избыточные высокодоступные веб-приложения
• Руководство. Создание инфраструктуры DNS частной конечной точки с помощью частного сопоставителя Azure для локальной рабочей нагрузки