Профиль маршрутизации и политика маршрутизации: в чем разница и как их применять

Профиль маршрутизации и политика маршрутизации: краткий ответ

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

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

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

Профиль маршрутизации: что это

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

Например, администратор может подготовить три профиля:

• прямой доступ к публичному ресурсу;
• доступ к внутренней сети через шлюз;
• передача определенных направлений через туннель.

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

Политика маршрутизации: что это

Политика описывает правила обработки трафика. Она сопоставляет поток с условиями и задает действие: разрешить подключение, запретить его, применить определенный профиль, отправить трафик через нужный канал или исключить направление из правила.

Условиями могут выступать адрес источника, целевой адрес, тип соединения, пользователь или группа. Точный набор зависит от сетевого продукта. Политика доступа в RD Gateway, например, ограничивает подключение к ресурсу, но сама по себе не создает маршрут от шлюза к целевому компьютеру.

Разница в одной сравнительной схеме

Профиль отвечает за подготовленный вариант пути. Политика решает, когда этот путь можно использовать. В конкретном продукте эти функции могут быть объединены, поэтому название объекта в интерфейсе не заменяет проверку его фактического поведения.

Профиль маршрутизации: что это и как работает

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

Профиль как готовый вариант подключения

Представим сервер, которому нужен доступ к трем направлениям:

• публичные сайты должны открываться напрямую;
• корпоративная сеть доступна через шлюз;
• резервная площадка доступна через зашифрованный туннель.

Профили позволяют описать эти варианты отдельно. Переключение между ними становится контролируемым действием, а тестирование и откат получают понятные границы.

Условное описание профиля может выглядеть так:

Название: rdp-through-gateway
Канал: encrypted-tunnel
Шлюз: gateway.corp.example
Назначение: 192.168.1.50
Область: только RDP

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

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

Какие параметры могут входить в профиль

Проверяйте профиль по категориям, а не по названию полей. В конкретном ПО могут встречаться:

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

Метрика, приоритет, протокол маршрутизации и отдельная таблица могут присутствовать в интерфейсе, но считать их обязательными свойствами профиля нельзя. Перед переносом настройки между Windows, Linux, маршрутизатором и VPN-клиентом проверьте, какие поля продукт действительно применяет.

Для VPN-сценариев полезно заранее разделить корпоративные подсети, домашнюю сеть и интернет. Практический пример такой схемы собран в материале о профиле маршрутизации для VPN и split tunneling.

Когда создавать отдельные профили

Создавайте отдельные профили, если меняется хотя бы один из следующих параметров:

• шлюз или удаленный сервер;
• тип трафика, например RDP вместо веб-доступа;
• требования к шифрованию;
• набор целевых сетей;
• область действия, например один сервер вместо всей LAN;
• резервный канал, который нужно включать при отказе основного.

Разделение упрощает тестирование. Если после изменения пропал доступ, можно сравнить активный профиль с рабочим и быстро вернуть прежний вариант. Профиль при этом не определяет, кто имеет право его использовать. Такое ограничение задает отдельная политика, если продукт разделяет эти уровни.

При большом количестве серверов храните описание профилей в системе контроля версий вместе с версией ПО, назначением и результатами проверки. Подходы к такой автоматизации профилей маршрутизации особенно полезны для Linux, виртуальных машин, Docker и Kubernetes.

Политика маршрутизации: что это и как она работает

Политика связывает характеристики трафика с разрешенным действием. Она отвечает за условия применения настройки, а в некоторых системах участвует и в выборе следующего узла. Поэтому термин политика маршрутизации требует проверки по документации конкретного продукта.

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

Общая последовательность выглядит так:

1. Система получает поток и определяет его источник, назначение и тип.
2. Правила сопоставляют поток с заданными условиями.
3. При совпадении выбирается действие: разрешить, запретить, применить профиль или изменить способ обработки.
4. Сетевой компонент ищет путь к назначению через выбранный интерфейс, шлюз, прокси или туннель.
5. Соединение проходит проверку авторизации и ограничения доступа.

Не каждый продукт выполняет все эти шаги в одном объекте. В одном случае политика только разрешает RDP-подключение, а маршрут строит операционная система. В другом policy-based routing выбирает таблицу или следующий узел на основании адреса источника. Порядок оценки правил тоже различается: встречается последовательная проверка, приоритет, наиболее точное совпадение или комбинация механизмов.

Политика доступа и политика выбора маршрута - не всегда одно и то же

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

RD Gateway показывает это разделение на практике. Клиент указывает адрес шлюза и имя целевого компьютера отдельно:

• шлюз принимает RDP-подключение через защищенный канал;
• политики доступа ограничивают пользователей и целевые компьютеры;
• сам шлюз должен иметь маршрут к внутреннему компьютеру;
• целевой компьютер должен разрешать нужное подключение через firewall и локальные правила.

Если политика разрешает пользователю доступ, но шлюз не видит сеть назначения, соединение не установится. Если маршрут работает, но политика запрещает группу, сеть останется доступной, а подключение получит отказ по правам.

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

Область действия и порядок правил

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

Порядок обработки зависит от платформы. Одни системы используют первое совпавшее правило, другие сравнивают приоритеты, третьи выбирают наиболее точное условие. Не переносите логику из firewall в маршрутизатор или из VPN-клиента в RD Gateway без проверки.

Для критичных направлений составьте короткую таблицу:

Такая таблица не заменяет конфигурацию, но помогает найти конфликт правил до изменения рабочей сети.

Как применять профиль и политику маршрутизации вместе

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

Шаг 1. Определить источник, назначение и тип трафика

Зафиксируйте четыре значения:

• источник: сервер, рабочая станция, пользовательская группа или вся LAN;
• назначение: публичный адрес, внутренняя подсеть или конкретный компьютер;
• тип соединения: веб-трафик, нативный RDP, DNS, SSH или поток всей локальной сети;
• требуемый узел выхода: прямой интерфейс, шлюз, прокси, VPN-сервер или маршрутизатор.

Слово прокси описывает разные задачи. Веб-прокси может менять путь браузерного трафика, а SOCKS5 или HTTPS CONNECT-инструмент может передавать отдельные TCP-соединения. Это не означает, что любой прокси автоматически обрабатывает RDP или весь трафик устройства.

Шаг 2. Описать доступные варианты в профилях

Создайте отдельные профили для прямого доступа, шлюза, прокси и туннеля, если используемая система поддерживает такую модель. В каждом профиле зафиксируйте:

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

Проверьте маршрут не только от клиента к шлюзу. Шлюз, прокси или туннельный сервер тоже должны иметь путь к конечному ресурсу. Публичный узел не получает доступ к приватной сети автоматически.

Шаг 3. Ограничить применение профилей политиками

Свяжите правила с конкретными направлениями и типами трафика. Определите, кому разрешено использовать профиль, какие назначения доступны и какие подключения нужно запретить.

Пример логики:

• RDP от администраторской сети к 192.168.1.50 разрешен через шлюз;
• RDP из гостевой сети запрещен;
• публичный веб-трафик идет напрямую;
• корпоративные подсети доступны только через туннель;
• служебный адрес VPN-сервера исключен из правила туннеля, чтобы не создать зацикливание.

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

Шаг 4. Проверить путь и отдельно проверить доступ

Проверяйте конфигурацию в такой последовательности:

1. доступен ли шлюз, прокси или туннельный узел;
2. видит ли этот узел конечную сеть и целевой адрес;
3. выбран ли нужный профиль;
4. сработало ли ожидаемое правило;
5. проходит ли авторизация пользователя;
6. разрешает ли firewall нужный порт и направление;
7. сохраняется ли шифрование на требуемом участке пути.

Такой порядок разделяет ошибки маршрута, firewall, политики и учетных данных. Проверка только на клиенте часто дает ложный результат: клиент видит шлюз, но промежуточный узел не может обратиться к назначению.

Настройка профиля маршрутизации: три практических сценария

RDP к внутреннему компьютеру через RD Gateway

Схема выглядит так: RDP-клиент подключается к RD Gateway, шлюз передает соединение к внутреннему компьютеру, а политики доступа ограничивают допустимые учетные записи и назначения.

В параметрах нужно различать два объекта:

• адрес шлюза: точка входа для удаленного подключения;
• имя целевого компьютера: конечный ресурс внутри сети.

Пример логической конфигурации:

Gateway: gateway.corp.example
Destination computer: 192.168.1.50
Allowed group: Remote-Admins
Transport: encrypted RDP tunnel

RD Gateway передает RDP через защищенный туннель и применяет политики доступа. При этом успешное подключение к gateway еще не подтверждает доступность 192.168.1.50. Проверьте маршрут и обратный путь между шлюзом и внутренним компьютером.

Нативный RDP через SOCKS5 или HTTPS CONNECT

Настройки веб-прокси Windows сами по себе не направляют все нативные RDP-соединения через прокси. У стандартного клиента Remote Desktop Connection нет общего поля SOCKS5, которое автоматически меняет путь подключения.

Для такой схемы нужен совместимый прокси-инструмент или промежуточный компонент, способный передать RDP через SOCKS5 либо HTTPS CONNECT. Проверьте четыре участка:

1. RDP-клиент устанавливает соединение с локальным или удаленным компонентом;
2. компонент действительно использует выбранный прокси;
3. прокси имеет маршрут к внутреннему адресу;
4. целевой компьютер разрешает подключение и возвращает ответы по рабочему пути.

Профиль здесь может описывать прокси-канал, а политика ограничивать список целевых адресов и пользователей, если конкретный инструмент поддерживает такие правила. Смена прокси в браузере не доказывает, что RDP пошел тем же маршрутом.

Трафик всей локальной сети через зашифрованный туннель на маршрутизаторе

Маршрутизатор может стать единой точкой управления для нескольких устройств LAN. Он принимает исходящий трафик, выбирает прямой путь или туннель и передает его удаленному серверу. Отдельный клиент на каждом компьютере и смартфоне в такой схеме не требуется.

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

• корпоративные подсети идут через туннель;
• локальные адреса остаются в LAN;
• обычный интернет-трафик использует прямой канал;
• служебные адреса туннеля исключаются из перенаправления.

Удаленный сервер должен иметь маршрут к нужным сетям и разрешать обратный трафик. Для тестовой площадки или удаленного узла можно использовать облачный VPS, но сам факт наличия публичного адреса не заменяет настройку маршрутов, firewall и туннеля.

Если сеть построена на Keenetic, сценарии Multi-WAN, VLAN и VPN с единой точкой управления разобраны в практическом руководстве по маршрутизации Keenetic.

Изменение веб-доступа внутри удаленной сессии

Прокси внутри Windows-сессии влияет на браузер и приложения, которые читают системные настройки веб-прокси. Это не меняет автоматически маршрут самого RDP-сеанса между клиентом, шлюзом и удаленным компьютером.

Сначала определите задачу:

• нужно изменить доступ к сайтам внутри удаленного рабочего стола - настройте веб-прокси в этой сессии;
• нужно передать сам RDP через промежуточный узел - используйте RD Gateway или совместимый прокси-инструмент;
• нужно направить трафик всей сети - настройте туннель и правила на маршрутизаторе.

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

Веб-прокси принимают за универсальный маршрут для RDP

Симптом: браузер открывает сайты через прокси, но RDP подключается напрямую или не устанавливает соединение.

Причина: системные веб-настройки Windows не обязаны применяться к нативному RDP. Браузерный прокси и транспорт удаленного рабочего стола используют разные механизмы.

Корректное действие: для доступа к внутреннему компьютеру используйте RD Gateway. Для SOCKS5 или HTTPS CONNECT добавьте совместимый промежуточный компонент и проверьте его маршрут до назначения.

Адрес шлюза путают с адресом целевого компьютера

Симптом: администратор указывает внутренний IP в поле gateway или проверяет доступность шлюза и считает задачу решенной.

Причина: gateway и destination computer выполняют разные функции. Первый принимает соединение, второй предоставляет конечный сервис.

Корректное действие: задайте адрес шлюза отдельно от имени или IP целевого компьютера. Проверьте путь между ними, обратный маршрут и разрешение TCP-порта 3389, если используется RDP.

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

Симптом: прокси доступен из интернета, но адрес вроде 192.168.1.50 остается недостижимым.

Причина: публичный прокси не получает маршрут в приватную сеть автоматически. Он может не знать нужный следующий узел, не иметь обратного пути или блокировать внутренние адреса.

Корректное действие: проверьте маршрут с самого прокси или промежуточного узла до целевой сети. Затем проверьте firewall, NAT, обратное направление и разрешения на конечном компьютере.

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

Симптом: администратор меняет профиль, ожидая снятия запрета доступа, или меняет policy, ожидая появления маршрута к новой сети.

Причина: профиль и политика управляют разными уровнями. Профиль описывает канал или вариант подключения, а политика ограничивает или запускает его применение. В отдельных продуктах policy может участвовать в выборе маршрута, но это нужно подтвердить по документации.

Корректное действие: проверьте отдельно фактический путь, совпадение правила, права пользователя и состояние конечного сервиса.

Как проверить фактический маршрут и срабатывание политики

Проверить маршрут с фактического узла выхода

Начните с определения узла, который реально отправляет трафик дальше. Им может быть клиент, RD Gateway, SOCKS5-компонент, прокси, маршрутизатор или сервер, завершающий туннель.

Для Linux можно использовать штатные команды:

ip route get 192.168.1.50
traceroute -n 192.168.1.50

ip route get показывает выбранный интерфейс и следующий узел для конкретного адреса. traceroute помогает увидеть путь, но промежуточные устройства могут фильтровать диагностические пакеты, поэтому результат не всегда повторяет путь приложения.

Для Windows проверяйте маршрут и порт средствами конкретной версии системы:

Get-NetRoute -DestinationPrefix 192.168.1.50/32
Test-NetConnection 192.168.1.50 -Port 3389

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

Разделить сетевую доступность и авторизацию

Проводите тесты по отдельности:

1. доступен ли сам шлюз или прокси;
2. видит ли промежуточный узел целевой адрес;
3. открыт ли нужный порт на конечном компьютере;
4. совпадает ли трафик с политикой;
5. разрешены ли пользователь и группа;
6. проходит ли аутентификация.

Отказ по учетным данным не доказывает отсутствие маршрута. Тайм-аут до 192.168.1.50 не доказывает ошибку политики. Разделяйте эти результаты в журнале диагностики.

Проверить журналы и отсутствие обходного пути

Сопоставьте время теста с журналами клиента, шлюза, прокси, маршрутизатора и туннельного сервера. Зафиксируйте:

• активный профиль;
• правило политики, которое совпало;
• адрес шлюза или прокси;
• целевой адрес;
• выбранный интерфейс и следующий узел;
• результат авторизации;
• причину отказа, если соединение не прошло.

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

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

Чек-лист перед настройкой и изменением конфигурации

Что определить до создания профиля

• Кто отправляет трафик: один клиент, сервер, группа или вся LAN.
• Какой ресурс нужно достичь: публичный адрес, внутренняя подсеть или конкретный компьютер.
• Какой тип трафика используется: веб, RDP, SSH, DNS или весь исходящий поток.
• Где находится узел выхода: клиент, шлюз, прокси, VPN-сервер или маршрутизатор.
• Нужно ли шифрование на конкретном участке пути.
• Есть ли у шлюза, прокси или туннельного сервера маршрут к назначению.
• Какие направления должны идти напрямую, чтобы не создать петлю.
• Поддерживает ли продукт профили и связывает ли он их с политиками.

Что проверить в политике

• Условия совпадения: источник, назначение, тип соединения, пользователь или группа.
• Разрешенные и запрещенные направления.
• Исключения для локальных сетей, служебных адресов и резервного канала.
• Порядок применения правил или приоритеты, если платформа их поддерживает.
• Связь правила с профилем, таблицей маршрутов или следующим узлом.
• Логи срабатывания и понятную причину отказа.
• Разделение сетевой доступности, firewall и авторизации.

Что зафиксировать после изменения

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

Если конфигурация не проходит проверку, сначала установите фактический узел выхода, затем проверьте его маршрут до назначения. После этого анализируйте совпадение политики, права пользователя и состояние сервиса. Такая последовательность быстрее отделяет ошибку профиля от ошибки доступа и снижает риск изменения рабочей сети.