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

Короткий ответ: как направить трафик через нужный интерфейс

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

Практический профиль маршрутизации собирают из отдельных таблиц и правил ip rule. Для каждого потока определяют источник, назначение, порт и протокол, сопоставляют поток с правилом политики, выбирают таблицу, проверяют connected-маршрут до шлюза и подтверждают результат командой ip route get. Фактическое движение пакетов проверяют через tcpdump на локальном сервере и узле выхода.

ip rule show
ip route show table all
ip route get 198.51.100.25 from 203.0.113.10
ip route get 10.20.0.15 from 10.10.10.2
tcpdump -ni any host 10.20.0.15

Маршрут до сети и доступ к приложению проверяют раздельно. После выбора интерфейса остаются проверки шлюза, обратного маршрута, firewall, NAT, TCP или UDP-порта и авторизации приложения. Успешный ответ команды ip route get не доказывает, что сервис принимает соединения.

Профили маршрутизации Linux и policy based routing: что именно настраивается

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

Профиль, политика и таблица маршрутов: разница между понятиями

Последовательность обработки выглядит так:

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

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

Обычный набор таблиц Linux содержит local, main и default. Таблица local имеет наивысший приоритет и хранит локальные адреса и широковещательные маршруты. main содержит обычные маршруты интерфейсов и стандартный маршрут по умолчанию. default используется как последний резервный вариант. Для раздельных uplink добавляют собственные таблицы, например public, private и vpn.

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

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

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

Правило с приоритетом 100 сработает раньше правила с приоритетом 200. В выбранной таблице ядро ищет наиболее специфичный префикс. Маршрут 10.20.0.0/16 при прочих равных условиях будет выбран раньше маршрута 10.0.0.0/8. Если несколько маршрутов имеют одинаковую длину префикса, на выбор влияет метрика.

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

Несколько default route в main создают неоднозначную схему. Метрика может выбрать один маршрут, но она не выражает связь между исходным IP и шлюзом. Для multi-homing надежнее связать исходную сеть с отдельной таблицей и добавить в эту таблицу собственный connected-маршрут и default route.

Почему одного маршрута по умолчанию недостаточно

Представим сервер с двумя интерфейсами:

Если оба шлюза попали в одну таблицу, сервер может выбрать публичный маршрут для ответа на соединение, которое пришло через приватную сеть. Удаленный узел увидит ответ с неожиданного интерфейса или исходного адреса. Firewall, reverse path filtering и внешний маршрутизатор могут отбросить такой пакет.

Адрес назначения задает направление, но исходный адрес и контекст сокета влияют на обратный путь. Сервис, привязанный к 10.10.10.2, должен отправлять ответы через приватный шлюз. Сервис, слушающий 203.0.113.10, должен использовать публичную таблицу. Source-based policy routing связывает эти требования с правилами ядра.

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

Перед настройкой: опишите потоки и ожидаемую топологию

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

Зафиксируйте источник, назначение, порт и протокол

Указывайте порт и протокол, если разные приложения используют разные пути. Правило только по destination может оказаться слишком широким, когда один сервер отправляет запросы к одной сети с двух исходных IP. Для TCP запишите порт назначения и процесс, для UDP учитывайте отсутствие установочного рукопожатия.

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

ip -br addr show
ip route show table main
ip rule show
ip link show
ip neigh show

В контейнере или отдельном network namespace эти команды нужно выполнять внутри соответствующего пространства. Маршруты хоста не заменяют маршруты контейнера, а настройки гостевой ОС не заменяют правила гипервизора или внешнего шлюза.

Опишите цепочку прохождения трафика

Запишите путь в явном виде, например: клиент -> VPN-шлюз -> внутренняя сеть -> сервер. Для каждой точки укажите интерфейс, IP-адрес следующего узла и ожидаемый путь возврата.

Для доступа к внутреннему серверу полезна такая последовательность:

1. Клиент отправляет пакет на VPN-шлюз.
2. VPN-шлюз передает пакет во внутренний сегмент.
3. Внутренний маршрутизатор доставляет пакет серверу.
4. Сервер выбирает обратный маршрут к адресу клиента.
5. Ответ проходит через тот же VPN-шлюз или через согласованный обратный узел.

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

Выберите критерий привязки профиля

Выбирайте самый узкий критерий, который описывает реальную задачу:

Source subnet обычно дает простую и предсказуемую схему. Маркировка нужна, когда одного адреса недостаточно. Привязка к домену не входит напрямую в стандартный выбор маршрута ядра: домен сначала преобразуется в IP, после чего применяют адресное правило, маркировку, прокси или механизм конкретного VPN-клиента.

Настройка маршрутов для нескольких IP-адресов через iproute2

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

Создайте отдельные таблицы для сетевых профилей

Добавьте имена таблиц в /etc/iproute2/rt_tables:

100 public
200 private

Числа должны быть уникальны в этой системе. Имена нужны для читаемости команд и журналов, ядро работает с числовыми идентификаторами.

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

Для общей справки по policy routing и нескольким таблицам можно использовать шпаргалку по ip route, NAT и policy routing.

Добавьте connected-маршрут и шлюз в каждую таблицу

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

ip route add 203.0.113.0/24 dev eth0 src 203.0.113.10 table public
ip route add default via 203.0.113.1 dev eth0 src 203.0.113.10 table public

ip route add 10.10.10.0/24 dev eth1 src 10.10.10.2 table private
ip route add default via 10.10.10.1 dev eth1 src 10.10.10.2 table private

Шлюз должен находиться в непосредственно подключенной L2-подсети. Проверьте маску, состояние интерфейса и соседнюю запись ARP:

ip link show eth0
ip addr show dev eth0
ip route get 203.0.113.1
ip neigh show dev eth0
ping -I 203.0.113.10 -c 3 203.0.113.1

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

Для удаленной сети добавьте более специфичный маршрут в нужную таблицу:

ip route add 10.20.0.0/16 via 10.10.10.1 dev eth1 src 10.10.10.2 table private

Префикс 10.20.0.0/16 будет выбран раньше private default route для адресов этой сети.

Назначьте ip rule по исходной сети или адресу

Теперь свяжите исходные адреса с таблицами:

ip rule add from 203.0.113.10/32 priority 100 table public
ip rule add from 10.10.10.2/32 priority 110 table private

Для целой исходной сети используют префикс:

ip rule add from 10.10.10.0/24 priority 110 table private

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

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

ip rule del priority 100
ip rule del priority 110

При сложной схеме сначала проверяйте пересечения. Правило from 10.10.0.0/16 с приоритетом 100 перехватит адрес из более узкой сети 10.10.10.0/24, если узкое правило расположено ниже. Четкие диапазоны и последовательная нумерация приоритетов упрощают сопровождение.

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

Проверьте состав правил, содержимое таблиц и решение ядра для конкретного источника:

ip rule show
ip route show table public
ip route show table private
ip addr show
ip route get 198.51.100.25 from 203.0.113.10
ip route get 10.20.0.15 from 10.10.10.2

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

Тестируйте конкретный source address. Запрос без from может выбрать другой локальный адрес и скрыть ошибку policy routing. После локальной проверки запустите приложение и сравните ожидаемый поток с захватом пакетов.

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

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

Привязка по исходной подсети или конкретному IP

Для публичного и приватного адреса применяйте отдельные правила:

ip rule add from 203.0.113.10/32 priority 100 table public
ip rule add from 10.10.10.2/32 priority 110 table private

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

ip rule add from 10.10.20.0/24 priority 120 table vpn

Такой подход подходит для multi-WAN, разных арендаторов, сервисов с разными bind-адресами и сегментации backend-трафика. Если приложение использует wildcard bind на всех адресах, исходный IP может зависеть от выбора сокета. Проверяйте его через ss -lntup, настройки сервиса и tcpdump.

Расширенный разбор source-based routing с ip rule, пользовательскими таблицами и маркировкой доступен в руководстве по маршрутизации по источнику.

Привязка по сети или IP-адресу назначения

Если через конкретный канал должна проходить выделенная удаленная сеть, используйте destination rule:

ip rule add to 10.30.0.0/16 priority 130 table vpn
ip route add 10.30.0.0/16 dev tun0 table vpn

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

Следите за пересечением префиксов. Маршрут 10.30.0.0/16 перекроет default route в таблице vpn, а маршрут 10.30.10.0/24 внутри той же таблицы будет выбран раньше общего /16. При destination rules проверяйте приоритет самого правила, затем длину префикса в выбранной таблице.

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

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

ip rule add iif eth1 priority 140 table private

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

ip rule add oif eth0 priority 150 table public

Для входящих соединений iif не описывает процесс или сервис, который создал ответ. Для локального приложения сам интерфейс тоже не всегда надежный идентификатор: приложение может выбрать адрес через bind, namespace, socket mark или сетевой менеджер. Source IP обычно точнее, а интерфейс добавляют как дополнительное условие при понятной топологии.

fwmark, nftables и выбор маршрута для приложения или типа трафика

Когда поток нужно разделить по порту, протоколу, контейнеру или признаку соединения, применяют связку nftables -> mark -> ip rule fwmark -> отдельная таблица.

ip rule add fwmark 0x20/0xff priority 160 table vpn
ip route add 10.30.0.0/16 dev tun0 table vpn

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

table inet pbr {
    chain output {
        type route hook output priority mangle; policy accept;
        ip daddr 10.30.0.0/16 meta mark set 0x20
    }
}

Для транзитных пакетов классификацию выполняют в prerouting. Запросы и ответы должны получать согласованные метки. На практике для этого используют connection mark: сохраняют метку в conntrack и восстанавливают ее для последующих пакетов соединения. Схема зависит от firewall и ядра, поэтому после добавления правил проверяйте счетчики nftables и захват трафика.

Маршрутизация по приложению не входит в прямую логику ip rule. Приложение можно классифицировать по порту, UID, cgroup, namespace или отдельному VPN-механизму, после чего передать результат в mark. Per-app split tunneling может использовать маркировку, TUN-интерфейс, системный прокси или прокси самого VPN-клиента. Доменную политику сначала нужно связать с IP-адресами и учитывать смену DNS-ответов.

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

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

NetworkManager, systemd-networkd и Netplan

В NetworkManager правила и маршруты хранят в connection profile. Синтаксис зависит от версии, но логика остается одинаковой: задать маршрут с таблицей, preferred source и routing rule:

nmcli con mod public ipv4.routes "203.0.113.0/24 0.0.0.0, 203.0.113.1/32 0.0.0.0 table=100"
nmcli con mod public ipv4.routing-rules "priority 100 from 203.0.113.10/32 table 100"
nmcli con up public

Перед применением проверьте поддержку параметра table конкретной версией NetworkManager. Для удаленного сервера держите резервный доступ и не меняйте активный профиль без плана отката.

В systemd-networkd параметры записывают в файлы интерфейсов:

[Route]
Destination=0.0.0.0/0
Gateway=203.0.113.1
Table=100
PreferredSource=203.0.113.10

[RoutingPolicyRule]
From=203.0.113.10/32
Table=100
Priority=100

В Netplan та же логика описывается декларативно:

network:
  version: 2
  ethernets:
    eth0:
      addresses: [203.0.113.10/24]
      routes:
        - to: 0.0.0.0/0
          via: 203.0.113.1
          table: 100
      routing-policy:
        - from: 203.0.113.10/32
          table: 100
          priority: 100

После изменения выполните проверку конфигурации, reload и перезагрузку в тестовом окне. Снова проверьте ip rule show, таблицы, source address и маршрут после reboot. Не переносите значения priority, metric и имена полей между NetworkManager, systemd-networkd и Netplan без сверки документации установленной версии.

Виртуальные машины, Cloud-Init и Proxmox

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

Cloud-Init или шаблон виртуализации могут передать при создании экземпляра статический IP, gateway и DNS. После загрузки гостя проверьте, какие значения реально применились:

ip -br addr show
resolvectl status
ip route show
ip rule show

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

Для быстрого тестового стенда с несколькими VDS и отдельными сетевыми сегментами можно использовать облачную инфраструктуру Timeweb Cloud. Перед настройкой policy routing проверьте ограничения провайдера на дополнительные IP, виртуальные интерфейсы, anti-spoofing и пользовательские маршруты.

Безопасное внесение изменений в удаленную систему

Перед изменением маршрутов сохраните текущую конфигурацию:

ip addr show > /root/ip-config-before.txt
ip rule show > /root/ip-rules-before.txt
ip route show table all > /root/ip-routes-before.txt

Используйте резервный канал доступа, консоль гипервизора или out-of-band управление. Новое правило сначала добавляйте временно, затем проверяйте доступ к шлюзу и рабочему сервису. Сохраните команды удаления и заранее подготовьте откат default route.

Не меняйте одновременно интерфейсы, firewall, NAT и policy routing. Изменяйте один слой, проверяйте результат и фиксируйте вывод команд. После успешного теста переносите настройки в NetworkManager, systemd-networkd или Netplan и повторяйте проверку после перезагрузки.

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

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

Проверьте шлюз, source address и connected-маршрут

Для каждой пользовательской таблицы должны выполняться три условия:

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

Проверяйте маршрут с заданным источником:

ip route get 203.0.113.1 from 203.0.113.10
ip route get 10.10.10.1 from 10.10.10.2
ip route show table public
ip route show table private

Default route через шлюз из другой L2-подсети может привести к ошибкам ARP, сообщению unreachable или отправке пакета через неожиданный интерфейс. Параметр onlink не заменяет проверку VLAN, маски и соседнего устройства.

Устраните пересекающиеся подсети, метрики и конфликты приоритетов

Проверяйте три уровня выбора:

1. Priority правила: какое правило RPDB проверяется первым.
2. Префикс маршрута: какой маршрут внутри таблицы наиболее специфичен.
3. Metric: какой маршрут выбран среди вариантов с одинаковым префиксом.

Пример конфликта: правило from 10.10.0.0/16 с priority 100 выбирает таблицу public, а правило from 10.10.10.0/24 с priority 200 должно выбирать private. Узкое правило не сработает, потому что широкое уже вернуло результат.

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

Проверьте обратный маршрут и reverse path filtering

Удаленный узел должен знать маршрут к исходному IP. При NAT проверьте трансляцию на границе и убедитесь, что обратный пакет возвращается к тому же узлу выхода. Для TCP полезно наблюдать SYN, SYN-ACK и ACK на ожидаемых интерфейсах.

Reverse path filtering, параметр rp_filter, может отбросить пакет, если обратная проверка источника не согласуется с текущим интерфейсом. Узнайте режимы для системы и интерфейсов:

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

Режим 1 выполняет строгую проверку, режим 2 допускает более гибкую асимметрию, режим 0 отключает проверку. Не отключайте rp_filter вслепую. Сначала определите, допустима ли асимметрия по политике безопасности, исправьте обратный маршрут и согласуйте режим на всех нужных интерфейсах.

Firewall может блокировать пакет после успешного выбора маршрута. Проверьте фильтрацию на сервере, security groups, межсетевом экране, VPN-шлюзе и удаленном сервере.

Пошаговая диагностика: почему трафик все еще уходит не туда

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

Зафиксируйте точный поток перед проверкой

Запишите:

• IP-адрес источника и целевой IP-адрес или сеть.
• Порт назначения и протокол.
• Процесс, контейнер или network namespace.
• Ожидаемый интерфейс, шлюз, VPN-туннель или прокси.
• Ожидаемый путь ответа.

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

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

ip rule show
ip route show table all
ip route get 10.20.0.15 from 10.10.10.2
ip route get 10.30.0.15 from 10.10.20.2 mark 0x20
ip route get 198.51.100.25 from 203.0.113.10

Сопоставьте вывод с ожидаемым профилем. Проверьте наличие ранних правил from all, широких source-префиксов, destination rules и правил с fwmark. Если маршрут выбирается неверно, захват трафика пока не нужен: сначала исправьте RPDB или таблицу.

Проверьте шлюз, VPN или прокси с исходного узла

Доступность промежуточной точки проверяйте с нужного адреса:

ping -I 10.10.10.2 -c 3 10.10.10.1
ip route get 10.10.10.1 from 10.10.10.2
ip link show tun0
ip addr show dev tun0

Для VPN отдельно проверьте маршрут до endpoint через физический интерфейс. Если endpoint сам попал в VPN-таблицу, туннель может зациклиться или перестать устанавливать соединение. Для прокси проверьте доступность адреса и порта прокси, затем отдельно тестируйте целевой сервис.

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

Локальная таблица показывает решение ядра, но не подтверждает прохождение пакета через внешний шлюз. Используйте traceroute или tracepath с нужным source address, если эти утилиты поддерживают требуемые параметры в вашей системе.

traceroute -n -s 10.10.10.2 10.20.0.15
tracepath -b 10.20.0.15
tcpdump -ni any host 10.20.0.15

На сервере и узле выхода проверьте ARP или MAC до шлюза, направление пакетов и наличие ответов:

ip neigh show
tcpdump -ni eth0 host 203.0.113.1
tcpdump -ni eth1 host 10.20.0.15

Если пакет виден на неправильном интерфейсе, причина находится в правилах или таблице. Если он выходит правильно, но ответа нет, проверяйте внешний маршрут, firewall и удаленный узел. Руководство по source-based маршрутизации и разделению трафика между шлюзами помогает сопоставить такие симптомы с конфигурацией нескольких uplink.

Отделите маршрутизацию от firewall, порта и авторизации

После подтверждения пути проверьте следующие уровни:

1. Правила nftables или iptables на сервере и шлюзах.
2. NAT и security groups на границе сети.
3. Прослушивание нужного TCP или UDP-порта: ss -lntup.
4. Привязку сервиса к адресу: 0.0.0.0, конкретный IP или loopback.
5. Авторизацию приложения, ACL и политику самого сервиса.

nft list ruleset
ss -lntup
ip addr show
ip route get 10.20.0.15 from 10.10.10.2

Маршрут до сети может работать при закрытом порте. Открытый порт может отвечать отказом приложения. Эти результаты фиксируйте раздельно, чтобы не менять policy routing при проблеме firewall или авторизации.

Для краткой проверки команд и типовых связок пригодится шпаргалка по PBR, ip rule и fwmark.

Практические схемы для нескольких сетевых интерфейсов

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

Публичный интерфейс eth0 обслуживает внешний трафик, приватный eth1 передает management и backend-запросы. Создайте таблицы public и private, добавьте connected-маршрут и default route в каждую таблицу, затем назначьте правила по source IP.

ip route get 198.51.100.25 from 203.0.113.10
ip route get 10.20.0.15 from 10.10.10.2

Первый результат должен показать dev eth0 и публичный шлюз. Второй должен показать dev eth1 или private-маршрут через нужный шлюз. Проверьте ответы сервисов с обоих адресов, доступ к management-сети и маршрут возврата от внутренних систем к приватному адресу.

Выделенная подсеть через VPN или туннель

Для split tunneling оставьте общий интернет-маршрут в main или public, а конкретные сети направьте через tun0:

ip route add 198.51.100.0/24 via 203.0.113.1 dev eth0 table public
ip route add 10.30.0.0/16 dev tun0 table vpn
ip rule add to 10.30.0.0/16 priority 130 table vpn

Маршрут до VPN endpoint должен оставаться вне туннеля, обычно через физический интерфейс. Иначе endpoint может попытаться достичь самого себя через еще не установленный туннель. После подключения проверьте состояние tun0, маршрут до endpoint, маршрут внутри VPN и обратную запись на удаленной стороне.

Для выбранных приложений используйте mark или механизм per-app split tunneling конкретного VPN-клиента. Правило по сети назначения проще сопровождать, если все сервисы этой сети должны идти через один туннель.

Несколько исходных IP для разных сервисов

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

ip rule add from 203.0.113.10/32 priority 100 table public
ip rule add from 10.10.10.2/32 priority 110 table private
ss -lntup
ip route get 198.51.100.25 from 203.0.113.10
ip route get 10.20.0.15 from 10.10.10.2

Проверьте bind приложения, исходящий адрес в tcpdump, NAT на внешнем шлюзе и маршрут к серверу на стороне клиента. Правильная локальная таблица не исправит отсутствие обратной записи у провайдера или удаленной сети.

Гибридная сеть между дата-центром, ВМ и облаком

В гибридной схеме разделите зоны ответственности:

• Гостевая ОС выбирает маршрут внутри ВМ или контейнера.
• Гипервизор и виртуальный коммутатор передают кадры в нужный bridge или VLAN.
• Физический шлюз или firewall маршрутизирует между площадками.
• VPN или межсетевой экран задает туннель, NAT и фильтрацию.
• Удаленная сеть должна знать обратный путь к исходным подсетям.

Одинаковые подсети на двух площадках, неправильное имя bridge, отсутствие маршрута на гипервизоре или блокировка security group могут выглядеть как ошибка профиля внутри Linux. Проверяйте путь последовательно на госте, хосте, шлюзе и удаленном сегменте.

Итоговый чек-лист перед вводом в эксплуатацию

• Описан каждый реальный поток с source, destination, port и protocol.
• Зафиксирован ожидаемый интерфейс, шлюз, туннель или прокси.
• Созданы отдельные таблицы для независимых сетевых профилей.
• В каждой таблице есть connected-маршрут до шлюза.
• Gateway находится в правильной подсети и отвечает с нужного source address.
• Default route добавлен в правильную таблицу.
• Правила ip rule имеют понятные priority и не перекрывают узкие правила широкими условиями.
• Проверены маршруты с командами ip route get ... from ....
• Проверен фактический интерфейс выхода через tcpdump и трассировку.
• Маршрут до VPN endpoint не зацикливается через туннель.
• Удаленная сеть знает обратный маршрут к исходной подсети.
• Проверены NAT, firewall, security groups и reverse path filtering.
• Порт сервиса открыт, а процесс слушает нужный IP-адрес.
• Авторизация приложения проверена после сетевого теста.
• Виртуальный bridge, VLAN и маршруты на гипервизоре соответствуют схеме.
• Временные команды перенесены в NetworkManager, systemd-networkd, Netplan или другой используемый менеджер.
• Конфигурация проверена после reload и reboot.

Рабочая схема multi-homing строится вокруг потока, а не вокруг количества интерфейсов. Сначала определите source и destination, затем выберите правило, таблицу, шлюз и обратный путь. После этого подтвердите решение ядра и фактическое прохождение пакетов, а firewall и приложение проверяйте отдельными шагами.