Microsoft AZ-700: Проектирование Azure Virtual Network — Руководство по подготовке

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

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

Планирование адресного пространства и подсетей

Продуманный план IP-адресации предотвращает будущие переделки и позволяет избежать конфликтов с локальными сетями или другими VNet. Используйте иерархические блоки CIDR (например, один /16 на крупное бизнес-подразделение, /24 на VNet, /26–/22 на подсеть в зависимости от ее роли) и резервируйте непрерывные диапазоны для расширения, пиринга и сопоставлений сайтов VPN/S2S. Azure предъявляет требования к именам и подсетям для нескольких платформенных служб: подсеть GatewaySubnet должна существовать (и иметь достаточный размер для размещения VPN-шлюза и его единиц масштабирования), AzureFirewallSubnet должна быть выделенной и называться AzureFirewallSubnet, а AzureBastionSubnet должна быть выделенной подсетью размером /27 или больше. Application Gateway и многие сетевые виртуальные устройства также требуют выделенных подсетей (без других ресурсов). Планируйте адресное пространство так, чтобы оно не пересекалось между VNet, соединенными пирингом, и локальными диапазонами; пересекающиеся адресные пространства нарушают работу пиринга, VPN и маршрутизации. Рассмотрите возможность делегирования подсети при развертывании платформенных служб (AKS, управляемые экземпляры Azure Database) и избегайте размещения NSG или UDR, которые конфликтуют с обязательными маршрутами платформы для этих служб. Распространенная ошибка — выделение недостаточного размера для GatewaySubnet или AzureFirewallSubnet; эти службы могут масштабироваться и со временем требовать дополнительных IP-адресов. Компромиссы: меньшие CIDR экономят адресное пространство, но увеличивают риск будущей реконфигурации; большие CIDR ничего не стоят, но увеличивают сложность управления. Документируйте все назначения и резервируйте блоки для частных конечных точек PaaS, jump-хостов, агентов мониторинга и ресурсов для исходящего NAT.

Пиринг VNet, транзит через шлюз и приоритет маршрутов

Пиринг VNet обеспечивает подключение с низкой задержкой и высокой пропускной способностью, но не является транзитивным: трафик из подключенной через пиринг spoke-сети не маршрутизируется автоматически через вторую VNet, соединенную пирингом, для доступа к локальной сети. Чтобы централизовать подключение к локальной сети, необходимо развернуть центральную VNet (hub) со шлюзом VPN Gateway или ExpressRoute. Настройте пиринг для hub-сети с включенной опцией allowGatewayTransit и пиринг для spoke-сети с включенной опцией useRemoteGateways; VPN Gateway должен существовать только в hub-сети. Помните, что для пиринга требуются непересекающиеся адресные пространства, и он поддерживает как региональный, так и глобальный пиринг (глобальный пиринг влечет за собой плату за передачу данных и несколько более высокую задержку). Приоритет маршрутов имеет значение: определяемые пользователем маршруты (UDR) имеют приоритет над маршрутами, полученными по BGP, и системными маршрутами; маршруты BGP имеют приоритет над системными маршрутами. Если вам требуется принудительное туннелирование для проверки исходящего трафика, создайте UDR, указывающие на VirtualAppliance (NVA) или Azure Firewall, а затем, при необходимости, анонсируйте соответствующие маршруты обратно в локальную сеть через BGP. К распространенным ошибкам относятся: забыть установить allowGatewayTransit в hub-сети или useRemoteGateways в spoke-сетях, не загрузить заново конфигурации P2S-клиентов после добавления spoke-сетей (P2S-клиентам нужны обновленные маршруты) и предположение о транзитивности пиринга. Выбирайте SKU для VPN Gateway в зависимости от пропускной способности и функций P2S: рассмотрите VpnGw1/2/3 для производственных сред с P2S и BGP; у SKU Basic много ограничений, и он не рекомендуется для сценариев с hub-сетью.

• SKU для VPN Gateway: VpnGw1 — умеренная пропускная способность, поддержка OpenVPN/IKEv2/P2S; VpnGw2 — более высокая пропускная способность и масштабирование TLS; VpnGw3 — самая высокая пропускная способность и наибольший масштаб. Basic — ограниченные возможности, не рекомендуется для сценариев с hub-сетью.

Конечные точки служб, частные конечные точки и их влияние на DNS

Конечные точки служб (Service endpoints) расширяют идентификацию вашей VNet на службы Azure PaaS (Storage, SQL, Cosmos DB), благодаря чему трафик использует магистральную сеть Microsoft, в то время как публичная конечная точка службы защищена для выбранных подсетей. Частные конечные точки (Private Endpoints) размещают сетевой интерфейс в вашей подсети, который сопоставляется с частным IP-адресом PaaS-ресурса, обеспечивая полностью приватное подключение. Выбирайте конечные точки служб, когда вам нужен простой контроль доступа на уровне подсети без изменений в DNS; выбирайте частные конечные точки, когда требуется доступ на уровне отдельных ресурсов, изоляция на уровне VNet или полное отключение доступа из публичной сети. Частные конечные точки создают сетевой интерфейс (ENI) и должны быть связаны с частной зоной DNS (privatelink.<service>.azure.com) или требуют ручного создания A-записей DNS — частая ошибка — пренебрежение настройкой DNS, что заставляет клиентов разрешать публичный IP-адрес вместо частной конечной точки. Также имейте в виду, что частные конечные точки потребляют IP-адрес из целевой подсети; планируйте емкость IP-адресов. Конечные точки служб не отключают публичную конечную точку — чтобы полностью заблокировать учетную запись хранения, необходимо отключить доступ из публичной сети после включения частной конечной точки. Компромиссы в стоимости и эксплуатации: частные конечные точки увеличивают сложность управления (DNS для каждого ресурса и согласования) и немного усложняют эксплуатацию, но предлагают более строгую изоляцию; конечные точки служб проще и дешевле, но менее гранулярны.

Шлюз NAT, Azure Firewall и компромиссы при проектировании маршрутов

Для предсказуемого исходящего SNAT и упрощенного управления исходящим трафиком разверните Azure Virtual Network NAT (Standard NAT Gateway) в подсетях или на сетевых интерфейсах (NIC) и подключите общедоступные IP-адреса или префиксы уровня “Стандартный” (только SKU “Стандартный”). Шлюз NAT берет на себя управление эфемерными портами; если вы ожидаете большого количества исходящих подключений, подключите несколько префиксов общедоступных IP-адресов, чтобы увеличить количество доступных портов SNAT и избежать их исчерпания, что часто случается при большом количестве ВМ или хостов контейнеров. Azure Firewall обеспечивает централизованную, полностью управляемую проверку с отслеживанием состояния, аналитику угроз и фильтрацию по приложениям/FQDN; выбирайте Azure Firewall Standard для базовой фильтрации, а SKU “Премиум” — для проверки TLS, IDPS и расширенных возможностей защиты от угроз. Сетевые виртуальные модули (NVA сторонних производителей) предлагают более богатый функционал или альтернативы по стоимости, но требуют управления, настройки высокой доступности (HA) и планирования масштабирования. Определяемые пользователем маршруты (UDR), указывающие на VirtualAppliance или Internet/NAT, необходимо оценивать с учетом системных маршрутов Azure, поскольку неверные UDR могут нарушить трафик служб платформы (например, заблокировать трафик конечных точек служб или управляемые платформой пробы работоспособности). Для обеспечения высокой доступности и производительности рассмотрите SKU с избыточностью между зонами (Application Gateway v2, Firewall в зонах доступности) и возможности автомасштабирования в сравнении с модулями с фиксированной стоимостью. Распространенные ошибки: подключение NAT одновременно к подсети и сетевому интерфейсу приводит к неожиданному приоритету; забвение того, что для NAT требуются общедоступные IP-адреса уровня “Стандартный”; неверное именование и определение размера AzureFirewallSubnet; и предположение, что UDR будут проигнорированы — они переопределяют системные маршруты.

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

Сценарий: Компания Contoso Enterprises использует в Azure сеть топологии “звезда” (hub-and-spoke). В центральной виртуальной сети (hub) в регионе West US размещены шлюз ExpressRoute и VpnGw2 (в подсети GatewaySubnet). Несколько периферийных сетей (spokes) содержат подсети приложений и частные конечные точки для служб PaaS. Удаленные сотрудники подключаются к центральной сети через VPN типа “точка — сеть” (Point-to-Site, P2S).

Проблема: Удаленные пользователи могут получить доступ к ресурсам в центральной сети, но не могут связаться с ресурсами VNet в периферийных сетях после недавнего добавления новых периферийных сетей, а некоторые P2S-клиенты показывают устаревшие наборы маршрутов.

Рекомендуемый подход:

1. В центральной VNet убедитесь, что VPN-шлюз — это VpnGw2, развернутый в подсети GatewaySubnet подходящего размера (не менее /27); проверьте, что это единственный шлюз в пиринговой топологии и что ExpressRoute сосуществует с ним через обмен маршрутами.
2. В пиринговом соединении от центра к периферии установите allowGatewayTransit = true на стороне центральной сети. В каждом пиринговом соединении на стороне периферийной сети установите useRemoteGateways = true и убедитесь, что адресные пространства не пересекаются.
3. Повторно сгенерируйте и распространите обновленную конфигурацию P2S VPN-клиента с центрального VPN-шлюза (включив IKEv2/OpenVPN) и потребуйте от удаленных пользователей переустановить клиент, чтобы их таблицы маршрутизации включили новые префиксы периферийных сетей.
4. Если периферийные сети должны маршрутизировать исходящий трафик через центральную сеть для проверки, добавьте UDR в таблицы маршрутизации периферийных сетей, направляющие 0.0.0.0/0 на виртуальный модуль в центральной сети или на Azure Firewall (развернутый в AzureFirewallSubnet), и анонсируйте необходимые маршруты обратно через BGP по ExpressRoute/VPN.

Обоснование: Включение транзита через шлюз с помощью useRemoteGateways централизует маршрутизацию для локальных сетей и P2S через шлюз центральной сети без создания дополнительных шлюзов. Перевыпуск конфигураций P2S-клиентов обновляет их таблицы маршрутизации, делая доступными новые префиксы периферийных сетей. UDR и BGP обеспечивают контролируемый исходящий трафик и его видимость для проверки.

← ExpressRoute и подключение к WAN · Все домены · Гибридные сети →

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

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