Руководство по частной ссылке и DNS в Виртуальной глобальной сети Azure

Приватный канал Azure

Azure DNS

Брандмауэр Azure

Виртуальная глобальная сеть Azure

Приватный канал Azure позволяет клиентам получать доступ к службам PaaS Azure непосредственно из частных виртуальных сетей без использования общедоступного IP-адреса. Для каждой службы вы настраиваете частную конечную точку, которая использует частный IP-адрес из сети. Затем клиенты могут использовать частную конечную точку для частного подключения к службе.

Клиенты используют полное доменное имя службы для подключения к службе. Вы настраиваете DNS в сети для разрешения FQDN службы на частный IP-адрес конечной точки.

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

Запуск топологии сети

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

Рис. 1. Запуск топологии сети для всех сценариев частной конечной точки и DNS

Скачайте файл Visio этой архитектуры. Эта топология имеет следующие характеристики:

Это сеть с концентраторами, реализованная с помощью Виртуальной глобальной сети Azure.
Существует два региона с защищенным виртуальным концентратором, включающим Брандмауэр Azure.
Каждый защищенный региональный виртуальный концентратор имеет следующие параметры безопасности для подключений к виртуальной сети Azure:
- Интернет-трафик: Защищено Брандмауэр Azure – весь трафик в интернет проходит через брандмауэр регионального концентратора.
- Приватный трафик: Защищено Брандмауэр Azure — весь трафик между спицами проходит через брандмауэр регионального концентратора.
Каждый региональный виртуальный концентратор защищен брандмауэром Azure. Брандмауэры регионального концентратора имеют следующие параметры:
- DNS-серверы: По умолчанию (предоставлено Azure) — брандмауэр регионального концентратора использует Azure DNS для разрешения FQDN в коллекциях правил.
- DNS-прокси: включен — брандмауэр регионального концентратора отвечает на запросы DNS через порт 53. Перенаправляет запросы на Azure DNS для некэшированных значений.
- Журналы проверки правил брандмауэра и запросов DNS-прокси записываются в рабочую область Log Analytics, расположенную в том же регионе. Это логирование является стандартным требованием к безопасности сети.
Каждое спицевое соединение использует частный IP-адрес локального брандмауэра в качестве DNS-сервера. В противном случае вычисление правила полного доменного имени может быть не синхронизировано.

Меж-региональная маршрутизация

Маршрутизационные намерения и политики маршрутизации концентратора Виртуальная глобальная сеть позволяют управлять потоками трафика между концентраторами и контролировать, проходит ли этот трафик проверку Брандмауэр Azure или другого решения безопасности.

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

Если вам нужно, чтобы Брандмауэр Azure проверял частный трафик между концентраторами, вы можете включить это поведение, настроив политику маршрутизации частного трафика Private Traffic и активировав проверку межконцентраторного трафика. Это позволяет перенаправить частный трафик между центрами через Брандмауэр Azure для проверки.

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

Добавление спицевых сетей

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

Рис. 2. Настройка безопасности для подключений к виртуальной сети в виртуальном концентраторе

Ключевые проблемы

Начальная топология сети создает проблемы для настройки DNS для частных конечных точек.

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

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

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

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

Замечание

Чтобы настроить региональный брандмауэр в качестве DNS-поставщика сети-спицы, задайте пользовательский DNS-сервер в виртуальной сети-спице, чтобы указать частный IP-адрес брандмауэра вместо обычного значения DNS Azure.

Учитывая сложность включения DNS-прокси в региональных брандмауэрах, давайте рассмотрим причины его включения.

Брандмауэр Azure сетевые правила поддерживают ограничения на основе FQDN, чтобы точнее контролировать исходящий трафик, который правила приложения не обрабатывают. Прокси-сервер DNS должен быть включен для этой функции. Обычно используется ограничение трафика протокола NTP для известных конечных точек, таких как time.windows.com.
Служба ведения журнала запросов DNS обеспечивает преимущества для групп безопасности. Требуя, чтобы все подключенные ресурсы использовали брандмауэр Azure в качестве поставщика DNS, обеспечивается широкий охват ведения журнала, благодаря встроенной поддержке журналирования запросов DNS в брандмауэре Azure.

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

Рабочий сценарий

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

Рис. 3. Базовая конфигурация DNS для частных конечных точек

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

Клиент выдает запрос на stgworkload00.blob.core.windows.net.
Azure DNS, настроенный DNS-сервер для виртуальной сети, запрашивается IP-адрес для stgworkload00.blob.core.windows.net.

Выполнение следующей команды из виртуальной машины иллюстрирует, что виртуальная машина настроена на использование Azure DNS (168.63.129.16) в качестве поставщика DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 168.63.129.16
         DNS Servers: 168.63.129.16    
```
Частная зона privatelink.blob.core.windows.net DNS связана с Workload VNet, поэтому Azure DNS включает записи из Workload VNet в ответ.
Так как запись A существует в частной зоне DNS, которая сопоставляет полное доменное имя, stgworkload00.privatelink.blob.core.windows.net, с частным IP-адресом частной конечной точки, возвращается частный IP-адрес 10.1.2.4.

При выполнении следующей команды из виртуальной машины полное доменное имя учетной записи хранения разрешается на частный IP-адрес частной конечной точки.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 10.1.2.4   -- link: eth0
                                    (stgworkload00.privatelink.blob.core.windows.net)
```
Запрос отправляется частному IP-адресу частной конечной точки, которая составляет 10.1.2.4.
Запрос направляется через Приватный канал к учетной записи хранения.

Эта конструкция работает, так как Azure DNS:

Для виртуальной сети настроен DNS-сервер.
Известно о привязанной частной зоне DNS.
Разрешает DNS-запросы с помощью значений зоны.

Нерабочий сценарий

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

Рис. 4. Наивная попытка использовать частные конечные точки в начальной топологии сети

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

Клиент выдает запрос на stgworkload00.blob.core.windows.net.

При выполнении следующей команды на виртуальной машине показано, что виртуальная машина настроена на использование брандмауэра виртуального концентратора в качестве поставщика DNS.
```
resolvectl status eth0

Link 2 (eth0)
      Current Scopes: DNS
  Current DNS Server: 10.100.0.132
         DNS Servers: 10.100.0.132    
```
Брандмауэр включает DNS-прокси с параметром по умолчанию для пересылки запросов в Azure DNS. Запрос пересылается в Azure DNS.
Azure DNS не может разрешить stgworkload00.blob.core.windows.net в частный IP-адрес частной конечной точки, так как:
1. Частная зона DNS не может быть связана с концентратором виртуальной глобальной сети.
2. Azure DNS не знает о частной зоне DNS, связанной с виртуальной сетью рабочей нагрузки, так как настроенный DNS-сервер для виртуальной сети рабочей нагрузки является брандмауэром Azure.
Azure DNS отвечает на общедоступный IP-адрес учетной записи хранения.

При выполнении следующей команды из виртуальной машины полное доменное имя учетной записи хранения преобразуется в общедоступный IP-адрес учетной записи хранения.
```
resolvectl query stgworkload00.blob.core.windows.net

stgworkload00.blob.core.windows.net: 52.239.174.228 -- link: eth0
                                    (blob.bn9prdstr08a.store.core.windows.net)
```
Так как брандмауэр Azure выполняет прокси-запросы DNS, мы можем регистрировать их. Ниже приведены примеры журналов прокси-сервера DNS брандмауэра Azure.
```
DNS Request: 10.1.0.4:60137 - 46023 A IN stgworkload00.blob.core.windows.net. udp 63 false 512 NOERROR qr,rd,ra 313 0.009424664s
DNS Request: 10.1.0.4:53145 - 34586 AAAA IN blob.bn9prdstr08a.store.core.windows.net. udp 69 false 512 NOERROR qr,aa,rd,ra 169 0.000113s    
```
Клиент не получает частный IP-адрес для конечной точки приватного канала и не может установить частное подключение к учетной записи хранения.

Это поведение является ожидаемым. Это та проблема, на которую направлены сценарии.

Сценарии

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

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

Это важно

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

Каждый сценарий начинается с требуемого конечного состояния и сведения о требуемой конфигурации для получения от начальной топологии сети до требуемого конечного состояния. Решение использует паттерн расширений виртуального хаба, который предоставляет общие службы в качестве безопасного расширения регионального концентратора, а также Azure DNS Private Resolver для разрешения DNS на частных конечных точках в средах Виртуальная глобальная сеть. В следующей таблице содержатся ссылки на шаблон расширения виртуального концентратора и сценарии.

Гид	Описание
Выделенный PaaS в отдельном регионе	Рабочая нагрузка в одном регионе обращается к одному выделенному ресурсу PaaS.

Дальнейшие действия

Прочитайте сценарий использования выделенных ресурсов PaaS в отдельном регионе

Обратная связь

Были ли сведения на этой странице полезными?