Маршрутизация в Linux: полное руководство по ip rule, таблицам и политикам

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

Linux использует модель маршрутизации, основанную на политиках (policy routing). Ядро не просто заглядывает в одну таблицу маршрутизации при отправке пакета. Процесс начинается с просмотра базы правил (Routing Policy Database, RPDB), управляемой командой ip rule. Каждое правило содержит критерии отбора пакетов и указатель на конкретную таблицу маршрутизации. Если пакет подходит под условия правила, ядро выполняет поиск маршрута в назначенной таблице. Такой подход дает детальный контроль над трафиком: можно направить пакеты от определенного источника через одного провайдера, а трафик конкретного приложения - через VPN-туннель.

Правила обрабатываются в порядке возрастания приоритета: от меньших числовых значений к большим. Приоритет по умолчанию - 0, 32766 и 32767 для стандартных правил. Как только пакет совпадает с правилом, поиск прекращается. Если ни одно правило не подошло, ядро использует таблицу main. Эта архитектура лежит в основе балансировки нагрузки, отказоустойчивых схем и изоляции сетевых сред. Детальнее о базовых принципах статической маршрутизации читайте в практическом руководстве по ip route.

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

Ядро Linux по умолчанию оперирует тремя основными таблицами маршрутизации. Их идентификаторы и имена закреплены в файле /etc/iproute2/rt_tables.

local (255) - таблица с наивысшим приоритетом. Содержит маршруты к локальным адресам интерфейсов, широковещательные и loopback-маршруты. Ядро управляет ей автоматически. Просмотреть содержимое можно командой ip route show table local. Изменять эту таблицу вручную не рекомендуется.
main (254) - основная таблица. Используется по умолчанию, если правила ip rule не указывают другую таблицу. Сюда попадают все маршруты, добавленные командой ip route add без явного указания таблицы. Просмотр: ip route show table main.
default (253) - зарезервированная таблица. Исторически использовалась для правил, не указывающих таблицу явно. В современных системах обычно пуста и ждет пользовательских сценариев.

Для сложных конфигураций создаются пользовательские таблицы. Достаточно добавить строку с числовым идентификатором и именем в /etc/iproute2/rt_tables. Рекомендуемый диапазон для пользовательских таблиц - от 1 до 252. Пример записи:

100 isp1
200 isp2

После этого можно добавлять маршруты в таблицу по имени: ip route add default via 192.168.1.1 table isp1. Проверка содержимого конкретной таблицы выполняется командой ip route show table isp1. Полный список всех таблиц со всеми маршрутами: ip route show table all.

Правила ip rule: как ядро выбирает таблицу для пакета

База правил RPDB - это упорядоченный список условий. Просмотр текущих правил: ip rule show. Вывод по умолчанию содержит три правила:

0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

Первое правило направляет все пакеты к локальным адресам в таблицу local. Второе - в main. Третье - в default. Приоритеты 0, 32766 и 32767 зарезервированы. Пользовательские правила размещают между ними.

Синтаксис добавления правила:

ip rule add [критерии] table [имя_таблицы] priority [число]

Основные селекторы для отбора пакетов:

from [адрес/префикс] - исходный IP-адрес или подсеть. Самый частый критерий для source-based routing.
to [адрес/префикс] - адрес назначения. Применяется для направления трафика к конкретным сетям через альтернативные шлюзы.
fwmark [число/маска] - метка файрвола, установленная iptables или nftables. Позволяет маршрутизировать трафик на основе порта, протокола или UID процесса.
iif [интерфейс] - входной интерфейс. Работает только для пакетов, пришедших с указанного интерфейса.
oif [интерфейс] - выходной интерфейс. Ограничивает применение правила пакетами, покидающими конкретный интерфейс.
tos [значение] - поле Type of Service из IP-заголовка. Используется для QoS-маршрутизации.

Пример правила, отправляющего трафик от подсети 10.0.1.0/24 в таблицу vpn_table с приоритетом 1000:

ip rule add from 10.0.1.0/24 table vpn_table priority 1000

Удаление правила выполняется по критериям или приоритету:

ip rule del from 10.0.1.0/24 table vpn_table
ip rule del priority 1000

При создании правил критически важен порядок. Правило с меньшим приоритетом срабатывает раньше. Несогласованность приоритетов - частая причина петель маршрутизации и потери связности.

Практическая настройка маршрутизации с ip rule

Теоретическая база дает понимание инструментов. Реальная ценность раскрывается в прикладных сценариях. Ниже - три типовых кейса с полными командами и проверкой результата. Все примеры протестированы на Ubuntu 24.04 и Debian 12. Если вы работаете с Windows-инфраструктурой, посмотрите шпаргалку по командам route и netsh.

Балансировка нагрузки между двумя интернет-каналами

Сервер имеет два внешних интерфейса: eth0 (провайдер ISP1, шлюз 192.168.1.1) и eth1 (провайдер ISP2, шлюз 10.0.0.1). Локальная сеть разбита на две подсети: 192.168.100.0/24 и 192.168.200.0/24. Задача - направить клиентов первой подсети через ISP1, второй - через ISP2, с взаимным резервированием при падении канала.

Шаг 1. Создаем пользовательские таблицы. Добавляем в /etc/iproute2/rt_tables:

100 isp1
200 isp2

Шаг 2. Добавляем маршруты по умолчанию в каждую таблицу:

ip route add default via 192.168.1.1 table isp1
ip route add default via 10.0.0.1 table isp2

Шаг 3. Создаем правила source-based routing:

ip rule add from 192.168.100.0/24 table isp1 priority 1000
ip rule add from 192.168.200.0/24 table isp2 priority 1001

Шаг 4. Для балансировки на уровне соединений с использованием меток файрвола задействуем iptables. Помечаем пакеты в mangle-таблице:

iptables -t mangle -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-mark 1
iptables -t mangle -A PREROUTING -i eth1 -m state --state NEW -j CONNMARK --set-mark 2
iptables -t mangle -A OUTPUT -m state --state NEW -j CONNMARK --set-mark 1

Правила ip rule для меток:

ip rule add fwmark 1 table isp1 priority 1002
ip rule add fwmark 2 table isp2 priority 1003

Шаг 5. Проверка. Запустите с хоста из подсети 192.168.100.0/24 команду curl ifconfig.me. Внешний IP должен соответствовать ISP1. Для хоста из 192.168.200.0/24 - ISP2. Детальнее тема балансировки раскрыта в руководстве по source-based маршрутизации.

Направление трафика через VPN-туннель

Поднят WireGuard-туннель с интерфейсом wg0. Удаленная сеть офиса - 10.10.0.0/16. Весь трафик к этой сети должен идти через туннель. Остальной трафик - через основной шлюз. Дополнительно нужно направить весь исходящий трафик от процесса, запущенного под UID 1001, в тот же туннель.

Создаем таблицу vpn:

echo "150 vpn" >> /etc/iproute2/rt_tables

Добавляем маршрут через туннель:

ip route add default via 10.10.0.1 dev wg0 table vpn
ip route add 10.10.0.0/16 via 10.10.0.1 dev wg0 table vpn

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

ip rule add to 10.10.0.0/16 table vpn priority 500

Для трафика конкретного пользователя используем fwmark. Сначала правило iptables:

iptables -t mangle -A OUTPUT -m owner --uid-owner 1001 -j MARK --set-mark 10

Затем правило ip rule:

ip rule add fwmark 10 table vpn priority 501

Проверка: ip route get 10.10.5.8 должен показать шлюз через wg0. Для процесса под UID 1001 команда sudo -u username curl ifconfig.me вернет IP удаленного офиса.

Изоляция сетевых сред с помощью network namespaces

Network namespace изолирует весь сетевой стек: интерфейсы, таблицы маршрутизации, правила ip rule, файрвол. Это штатный механизм контейнеризации в Linux. Каждый namespace имеет собственный /proc/net, /sys/class/net и независимый набор правил RPDB.

Создадим два изолированных веб-сервера на одном хосте. Сервер А слушает порт 80 в namespace ns_a, сервер Б - порт 80 в ns_b. Для связи с внешним миром используем veth-пары.

Шаг 1. Создаем namespaces:

ip netns add ns_a
ip netns add ns_b

Шаг 2. Создаем veth-пары и распределяем их по namespaces:

ip link add veth_a type veth peer name veth_a_peer
ip link add veth_b type veth peer name veth_b_peer
ip link set veth_a netns ns_a
ip link set veth_b netns ns_b

Шаг 3. Назначаем адреса и поднимаем интерфейсы:

ip netns exec ns_a ip addr add 192.168.10.2/24 dev veth_a
ip netns exec ns_a ip link set veth_a up
ip netns exec ns_a ip link set lo up
ip addr add 192.168.10.1/24 dev veth_a_peer
ip link set veth_a_peer up

Аналогично для ns_b с подсетью 192.168.20.0/24.

Шаг 4. В каждом namespace настраиваем маршрутизацию:

ip netns exec ns_a ip route add default via 192.168.10.1

Шаг 5. На хосте включаем IP-форвардинг и настраиваем NAT для доступа namespaces во внешнюю сеть:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.20.0/24 -o eth0 -j MASQUERADE

Каждый namespace теперь имеет собственный сетевой стек. Внутри ns_a можно запустить веб-сервер на порту 80, и он не будет конфликтовать с сервером в ns_b. Правила ip rule внутри каждого namespace настраиваются независимо командой ip netns exec ns_a ip rule add ....

Диагностика и устранение проблем маршрутизации

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

ip route get 8.8.8.8 from 192.168.100.50

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

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

Петля маршрутизации - пакет бесконечно пересылается между шлюзами. Диагностируется traceroute: если видна зацикленная последовательность хопов, проверьте согласованность таблиц и правил.
Неверный приоритет правила - пользовательское правило с приоритетом 100 перекрывается стандартным правилом local с приоритетом 0. Решение: размещать пользовательские правила в диапазоне 100-32765.
Отсутствие маршрута в целевой таблице - правило ip rule указывает на таблицу, в которой нет подходящего маршрута. Проверьте содержимое таблицы: ip route show table [имя].
Не поднят интерфейс туннеля - правило активно, таблица содержит маршрут через tun0, но интерфейс в состоянии DOWN. Пакеты уходят в «черную дыру».

Команда ip route show table all выводит содержимое всех таблиц сразу - это быстрый способ аудита конфигурации. Для мониторинга в реальном времени используйте ip monitor route - она показывает добавление и удаление маршрутов в динамике. Дополнительные методы диагностики описаны в руководстве по диагностике IP-маршрутизации.

Сохранение конфигурации и автоматизация

Правила ip route и ip rule, добавленные через командную строку, не переживают перезагрузку. Для production-сред настройки должны быть персистентными. Способ сохранения зависит от системы управления сетью.

systemd-networkd - современный и рекомендуемый метод для серверов. Конфигурация описывается в файлах .network. Пример для интерфейса и правил маршрутизации:

# /etc/systemd/network/10-eth0.network
[Match]
Name=eth0

[Network]
Address=192.168.1.10/24
Gateway=192.168.1.1

[Route]
Destination=10.0.0.0/8
Gateway=192.168.1.254
Table=isp1

[RoutingPolicyRule]
From=192.168.100.0/24
Table=isp1
Priority=1000

После создания файлов выполните systemctl restart systemd-networkd. systemd-networkd автоматически подхватывает изменения и восстанавливает конфигурацию при загрузке.

Netplan - стандарт для Ubuntu. Файлы конфигурации в /etc/netplan/*.yaml:

network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.168.1.10/24
      routes:
        - to: 10.0.0.0/8
          via: 192.168.1.254
          table: 100
      routing-policy:
        - from: 192.168.100.0/24
          table: 100
          priority: 1000

Применение: netplan apply.

Скрипты if-up.d - legacy-подход для систем с ifupdown (Debian). Разместите исполняемый скрипт в /etc/network/if-up.d/. Он выполнится при поднятии интерфейса. Минус - отсутствие централизованного управления и сложность отладки.

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

Независимо от выбранного метода, после настройки выполните полную перезагрузку сервера и проверьте сохранность правил командами ip rule show и ip route show table all. Только так гарантируется корректное восстановление конфигурации в аварийных сценариях.