Разрешение имен ресурсов в виртуальных сетях Azure
Внимание
Эта статья ссылается на CentOS, дистрибутив Linux, который приближается к состоянию конца жизни (EOL). Обратите внимание на использование и план соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.
Azure можно использовать для размещения решений IaaS, PaaS и гибридных решений. Чтобы упростить взаимодействие между виртуальными машинами и другими ресурсами, развернутыми в виртуальной сети, может потребоваться разрешить им взаимодействовать друг с другом. Использование легко запоминаемых и не изменяющихся имен упрощает процесс обмена данными, а не использует IP-адреса.
Если для ресурсов, развернутых в виртуальных сетях, требуется разрешение доменных имен во внутренние IP-адреса, это можно сделать с помощью одного из четырех методов:
разрешение имен с помощью собственного DNS-сервера (при этом запросы могут перенаправляться на DNS-серверы, предоставляемые Azure).
Тип разрешения имен зависит от способа взаимодействия ресурсов друг с другом. В приведенной ниже таблице представлены сценарии и соответствующие решения для разрешения имен.
Примечание.
Частные зоны 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-серверов. 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 для виртуальных машин поддерживается во всех виртуальных сетях на основе Azure Resource Manager. Записи формы [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 и связать ее с виртуальной сетью. Эта зона переопределяет зоны обратного поиска по умолчанию для виртуальной сети. Эта зона пуста. Обратный DNS возвращает NXDOMAIN , если эти записи не создаются вручную.
Автоматическая регистрация записей 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 на наиболее распространенные дистрибутивы.
RHEL/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
Примечание.
Пакет 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/CentOS (использует NetworkManager):
Используйте текстовый редактор, чтобы добавить строку
RES_OPTIONS="options timeout:1 attempts:5"в файл /etc/sysconfig/network-scripts/ifcfg-eth0.Используйте следующую команду, чтобы перезапустить службу NetworkManager:
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.
Внимание
Если VPN-шлюз используется в этой настройке вместе с пользовательскими IP-адресами DNS-сервера в виртуальной сети, то необходимо добавить в список IP-адрес Azure DNS (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-серверы, перенаправляющие запросы между двумя виртуальными сетями).
При использовании разрешения имен, предоставленного 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) для клиентов, которых оно обслуживает, и иметь доступ к Интернету.
Быть защищенным от доступа из Интернета для снижения угроз, исходящих от внешних агентов.
Примечание.
- Для повышения производительности при использовании виртуальных машин Azure в качестве DNS-серверов следует отключить IPv6.
- Группы безопасности сети выполняют роль брандмауэров для конечных точек сопоставителя DNS. Измените или переопределите правила безопасности NSG, чтобы разрешить доступ к UDP-порту 53 (и, при желании, к TCP-порту 53) на конечных точках прослушивателя DNS. Когда вы завершите настройку пользовательских DNS-серверов в сети, трафик через порт 53 будет обходить группы безопасности сети, настроенные для подсети.
Внимание
Если вы используете DNS-серверы Windows в качестве настраиваемых DNS-серверов, перенаправляющих DNS-запросы на dns-серверы Azure, убедитесь, что вы увеличиваете значение времени ожидания пересылки более 4 секунд, чтобы разрешить Рекурсивным DNS-серверам Azure выполнять правильные операции рекурсии.
Дополнительные сведения об этой проблеме см. в разделе "Перенаправление" и время ожидания разрешения условных пересылки.
Эта рекомендация также может применяться к другим платформам DNS-сервера с значением времени ожидания пересылки в 3 секунды или меньше.
Это может привести к разрешению записей зоны Частная зона DNS с общедоступными IP-адресами.
Веб-приложения
Предположим, вам необходимо выполнять разрешение имен из веб-приложения, созданного с помощью службы приложений, которое связано с виртуальной сетью, в виртуальные машины в той же виртуальной сети. В дополнение к настройке пользовательского 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-серверами, указанными для виртуальной сети.
Примечание.
Свойства сетевых подключений, например IP-адреса DNS-серверов, не следует изменять непосредственно на виртуальных машинах. Дело в том, что они могут быть удалены во время восстановление службы при замене виртуального сетевого адаптера. Это относится к виртуальным машинам Windows и Linux.
Примечание.
Изменение параметров DNS-суффикса непосредственно в виртуальных машинах может нарушить сетевое подключение, что может привести к прерыванию или потере трафика на виртуальных машинах. Чтобы устранить эту проблему, необходимо перезапустить виртуальные машины.
При использовании модели развертывания Azure Resource Manager можно указать DNS-серверы для виртуальной сети и сетевого интерфейса. Дополнительные сведения см. в разделах Создание, изменение или удаление виртуальной сети и Создание, изменение или удаление сетевых интерфейсов.
Примечание.
Если вы выбрали пользовательский DNS-сервер для виртуальной сети, необходимо указать по крайней мере один адрес IP-адрес DNS-сервера, иначе виртуальная сеть будет игнорировать конфигурацию и вместо этого использовать DNS, предоставленный Azure.
Примечание.
Если вы измените параметры DNS для уже развернутой виртуальной сети или виртуальной машины, чтобы новые параметры DNS ступили в силу, необходимо выполнить обновление аренды DHCP на всех затронутых виртуальных машинах в виртуальной сети. Для виртуальных машин под управлением ОС Windows это можно сделать, введя ipconfig /renew непосредственно на виртуальной машине. Для других ОС эти действия будут другими. См. соответствующую документацию по типу ОС.
Следующие шаги
Модель развертывания с помощью Azure Resource Manager: