Как настроить профиль маршрутизации Linux на сервере: policy routing, таблицы и проверка

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

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

Термин «профиль маршрутизации» описывает логическую конфигурацию Linux, а не универсальный объект Kubernetes. Если сервер нельзя менять напрямую, схему можно сначала проверить на отдельном VPS в облачной инфраструктуре. Сценарии с несколькими интерфейсами и IP-адресами разобраны в отдельном руководстве по привязке трафика.

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

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

Policy Based Routing добавляет отдельные таблицы и правила выбора. Таблица содержит маршруты, а ip rule определяет, когда ядро должно обратиться к конкретной таблице. Числовое значение priority задает порядок проверки правил: меньшее число обрабатывается раньше.

Когда стандартной таблицы маршрутизации недостаточно

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

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

Если все соединения должны уходить через один шлюз, достаточно обычного маршрута в main. Policy routing усложняет схему, поэтому его используют для конкретного сетевого требования, а не «на всякий случай».

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

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

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

Шаг 1. Подготовьте интерфейсы для настройки маршрутизации Linux на сервере

Сначала соберите исходные данные и подготовьте способ аварийного доступа. Ошибка в default route может закрыть SSH за одну команду.

Если вы меняете маршрут управления, работайте через консоль провайдера, IPMI, KVM или другой внеполосный канал. Не начинайте настройку на удаленном сервере, если единственный доступ идет через тот же маршрут, который вы собираетесь изменить.

Проверьте текущие адреса, маршруты и правила

Сохраните вывод команд до изменений. Он понадобится для сравнения и возврата исходной схемы.

ip -br addr
ip route show table main
ip rule list
ip route show table all
ip route get 203.0.113.20
ip route get 203.0.113.20 from 198.51.100.10

Команда ip -br addr показывает интерфейсы в компактном виде. Через ip route show table main проверьте основной default route, подключенные сети и уже существующие статические маршруты. Команда ip rule list обнаруживает policy rules, которые могли остаться после VPN, контейнерного стека или предыдущей настройки.

В стандартном наборе правил обычно присутствуют таблица local с приоритетом 0, таблица main с приоритетом 32766 и default с приоритетом 32767. Пользовательское правило с приоритетом 100 будет проверено раньше main. Ориентируйтесь на фактический вывод, поскольку дополнительные компоненты могут добавить свои правила.

Команда ip route get показывает, какой маршрут ядро выберет для конкретного назначения. Вариант с from позволяет проверить поведение для нужного исходного IP. Если источник не принадлежит серверу или интерфейс еще не настроен, результат не отражает будущую схему.

Определите менеджер сети и источник текущей конфигурации

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

• NetworkManager хранит параметры в профиле подключения и применяет их при активации соединения.
• systemd-networkd читает декларативные файлы из каталога сетевой конфигурации и создает интерфейсы, маршруты и правила.
• Netplan описывает сеть в YAML, а затем передает конфигурацию выбранному backend, обычно NetworkManager или systemd-networkd.
• Облачная инициализация может менять адреса и маршруты при запуске виртуальной машины.

Проверьте активные службы:

systemctl is-active NetworkManager
systemctl is-active systemd-networkd
ls -la /etc/netplan/

Для одного интерфейса выбирайте один механизм управления. Не редактируйте одновременно Netplan, профиль NetworkManager и файлы systemd-networkd в надежде, что параметры объединятся. Конфигурации могут конфликтовать, а результат после перезагрузки окажется непредсказуемым.

Шаг 2. Policy routing Linux: настройка отдельной таблицы и правил

Ниже используется условная схема:

• eth0, адрес 192.0.2.10/24, основной интерфейс управления;
• eth1, адрес 198.51.100.10/24, отдельный канал;
• шлюз второго канала, 198.51.100.1;
• таблица uplink2 с номером 200;
• целевой адрес для проверки, 203.0.113.20.

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

Создайте таблицу и добавьте connected-маршрут до шлюза

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

echo '200 uplink2' >> /etc/iproute2/rt_tables

Перед добавлением проверьте, нет ли уже строки с номером 200 или именем uplink2. Дублирование затрудняет диагностику. После регистрации добавьте маршрут до подсети шлюза:

ip route add 198.51.100.0/24 dev eth1 src 198.51.100.10 table uplink2
ip route show table uplink2

Эта запись сообщает ядру, что шлюз 198.51.100.1 доступен через eth1. В отдельной таблице connected-маршрут нужен независимо от того, что похожая запись уже есть в main.

Теперь добавьте маршрут по умолчанию:

ip route add default via 198.51.100.1 dev eth1 table uplink2
ip route show table uplink2

Ожидаемый результат содержит два маршрута: сеть 198.51.100.0/24 через eth1 и default через 198.51.100.1. Если default route добавляется раньше connected-маршрута, ядро может отклонить шлюз как недостижимый.

Как добавить маршрут в Linux для конкретной сети или шлюза

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

ip route add 10.20.0.0/16 via 198.51.100.1 dev eth1 table uplink2

Такой вариант подходит для VPN, приватной сети или отдельного резервного канала. Для конкретного хоста укажите более узкий префикс, например 10.20.15.25/32.

Метрика выбирает маршрут внутри одной таблицы, если совпадает префикс. Приоритет priority выбирает порядок правил между таблицами. Эти параметры решают разные задачи. Метрика не заменяет ip rule.

Подробные варианты синтаксиса ip route, статических маршрутов и VLAN собраны в руководстве по маршрутизации Linux.

Добавьте ip rule по исходному IP-адресу

Свяжите таблицу с исходным адресом второго интерфейса:

ip rule add from 198.51.100.10/32 table uplink2 priority 100
ip rule list
ip route get 203.0.113.20 from 198.51.100.10

Правило сработает для трафика, у которого source IP равен 198.51.100.10. Явный приоритет делает порядок предсказуемым. В выводе проверки ожидайте интерфейс eth1, шлюз 198.51.100.1 и исходный адрес 198.51.100.10.

Источник влияет на весь трафик, который подходит под правило. Если часть адресов должна идти через main, добавьте более специфичные правила с меньшим числом priority или создайте отдельные маршруты в пользовательской таблице. Не оставляйте широкое правило без проверки доступа к локальным, VPN- и служебным подсетям.

Когда использовать fwmark для выбора таблицы

Источник не всегда позволяет разделить соединения. Один IP может использовать несколько приложений, а один сервис может работать с разными направлениями. В таких случаях firewall помечает выбранный пакет, а ip rule направляет его в нужную таблицу.

ip rule add fwmark 0x20/0xff table uplink2 priority 110
ip rule list
ip route get 203.0.113.20 mark 0x20

Связка состоит из трех частей: правило firewall выбирает трафик, добавляет маркер, а policy rule ищет этот маркер. В сложных TCP-сценариях метку нужно сохранять для связанных пакетов, включая ответные соединения. Иначе исходящий пакет пойдет через второй шлюз, а ответный трафик потеряет связь с выбранной политикой.

Полная схема source-based маршрутизации, ip rule и маркировки пакетов описана в практическом руководстве по Policy-Based Routing. В этой статье достаточно проверить саму связку таблицы и правила.

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

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

Netplan и systemd-networkd: маршруты и правила в декларативной конфигурации

Для системы с Netplan добавьте маршруты и policy rule в YAML-файл, который обслуживает нужный интерфейс. Пример для второго интерфейса:

network:
  version: 2
  ethernets:
    eth1:
      addresses:
        - 198.51.100.10/24
      routes:
        - to: 198.51.100.0/24
          scope: link
          table: 200
        - to: default
          via: 198.51.100.1
          table: 200
      routing-policy:
        - from: 198.51.100.10/32
          table: 200
          priority: 100

Сохраните отступы YAML и не копируйте блок поверх существующих адресов без проверки. Если интерфейс уже описан в другом файле, объедините параметры в активной конфигурации.

Перед применением проверьте конфигурацию безопасным способом:

netplan try
netplan apply
ip rule list
ip route show table 200

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

Если systemd-networkd управляет интерфейсом напрямую, логика задается в файле .network:

[Match]
Name=eth1

[Network]
Address=198.51.100.10/24

[Route]
Destination=198.51.100.0/24
Table=200
Scope=link

[Route]
Gateway=198.51.100.1
Destination=0.0.0.0/0
Table=200

[RoutingPolicyRule]
From=198.51.100.10/32
Table=200
Priority=100

После изменения перезапустите только тот компонент, который действительно управляет интерфейсом, и проверьте состояние:

networkctl status eth1
ip route show table 200
ip rule list

Не назначайте один интерфейс одновременно Netplan, NetworkManager и systemd-networkd. Netplan может использовать systemd-networkd как backend, поэтому проверяйте не название файла, а фактически активный механизм.

NetworkManager: постоянные маршруты и policy rules через соединение

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

nmcli connection show
nmcli device status

Пример команд для профиля WAN2:

nmcli con mod WAN2 ipv4.never-default yes
nmcli con mod WAN2 ipv4.routes '198.51.100.0/24 0.0.0.0 table=200, 0.0.0.0/0 198.51.100.1 table=200'
nmcli con mod WAN2 ipv4.routing-rules 'priority 100 from 198.51.100.10/32 table 200'
nmcli con up WAN2

Синтаксис атрибутов таблицы зависит от версии NetworkManager. После изменения проверьте не только успешный код команды, но и итоговое состояние:

nmcli connection show WAN2
ip route show table 200
ip rule list
ip route get 203.0.113.20 from 198.51.100.10

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

Шаг 4. Проверьте, что профиль маршрутизации направляет нужный трафик

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

Проверьте выбранную таблицу с помощью ip route get

Для source-based policy routing выполните:

ip rule list
ip route get 203.0.113.20 from 198.51.100.10
ip route show table uplink2

Проверьте в выводе dev eth1, via 198.51.100.1 и src 198.51.100.10. Для маркированного трафика используйте:

ip route get 203.0.113.20 mark 0x20

В некоторых версиях iproute2 поле таблицы не выводится в строке ip route get. Тогда сопоставьте результат с порядком ip rule list и отдельно проверьте содержимое таблицы 200.

Проверьте точечные маршруты тем же способом:

ip route get 10.20.15.25 from 198.51.100.10
ip route get 10.20.15.25

Сравнение двух запросов показывает, меняется ли путь в зависимости от source IP. Это быстрее, чем сразу запускать трассировку и анализировать десятки промежуточных узлов.

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

Запустите захват на ожидаемом интерфейсе во время тестового соединения:

tcpdump -ni eth1 host 203.0.113.20
ss -tnp
tracepath 203.0.113.20

В tcpdump проверьте исходный адрес, направление пакета, TCP-флаги и наличие ответов. Если исходящий пакет виден на eth1, а ответ приходит через eth0 или не приходит совсем, ищите асимметрию, ошибку обратного маршрута, NAT или фильтрацию.

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

Удаленная сторона должна знать маршрут к исходному адресу. Если такой маршрут добавить нельзя, проверьте, должен ли сервер выполнять SNAT или MASQUERADE. После NAT удаленный узел видит другой source IP, поэтому анализировать нужно адрес до и после трансляции.

Подтвердите доступность сервиса, а не только сети

Успешный ip route get подтверждает выбор маршрута. Он не подтверждает прохождение пакета, открытый порт или ответ приложения.

nc -vz -s 198.51.100.10 203.0.113.20 443
ss -lntp
nft list ruleset

Для HTTP или HTTPS выполните запрос с привязкой к нужному адресу через curl --interface 198.51.100.10. Сверьте результат с состоянием сервиса, локальным firewall, security groups у VPS-провайдера, NetworkPolicy и журналом приложения.

Пошаговая проверка интерфейсов, gateway, DNS, VPN, MTU, firewall и TCP-портов собрана в чек-листе диагностики маршрутизации на сервере.

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

Диагностируйте сбой по цепочке: правило, таблица, шлюз, интерфейс, исходящий пакет, обратный путь, NAT, firewall и сервис.

Шлюз не достигается из отдельной таблицы маршрутизации

Наличие маршрута до шлюза в main не помогает таблице uplink2. Ядро проверяет путь в контексте выбранной таблицы. Поэтому сначала добавьте connected-маршрут:

ip route add 198.51.100.0/24 dev eth1 src 198.51.100.10 table 200
ip route get 198.51.100.1 table 200

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

Правило ip rule не срабатывает или выбирается другая таблица

Сначала прочитайте список правил сверху вниз. Проверьте три параметра:

• совпадает ли source IP или destination с фактическим пакетом;
• нет ли более раннего правила, которое завершает поиск в другой таблице;
• совпадает ли fwmark и его маска с маркировкой firewall.

Не смешивайте понятия priority правила и metric маршрута. Priority выбирает порядок обращения к таблицам. Metric сравнивает маршруты внутри выбранной таблицы.

Ответный трафик пропадает из-за асимметричной маршрутизации и rp_filter

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter
sysctl net.ipv4.conf.eth1.rp_filter

Исправление выбирайте по архитектуре. Предпочтительный вариант, добавить корректный обратный маршрут или настроить ожидаемый NAT. Ослабление reverse path filtering может скрыть ошибку схемы и снизить защиту от поддельных адресов, поэтому изменение параметров ядра нужно документировать и проверять после перезагрузки.

Пересекающиеся подсети, NAT и firewall меняют ожидаемый путь

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

• не пересекаются ли локальная, корпоративная, Pod- и Service-сети;
• какой source IP видит удаленный сервер после SNAT или MASQUERADE;
• не блокируют ли пакет nftables, iptables или security group;
• не меняет ли firewall метку, интерфейс или состояние соединения;
• не перезаписывает ли сетевой менеджер таблицу и правила после переподключения.

Маршрутизация на Kubernetes-узле: что проверить до ручных изменений

В стандартном API Kubernetes нет ресурса «профиль маршрутизации», который централизованно задает путь каждого пакета. Маршрутизация между Pod, Service, узлами и внешними адресами формируется сочетанием Linux, CNI-плагина, NAT, firewall и настроек самого приложения.

Почему NetworkPolicy не заменяет маршрутизацию

NetworkPolicy управляет разрешениями на сетевое взаимодействие. Она не создает маршрут между Pod-сетями и внешними адресами и не выбирает шлюз для каждого пакета.

Если Pod не подключается к внешнему API, проверьте всю цепочку:

• маршрут Pod-сети на узле;
• маршрут до внешнего назначения;
• правила CNI и применяемый dataplane;
• NetworkPolicy в namespace;
• NAT и обратный маршрут;
• firewall, security group и порт;
• ответ удаленного сервиса.

Проверка только объекта NetworkPolicy не показывает, существует ли путь до назначения. Аналогично, запись в таблице узла не подтверждает, что CNI пропускает пакет.

Как не конфликтовать с CNI-плагином

Перед ручными изменениями определите используемый CNI и его модель работы. Плагин может создавать маршруты, туннели, правила NAT и фильтрации. Некоторые реализации строят dataplane через eBPF, поэтому привычные записи iptables могут не отражать весь путь пакета.

kubectl get pods -A -o wide
kubectl get networkpolicy -A
ip route
ip rule list

Проверьте диапазоны Pod и Service, маршруты на всех затронутых узлах и правила, которые CNI добавляет при запуске. Не используйте для новой таблицы подсеть, пересекающуюся с Pod-сетью или VPN.

После изменения проверьте три сценария: Pod-to-Pod, Pod-to-Service и Pod-to-external. Повторите тест после перезапуска CNI-компонента и после перезагрузки узла. Если ручное правило исчезает или меняется, перенесите настройку в поддерживаемый механизм CNI либо в конфигурацию сетевого менеджера, который отвечает за узел.

Чек-лист перед вводом профиля маршрутизации в рабочую среду

1. [ ] Сохранен вывод исходных ip -br addr, ip route и ip rule list.
2. [ ] Определены source IP, destination, протокол, порт и ожидаемый исходящий интерфейс.
3. [ ] Проверены шлюз, маска, VLAN и connected-маршрут в пользовательской таблице.
4. [ ] Выбран один механизм управления сетью: NetworkManager, systemd-networkd или Netplan с одним backend.
5. [ ] Таблица зарегистрирована в /etc/iproute2/rt_tables под свободным номером.
6. [ ] Для каждого правила задан явный priority, а его условие совпадает с фактическим трафиком.
7. [ ] Различаются priority правила и metric маршрута.
8. [ ] Проверены ip route get с нужным source IP и, если требуется, с mark.
9. [ ] Через tcpdump подтвержден выход пакета и получение ответа на ожидаемом интерфейсе.
10. [ ] Проверены обратный маршрут, NAT, firewall, security group, порт и ответ приложения.
11. [ ] Проверены параметры rp_filter при наличии нескольких интерфейсов или асимметричного пути.
12. [ ] После перезагрузки или переподключения интерфейса таблица и правила появляются снова.
13. [ ] На Kubernetes-узле проверены CNI, Pod-сети, Service-сети и NetworkPolicy.

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