Настройка Policy-Based Routing (PBR) в Windows Server 2026: Полное практическое руководство

Что такое Policy-Based Routing и зачем он нужен в Windows Server 2026

Обычная статическая маршрутизация направляет пакеты по самому короткому пути к сети назначения. Policy-Based Routing расширяет эту логику. Вы можете выбирать маршрут на основе источника трафика, порта назначения, протокола или их комбинации. Это ключевой инструмент для реализации сложной сетевой логики непосредственно на сервере Windows.

Представьте сервер с двумя сетевыми адаптерами: один подключен к интернету, другой к внутренней сети. Без PBR весь исходящий трафик, независимо от цели, пойдет через один шлюз по умолчанию. С PBR вы создадите правила: "весь трафик к внутренним серверам (порт 3389) отправлять через интерфейс внутренней сети, а весь веб-трафик (порт 80, 443) через интерфейс интернет". Это базовый пример, который решает конкретные задачи безопасности и производительности.

Эта инструкция написана и проверена для Windows Server 2026. Функционал маршрутизации на основе политик доступен через роль Routing and Remote Access, а также командлеты PowerShell. Мы разберем оба метода.

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

PBR применяется там, где стандартной маршрутизации недостаточно. Вот три практических кейса:

Изоляция трафика серверных подсетей. У вас есть подсеть серверов приложений (10.0.10.0/24) и подсеть пользователей (10.0.20.0/24). Политика безопасности требует, чтобы трафик серверов выходил в интернет через шлюз с расширенным мониторингом (172.16.1.1), а пользовательский трафик через обычный шлюз провайдера (192.168.1.1). PBR решает это правило фильтром по исходному IP-адресу.
Приоритизация трафика по протоколу. Весь HTTPS-трафик (порт 443) критически важен для бизнеса и должен идти через uplink с гарантированной полосой пропускания или DDoS-защитой. Вы создаете фильтр по протоколу TCP и порту назначения 443, связывая его с нужным сетевым интерфейсом. Это улучшает пользовательский опыт и безопасность.
Создание многоуровневой DMZ. Веб-сервер в демилитаризованной зоне должен принимать входящие подключения с интернета через один интерфейс, а исходящие подключения для обновлений или к внутренним БД должны идти через другой, изолированный интерфейс. PBR позволяет реализовать такое разделение на одном физическом хосте, упрощая архитектуру.

Эти сценарии напрямую влияют на безопасность, соответствие нормативным требованиям и отказоустойчивость инфраструктуры. Реализовать их стандартными маршрутами или одной таблицей маршрутизации невозможно.

Подготовка Windows Server 2026 к настройке PBR

Перед созданием политик убедитесь, что среда корректно подготовлена. Основное требование установленная и настроенная роль "Служба маршрутизации и удаленного доступа" (RRAS). Все сетевые интерфейсы должны иметь статические IP-адреса, корректные маски подсети и, при необходимости, шлюзы по умолчанию. Проверьте базовую связность командой `ping` или `Test-NetConnection`.

Рекомендация: выполняйте настройки в тестовой среде или в заранее согласованное окно обслуживания. Изменения маршрутизации могут привести к временной потере сетевого соединения.

Установка и базовая конфигурация роли RRAS

Если роль RRAS не установлена, сделайте это одним из способов.

С помощью PowerShell (рекомендуется для автоматизации):

Install-WindowsFeature RemoteAccess -IncludeManagementTools
Install-WindowsFeature Routing

После установки запустите оснастку "Маршрутизация и удаленный доступ" из меню "Администрирование". Мастер настройки предложит выбрать конфигурацию. Для целей PBR выберите "Настраиваемая конфигурация", а затем "Маршрутизация только для локальной сети". Не настраивайте VPN или NAT, если они не требуются для вашего сценария.

После завершения мастера служба RRAS запустится. Вы увидите древовидную структуру с узлами "IPv4" и "IPv6". Для работы с политиками маршрутизации на основе исходного адреса разверните узел IPv4 Общие Статические маршруты.

Пошаговая настройка Policy-Based Routing через оснастку RRAS

Интерфейс RRAS предоставляет графический способ создания политик. Логика состоит из двух шагов: сначала создается фильтр трафика, затем политика, связывающая этот фильтр с конкретным действием (например, с выходным интерфейсом или шлюзом).

В оснастке "Маршрутизация и удаленный доступ" перейдите к IPv4 Общие Статические маршруты.
Щелкните правой кнопкой мыши на "Общие статические маршруты" и выберите Создать фильтр на основе политики....
В диалоговом окне задайте критерии фильтра: исходный и целевой IP, маски, протокол (TCP/UDP/ICMP) и порты.
После создания фильтра щелкните правой кнопкой мыши на "Общие статические маршруты" и выберите Создать новую политику....
Присвойте политике имя, добавьте созданный фильтр и укажите действие: "Направить пакеты по этому интерфейсу" или "Направить пакеты по этому адресу маршрутизатора следующего перехода".
Настройте порядок (приоритет) политик. Политики с более низким порядковым номером обрабатываются первыми.

Политики вступают в силу немедленно после применения. Не перезапускайте службу RRAS, иначе потребуется повторная активация политик.

Пример 1: Изоляция трафика серверной подсети

Цель: направить весь трафик из подсети серверов 10.0.10.0/24 через специальный шлюз 172.16.1.1, а весь остальной трафик через основной шлюз 192.168.1.1.

Создайте фильтр: в мастере фильтра укажите:
- Источник: IP-адрес 10.0.10.0, Маска: 255.255.255.0.
- Назначение: "Любой".
- Протокол: "Любой".
Создайте политику: назовите её "Server-Subnet-Outbound". Добавьте созданный фильтр. В качестве действия выберите "Направить пакеты по этому адресу маршрутизатора следующего перехода" и укажите 172.16.1.1.
Настройте порядок: убедитесь, что эта политика имеет более высокий приоритет (меньший номер), чем политика или маршрут по умолчанию для общего трафика.

Теперь любой пакет, исходящий с адреса в диапазоне 10.0.10.0/24, будет отправлен на шлюз 172.16.1.1.

Пример 2: Маршрутизация по порту назначения (например, для HTTPS)

Цель: весь HTTPS-трафик (TCP порт 443) с сервера должен направляться через интерфейс "Ethernet2", подключенный к VLAN с системой DDoS-защиты.

Создайте фильтр:
- Источник: "Любой" (или IP сервера).
- Назначение: "Любой".
- Протокол: TCP.
- Порт назначения: 443.
Создайте политику: назовите "HTTPS-Through-DDoS-VLAN". Добавьте фильтр. В качестве действия выберите "Направить пакеты по этому интерфейсу" и укажите "Ethernet2".

Это правило полезно не только для безопасности, но и для балансировки нагрузки, когда определенные типы сервисов должны использовать выделенные каналы связи.

Если ваша инфраструктура использует несколько протоколов динамической маршрутизации для основной маршрутизации, изучите наше руководство по динамической маршрутизации OSPF, BGP и EIGRP. PBR часто работает поверх этих протоколов, обеспечивая тонкую настройку.

Настройка PBR с помощью PowerShell: автоматизация и тонкий контроль

Графический интерфейс удобен для разовых настроек, но для управления инфраструктурой как кодом или повторяемых развертываний необходим PowerShell. В Windows Server 2026 для работы с маршрутизацией используются командлеты модуля NetTCPIP и RemoteAccess.

Основное преимущество PowerShell воспроизводимость. Вы можете сохранить последовательность команд в скрипт и применять ее к множеству серверов, что критично для среды DevOps.

Ключевые командлеты и готовые скрипты

Для управления маршрутами используется командлет New-NetRoute. Однако для создания политик маршрутизации на основе исходного адреса (Source Policy Route) требуется указать параметр -PolicyStore.

Скрипт, реализующий сценарий "Изоляция трафика серверной подсети" из примера 1:

# Создание политики маршрутизации для подсети 10.0.10.0/24 через шлюз 172.16.1.1
New-NetRoute -DestinationPrefix "0.0.0.0/0" -NextHop 172.16.1.1 -InterfaceAlias "Ethernet1" -PolicyStore "ActiveStore" -RouteMetric 10 -AddressFamily IPv4 -SourcePrefix "10.0.10.0/24"

Пояснение параметров:

-DestinationPrefix "0.0.0.0/0": правило применяется для трафика к любому адресу назначения.
-SourcePrefix "10.0.10.0/24": ключевой параметр PBR. Указывает исходную сеть, к которой применяется правило.
-PolicyStore "ActiveStore": указывает, что маршрут является политическим и будет отображен в `route print` с пометкой "policy".
-RouteMetric: метрика маршрута. Влияет на приоритет среди нескольких правил PBR для одного источника.

Для управления самой службой RRAS используйте модуль RemoteAccess. Например, перезапуск службы:

Restart-Service RemoteAccess -Force

Для комплексной автоматизации сетевых задач, например разблокировки исполняемых файлов в корпоративной среде, могут потребоваться смежные техники. В руководстве по разблокировке загружаемых файлов в Windows рассматриваются методы работы с групповыми политиками и PowerShell, которые дополняют автоматизацию администрирования.

Диагностика, типичные ошибки и как их избежать

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

Как проверить, что политика маршрутизации работает

Выполните последовательность команд для диагностики:

Просмотр таблицы маршрутов с политиками:
```
route print
```
Или точнее в PowerShell:
```
Get-NetRoute -PolicyStore ActiveStore | Format-Table -AutoSize
```
В выводе ищите строки с пометкой "policy". Они отображают активные правила PBR.
Тестирование пути с указанием исходного интерфейса:
```
Test-NetConnection -ComputerName 8.8.8.8 -Source 10.0.10.5
```
Эта команда эмулирует отправку пакета с адреса 10.0.10.5 (входящего в вашу политику). С помощью `tracert` или анализа сетевого трафика (Wireshark на выходном интерфейсе) убедитесь, что пакеты идут по ожидаемому пути.
Проверка журналов RRAS: откройте "Просмотр событий Windows Журналы приложений и служб Microsoft Windows RemoteAccess". Фильтруйте события по ID 4 (успешное применение политики) или 2 (ошибка).

Типичные ошибки и решения:

Политика не применяется. Проверьте порядок (приоритет) политик в оснастке RRAS. Правило с более высоким приоритетом (меньшим номером) может перехватывать трафик. Проверьте корректность масок подсети в фильтрах. Ошибка в маске (например, /24 вместо /25) приведет к тому, что трафик не будет попадать под фильтр.
Конфликт с маршрутом по умолчанию. PBR-правило имеет более низкий приоритет, чем маршрут по умолчанию в основной таблице маршрутизации. Убедитесь, что метрика PBR-маршрута (в PowerShell) или порядок политики (в GUI) обеспечивают его приоритетную обработку.
Брандмауэр Windows блокирует трафик. PBR меняет путь пакета, но не отключает правила брандмауэра. Убедитесь, что для новых или измененных путей в брандмауэре разрешен соответствующий трафик. Это особенно актуально при настройке исходящих подключений через нестандартные интерфейсы.
Асимметричная маршрутизация. Если входящий трафик приходит по одному пути, а исходящий уходит по другому (заданному PBR), stateful-устройства (фаерволы, NAT) могут разорвать соединение. Эта проблема детально разбирается в статье про асимметричную маршрутизацию, где даны решения для Cisco, MikroTik и Linux.

Ограничения RRAS для PBR и когда стоит рассмотреть альтернативы

Хотя RRAS в Windows Server 2026 надежно реализует PBR для многих задач, у этого подхода есть границы применимости.

Основные ограничения:

Производительность. Обработка сложных политик PBR на уровне ОС Windows создает дополнительную нагрузку на ЦП. При очень высоких скоростях передачи данных (10 Гбит/с и выше) или при наличии тысяч сложных правил производительность может стать узким местом.
Масштабируемость управления. Управление десятками и сотнями политик через оснастку RRAS становится громоздким. PowerShell решает эту проблему лишь частично, требуя собственной системы управления скриптами.
Отсутствие продвинутого синтаксиса правил. По сравнению с профессиональными маршрутизаторами (Cisco IOS, Juniper JunOS) или продвинутыми программными решениями на Linux (nftables, FRR), фильтры RRAS менее гибки. Например, сложнее создавать правила на основе состояния соединения или временных интервалов.

Рекомендации по выбору альтернатив:

Для средних корпоративных сетей, интеграции с Active Directory и сценариев, где Windows-сервер уже является шлюзом, RRAS оптимальный выбор. Его проще внедрить и поддерживать в гомогенной среде Windows.
Для высоконагруженных ядер сети, дата-центров или сред с разнородным оборудованием рассмотрите выделенные аппаратные маршрутизаторы (Cisco, MikroTik) или программные маршрутизаторы на базе Linux (например, с использованием FRR или просто iptables/nftables с правилами маркировки пакетов). Эти системы изначально созданы для маршрутизации и обеспечивают лучшую производительность и гибкость.
Для сценариев, где требуется глубокая интеграция с облаками (например, распределение трафика между локальным дата-центром и Azure/AWS), может быть эффективнее использовать встроенные механизмы облачных провайдеров совместно с VPN-шлюзами. Настройке такой интеграции посвящена статья о сетевой интеграции Windows Server с Azure и AWS.

Использование Windows Server в качестве маршрутизатора это взвешенное решение, которое хорошо работает в определенных рамках. Понимание этих рамок позволяет выбрать правильный инструмент для каждой задачи.