Профили маршрутизации в Linux: как работают и где применяются

Профили маршрутизации в Linux: что это и зачем они нужны

Профиль маршрутизации в Linux - это логическая схема, которая объединяет пользовательские таблицы маршрутов, правила выбора таблицы через ip rule, маршруты по умолчанию, адреса источника и при необходимости метки пакетов. Такой набор параметров позволяет направлять разные типы трафика через разные шлюзы и интерфейсы. В отличие от простой конфигурации с одной таблицей main, профиль решает задачи с несколькими провайдерами, VPN-туннелями и изолированными сетевыми пространствами.

Когда на сервере один внешний канал и одна внутренняя сеть, достаточно таблицы main с маршрутом по умолчанию. Но при появлении второго uplink, VPN только для части подсетей или контейнерных namespace одного набора маршрутов уже недостаточно. Профиль связывает конкретный тип трафика с нужной таблицей и маршрутом, а ядро Linux выбирает путь по цепочке: сначала проверяются правила ip rule, затем выбранная таблица ищет наиболее специфичный маршрут.

Профиль маршрутизации - это не отдельная команда Linux

В Linux нет встроенной команды routing profile или файла с таким именем. Термин «профиль маршрутизации» используют администраторы для описания согласованного набора настроек, которые меняются вместе. В состав профиля обычно входят:

• отдельная таблица маршрутов, например isp1 или vpn;
• правила ip rule, которые направляют трафик в эту таблицу по условиям (адрес источника, интерфейс, метка);
• маршрут по умолчанию внутри таблицы;
• адрес источника (src) для исходящих пакетов;
• при необходимости метки пакетов (fwmark) для более тонкого отбора.

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

Когда обычной таблицы main недостаточно

Простая схема с одним default route в таблице main подходит для сервера с одним внешним интерфейсом. Но в следующих случаях нужна policy routing:

• два и более провайдера, когда ответный трафик должен уходить через тот же канал, что и входящий;
• VPN только для определённых сетей или приложений (split tunneling);
• разделение подсетей: management, storage, пользовательский трафик через разные шлюзы;
• контейнерные среды, где каждому namespace требуется собственный маршрут по умолчанию.

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

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

Политическая маршрутизация (policy routing) - это механизм ядра, который выбирает таблицу маршрутов на основе правил, а не только адреса назначения. Профиль маршрутизации - практическая реализация этого механизма для конкретной задачи. ip rule задаёт условия выбора таблицы, а ip route описывает сами маршруты внутри таблицы. Вместе они образуют профиль.

Таблицы маршрутизации Linux: из чего состоит профиль

Ядро Linux хранит маршруты в таблицах. По умолчанию существуют три основные таблицы: local, main и default. Для профилей создают дополнительные таблицы с именами, которые регистрируют в файле /etc/iproute2/rt_tables.

Таблицы local, main, default и пользовательские таблицы

• local - содержит маршруты к локальным адресам и широковещательным адресам. Эта таблица обрабатывается первой и не подлежит редактированию.
• main - основная таблица, куда попадают маршруты, добавленные без указания таблицы.
• default - резервная таблица, обычно пустая, используется как fallback.
• пользовательские таблицы - например, isp1, isp2, vpn. Их имена и номера задаются в /etc/iproute2/rt_tables.

Просмотреть содержимое таблицы можно командой ip route show table <имя>.

Что описывает запись маршрута

Каждая запись маршрута содержит несколько полей:

• destination prefix - сеть назначения, например 10.0.0.0/8;
• via - IP-адрес шлюза;
• dev - сетевой интерфейс;
• src - адрес источника для исходящих пакетов;
• scope - область действия маршрута: link для непосредственно подключённых сетей, global для маршрутов через шлюз;
• proto - протокол, который добавил маршрут: kernel, static, dhcp;
• metric - числовой приоритет маршрута, меньшее значение предпочтительнее.

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

Как отделить профили друг от друга

Для каждого провайдера или логического канала создают отдельную таблицу. В неё добавляют:

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

Такое разделение предотвращает конфликты маршрутов и упрощает диагностику.

Маршрутизация по правилам Linux: как выбирается путь

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

ip rule и приоритеты правил

Правила задаются командой ip rule add. Селекторы включают:

• from - адрес источника;
• to - адрес назначения;
• iif - входящий интерфейс;
• oif - исходящий интерфейс;
• fwmark - метка пакета;
• uidrange - диапазон UID пользователя.

Правила имеют приоритет priority, меньшее значение проверяется раньше. Стандартные правила: local (0), main (32766), default (32767). Пользовательские правила обычно вставляют с приоритетом от 100 до 30000, чтобы они срабатывали после local, но до main.

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

Внутри таблицы маршрут выбирается по принципу longest prefix match. Например, для пакета на адрес 10.10.5.1 при наличии маршрутов 10.0.0.0/8, 10.10.0.0/16 и default будет выбран 10.10.0.0/16, так как его префикс длиннее. Метрика не влияет на выбор между маршрутами с разной длиной префикса.

Метрики маршрутов Linux и приоритеты маршрутов

Метрика (metric) используется для выбора между маршрутами с одинаковым префиксом в одной таблице. Например, два default маршрута с метриками 100 и 200: будет использован первый. Приоритет правила (priority) определяет порядок проверки правил, а не выбор маршрута. Это разные уровни.

Проверка решения через ip route get

Команда ip route get показывает, какой маршрут выберет ядро для заданного пакета. Примеры:

ip route get 8.8.8.8 from 192.0.2.10
ip route get 10.0.0.5 iif eth0 mark 1

В выводе смотрите поля dev, via, src и table. Это быстрый способ проверить политику до реального теста.

Настройка policy routing в Linux: профиль для двух провайдеров

Рассмотрим практический сценарий: сервер с двумя интерфейсами eth0 (провайдер ISP1) и eth1 (провайдер ISP2). Нужно, чтобы трафик, созданный с адреса ISP1, уходил через ISP1, а с адреса ISP2 - через ISP2.

Спроектировать таблицы и правила до изменения конфигурации

Соберите данные: IP-адреса интерфейсов, шлюзы, локальные подсети. Определите имена таблиц, например isp1 и isp2. Политика: from <адрес_isp1> lookup isp1, from <адрес_isp2> lookup isp2. Проверьте, через какой канал должен сохраняться SSH-доступ.

Настройка маршрутов в Linux в отдельной таблице

Добавьте маршруты в таблицы:

ip route add 192.0.2.0/24 dev eth0 src 192.0.2.10 table isp1
ip route add default via 192.0.2.1 dev eth0 table isp1
ip route add 198.51.100.0/24 dev eth1 src 198.51.100.20 table isp2
ip route add default via 198.51.100.1 dev eth1 table isp2

Проверьте: ip route show table isp1.

Добавить правила выбора таблицы

Добавьте правила:

ip rule add from 192.0.2.10 table isp1 priority 100
ip rule add from 198.51.100.20 table isp2 priority 200

Правила должны срабатывать до main. Убедитесь, что локальный трафик не заблокирован.

Проверить, протестировать и откатить конфигурацию

Проверьте ip rule list, ip route get 8.8.8.8 from 192.0.2.10. Выполните тесты с привязкой к источнику: ping -I 192.0.2.10 8.8.8.8. Для отката удалите правила и таблицы:

ip rule del from 192.0.2.10 table isp1
ip route flush table isp1

Где применяются профили маршрутизации в Linux

Профили решают задачи изоляции трафика и выбора пути в сложных сетях. Ниже типовые сценарии.

Несколько провайдеров и резервирование каналов

При двух uplink профили обеспечивают корректный возврат трафика. Без policy routing ответный пакет может уйти через другого провайдера, что вызовет асимметрию и обрыв соединения. Настройте source-based routing и проверьте rp_filter.

Разделение подсетей и сервисного трафика

Management-сеть, storage-сеть и пользовательский трафик можно направить через разные шлюзы. Например, storage без default route, management через отдельный интерфейс. Используйте комбинацию route-based и policy-based подходов.

VPN: только нужные сети через туннель

Для split tunneling создайте таблицу vpn с маршрутами только к нужным сетям и правилом from <локальная_сеть> lookup vpn. При full-tunnel отдельно планируйте маршрут к VPN-серверу и DNS.

Контейнеры и сетевые пространства имен

Каждый network namespace может иметь собственные таблицы и правила. CNI-плагины используют policy routing для маршрутизации трафика контейнеров. На хосте маршрутизация между namespace настраивается через veth и bridge.

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

Команды ip route и ip rule меняют состояние ядра только до перезагрузки или пересоздания интерфейса. Для постоянной конфигурации используйте сетевой менеджер.

Временная настройка через iproute2

Ручная настройка подходит для лабораторных проверок и аварийных исправлений. Но NetworkManager или systemd-networkd могут удалить эти маршруты при переподнятии интерфейса.

NetworkManager, systemd-networkd и netplan

В NetworkManager policy routing настраивается через nmcli или файлы ключей. В systemd-networkd используйте секции [Route] и [RoutingPolicyRule]. В netplan - routes и routing-policy. Сверяйте синтаксис с версией дистрибутива.

Проверка постоянной конфигурации

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

Диагностика профилей маршрутизации: почему трафик идет не туда

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

Проверить список правил и содержимое таблиц

Используйте ip rule list, ip route show table main, ip route show table <имя>. Сверьте приоритеты, селекторы и наличие маршрута к шлюзу.

Проверить фактический выбор маршрута

Выполните ip route get <адрес> from <источник> для нескольких комбинаций. Сравните результат с ожидаемой политикой.

Проверить обратный путь, rp_filter и асимметрию

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

Проверить DNS, MTU и правила firewall

Проверьте DNS-резолвинг, MTU и правила nftables/iptables. Для каждого теста фиксируйте адрес источника и интерфейс.

Типовые ошибки и безопасная эксплуатация policy routing

Избегайте распространённых ошибок при внедрении профилей.

Смешивание priority правила и metric маршрута

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

Отсутствие маршрута к шлюзу или локальной сети

Default route в пользовательской таблице не работает без маршрута к next hop. Проверьте scope link и адрес источника.

Потеря SSH-доступа и неправильный обратный маршрут

На удалённом сервере изменения могут оборвать сессию. Используйте резервную консоль, тестируйте из отдельной сессии, готовьте rollback.

Финальный чек-лист проверки профиля

• Таблицы и их имена зарегистрированы в rt_tables.
• Приоритеты правил корректны.
• Маршруты к шлюзам присутствуют.
• Default route в каждой таблице.
• Source address указан.
• ip route get для ключевых направлений возвращает ожидаемый интерфейс.
• Фактический трафик проверен через tcpdump.
• Обратный путь и rp_filter настроены.
• DNS, firewall и VPN работают.
• Конфигурация восстанавливается после перезагрузки.

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