Разрешение имен ресурсов в виртуальных сетях Azure | Документация Майкрософт

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

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

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

Примечание

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

Примечание

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

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

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

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

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

Примечание

Используя веб-роли и рабочие роли облачных служб, вы можете также получать доступ ко внутренним IP-адресам экземпляров ролей с помощью REST API управления службами Azure. Дополнительные сведения см. в справочнике по REST API управления службами. Адрес основан на имени роли и номере экземпляра.

Компоненты

Разрешение имен 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 для виртуальных машин поддерживается во всех виртуальных сетях на основе ARM. Записи формы [vmname].internal.cloudapp.net , управляемые Azure, автоматически добавляются при запуске виртуальной машины и удаляются при остановке виртуальной машины (освобождена). См. следующий пример.

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

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

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

Примечание

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

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

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

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

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

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

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

  • Ubuntu (используется пакет resolvconf) :
    • Установите пакет dnsmasq с помощью команды sudo apt-get install dnsmasq.
  • SUSE (используется пакет netconf) :
    • Установите пакет dnsmasq с помощью команды sudo zypper install dnsmasq.
    • Включите службу dnsmasq с помощью команды systemctl enable dnsmasq.service.
    • Запустите службу dnsmasq с помощью команды systemctl start dnsmasq.service.
    • Измените путь /etc/sysconfig/network/config и замените блок NETCONFIG_DNS_FORWARDER="" текстом dnsmasq.
    • Укажите в файле resolv.conf кэш в качестве локального сопоставителя DNS, используя netconfig update.
  • CentOS (используется пакет NetworkManager) :
    • Установите пакет dnsmasq с помощью команды sudo yum install dnsmasq.
    • Включите службу dnsmasq с помощью команды systemctl enable dnsmasq.service.
    • Запустите службу dnsmasq с помощью команды systemctl start dnsmasq.service.
    • Добавьте строку prepend domain-name-servers 127.0.0.1; в файл /etc/dhclient-eth0.conf.
    • Перезапустите сетевую службу с помощью команды service network restart, чтобы указать кэш в качестве локального сопоставителя DNS.

Примечание

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

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

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

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

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

options timeout:1 attempts:5

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

  • Ubuntu (используется пакет resolvconf):
    1. Добавьте строку options в /etc/resolveconf/resolv.conf.d/tail.
    2. Запустите resolvconf -u, чтобы выполнить обновление.
  • SUSE (используется пакет netconf):
    1. Добавьте параметр timeout:1 attempts:5 в блок NETCONFIG_DNS_RESOLVER_OPTIONS="" в etc/sysconfig/network/config.
    2. Запустите netconfig update, чтобы выполнить обновление.
  • CentOS (используется пакет NetworkManager):
    1. Добавьте строку RES_OPTIONS="options timeout:1 attempts:5" в файл /etc/sysconfig/network-scripts/ifcfg-eth0.
    2. Выполните обновление с помощью команды systemctl restart NetworkManager.service.

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

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

Примечание

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

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

Ваши требования к разрешению имен могут выйти за рамки возможностей Azure. Например, может потребоваться использовать домены Active Directory Microsoft Windows Server или разрешение 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.

Примечание

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

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

Схема разрешения DNS между виртуальными сетями

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

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

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

Если вы предоставляете собственное решение DNS, оно должно:

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

Примечание

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

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

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

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

  2. На портале Azure для плана служб приложений, в котором размещается веб-приложение, в разделе Сети > Интеграция виртуальной сети выберите Синхронизировать сеть.

    Снимок экрана: разрешение имен виртуальной сети

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

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

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

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

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

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

Примечание

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

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

Примечание

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

При использовании классической модели развертывания можно указать DNS-серверы для виртуальной сети в портал Azure или файле конфигурации сети. Для облачных служб DNS-серверы можно указать с помощью файла конфигурации службы или в PowerShell с помощью командлета New-AzureVM.

Примечание

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

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

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

Классическая модель развертывания: