Microsoft AZ-140: Сетевое взаимодействие, подключение и транспорт — Руководство по подготовке

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

Часть Microsoft Azure Virtual Desktop Specialty AZ-140 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Сетевое взаимодействие, подключение и транспорт являются основой стабильного и производительного развертывания Azure Virtual Desktop (AVD). Плоскость управления доступна из интернета и полностью управляется Microsoft, в то время как узлы сеансов находятся в ваших виртуальных сетях и должны иметь доступ к службам платформы Azure и, зачастую, к локальным приложениям. Продуманная архитектура сочетает принципы наименьших привилегий и нулевого доверия (zero-trust) с необходимостью обеспечить транспорт с низкой задержкой и устойчивостью к потерям для пользовательского сеанса. В этом разделе собраны шаблоны и решения для проектирования виртуальных сетей, контроля доступа, исходящих подключений, гибридных каналов, частного доступа и устранения неполадок.

Проектирование сети для узлов сеансов: VNet, подсети, NSG, ASG, UDR и DNS

• Топология VNet и подсетей

  • Используйте топологию «звезда» (hub-and-spoke). Размещайте общие службы (Azure Firewall, NAT Gateway, VPN/ExpressRoute, Private DNS Resolver) в центральной сети (hub); размещайте узлы сеансов AVD в одной или нескольких периферийных сетях (spoke) для каждого региона и уровня рабочей нагрузки.
  • Сегментируйте по функциям. Создавайте выделенные подсети для узлов сеансов, инструментов управления/обслуживания, Azure Bastion и любых NVA. Держите AzureBastionSubnet отдельно и с требуемым размером.
  • Адресация. Выделяйте достаточное количество IP-адресов для автомасштабирования и жизненного цикла образов. Зарезервируйте емкость для роста масштабируемых наборов и режимов вывода узлов из эксплуатации (drain modes).

• NSG и ASG

  • Входящие подключения: Запрещать по умолчанию. Не открывайте доступ к TCP 3389 из интернета. Разрешайте только:
    • Доступ от Azure Bastion к узлам сеансов по TCP 3389 для аварийного административного доступа, ограниченный подсетью AzureBastionSubnet или группой ASG для управления.
    • Доступ для RDP Shortpath для управляемых сетей по UDP 3390 только из доверенных частных источников (подсети филиалов, пулы адресов корпоративного VPN или префиксы ExpressRoute).
  • Исходящие подключения: Разрешайте минимально необходимый набор, используя теги служб и FQDN. Используйте теги служб AzureVirtualDesktop, Storage, KeyVault, AzureActiveDirectory, AzureMonitor, WindowsUpdate и MicrosoftGraph, где это применимо. Предпочитайте использовать ASG для указания групп узлов сеансов вместо IP-адресов.

• UDR и маршрутизация

  • Интернет по умолчанию и принудительное туннелирование. Если вы используете принудительное туннелирование через NVA или локальную сеть, убедитесь, что явные маршруты для трафика плоскости управления AVD по-прежнему разрешены в интернет или предоставляются через Private Link. Избегайте «черной дыры» для маршрута 0.0.0.0/0 без разрешений на исходящий трафик для служб Azure, необходимых агенту AVD и FSLogix.
  • Транзит через шлюз и пиринг. Включите транзит через шлюз из центральной сети в периферийные и осторожно используйте распространение BGP; проверяйте действующие маршруты на сетевых интерфейсах (NIC), чтобы убедиться в конечном результате.
  • Масштабирование исходящего трафика. Подключите NAT Gateway к подсетям узлов сеансов, когда множество узлов обращаются в интернет, чтобы избежать исчерпания портов SNAT и стабилизировать исходящие IP-адреса.

• DNS

  • Для узлов, присоединенных к Active Directory или Azure AD DS, настройте VNet на использование соответствующих DNS-серверов домена; предоставляемый Azure DNS не может разрешать записи AD SRV. Для Azure AD DS укажите в настройках DNS виртуальной сети IP-адреса управляемого домена перед присоединением узлов сеансов к домену.
  • Гибридное разрешение имен: Используйте Azure DNS Private Resolver для связи между частными зонами Azure Private DNS и локальными DNS. Настройте правила для исходящих запросов для перенаправления выбранных зон (например, зон privatelink и Azure PaaS) и правила для входящих запросов для обслуживания локальных клиентов.
  • Частный DNS. Свяжите частные зоны со всеми VNet, которые должны разрешать имена частных конечных точек (для Storage, Key Vault и AVD Private Link, если они используются).

Сетевое подключение и транспорт: обратное подключение, Shortpath, UDP/TCP и необходимые конечные точки

• Транспорт с обратным подключением

  • Узлы сеансов инициируют исходящие TLS-соединения к плоскости управления и шлюзам AVD; клиенты подключаются к шлюзам по TLS. Брокер организует обратное подключение, чтобы узел сеансов никогда не требовал входящего RDP-подключения из общедоступной сети. Такая архитектура устраняет необходимость открывать порт TCP 3389 в интернет и позволяет работать из-за NAT, брандмауэров и прокси-серверов.
  • Обеспечьте исходящий трафик по TCP 443 и, для оптимальной производительности, по UDP 443 от узлов и клиентов к шлюзам и конечным точкам службы AVD.

• RDP Shortpath

  • Управляемые сети: обеспечивает прямой UDP-канал передачи данных от узла к клиенту с использованием частных IP-адресов, обычно через корпоративную локальную сеть, VPN типа «сеть-сеть» или ExpressRoute. Порт UDP по умолчанию на узле сеансов — 3390. Откройте порт UDP 3390 в брандмауэре ОС узла и в NSG для трафика из доверенных частных источников. Этот путь снижает задержку и джиттер, улучшая интерактивность и производительность мультимедиа.
  • Общедоступные сети: использует управляемое AVD реле для установки UDP-канала передачи данных через порт 443, улучшая производительность, когда прямая доступность по частным IP-адресам отсутствует. Разрешите исходящий трафик по UDP 443 к конечным точкам службы AVD. Это идеальный вариант для сценариев удаленной работы из дома без корпоративного VPN.

• Транспорт UDP, резервный TCP и пользовательский опыт

  • RDP использует двойной транспорт: надежный управляющий канал TCP и оптимизированный медиаканал UDP. Если UDP заблокирован, RDP переключается в режим только TCP, который более чувствителен к задержке, джиттеру и потере пакетов; пользователи могут столкнуться с низкой частотой кадров и ухудшением качества звука.
  • Целевая задержка приема-передачи (round-trip) до региона пула узлов — менее 100 мс; задержка менее 50 мс обеспечивает отклик, близкий к работе на локальном рабочем столе. Используйте Azure Virtual Desktop Experience Estimator для помощи в выборе региона.
  • QoS и DSCP. Приоритизируйте трафик по UDP 3390 (управляемый Shortpath) или UDP 443 (публичный Shortpath) и управляющий канал TCP 443 на пограничных устройствах, чтобы защитить качество сеанса при высокой нагрузке на сеть.

• Требования к подключению к службам Azure и шаблоны исходящих конечных точек

  • Разрешите узлам сеансов доступ к:
    • Тегу службы AzureVirtualDesktop по TCP 443 и UDP 443.
    • Конечным точкам службы хранилища для контейнеров FSLogix и диагностики.
    • AzureActiveDirectory и Microsoft Graph для потоков идентификации и получения токенов.
    • Конечным точкам WindowsUpdate и доставки контента Microsoft для установки исправлений и приложений Microsoft 365.
    • AzureMonitor и Log Analytics при использовании AVD Insights.
  • Предпочтительно использовать теги служб и правила на основе FQDN в Azure Firewall. Для NVA поддерживайте актуальный список разрешений и избегайте перехвата TLS-трафика для этих конечных точек.

• Рекомендации по прокси-серверам

  • Агент AVD поддерживает исходящие подключения через системный прокси-сервер. Настройте WinHTTP на узлах сеансов, если явное использование прокси-сервера обязательно; избегайте прокси, требующих интерактивной аутентификации для служебного трафика.
  • Пример настройки системного прокси-сервера:

netsh winhttp set proxy "http=myproxy.contoso.com:8080;https=myproxy.contoso.com:8080" bypass-list="localhost;127.0.0.1"

Гибридное подключение и периметр: VPN, ExpressRoute, Azure Firewall, прокси-серверы, Private Link, частный DNS и Bastion

• К локальным приложениям

  • VPN Gateway: быстро развертывается, подходит для подключений филиалов с низкой и средней пропускной способностью. Используйте режим active-active с BGP для отказоустойчивости.
  • ExpressRoute: частное, предсказуемое подключение для высокопроизводительных, чувствительных к задержкам рабочих нагрузок и большого числа пользователей. Включите ExpressRoute FastPath, чтобы уменьшить количество переходов на пути данных. При необходимости используйте подключение к пирингу Microsoft для SaaS, но помните, что конечные точки службы AVD все равно требуют доступа в интернет или через Private Link.
  • Virtual WAN может упростить архитектуру с несколькими филиалами благодаря интеграции с партнерами SD-WAN, централизованным политикам и глобальному транзиту.

• Azure Firewall и средства контроля периметра

  • Используйте Azure Firewall Premium для инспекции TLS там, где это поддерживается; не выполняйте инспекцию TLS для трафика плоскости управления AVD, так как закрепление сертификатов (certificate pinning) и использование WebSocket могут нарушить подключение и снизить производительность.
  • Используйте теги FQDN AzureVirtualDesktop и WindowsUpdate для упрощения управления правилами. Разместите Azure Firewall в центральной сети (hub) и опубликуйте маршруты по умолчанию через UDR в периферийные сети (spokes); создайте необходимые исключения для доступа к службам AVD через интернет или внедрите Private Link.

• Частные конечные точки и Private Link

  • Хранилище и Key Vault: используйте частные конечные точки (Private Endpoints) для контейнеров профилей FSLogix и любых секретов, используемых при подготовке. Свяжите соответствующие частные зоны DNS privatelink с вашими VNet и при необходимости настройте пересылку для локальных клиентов.
  • Azure Virtual Desktop: настройте Private Link для AVD, где это возможно, чтобы ограничить доступ к плоскости управления и шлюзам вашей частной сетью. Создайте частные конечные точки AVD в выделенной подсети и включите соответствующие зоны DNS privatelink, например, зоны privatelink службы avd, чтобы узлы и клиенты разрешали FQDN-имена AVD в частные IP-адреса. Это сокращает исходящий трафик в публичную сеть и усиливает модель безопасности «нулевого доверия» (zero-trust).

• Azure Bastion для административного доступа

  • Используйте Azure Bastion для JIT-доступа (just-in-time) по RDP к узлам сеансов через браузер по TCP 443, не открывая входящие порты в интернет.
  • Ограничьте разрешающие RDP-правила на узлах сеансов до AzureBastionSubnet с помощью NSG или ASG. Прямой доступ по RDP из недоверенных сетей должен оставаться отключенным.

Мониторинг и устранение неполадок: Network Watcher и диагностика

• Azure Monitor и AVD Insights

  • Включите AVD Insights для получения сквозной видимости качества подключений, времени входа в систему и производительности сеансов. Сопоставляйте всплески времени кругового пути (round-trip time) или потерь UDP с жалобами пользователей.

• Инструменты Network Watcher

  • Connection troubleshoot. Проверяйте доступность служб Azure, учетных записей хранения и локальных конечных точек с узла сеансов. Пример на PowerShell:

$nw = Get-AzNetworkWatcher -Location "EastUS"
Test-AzNetworkWatcherConnectivity -NetworkWatcher $nw `
  -SourceId "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vmName>" `
  -DestinationAddress "store1.file.core.windows.net" -DestinationPort 445

• Effective security rules and routes. Проверяйте действующие правила NSG и маршруты на сетевом интерфейсе (NIC), чтобы убедиться, что трафик по UDP 3390, UDP 443 и TCP 443 разрешен, как и предполагалось.

• NSG Flow Logs v2. Отправляйте их в рабочую область Log Analytics для проверки исходящего трафика (egress) с узлов сеансов и выявления отказов, которые приводят к переключению на TCP.

• Packet capture. Используйте на тестовом узле для подтверждения установки UDP Shortpath и анализа повторных передач и джиттера.

• Диагностика клиента и узла

  • В рамках сеанса отслеживайте метрики RemoteFX Graphics Frames Skipped и состояние транспорта RDP, чтобы различать узкие места на стороне сервера, сети или клиента.
  • Используйте информацию о подключении в клиенте AVD для подтверждения режима транспорта (UDP/Shortpath или TCP) и времени кругового пути. Если вы видите пути только через TCP, проверьте разрешения на прокси-сервере и брандмауэре, а также наличие блокировок UDP 3390/443.

Практический сценарий проблемы

Компания IKEA планирует предоставить Azure Virtual Desktop для 1200 специалистов по планированию и закупкам в магазинах по всей Европе. Пользователи получают доступ к SAP GUI и серверу лицензий в локальной среде, при этом половина пользователей работает удаленно без корпоративного VPN. Пользователи сообщают о нестабильной отзывчивости в часы пик и периодических сбоях при входе в систему после внедрения нового исходящего прокси-сервера.

1. Спроектировать архитектуру «звезда» (hub-and-spoke) с масштабированием исходящего трафика

   • Создать центральную виртуальную сеть (hub VNet) с Azure Firewall Premium и NAT Gateway; развернуть периферийные виртуальные сети (spoke VNets) для узлов сеансов в каждом регионе. Подключить NAT Gateway к каждой подсети узлов сеансов, чтобы избежать исчерпания портов SNAT, когда тысячи потоков UDP/TCP открываются во время утренних входов в систему.
   • Зачем: Это стабилизирует исходящие IP-адреса и предоставляет достаточное количество эфемерных портов, предотвращая периодические сбои подключений к шлюзам AVD и хранилищу.

2. Внедрить точные правила NSG и ASG

   • Назначить сетевые интерфейсы узлов сеансов в ASG. Разрешить входящий трафик UDP 3390 только с доверенных частных префиксов, разрешить входящий TCP 3389 из AzureBastionSubnet и разрешить исходящий TCP/UDP 443 к тегам служб AzureVirtualDesktop, Storage, AzureActiveDirectory и AzureMonitor.
   • Зачем: Это обеспечивает принцип наименьших привилегий, одновременно включая Shortpath для управляемых сетей и безопасное администрирование через Bastion.

3. Настроить DNS для гибридного разрешения имен

   • Направить DNS виртуальной сети на контроллеры домена в Azure. Развернуть Azure DNS Private Resolver с правилами для исходящего трафика для пересылки запросов к зонам privatelink и зонам Azure PaaS; настроить локальный DNS для пересылки запросов к частным зонам Azure на входящую конечную точку сопоставителя (resolver).
   • Зачем: Это гарантирует, что узлы AVD будут последовательно разрешать SRV-записи AD, частные конечные точки FSLogix и любые FQDN AVD Private Link как в облачных, так и в локальных сетях.

4. Включить RDP Shortpath как для управляемых, так и для общедоступных сетей

   • Включить Shortpath для управляемых сетей на узлах сеансов и открыть порт UDP 3390 для внутреннего трафика; включить Shortpath для общедоступных сетей, чтобы разрешить ретрансляцию UDP 443 для удаленных сотрудников без VPN. Обновить QoS на маршрутизаторах филиалов, чтобы приоритизировать потоки UDP 3390 и UDP/TCP 443 для AVD.
   • Зачем: Это максимизирует интерактивную производительность для офисных пользователей через прямой частный UDP-канал и улучшает опыт домашних пользователей через UDP 443, при этом QoS защищает эти потоки во время перегрузок сети.

5. Обеспечить безопасность и упростить периметр с помощью Azure Firewall и политики прокси

   • В Azure Firewall используйте теги FQDN для AzureVirtualDesktop и WindowsUpdate; исключите их из проверки TLS. На новом исходящем прокси-сервере настройте явные разрешения для AVD WebSocket через TLS и отключите аутентификацию для трафика агента AVD. Настройте прокси WinHTTP единообразно на всех узлах сеансов.
   • Зачем: Это позволяет избежать нарушения работы обратного подключения (reverse connect) и Shortpath для общедоступных сетей из-за перехвата TLS или аутентификации на прокси, сохраняя при этом централизованное управление.

6. Обеспечить частный доступ к критически важным PaaS

   • Создать Private Endpoints для учетных записей хранения FSLogix и связать необходимые частные DNS-зоны privatelink со всеми виртуальными сетями AVD; убедиться, что SMB через частные IP-адреса работает успешно. Рассмотреть возможность использования AVD Private Link для ограничения доступа к плоскости управления и шлюзу только с частных IP-адресов, если этого требует корпоративная политика.
   • Зачем: Это устраняет зависимость от общедоступного исходящего трафика для профилей пользователей и, опционально, для службы AVD, улучшая уровень безопасности и предсказуемость.

7. Установить гибридное подключение к локальным приложениям

   • Развернуть ExpressRoute с FastPath к основному центру обработки данных для доступа к SAP и серверу лицензий с низкой задержкой; сохранить VPN Gateway для резервного копирования филиалов. Анонсировать необходимые локальные префиксы с помощью BGP и проверить следующий переход (next hop) и действующие маршруты на сетевых интерфейсах узлов сеансов.
   • Зачем: ExpressRoute обеспечивает предсказуемую производительность в масштабе, а VPN-шлюз используется для отказоустойчивости.

8. Мониторить и проверять

   • Включить AVD Insights и Network Watcher Connection Monitor для синтетических тестов до SAP и хранилища. Включить NSG Flow Logs для подтверждения использования UDP 3390 и UDP 443. Использовать Connection troubleshoot в часы пик для выявления узких мест в прокси-сервере или брандмауэре.
   • Зачем: Видимость, основанная на данных, подтверждает, что пути Shortpath активны, пропускная способность для исходящего трафика достаточна, а политики периметра не вызывают непредвиденных потерь или задержек.

← Идентификация · Все домены · Образы узлов сеансов и подготовка →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Microsoft →