Microsoft AZ-700: Azure Virtual WAN и Hub-Spoke — Руководство по подготовке

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

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

Virtual WAN или классическая звездообразная топология: выбор правильной транзитной модели

Проектирование глобальной транзитной сети требует выбора между Azure Virtual WAN (vWAN) и традиционной звездообразной топологией («центр-периферия»), построенной на основе VNet, NVA и пиринга. Virtual WAN предоставляет управляемую Microsoft глобальную магистральную сеть с vHubs, которые нативно поддерживают подключения VPN, ExpressRoute и P2S, а также автоматическое распространение маршрутов, масштабирование site-to-site и интеграцию с партнерскими SD-WAN решениями. Для организаций, которым требуется множество подключений филиалов, глобальная маршрутизация и простая операционная модель, vWAN сокращает объем работ по оркестрации и повышает отказоустойчивость. В отличие от этого, созданная вручную звездообразная топология (VNet с Azure Firewall или сторонним NVA в центральном концентраторе и периферийными сетями, подключенными через пиринг) дает максимальный контроль над потоком пакетов, пользовательские функции NVA и часто более низкие постоянные затраты для небольших развертываний. Ключевые компромиссы — это пропускная способность и предсказуемость в обмен на детальный контроль: концентраторы vWAN абстрагируют многие детали и предлагают почти глобальный масштаб, но добавляют затраты на управляемую услугу и менее гибкую настройку пути пакетов. Распространенные ошибки включают предположение, что vWAN автоматически обеспечивает транзитивный пиринг с VNet, которые не подключены явно; каждая периферийная сеть или VNet должна быть подключена и связана с таблицами маршрутизации концентратора. Другая частая ошибка — пренебрежение правилами управления и ограничениями на именование подсетей (например, обязательное имя AzureFirewallSubnet для Azure Firewall), что нарушает автоматизированные развертывания, если их не соблюдать.

Защищенный виртуальный концентратор, интеграция Azure Firewall и NVA

Модель защищенного виртуального концентратора добавляет уровни проверки и политик в vWAN за счет интеграции Azure Firewall (или стороннего NVA) и Firewall Manager для централизации безопасности, NAT и маршрутизации для периферийных сетей и локальных площадок. Azure Firewall следует развертывать в выделенной подсети AzureFirewallSubnet, а выбирать между SKU Azure Firewall нужно на основе требуемых функций. Тщательно планируйте таблицы маршрутизации: таблицы маршрутизации концентратора управляют потоками трафика к периферийным сетям, сайтам VPN, P2S и в интернет. Чтобы принудительно туннелировать трафик на NVA, вы связываете подключение периферийной сети с таблицей маршрутизации концентратора, которая направляет трафик 0.0.0.0/0 на NVA/Firewall. Учитывайте высокую доступность и пропускную способность: Azure Firewall является зональной службой и поддерживает автомасштабирование в SKU Standard и Premium, но для проверки TLS и IDPS требуется SKU Premium. Избегайте размещения Application Gateway или конечных точек Private Link в подсетях, используемых инфраструктурой брандмауэра; им требуются собственные подсети. Следите за исчерпанием портов NAT и SNAT при крупномасштабных исходящих потоках; реализуйте пул SNAT, используйте Azure Firewall с правилами DNAT или NAT Gateway, где это применимо.

• Azure Firewall Standard и Premium: Standard поддерживает межсетевой экран с отслеживанием состояния, фильтрацию по FQDN, базовые SNAT/DNAT; Premium добавляет проверку TLS, IDPS, URL-фильтрацию и исключения для тегов полных доменных имен (FQDN).
• Load Balancer Basic и Standard: Standard поддерживает избыточность между зонами, пробы работоспособности для внутренних ресурсов и является обязательным для ILB службы Private Link; у Basic отсутствует отказоустойчивость на уровне зон и более строгие правила безопасности.
• SKU для VPN Gateway: VpnGw1/2/3 (с возрастающей пропускной способностью и количеством одновременных туннелей); используйте более высокие уровни для большего числа туннелей S2S или более высокой совокупной пропускной способности.

Шаблоны частного подключения: Private Link, частные конечные точки и конечные точки служб

Private Link и частные конечные точки обеспечивают первоклассный доступ к PaaS без маршрутизации трафика через интернет; конечные точки служб защищают доступ к службам, но оставляют исходящий трафик в общедоступной магистральной сети службы. Используйте частную конечную точку, когда вам нужны частные IP-адреса для каждого ресурса и интеграция с DNS; используйте конечные точки служб, когда вам нужен более простой контроль доступа на уровне подсети и вы готовы к тому, что исходящий трафик будет направляться в магистральную сеть службы. Важные операционные детали включают разрешение DNS: частные конечные точки требуют обновления локальных DNS или Azure DNS Private Zones, чтобы клиенты разрешали частный IP-адрес; для сетей, подключенных через S2S, часто используются серверы условной пересылки на локальные DNS-серверы. Сценарии использования службы Private Link между подписками поддерживаются, если ресурсы находятся в одном клиенте Azure AD; развертывайте службу Private Link за внутренним Load Balancer (ILB) уровня Standard для обеспечения масштабируемости и избыточности между зонами. Частая ошибка — использование ILB уровня Basic или неправильного SKU, что ограничивает работоспособность и масштабирование внутренних ресурсов. Для службы Private Link, поддерживающей большой объем подключений, используйте ILB уровня Standard, внутренние ресурсы на основе масштабируемых наборов и рассмотрите возможность использования нескольких сетевых интерфейсов конечной точки для каждого экземпляра внутреннего ресурса. Также рассмотрите защиту от DDoS-атак: включите DDoS Protection Standard для сетевых интерфейсов, доступных извне, и планируйте масштабирование портов SNAT и использование NAT Gateway там, где возникает много исходящих подключений.

Таблицы маршрутизации концентратора vWAN и практическое проектирование маршрутов

vWAN использует таблицы маршрутизации концентратора для управления трафиком между подключенными периферийными сетями (spokes), локальными площадками и интернетом. Каждое подключение (площадка, VNet, P2S) может быть связано с таблицей маршрутизации концентратора; приоритеты маршрутов и правила их распространения (propagation) определяют итоговую пересылку трафика. Хороший дизайн начинается с таблицы маршрутизации концентратора по умолчанию, которая перенаправляет трафик, предназначенный для интернета, на Azure Firewall или NVA, и специализированных таблиц маршрутизации для филиалов, которым требуется локальный выход в интернет (on-prem breakout). BGP с локальных VPN-устройств распространяет префиксы в концентратор, и вы можете перераспределять их в периферийные сети или фильтровать с помощью таблиц маршрутизации. Распространенная ошибка — это конфликтующие определяемые пользователем маршруты (UDR) в периферийных VNet, которые пытаются переопределить маршруты, полученные от концентратора. В vWAN таблицы маршрутизации концентратора имеют приоритет для межсетевых соединений, но UDR в периферийных сетях по-прежнему влияют на локальный исходящий трафик (local egress). Для принудительного туннелирования свяжите подключения периферийных сетей с таблицей маршрутизации концентратора, направляющей трафик 0.0.0.0/0 на выбранное вами устройство инспекции. Отслеживайте и планируйте лимиты маршрутов: концентраторы vWAN имеют максимальное количество изучаемых и объявляемых префиксов — проектируйте суммирование префиксов и используйте BGP-сообщества (communities) или фильтры, чтобы не выходить за рамки ограничений. Всегда тестируйте разрешение имен DNS и split-DNS для частных конечных точек (private endpoints), а также документируйте поведение при отказе для multi-hub конфигураций active/active, чтобы соответствовать SLA по отказоустойчивости.

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

Сценарий: Contoso Manufacturing управляет глобальной инфраструктурой в Azure с существующей архитектурой hub-and-spoke VNet в двух регионах, несколькими локальными площадками, подключенными через SD-WAN, и требованием централизовать безопасность и обеспечить частное подключение к PaaS между подписками.

Задача: им нужен масштабируемый, управляемый глобальный транзит, который централизует инспекцию трафика (инспекция TLS, IDPS), поддерживает множество подключений филиалов через SD-WAN и предоставляет частный доступ к нескольким ресурсам PaaS (хранилища и базы данных) для периферийных сетей и локальных площадок без их публикации в интернете.

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

1. Разверните Azure Virtual WAN (vWAN) и создайте защищенные виртуальные концентраторы (secured virtual hubs) в каждом регионе. В каждом концентраторе включите Azure Firewall Premium (для инспекции TLS и IDPS) и интегрируйте его с Firewall Manager. Свяжите концентратор с партнерскими подключениями SD-WAN в vWAN для прямого подключения филиалов (direct branch on-ramp).
2. Настройте таблицы маршрутизации концентратора для направления трафика в интернет и между регионами на Azure Firewall Premium; создайте специализированные таблицы маршрутизации для филиалов, которые должны выходить в интернет через локальную инфраструктуру. Используйте BGP от SD-WAN для объявления локальных префиксов в vWAN и применяйте фильтры префиксов, чтобы избежать разрастания таблиц маршрутизации (route bloat).
3. Для сервисов PaaS подготовьте службы Private Link в выделенной VNet в каждом регионе за Standard Internal Load Balancer и предоставьте доступ к ним через Private Endpoints в периферийных VNet и на локальных площадках с помощью подключения vWAN. Используйте Azure DNS Private Zones и условные пересылки (conditional forwarders) для обеспечения разрешения имен с локальных площадок.
4. Включите DDoS Protection Standard на публичных конечных точках, разверните NAT Gateway для обработки больших объемов исходящего трафика (SNAT) в периферийных сетях и отслеживайте метрики SNAT/DNAT. Используйте политики Firewall Manager для централизованного распространения правил и настройте сбор логов в централизованную рабочую область Log Analytics.

Обоснование: этот подход использует vWAN для масштабируемого подключения филиалов и глобального транзита, Azure Firewall Premium для централизованной расширенной инспекции, требуемой политикой безопасности, и Private Link для безопасного доступа к PaaS без публикации в интернете, обеспечивая баланс между управляемостью, безопасностью и операционным масштабом.

← Мониторинг сети и устранение неполадок · Все домены

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

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