Microsoft AZ-104: Виртуальные сети Azure — Руководство по подготовке

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

Обзор

Azure Virtual Networking создает программно-определяемую структуру центра обработки данных для рабочих нагрузок IaaS и PaaS. Вы разрабатываете план адресации с использованием CIDR, создаете подсети в соответствии с границами доверия, обеспечиваете безопасность потоков трафика “восток-запад” и “север-юг” с помощью групп безопасности сети (NSG) и Azure Firewall, соединяете среды с помощью пиринга VNet, VPN Gateway или ExpressRoute, управляете трафиком с помощью определяемых пользователем маршрутов и обеспечиваете надежное разрешение имен с помощью Azure DNS. Правильная настройка этих компонентов позволяет создавать масштабируемые архитектуры типа “звезда” (hub-and-spoke), обеспечивать безопасный доступ к PaaS через приватные конечные точки (Private Endpoints) и предсказуемую маршрутизацию, отвечающую требованиям производительности и соответствия нормативам.

Адресация, сегментация и политики (VNet, подсети, NSG, ASG, UDR)

Виртуальная сеть определяет одно или несколько непересекающихся адресных пространств RFC1918 с использованием нотации CIDR (например, 10.0.0.0/16). Вы можете добавлять дополнительные префиксы адресов позже, если они не конфликтуют с пиринговыми сетями. Подсети сегментируют VNet на маршрутизируемые блоки (например, 10.0.1.0/24 для веб-уровня, 10.0.2.0/24 для уровня приложений). Зарезервируйте выделенную подсеть GatewaySubnet для шлюзов VPN/ExpressRoute; выделяйте адресное пространство с запасом (не менее /27), чтобы избежать ограничений при масштабировании в будущем. Распределение IP-адресов по умолчанию динамическое; при необходимости вы можете назначать статические частные IP-адреса сетевым интерфейсам (NIC).

Системные маршруты по умолчанию разрешают трафик внутри VNet и направляют 0.0.0.0/0 в интернет (при наличии публичного IP-адреса). Определяемые пользователем маршруты (UDR) переопределяют эти значения по умолчанию на уровне подсети. Создайте таблицу маршрутизации и свяжите ее с подсетью; записи включают:

Следующий переход (Next hop): Виртуальный модуль (IP-адрес NVA в той же VNet), Шлюз виртуальной сети (для направления в локальную сеть через VPN/ExpressRoute), Интернет (для принудительного вывода в интернет) или None (для отбрасывания трафика).
Принудительное туннелирование: Направьте 0.0.0.0/0 на шлюз виртуальной сети, чтобы принудительно отправлять весь исходящий трафик в локальную сеть, или на NVA/Azure Firewall для централизованного контроля исходящего трафика. Если вы используете BGP со шлюзом, который анонсирует маршрут по умолчанию, рассмотрите возможность отключения распространения маршрутов шлюза для определенных подсетей, чтобы предотвратить непреднамеренный выбор пути.

NSG применяют политики с отслеживанием состояния для уровней L3–L4 к сетевым интерфейсам (NIC) или подсетям; обе области применения могут использоваться одновременно, и трафик должен быть разрешен всеми применимыми NSG. Правила оцениваются по приоритету (100–4096; чем меньше число, тем выше приоритет) и направлению (входящее/исходящее). Правила по умолчанию включают:

Входящие: AllowVnetInBound (65000), AllowLoadBalancerInBound (65001), DenyAllInBound (65500)
Исходящие: AllowVnetOutBound (65000), AllowInternetOutBound (65001), DenyAllOutBound (65500) Переопределяйте правила по умолчанию с помощью пользовательских правил с более высоким приоритетом. Используйте теги служб (например, Internet, AzureLoadBalancer, Storage) для упрощения обслуживания и группы IP-адресов (IP Groups) для создания повторно используемых списков адресов.

Группы безопасности приложений (ASG) отделяют IP-адресацию от политик. Назначайте сетевые интерфейсы (NIC) группам ASG, которые представляют роли (например, Web, App, DB), и ссылайтесь на эти ASG в правилах NSG. Это позволяет изменять политики, не затрагивая IP-адреса или подсети, и способствует последовательной сегментации на основе ролей внутри VNet.

Варианты подключения: пиринг, VPN Gateway и ExpressRoute

Пиринг виртуальных сетей (VNet peering) соединяет виртуальные сети через магистральную сеть Microsoft, обеспечивая низкую задержку и высокую пропускную способность. Локальный пиринг работает в пределах одного региона; глобальный пиринг — между регионами. Пиринг не является транзитивным и требует непересекающихся адресных пространств. Ключевые флаги:

Allow virtual network access: разрешает маршрутизируемое подключение между пиринговыми сетями.
Allow forwarded traffic: позволяет трафику, пересылаемому NVA, проходить через пиринг.
Use remote gateways: позволяет виртуальной сети использовать шлюз VPN/ER в пиринговой сети-«хабе». В хабе должен быть установлен флаг Allow gateway transit. Виртуальная сеть может использовать удаленные шлюзы только от одного пира. Пиринговые сети не получают автоматически маршруты клиентов P2S; конечные пользователи должны устанавливать обновленные конфигурации VPN-клиента, включающие маршруты к новым периферийным сетям.

Azure VPN Gateway предоставляет туннели IPSec/IKE:

Site-to-site (S2S): соединяет локальные VPN-устройства с Azure; для большинства сценариев используйте VPN на основе маршрутов (route-based VPN, IKEv2), особенно при работе с BGP и несколькими туннелями.
Point-to-site (P2S): позволяет отдельным клиентам (Windows, macOS, Linux) подключаться с использованием OpenVPN, IKEv2 или SSTP. Конфигурация клиента содержит статические маршруты к префиксам Azure; ее необходимо загружать заново при изменении адресных пространств или добавлении доступных периферийных сетей за хабом.
VNet-to-VNet: использует S2S в пределах регионов/клиентов Azure, требуя непересекающихся адресов. Полезно, когда пиринг невозможен (например, между разными клиентами с административными границами).
SKU: Предпочтительны VpnGw1–VpnGw5 (и их AZ-варианты для избыточности между зонами). Basic является устаревшим и лишен многих функций (нет IKEv2/BGP). Тип Route-based поддерживает P2S, BGP и режим active-active. Тип Policy-based ограничен (только S2S, без BGP).
BGP динамически анонсирует префиксы, поддерживает транзит через несколько туннелей и упрощает отказоустойчивость маршрутов. Правила VPN NAT могут транслировать пересекающиеся локальные/Azure префиксы, когда это неизбежно.

ExpressRoute обеспечивает частное подключение с гарантированным SLA через канал партнера к пограничной сети Microsoft:

Канал (circuit) предоставляется провайдером (пропускная способность, модель тарификации, SKU) и привязывается к вашей подписке через ключ службы (service key). Избыточность встроена: каждый канал предоставляет двойное подключение (основное/резервное); ваш маршрутизатор должен устанавливать две BGP-сессии для обеспечения высокой доступности (HA).
Типы пиринга:
- Private peering (частный пиринг): передает частный трафик RFC1918 в виртуальные сети через шлюз виртуальной сети ExpressRoute (ErGw1AZ–ErGw3AZ). Поддерживает BGP, быстрое переключение при сбое и опциональный FastPath для ускорения плоскости данных.
- Microsoft peering (пиринг Майкрософт): предоставляет доступ к публичным службам Microsoft (например, Storage, SQL, Microsoft 365) через публичные IP-адреса с использованием фильтров маршрутов. Используется для доступа к общедоступным конечным точкам без выхода в публичный интернет. Для Microsoft 365 требуется дополнительное согласование.
Используйте ExpressRoute Global Reach для соединения локальных площадок через магистральную сеть Microsoft. Для принудительного туннелирования анонсируйте маршрут по умолчанию через private peering или используйте его в паре с UDR/Azure Firewall для выборочного исходящего трафика.

Совместное использование: В одной виртуальной сети могут одновременно существовать шлюзы VPN и ExpressRoute, используя одну и ту же GatewaySubnet; для управления потоками трафика используйте транзит через шлюз и UDR. ExpressRoute предпочтителен для стабильного корпоративного трафика; VPN служит в качестве резервного канала или для подключения филиалов/небольших офисов.

Разрешение имен и безопасный доступ к PaaS (Azure DNS, конечные точки)

Azure DNS используется для хостинга общедоступных зон (public zones), чтобы ваши публичные записи размещались на глобальной DNS-платформе Azure с высокой доступностью. Для разрешения имен внутри VNet используются частные зоны Azure DNS (Azure DNS Private Zones), которые обеспечивают службу имен с разделением горизонтов (split-horizon). Свяжите виртуальные сети с частной зоной, чтобы включить разрешение имен; опционально можно включить автоматическую регистрацию (auto-registration), чтобы A-записи ВМ регистрировались и обновлялись автоматически при изменении IP-адреса сетевого интерфейса. Для гибридного разрешения имен и условной пересылки (conditional forwarding) между Azure и локальной средой разверните Azure DNS Private Resolver с входящими/исходящими конечными точками и наборами правил, которые пересылают запросы для выбранных доменов (например, corp.contoso.com на локальный DNS-сервер или privatelink.* обратно в Azure).

Конечные точки служб (Service Endpoints) расширяют идентификацию вашей VNet на выбранные службы Azure (например, Storage, SQL) через магистральную сеть Microsoft, при этом служба сохраняет свой публичный IP-адрес. В брандмауэре PaaS-службы доступ ограничивается до конкретной VNet/подсети. Их легко включить для каждой подсети и службы, они не требуют изменений в DNS и хорошо подходят для простых сценариев только в Azure. Однако ресурс по-прежнему имеет публичный IP-адрес и недоступен по частному адресу из локальной сети без обращения к публичной конечной точке.

Частные конечные точки (Private Endpoints) размещают сетевой интерфейс (NIC) с частным IP-адресом из вашей подсети непосредственно на PaaS-ресурсе через службу Private Link. Трафик остается в частной сети, что обеспечивает гранулярный контроль над эксфильтрацией данных и доступ из локальной сети через VPN/ExpressRoute. Правильная настройка DNS крайне важна: необходимо переопределить публичное FQDN ресурса так, чтобы оно разрешалось в его privatelink FQDN, которое указывает на ваш частный IP-адрес. Используйте частные зоны Azure DNS (например, privatelink.blob.core.windows.net), связанные с виртуальными сетями. Выбирайте Private Endpoints, когда вам нужна полноценная частная адресация, доступ из гибридной среды и строгий контроль исходящего трафика.

Azure Firewall и централизованное управление исходящим/входящим трафиком

Azure Firewall — это облачный межсетевой экран с отслеживанием состояния, который эластично масштабируется и обеспечивает централизованное управление политиками для звездообразных топологий (hub-and-spoke). Он развертывается в выделенной подсети AzureFirewallSubnet. Для сценариев принудительного туннелирования добавьте подсеть AzureFirewallManagementSubnet, чтобы трафик управления использовал интернет, а трафик данных следовал вашему маршруту по умолчанию.

Типы коллекций правил применяются в следующем порядке и в соответствии с приоритетом коллекции правил:

Правила DNAT транслируют входящие публичные IP-адреса/порты на межсетевом экране в частные адреса (например, сопоставляют публичный IP-адрес:443 межсетевого экрана с веб-ВМ). Используйте их в паре с NSG в целевой подсети для реализации принципа наименьших привилегий.
Сетевые правила фильтруют трафик уровней L3–L4 (IP-адреса источника/назначения, протоколы, порты). Используются для протоколов, отличных от HTTP(S), и для контроля исходящих потоков и потоков между периферийными сетями.
Правила приложений контролируют исходящий трафик HTTP/S по FQDN или тегам FQDN (например, WindowsUpdate). SKU уровня Premium добавляет проверку TLS и IDPS для глубокой фильтрации HTTP(S). Аналитика угроз может быть настроена в режим Alert (Оповещение) или Deny (Запрет) для реагирования на известные вредоносные IP-адреса/домены. Комбинируйте Azure Firewall с UDR (маршрут 0.0.0.0/0 к межсетевому экрану как к виртуальному устройству) для централизации исходящего трафика; разрешите перенаправленный трафик в настройках пиринга для периферийных сетей. Записывайте журналы в Log Analytics для аудита и аналитики и используйте иерархии политик/Azure Firewall Manager для стандартизации в масштабе.

Практический сценарий

Компании Adobe необходимо модернизировать гибридную сеть: безопасный центральный узел (hub) в Azure должен обеспечивать централизованный выход в интернет, высокодоступное подключение к локальной среде, частный доступ к Storage и SQL, а также предсказуемое разрешение имен в Azure и центрах обработки данных. Удаленным разработчикам также необходим P2S-доступ ко всем периферийным сетям (spokes).

Спроектировать адресное пространство и сегментацию

Создать VNet для центрального узла (Hub) 10.0.0.0/16 с подсетями: AzureFirewallSubnet 10.0.0.0/26, GatewaySubnet 10.0.0.64/27, SharedServices 10.0.1.0/24. Создать VNet для периферийных сетей: Apps 10.1.0.0/16 и Data 10.2.0.0/16.
Обоснование: Непересекающиеся CIDR-блоки обеспечивают возможность пиринга и будущего роста; выделенные подсети отвечают требованиям платформы и упрощают определение области действия UDR/NSG.

Настроить подключение по топологии hub-and-spoke

Настроить пиринг Hub↔Apps и Hub↔Data с опциями Allow virtual network access (Разрешить доступ к виртуальной сети) и Allow forwarded traffic (Разрешить перенаправленный трафик). На центральном узле установить Allow gateway transit (Разрешить транзит через шлюз); на периферийных — Use remote gateways (Использовать удаленные шлюзы).
Обоснование: Централизует потоки “север-юг” через шлюз/межсетевой экран центрального узла, одновременно разрешая трафик “восток-запад” через центральный узел, что позволяет избежать сложности полносвязной топологии.

Обеспечить частное, избыточное подключение к локальной среде

Заказать канал ExpressRoute (Private Peering) у провайдера; настроить двойные сеансы BGP. Развернуть шлюз виртуальной сети ExpressRoute (SKU ErGw2AZ) в GatewaySubnet центрального узла и подключить к нему канал.
Обоснование: Частное подключение с гарантированным SLA, встроенной избыточностью и шлюзом, избыточным между зонами, отвечает корпоративным требованиям к высокой доступности (HA) и производительности.

Централизовать исходящий трафик и защитить рабочие нагрузки

Развернуть Azure Firewall Standard в подсети AzureFirewallSubnet. Создать UDR в каждой периферийной подсети: 0.0.0.0/0, следующий переход (next hop) — Virtual appliance (Виртуальное устройство) → частный IP-адрес межсетевого экрана. Добавить NSG к периферийным сетям, разрешая только необходимые порты к межсетевому экрану и внутри VNet.
Обоснование: Azure Firewall + UDR обеспечивают согласованную политику для исходящего трафика, ведение журналов и аналитику угроз; NSG предоставляют микросегментацию на уровне подсети/сетевого интерфейса.

Обеспечить безопасность PaaS с помощью полностью частного доступа

Создать частные конечные точки (Private Endpoints) для Storage и SQL в периферийной сети Data. Связать частные зоны Azure Private DNS (privatelink.blob.core.windows.net, privatelink.database.windows.net) с центральной и периферийными сетями. Отключить доступ из общедоступной сети на ресурсах PaaS.
Обоснование: Private Endpoints устраняют доступность ресурсов извне и разрешают доступ из локальной среды через ExpressRoute; Azure Private DNS обеспечивает корректное разрешение имен.

Реализовать гибридное разрешение имен и условную пересылку

Развернуть Azure DNS Private Resolver в центральном узле с входящими и исходящими конечными точками. Создать правила для пересылки запросов к corp.adobe.com на локальный DNS-сервер и для разрешения зон privatelink внутри Azure.
Обоснование: Обеспечивает детерминированное разрешение DNS по принципу “разделения горизонтов” (split-horizon) между Azure и локальной средой без использования пользовательских ВМ с DNS.

Предоставить удаленным разработчикам доступ ко всем периферийным сетям

Настроить P2S VPN на VPN-шлюзе центрального узла для совместной работы с ExpressRoute (coexistence). Распространить профиль VPN-клиента. После добавления периферийных сетей повторно загрузите клиентский пакет, чтобы он включал маршруты к 10.1.0.0/16 и 10.2.0.0/16.
Обоснование: P2S на базе центрального узла упрощает эксплуатацию и, благодаря обновленным клиентским маршрутам и транзиту через шлюз пиринга, предоставляет пользователям доступ ко всем периферийным сетям.

Усилить защиту с помощью ASG и NSG

Назначить сетевые интерфейсы (NIC) группам ASG (Web, App, DB) и реализовать правила NSG, разрешающие трафик Web→App (TCP 443) и App→DB (TCP 1433) по ASG, и запрещающие все остальное. Сохранить правила по умолчанию, где это уместно.
Обоснование: Политика на основе ролей масштабируется без необходимости управления IP-адресами и реализует принцип наименьших привилегий.

Эта архитектура отвечает требованиям Adobe, обеспечивая избыточность ExpressRoute, централизованное управление через Azure Firewall, частный доступ к PaaS и согласованное разрешение DNS. При этом удаленные пользователи и локальные системы могут безопасно получать доступ к любой рабочей нагрузке через центральный узел.

← Виртуальные машины Azure и вычислительные ресурсы · Все домены · Балансировка нагрузки Azure и управление трафиком →

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