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

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

Azure DNS

Брандмауэр Azure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

В следующем примере показана базовая конфигурация частной конечной точки. Виртуальная сеть содержит клиент, требующий использования службы 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    
```
Частная зона DNS privatelink.blob.core.windows.net связана с виртуальной сетью рабочей нагрузки, поэтому Azure DNS включает записи из виртуальной сети рабочей нагрузки в ответ.
Так как запись 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 во время предоставления через Приватный канал, что может привести к различным поведением, но такие различия обычно не являются фактором в решениях для этих сценариев.

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

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

Следующие шаги

Чтение отдельного региона, выделенного сценария ресурсов PaaS

Share via

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