Поделиться через

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

  • Статья

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

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

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

Зоны Azure Частная зона DNS являются предпочтительным решением и обеспечивают гибкость в управлении зонами и записями DNS. Дополнительные сведения см. в статье Использование Azure DNS для частных доменов.

Примечание.

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

Сценарий Решение DNS-суффикс
Разрешение имен между виртуальными машинами, расположенными в одной виртуальной сети или Облачные службы экземплярах ролей Azure в одной облачной службе. Зоны Частная зона DNS Azure или разрешение имен, предоставленных Azure Имя узла или полное доменное имя
Разрешение имен между виртуальными машинами, расположенными в разных виртуальных сетях, или экземплярами ролей, расположенными в разных облачных службах. Зоны Azure Частная зона DNS, частный сопоставитель Azure DNS или управляемые клиентом DNS-серверы, перенаправляющие запросы между виртуальными сетями для разрешения с помощью Azure (прокси-сервер DNS). См. раздел Разрешение имен с помощью собственного DNS-сервера. только полное доменное имя
Разрешение имен из службы приложение Azure (веб-приложения, функции или бота) с помощью интеграции виртуальной сети с экземплярами ролей или виртуальными машинами в одной виртуальной сети. Частный сопоставитель DNS Azure или управляемые клиентами DNS-серверы, перенаправляющие запросы между виртуальными сетями для разрешения в Azure (DNS-прокси). См. раздел Разрешение имен с помощью собственного DNS-сервера. только полное доменное имя
Разрешение имен из Служба приложений веб-приложений на виртуальные машины в одной виртуальной сети. Частный сопоставитель DNS Azure или управляемые клиентами DNS-серверы, перенаправляющие запросы между виртуальными сетями для разрешения в Azure (DNS-прокси). См. раздел Разрешение имен с помощью собственного DNS-сервера. только полное доменное имя
Разрешение имен из Служба приложений веб-приложений в одной виртуальной сети на виртуальные машины в другой виртуальной сети. Частный сопоставитель DNS Azure или управляемые клиентами DNS-серверы, перенаправляющие запросы между виртуальными сетями для разрешения в Azure (DNS-прокси). См. раздел Разрешение имен с помощью собственного DNS-сервера. только полное доменное имя
Разрешение имен локального компьютера и службы из экземпляров роли или виртуальных машин в Azure. Частный сопоставитель Azure DNS или управляемые клиентом DNS-серверы (локальный контроллер домена, локальный контроллер домена только для чтения или дополнительный DNS-сервер, синхронизированный с помощью передачи зон, например). См. раздел Разрешение имен с помощью собственного DNS-сервера. только полное доменное имя
Разрешение имен узлов Azure с локальных компьютеров. Перенаправление запросов на управляемый клиентом прокси-сервер DNS в соответствующей виртуальной сети. Прокси-сервер перенаправляет запросы в Azure для разрешения. См. раздел Разрешение имен с помощью собственного DNS-сервера. только полное доменное имя
Обратный поиск DNS для внутренних IP-адресов. Зоны Azure Частная зона DNS, разрешение имен, разрешение имен, частный сопоставитель Azure DNS или разрешение имен с помощью собственного DNS-сервера. Нет данных
Разрешение имен между виртуальными машинами или экземплярами ролей, расположенными не в виртуальной сети, а в различных облачных службах. Неприменимо. Подключение между виртуальными машинами и экземплярами ролей в разных облачных службах не поддерживается за пределами виртуальной сети. Нет данных

разрешение имен 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 Облачные службы можно также получить доступ к внутренним IP-адресам экземпляров ролей с помощью REST API управления службами Azure. Дополнительные сведения см. в справочнике по REST API управления службами. Адрес основан на имени роли и номере экземпляра.

Функции

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

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

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

При использовании разрешения имен, предоставленных Azure, рассмотрите следующие моменты:

  • Суффикс DNS, созданный в Azure, нельзя изменить.
  • Поиск по DNS ограничивается виртуальной сетью. DNS-имена, созданные для одной виртуальной сети, не могут быть разрешены из других виртуальных сетей.
  • Регистрация собственных записей вручную запрещена.
  • WinS и NetBIOS не поддерживаются. Виртуальные машины не отображаются в проводнике Windows.
  • Имена узлов должны быть совместимыми с DNS. Имена должны использовать только от 0 до 9, от 0 до z и дефис (-). Имена не могут начинаться или заканчиваться дефисом.
  • Трафик запросов DNS регулируется для каждой виртуальной машины. Регулирование не должно влиять на большинство приложений. Если вы наблюдаете регулирование запросов, убедитесь, что кэширование на стороне клиента включено. Для получения дополнительных сведений ознакомьтесь с разделом Настройка клиента DNS.
  • Для каждой виртуальной машины в виртуальной сети необходимо использовать другое имя, чтобы избежать проблем с разрешением DNS.
  • Для всех классических виртуальных сетей, использующих классическую модель развертывания, зарегистрированы только те виртуальные машины, которые находятся в первых 180 облачных службах. Это ограничение не применяется к виртуальным сетям в Resource Manager.
  • Сервер Azure DNS использует IP-адрес 168.63.129.16. Этот адрес является статическим IP-адресом и не изменяется.

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

Обратный DNS для виртуальных машин поддерживается во всех виртуальных сетях на основе 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 возвращают две записи. Одна запись является формой \[vmname\].[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 (PTR) не хранятся в частной зоне DNS пересылки. Обратные записи DNS хранятся в обратной зоне DNS (in-addr.arpa). Обратная зона DNS по умолчанию, связанная с виртуальной сетью, недоступна для просмотра или редактирования.

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

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

Примечание.

Так как частные зоны Azure DNS являются глобальными, можно создать обратный поиск DNS для охвата нескольких виртуальных сетей. Необходимо создать зону azure Частная зона DNS для обратного поиска (in-addr.arpaзоны), а затем связать ее с виртуальными сетями. Необходимо вручную управлять обратными записями DNS для виртуальных машин.

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

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

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

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

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

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

RHEL (использует NetworkManager)

  1. Установите пакет со следующей dnsmasq командой:

    sudo yum install dnsmasq

  2. Включите службу с помощью следующей dnsmasq команды:

    systemctl enable dnsmasq.service

  3. Запустите службу с помощью следующей dnsmasq команды:

    systemctl start dnsmasq.service

  4. Использование текстового редактора для добавления prepend domain-name-servers 127.0.0.1; /etc/dhclient-eth0.confв :

  5. Чтобы перезапустить сетевую службу, используйте следующую команду:

    service network restart

Примечание.

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

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

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

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

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

options timeout:1 attempts:5

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

RHEL (использует NetworkManager)

  1. Используйте текстовый редактор для добавления строки RES_OPTIONS="options timeout:1 attempts:5" в файл /etc/sysconfig/network-scripts/ifcfg-eth0.

  2. Чтобы перезапустить NetworkManager службу, используйте следующую команду:

    systemctl restart NetworkManager.service

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

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

Примечание.

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

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

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

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

Внимание

Если azure VPN-шлюз используется в этой настройке вместе с пользовательскими IP-адресами DNS-сервера в виртуальной сети, IP-адрес Azure DNS (168.63.129.16) необходимо добавить в список для поддержания неразрывной службы.

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

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

Примечание.

Экземпляр роли может выполнять разрешение имен виртуальных машин в пределах той же виртуальной сети. В нем используется полное доменное имя, состоящее из имени узла виртуальной машины и internal.cloudapp.net DNS-суффикса. В этом случае разрешение имен выполняется успешно, только если экземпляр роли имеет имя виртуальной машины, определенное в файле Role Schema (CSCFG-файл):<Role name="<role-name>" vmName="<vm-name>">.

Экземпляры ролей, которые должны выполнять разрешение имен виртуальных машин в другой виртуальной сети (FQDN с помощью internal.cloudapp.net суффикса), должны использовать метод, описанный в этом разделе (пользовательские DNS-серверы, перенаправляющие между двумя виртуальными сетями).

Схема, показывающая DNS между виртуальными сетями.

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

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

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

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

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

  • Укажите соответствующее разрешение имен узлов с помощью динамического DNS (DDNS), например. При использовании DDNS может потребоваться отключить очистку записей DNS. Аренда DHCP Azure длинна, и очистка может преждевременно удалить записи DNS.
  • Предоставлять корректное рекурсивное разрешение для разрешения внешних доменных имен.
  • Быть доступным (по протоколам TCP и UDP через порт 53) для клиентов, которых оно обслуживает, и иметь доступ к Интернету.
  • Защита от доступа из Интернета для устранения угроз, связанных с внешними агентами.

Для повышения производительности при использовании виртуальных машин Azure в качестве DNS-серверов IPv6 следует отключить.

Группы безопасности сети (NSG) выполняют роль брандмауэров для конечных точек сопоставителя DNS. Измените или переопределите правила безопасности NSG, чтобы разрешить доступ к порту UDP 53 (и при необходимости TCP-порт 53) к конечным точкам прослушивателя DNS. После установки пользовательских DNS-серверов в сети трафик через порт 53 передает группы безопасности сети подсети.

Внимание

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

Дополнительные сведения об этой проблеме см. в разделе "Перенаправление" и время ожидания разрешения условных пересылки.

Эта рекомендация также может применяться к другим платформам DNS-сервера с значениями времени ожидания пересылки в три секунды или меньше.

Это может привести к разрешению записей зоны Частная зона DNS с общедоступными IP-адресами.

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

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

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

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

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

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

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

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

Примечание.

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

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

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

Примечание.

При изменении параметров DNS для виртуальной сети или виртуальной машины, уже развернутой, чтобы новые параметры DNS вступят в силу, необходимо выполнить продление аренды DHCP на всех затронутых виртуальных машинах в виртуальной сети. Для виртуальных машин, работающих под управлением ОС Windows, введите ipconfig /renew непосредственно в виртуальную машину. Для других ОС эти действия будут другими. См. соответствующую документацию по типу ОС.

Связанный контент

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