Разрешение имен ресурсов в виртуальных сетях Azure

Azure можно использовать для размещения решений IaaS, PaaS и гибридных решений. Чтобы упростить взаимодействие между виртуальными машинами и другими ресурсами, развернутыми в виртуальной сети, может потребоваться разрешить им взаимодействовать друг с другом. Использование легко запоминаемых и не изменяющихся имен упрощает процесс обмена данными, а не использует IP-адреса.

Если для ресурсов, развернутых в виртуальных сетях, требуется разрешение доменных имен во внутренние IP-адреса, это можно сделать с помощью одного из четырех методов:

• частные зоны Azure DNS;

• разрешение имен Azure;

• разрешение имен с помощью собственного DNS-сервера (при этом запросы могут перенаправляться на DNS-серверы, предоставляемые Azure).

• Частный сопоставитель DNS Azure

Тип разрешения имен зависит от способа взаимодействия ресурсов друг с другом. В приведенной ниже таблице представлены сценарии и соответствующие решения для разрешения имен.

разрешение имен Azure;

Разрешение имен Azure предоставляет только базовые возможности полномочных DNS-серверов. Azure управляет именами и записями зон DNS, если используется DNS, предоставляемый Azure. Вы не можете управлять именами зон DNS или жизненным циклом записей DNS. Если вам требуется полное решение DNS для виртуальных сетей, можно использовать частные зоны Azure DNS с dns-серверами , управляемыми клиентом , или частным сопоставителям Azure DNS.

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

Функции

Разрешение имен Azure предоставляет следующие возможности.

• Удобство использования. Настройка не требуется.

• обеспечение высокой доступности; Каждый набор масштабирования помещает свои виртуальные машины в группу доступности с 5 доменами сбоя (FD) и 5 доменами обновления (UD) для обеспечения доступности (дополнительные сведения о доменах сбоя и обновления см. Вам не нужно создавать кластеры DNS-серверов и управлять ими.

• Службу можно использовать с собственными DNS-серверами, чтобы разрешить как локальные, так и имена узлов Azure.

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

• Можно использовать разрешение имен между виртуальными машинами в виртуальных сетях, использующих модель развертывания с помощью Azure Resource Manager, без необходимости указывать полное доменное имя. Виртуальные сети в классической модели развертывания требуют полное доменное имя при разрешении имен в разных облачных службах.

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

Рекомендации

Указывает на то, что следует учитывать при использовании разрешения имен, предоставленных Azure:

• Суффикс DNS, созданный в Azure, нельзя изменить.

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

• Вы не можете вручную зарегистрировать собственные записи.

• WinS и NetBIOS не поддерживаются. Виртуальные машины не отображаются в проводнике Windows.

• Имена узлов должны быть совместимыми с DNS. Имена должны использовать только 0-9, a-z и "-", и не могут начинаться или заканчиваться с "-".

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

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

• Для всех классических виртуальных сетей, использующих классическую модель развертывания, зарегистрированы только те виртуальные машины, которые находятся в первых 180 облачных службах. Это ограничение не применяется к виртуальным сетям в Azure Resource Manager.

• Сервер Azure DNS использует IP-адрес 168.63.129.16. Этот адрес является статическим IP-адресом и не изменяется.

Рекомендации по обратным зонам DNS

Обратный DNS для виртуальных машин поддерживается во всех виртуальных сетях на основе Azure Resource Manager. Управляемые Azure записи обратного DNS (PTR) формы [vmname].internal.cloudapp.net автоматически добавляются в DNS при запуске виртуальной машины и удаляются при остановке виртуальной машины (освобождено). См. следующий пример.

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.cloudapp.net

Internal.cloudapp.net обратная зона DNS управляется Azure и не может просматриваться напрямую или изменяться. Перенаправление на полное доменное имя формы [vmname].internal.cloudapp.net разрешает IP-адрес, назначенный виртуальной машине.

Если частная зона Azure DNS связана с виртуальной сетью с ссылкой на виртуальную сеть и авторегистрация включена в этой связи, обратные запросы DNS возвращают две записи. Одна запись имеет форму [имя_виртуальной машины].[ privatednszonename] и другой — форма [vmname].internal.cloudapp.net. См. следующий пример.

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

При возврате двух записей PTR, как показано ранее, переадресация любого полного доменного имени возвращает IP-адрес виртуальной машины.

Обратные подстановки DNS относятся к определенной виртуальной сети, даже если это пиринговая связь с другими виртуальными сетями. Обратные запросы DNS для IP-адресов виртуальных машин, расположенных в одноранговых виртуальных сетях, возвращают NXDOMAIN.

Вы можете отключить обратную функцию DNS в виртуальной сети, создав собственную зону обратного поиска с помощью частных зон Azure DNS, а затем связав эту зону с виртуальной сетью. Например, если ip-адрес виртуальной сети равен 10.20.0.0/16, можно создать пустую частную зону DNS 20.10.in-addr.arpa и связать ее с виртуальной сетью. Эта зона переопределяет зоны обратного поиска по умолчанию для виртуальной сети. Эта зона пуста. Обратный DNS возвращает NXDOMAIN , если эти записи не создаются вручную.

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

Настройка клиента DNS

В этом разделе рассматривается кэширование на стороне клиента и повторение операций на стороне клиента.

Кэширование на стороне клиента

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

По умолчанию DNS-клиент Windows имеет встроенный кэш DNS. Некоторые дистрибутивы Linux по умолчанию не включают кэширование. Если локальный кэш отсутствует, включите кэш DNS на каждой виртуальной машине Linux.

Доступно множество различных пакетов кэширования DNS (например, dnsmasq). Ниже описаны шаги по установке пакета dnsmasq на наиболее распространенные дистрибутивы.

Повторные попытки на стороне клиента

DNS использует преимущественно протокол UDP. Так как протокол UDP не гарантирует доставку сообщений, логика повторных попыток обрабатывается в самом протоколе DNS. Каждый DNS-клиент (ОС) может реализовывать разную логику повторных попыток в зависимости от предпочтений создателя.

• Операционные системы Windows выполняют повторную попытку через одну секунду, затем через две и четыре, а затем еще через четыре секунды.
• Повторные попытки в ОС Linux по умолчанию выполняются через пять секунд. Рекомендуется изменить параметры повторных попыток, указав пять попыток с интервалами в одну секунду.

Проверьте текущие параметры на виртуальной машине Linux в файле cat /etc/resolv.conf. Например, просмотрите строку options.

options timeout:1 attempts:5

Файл resolv.conf создается автоматически и не должен быть изменен. Шаги по добавлению строки options отличаются в разных дистрибутивах.

Разрешение имен с помощью собственного DNS-сервера

В этом разделе рассматриваются виртуальные машины, экземпляры ролей и веб-приложения.

Виртуальные машины и экземпляры роли

Ваши требования к разрешению имен могут выйти за рамки возможностей Azure. Например, может потребоваться использовать домены Microsoft Windows Server Active Directory для разрешения DNS-имен между виртуальными сетями. Для покрытия этих сценариев Azure позволяет использовать собственные DNS-серверы.

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

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

При использовании разрешения имен, предоставленного Azure, протокол конфигурации динамических узлов Azure (DHCP) предоставляет внутренний суффикс DNS (internal.cloudapp.net) для каждой виртуальной машины. Этот суффикс обеспечивает разрешение имен узлов как записей имени узла в зоне internal.cloudapp.net. При использовании собственного решения разрешения имен этот суффикс не предоставляется виртуальным машинам, так как он вмешивается в другие архитектуры DNS (например, сценарии, присоединенные к домену). Вместо этого Azure предоставляет нефункционный заполнитель (reddog.microsoft.com).

При необходимости внутренний DNS-суффикс можно определить с помощью PowerShell или API.

• Для виртуальных сетей, использующих модели развертывания с помощью Resource Manager, суффикс можно определить с помощью REST API сетевого интерфейса, командлета PowerShell Get-AzNetworkInterface или команды Azure CLI az network nic show.

Если переадресация запросов в Azure не соответствует вашим потребностям, предоставьте собственное решение DNS или разверните частный сопоставитель Azure DNS.

Если вы предоставляете собственное решение DNS, необходимо выполнить следующие действия.

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

• Предоставлять корректное рекурсивное разрешение для разрешения внешних доменных имен.

• Быть доступным (по протоколам TCP и UDP через порт 53) для клиентов, которых оно обслуживает, и иметь доступ к Интернету.

• Быть защищенным от доступа из Интернета для снижения угроз, исходящих от внешних агентов.

Веб-приложения

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

Если вы еще не сделали этого, включите интеграцию с виртуальной сетью для веб-приложения, как описано в разделе Интеграция приложения с виртуальной сетью Azure.

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

Чтобы использовать пользовательские DNS-серверы, выполните приведенные действия.

• Настройте DNS-сервер в целевой виртуальной сети на виртуальной машине, которая может перенаправлять запросы в рекурсивный сопоставитель Azure (виртуальный IP-адрес: 168.63.129.16). Пример DNS-сервера пересылки доступен в коллекции шаблонов быстрого запуска Azure и на сайте GitHub.

• Настройте DNS-сервер пересылки в исходной виртуальной сети на виртуальной машине. Настройте этот DNS-сервер пересылки для перенаправления запросов на DNS-сервер в целевой виртуальной сети.

• Настройте исходный DNS-сервер в параметрах исходной виртуальной сети.

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

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

Указание DNS-серверов

При использовании собственных DNS-серверов Azure позволяет указать несколько DNS-серверов для каждой виртуальной сети. Можно также указать несколько DNS-серверов для каждого сетевого интерфейса (для Azure Resource Manager) или каждой облачной службы (для классической модели развертывания). DNS-серверы, указанные для облачной службы или сетевого интерфейса, имеют более высокий приоритет по сравнению с DNS-серверами, указанными для виртуальной сети.

При использовании модели развертывания Azure Resource Manager можно указать DNS-серверы для виртуальной сети и сетевого интерфейса. Дополнительные сведения см. в разделах Создание, изменение или удаление виртуальной сети и Создание, изменение или удаление сетевых интерфейсов.

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

Модель развертывания с помощью Azure Resource Manager:

• Управление виртуальной сетью

• Управление сетевым интерфейсом