Несколько сетевых интерфейсов в Linux: адресация, маршрутизация и выбор исходного IP-адреса

Короткий ответ: как настроить несколько сетевых интерфейсов в Linux

Каждому сетевому интерфейсу Linux назначают IP-адрес из подсети, к которой он подключен. После назначения адреса ядро обычно добавляет маршрут к этой непосредственно подключенной сети. Для удаленных сетей задают статические маршруты через доступный шлюз.

В простой схеме один интерфейс обслуживает локальную сеть, второй подключает сервер к Интернету. Локальные маршруты идут через первый интерфейс, а в таблице main остается один основной маршрут по умолчанию через второй шлюз. Два независимых шлюза по умолчанию требуют отдельного проектирования. Если трафик нужно разделить по исходному IP-адресу, применяют policy-based routing с командами ip rule и дополнительными таблицами.

Три уровня настройки: адрес, маршрут и правило

Уровень	Что задает	Пример проверки
IP-адрес и префикс	Принадлежность интерфейса к подсети и диапазон непосредственно доступных адресов	`ip addr show dev ens160`
Маршрут	Путь к сети назначения через интерфейс или шлюз	`ip route`
Правило маршрутизации	Выбор таблицы по источнику, назначению, входному интерфейсу или метке пакета	`ip rule`

IP-адрес 10.10.0.10/24 добавляет интерфейс в сеть 10.10.0.0/24. Второй адрес 10.20.0.10/24 добавляет отдельную подключенную сеть. Само наличие второго адреса не создает маршрут для всего исходящего трафика через второй интерфейс.

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

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

connected routes к сетям, подключенным напрямую;
статические маршруты к удаленным локальным сетям;
один default route через главный шлюз;
метрики для приоритета маршрутов при простом резервировании.

Policy-based routing требуется, когда у сервера два независимых провайдера, сервисы привязаны к разным IP-адресам, ответы должны возвращаться через тот же канал или выбор пути зависит от источника и назначения. Ключевые команды для первичной проверки: ip addr, ip route, ip route get и ip rule.

Проверка текущей конфигурации перед изменениями

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

Как определить интерфейсы, адреса и состояние link

Краткий список интерфейсов и их состояние показывает команда:

ip -br link

Для одновременного просмотра интерфейсов и IP-адресов используйте:

ip -br addr

В выводе проверьте состояние UP, наличие адресов IPv4 и IPv6, префиксы и соответствие физическим портам. В Linux имя интерфейса может выглядеть как ens160, enp1s0, eno1 или bond0. Имя eth0 не считается универсальным.

Bridge, VLAN и bonding нужно отличать от физических NIC. Подробные параметры можно посмотреть так:

ip -d link show
ip addr show
bridge link
ip -d link show type vlan

Если интерфейс включен, но физический линк отсутствует, проверьте состояние кабеля, виртуального адаптера, VLAN и коммутатора. Для Ethernet-порта дополнительно пригодится ethtool ens160.

Как посмотреть маршруты и правила

Основная таблица маршрутизации отображается командой:

ip route
ip route show table main

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

ip rule
ip route show table all

В стандартной конфигурации обычно видны три правила:

приоритет 0 обращается к таблице local;
приоритет 32766 использует таблицу main;
приоритет 32767 обращается к таблице default.

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

ip route get 10.30.2.15
ip route get 203.0.113.20 from 10.10.0.10

Как определить, чем управляется сеть

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

systemctl is-active NetworkManager
systemctl is-active systemd-networkd
networkctl status
nmcli connection show
ls -l /etc/netplan/

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

Команды ip addr add и ip route add используйте для временной проверки. После успешного теста перенесите параметры в NetworkManager, netplan или systemd-networkd.

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

Адрес, префикс, шлюз и физический VLAN должны описывать одну и ту же сеть. Ошибка в префиксе меняет connected route и может направить ARP или ответный пакет через неправильный интерфейс.

IP-адрес и префикс должны соответствовать физической сети

Предположим, сервер подключен к двум разным L2-сегментам:

ens160 подключен к сети 10.10.0.0/24 и получает адрес 10.10.0.10/24;
ens192 подключен к сети 10.20.0.0/24 и получает адрес 10.20.0.10/24.

Префикс /24 соответствует маске 255.255.255.0. Система добавит маршруты примерно такого вида:

10.10.0.0/24 dev ens160 proto kernel scope link src 10.10.0.10
10.20.0.0/24 dev ens192 proto kernel scope link src 10.20.0.10

Адрес 10.20.0.10/24 на интерфейсе, физически подключенном к сети 10.10.0.0/24, не делает этот порт участником сети 10.20.0.0/24. Коммутатор, VLAN и префикс должны совпадать с топологией.

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

Подключение двух NIC к одной подсети, например 10.10.0.0/24, без bonding, bridge или продуманной multihoming-схемы создает неоднозначность. Ядро может ответить на ARP-запрос через интерфейс, который не связан с реальным путем к соседнему узлу. Такой эффект часто называют ARP flux.

Проблемы проявляются в виде:

MAC-адрес одного интерфейса появляется на порту, связанном с другим интерфейсом;
ответы на входящие соединения уходят через другой NIC;
строгая проверка обратного пути отбрасывает пакеты;
firewall видит соединение на одном интерфейсе, а ответ приходит на другом.

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

Временное назначение адреса для проверки

Включите интерфейс и назначьте адрес на время теста:

sudo ip link set dev ens160 up
sudo ip addr add 10.10.0.10/24 dev ens160
ip addr show dev ens160

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

sudo ip addr replace 10.10.0.10/24 dev ens160

Проверьте соседний узел с принудительным выбором интерфейса или исходного адреса:

ping -I ens160 -c 3 10.10.0.1
ping -I 10.10.0.10 -c 3 10.10.0.1

После теста удалите адрес:

sudo ip addr del 10.10.0.10/24 dev ens160

Изменения, внесенные через ip, не переживают перезагрузку. Не считайте временную проверку постоянной настройкой.

Таблицы маршрутизации Linux: маршруты, метрики и шлюзы

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

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

Маршрут к конкретной сети выглядит так:

10.30.0.0/16 via 10.10.0.1 dev ens160

Он отправляет адреса из сети 10.30.0.0/16 через шлюз 10.10.0.1 и интерфейс ens160. Маршрут по умолчанию может выглядеть так:

default via 10.20.0.1 dev ens192

Ядро сначала учитывает правила policy routing. После выбора таблицы оно ищет самый специфичный префикс. Маршрут 10.30.0.0/16 приоритетнее 0.0.0.0/0, потому что точнее описывает назначение. Если совпадает несколько маршрутов с одинаковым префиксом, учитывается метрика и другие параметры.

Маршрут через шлюз допустим, когда шлюз достижим через интерфейс. Для сети из примера это значит, что у ens160 должен существовать connected route к 10.10.0.0/24. Параметр onlink применяйте только при подтвержденной L2-доступности шлюза, иначе он скрывает ошибку в адресации.

Почему не стоит бездумно добавлять два шлюза по умолчанию

Два default route с одинаковым приоритетом могут привести к распределению маршрутов между каналами. Ответный трафик TCP при этом способен уйти через другой адрес или шлюз. Stateful firewall, NAT и удаленный провайдер часто воспринимают такой путь как нарушение состояния соединения.

Разные метрики подходят для простой схемы приоритетного failover:

default via 10.20.0.1 dev ens192 metric 100
default via 10.30.0.1 dev ens224 metric 200

Пока доступны оба маршрута, ядро выбирает маршрут с метрикой 100. Метрика не проверяет Интернет, удаленный сервис или состояние upstream. При отказе шлюза маршрут может остаться в таблице и продолжить получать пакеты.

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

Параметр `src` и предпочтительный исходный адрес

Параметр src задает предпочтительный исходный адрес для новых соединений:

sudo ip route replace default via 10.20.0.1 dev ens192 src 10.20.0.10

После такой настройки ядро предпочитает адрес 10.20.0.10, если приложение не задало другой source address через bind() или собственную настройку. Поле src не выбирает таблицу и не заменяет ip rule. Для двух независимых шлюзов нужны правила, которые связывают исходный адрес с нужной таблицей.

Сценарий: локальная сеть через один интерфейс, Интернет через другой

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

Схема адресов и ожидаемые маршруты

Интерфейс	IP-адрес	Назначение	Шлюз
`ens160`	`10.10.0.10/24`	Локальная сеть `10.10.0.0/24`, удаленная сеть `10.30.0.0/16`	`10.10.0.1` для удаленной локальной сети
`ens192`	`10.20.0.10/24`	Внешний канал	`10.20.0.1` для default route

После назначения адресов ожидайте connected routes к 10.10.0.0/24 и 10.20.0.0/24. В основной таблице должен остаться один default route через 10.20.0.1. Локальный интерфейс не должен добавлять свой шлюз по умолчанию.

Для лабораторного стенда с двумя виртуальными NIC подойдет облачный VDS, например Timeweb Cloud. Перед настройкой проверьте, какие подсети и шлюзы провайдер назначил конкретному серверу.

Настройка маршрутов командой `ip route`

Временная настройка для указанной схемы:

sudo ip route replace 10.10.0.0/24 dev ens160 src 10.10.0.10
sudo ip route replace 10.20.0.0/24 dev ens192 src 10.20.0.10
sudo ip route replace 10.30.0.0/16 via 10.10.0.1 dev ens160
sudo ip route replace default via 10.20.0.1 dev ens192 src 10.20.0.10 metric 100

Если connected routes появились автоматически, первые две команды не нужны. Начните с проверки:

ip route show dev ens160
ip route show dev ens192
ip route

Проверьте доступность шлюзов до тестирования удаленных сетей:

ping -I ens160 -c 3 10.10.0.1
ping -I ens192 -c 3 10.20.0.1

Маршрут к удаленной локальной сети должен идти через ens160:

ip route get 10.30.2.15

Ожидаемый результат содержит via 10.10.0.1 dev ens160. Внешнее назначение должно использовать второй интерфейс:

ip route get 203.0.113.20

Ожидайте via 10.20.0.1 dev ens192 src 10.20.0.10. Если команда показывает другой NIC, сначала исправьте таблицу маршрутизации и только потом проверяйте приложение.

Проверка разделения трафика

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

ping -I ens160 -c 3 10.30.2.15
sudo tcpdump -ni ens160 host 10.30.2.15

Для внешнего канала:

ping -I 10.20.0.10 -c 3 203.0.113.20
sudo tcpdump -ni ens192 host 203.0.113.20

Если ICMP запрещен, отсутствие ответа не доказывает ошибку маршрутизации. Проверьте реальный порт приложения с помощью ss, curl --interface или тестового клиента. В захвате должны быть видны исходящие пакеты на ожидаемом интерфейсе, ARP к нужному шлюзу и ответы от удаленной стороны.

Policy-based routing и выбор исходного IP-адреса Linux

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

Когда нужен source-based routing

У сервера два провайдерских канала с независимыми шлюзами.
Адрес 10.10.0.10 должен выходить через шлюз 10.10.0.1, а адрес 10.20.0.10 через 10.20.0.1.
Сервисы слушают разные IP-адреса и должны отвечать через соответствующие интерфейсы.
Входящий запрос пришел через один канал, поэтому SYN-ACK должен вернуться через тот же канал.
Маршрутизация зависит от исходной сети, назначения, входного интерфейса или firewall mark.

Если нужен единственный Интернет-шлюз и несколько локальных сетей, source-based routing добавляет лишнюю сложность. Сначала проверьте, решает ли задачу маршрут к конкретной подсети или один default route.

Отдельные таблицы маршрутов и правила `ip rule`

Назначьте имена таблицам в файле /etc/iproute2/rt_tables. Добавьте строки:

100 isp_a
200 isp_b

Создайте в каждой таблице connected route и default route. Шлюз должен находиться в той же таблице и быть достижимым через соответствующий интерфейс:

sudo ip route replace 10.10.0.0/24 dev ens160 src 10.10.0.10 table isp_a
sudo ip route replace default via 10.10.0.1 dev ens160 src 10.10.0.10 table isp_a
sudo ip route replace 10.20.0.0/24 dev ens192 src 10.20.0.10 table isp_b
sudo ip route replace default via 10.20.0.1 dev ens192 src 10.20.0.10 table isp_b

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

sudo ip rule add pref 100 from 10.10.0.10/32 table isp_a
sudo ip rule add pref 110 from 10.20.0.10/32 table isp_b
ip rule

Меньшее значение pref означает более высокий приоритет. Правила с приоритетами 100 и 110 выполняются после таблицы local с приоритетом 0, но перед стандартной таблицей main с приоритетом 32766.

В policy table добавляйте маршруты ко всем внутренним сетям, которые должны обходить провайдерский default route. Иначе пакет с исходным адресом 10.10.0.10 к внутренней сети может попасть под default route таблицы isp_a и уйти к провайдеру.

После добавления правил проверьте каждую комбинацию источника и назначения:

ip route get 203.0.113.20 from 10.10.0.10
ip route get 203.0.113.20 from 10.20.0.10
ip route show table isp_a
ip route show table isp_b

В первом результате ожидайте dev ens160 via 10.10.0.1 src 10.10.0.10, во втором dev ens192 via 10.20.0.1 src 10.20.0.10. Подробная схема создания профиля маршрутизации и диагностики policy routing приведена в статье о профиле маршрутизации для нескольких интерфейсов Linux.

Команды ip rule add не проверяют, существует ли такое правило. Повторный запуск может создать дубликаты. Перед изменениями смотрите ip rule list, а для удаления используйте точное правило:

sudo ip rule del pref 100 from 10.10.0.10/32 table isp_a

Проверка выбранного исходного адреса

Команда ip route get с параметром from показывает, как ядро обработает пакет с заданным источником:

ip route get 203.0.113.20 from 10.10.0.10
ip route get 203.0.113.20 from 10.20.0.10

Проверяйте четыре поля: dev, via, src и выбранную таблицу, если она выводится в конкретной версии iproute2.

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

curl --interface 10.10.0.10 --connect-timeout 5 service-hostname
curl --interface 10.20.0.10 --connect-timeout 5 service-hostname
ss -tnp

Если приложение само вызывает bind() и выбирает source address, системный маршрут не сможет заменить этот выбор. Для сервисов с несколькими адресами задайте явный listen или bind address в конфигурации приложения.

Особенности входящих соединений и ответного трафика

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

Проверьте всю цепочку:

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

Сервер может принять SYN через ens160, но отправить SYN-ACK через ens192, если таблица main содержит единственный default route через второй шлюз. Внешне это выглядит как недоступный порт, хотя процесс слушает правильный адрес.

Резервирование каналов: метрики, failover и ограничения

Резервный канал решает другую задачу, чем policy-based routing. В первом случае нужен выбор работоспособного пути, во втором, разделение трафика по заданному признаку.

Основной и резервный default route

Минимальная схема с приоритетом маршрутов:

sudo ip route replace default via 10.20.0.1 dev ens192 metric 100
sudo ip route add default via 10.30.0.1 dev ens224 metric 200
ip route

При наличии обоих маршрутов Linux выбирает метрику 100. Если основной интерфейс получает состояние DOWN или маршрут удаляется сетевым менеджером, активным становится путь с метрикой 200.

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

Проверка доступности шлюза и внешнего назначения

Проверяйте несколько точек:

локальный шлюз, например 10.20.0.1;
следующий узел после шлюза;
контрольный внешний адрес;
реальный сервис и его TCP-порт.

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

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

ip monitor route
ip monitor rule
ip monitor link

Когда нужен bonding или специализированный менеджер

Задача	Подход	Что получает система
Единый логический канал из нескольких физических портов	Bonding	Один логический интерфейс и выбранный режим агрегации или резервирования
Несколько равнозначных путей к одной сети	Multipath или ECMP	Выбор между маршрутами с одинаковым назначением
Разделение трафика по исходному IP или назначению	Policy-based routing	Разные таблицы и правила для разных потоков
Управление профилями, метриками и health check	NetworkManager или отдельный сетевой контроллер	Постоянные настройки и автоматическая смена маршрута

Bonding не заменяет два независимых провайдерских шлюза. Policy routing не объединяет физические порты в один канал. Выбирайте механизм по требованию: один логический интерфейс, балансировка, резервирование или разделение трафика.

Постоянная настройка через NetworkManager, netplan и systemd-networkd

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

NetworkManager и `nmcli`

Сначала найдите точные имена профилей:

nmcli connection show
nmcli device status

Для простой схемы без default route на локальном интерфейсе используйте профиль подключения, а не только имя NIC:

sudo nmcli connection modify LAN ipv4.method manual ipv4.addresses 10.10.0.10/24 ipv4.never-default yes
sudo nmcli connection modify LAN +ipv4.routes '10.30.0.0/16 10.10.0.1'
sudo nmcli connection modify WAN ipv4.method manual ipv4.addresses 10.20.0.10/24 ipv4.gateway 10.20.0.1 ipv4.route-metric 100
sudo nmcli connection up LAN
sudo nmcli connection up WAN

Если профиль получает параметры по DHCP, проверьте, не добавляет ли DHCP второй default route. Для статической адресации задайте ipv4.method manual, адрес, шлюз и DNS явно. Сохраненные параметры можно проверить так:

nmcli connection show LAN
nmcli connection show WAN
nmcli -f ipv4.addresses,ipv4.routes,ipv4.route-metric,ipv4.routing-rules connection show LAN

В актуальных версиях NetworkManager для policy routing доступны свойства ipv4.route-table и ipv4.routing-rules. Типовой принцип выглядит так:

sudo nmcli connection modify LAN ipv4.route-table 100
sudo nmcli connection modify LAN +ipv4.routes '10.10.0.0/24 0.0.0.0'
sudo nmcli connection modify LAN +ipv4.routes '0.0.0.0/0 10.10.0.1'
sudo nmcli connection modify LAN +ipv4.routing-rules 'priority 100 from 10.10.0.10/32 table 100'

Синтаксис свойств зависит от версии NetworkManager. После изменения проверьте таблицу командой ip route show table 100 и фактический выбор через ip route get.

Netplan и systemd-networkd

Netplan хранит декларативное описание сети в YAML и передает его выбранному renderer. Для policy routing пример может выглядеть так:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens160:
      addresses:
        - 10.10.0.10/24
      routes:
        - to: 10.10.0.0/24
          scope: link
          table: 100
        - to: 10.30.0.0/16
          via: 10.10.0.1
          table: 100
        - to: default
          via: 10.10.0.1
          table: 100
      routing-policy:
        - from: 10.10.0.10/32
          table: 100
          priority: 100
    ens192:
      addresses:
        - 10.20.0.10/24
      routes:
        - to: 10.20.0.0/24
          scope: link
          table: 200
        - to: default
          via: 10.20.0.1
          table: 200
      routing-policy:
        - from: 10.20.0.10/32
          table: 200
          priority: 110

В новых конфигурациях netplan маршрут по умолчанию задают через routes. Старый параметр gateway4 в некоторых версиях помечен как устаревший. Перед применением проверьте YAML и используйте временный режим:

sudo netplan generate
sudo netplan try
sudo netplan apply

systemd-networkd использует файлы с секциями [Match], [Network], [Route] и [RoutingPolicyRule]. Минимальный профиль для таблицы 100:

[Match]
Name=ens160

[Network]
Address=10.10.0.10/24

[Route]
Destination=10.10.0.0/24
Scope=link
Table=100

[Route]
Destination=10.30.0.0/16
Gateway=10.10.0.1
Table=100

[Route]
Destination=0.0.0.0/0
Gateway=10.10.0.1
Table=100

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

Для второго интерфейса создайте аналогичный профиль с адресом 10.20.0.10/24, таблицей 200, шлюзом 10.20.0.1 и правилом с приоритетом 110. После перезапуска сервиса проверьте networkctl status, ip rule и ip route show table all.

Безопасное применение на удаленном сервере

Изменение default route может немедленно оборвать SSH. Перед применением подготовьте:

консоль гипервизора или out-of-band-доступ;
второе SSH-соединение, открытое до изменений;
резервную копию файла netplan, профиля NetworkManager или файла networkd;
команды отката с прежним адресом, шлюзом и маршрутом;
окно обслуживания, если сервер обслуживает рабочие соединения.

Сначала применяйте один параметр, затем проверяйте ip route get. Не удаляйте старый маршрут, пока не убедились, что новый шлюз отвечает и обратный путь работает. После смены профиля проверьте SSH, DNS, доступ к локальным сетям и исходящий TCP.

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

Ищите проблему по цепочке: выбор маршрута, правило, соседний узел, сокет, фактический пакет, обратный путь и firewall. Проверка одной команды ip route не показывает все причины.

Проверка результата через `ip route get`

Начните с маршрута к реальному адресу назначения:

ip route get 10.30.2.15
ip route get 203.0.113.20
ip route get 203.0.113.20 from 10.10.0.10
ip route get 203.0.113.20 from 10.20.0.10

Сопоставьте результат с ожидаемой схемой:

dev показывает выбранный интерфейс;
via показывает шлюз;
src показывает выбранный исходный адрес;
отсутствие маршрута указывает на ошибку в таблице или policy rule.

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

Проверка правил, соседей и сокетов

Проверьте порядок правил:

ip rule list
ip route show table main
ip route show table 100
ip route show table 200

Затем проверьте ARP и состояния соседей:

ip neigh show
ip neigh show dev ens160
ip neigh show dev ens192

Состояние REACHABLE подтверждает недавнюю доступность соседа. STALE означает устаревшую, но допустимую запись. FAILED указывает на проблему ARP, VLAN, физического линка или шлюза.

Для проверки слушающих портов и активных соединений используйте:

ss -ltnp
ss -tnp

В локальном адресе сокета ищите конкретный IP или wildcard-адрес. Если процесс слушает только 10.10.0.10:443, соединение на 10.20.0.10:443 не попадет в этот listener. Приложение может выбирать исходный адрес самостоятельно или явно привязывать сокет к интерфейсу.

Проверка фактического интерфейса через `tcpdump`

Захват пакетов отделяет ошибку маршрутизации от проблем firewall и приложения:

sudo tcpdump -ni ens160 host 10.30.2.15
sudo tcpdump -ni ens192 host 203.0.113.20
sudo tcpdump -ni ens160 arp
sudo tcpdump -ni any port 443

Интерпретируйте результат по этапам:

SYN виден на ожидаемом интерфейсе, но ответа нет. Проверяйте удаленный firewall, обратный маршрут и доступность сервиса.
SYN уходит через неправильный NIC. Проверяйте ip route get, ip rule, метрику и источник адреса.
ARP-запрос идет к неправильному шлюзу. Проверяйте префикс, connected route и привязку шлюза к интерфейсу.
SYN-ACK приходит, но ядро или приложение не отвечает. Проверяйте rp_filter, firewall и listener.

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

Асимметричная маршрутизация и `rp_filter`

Асимметрия возникает, когда пакет приходит через ens160, а обратный маршрут до его источника указывает на ens192. Она может появиться из-за двух default route, отсутствия обратного маршрута, NAT или policy rule с неправильным приоритетом.

Проверьте reverse path filtering:

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter
sysctl net.ipv4.conf.ens160.rp_filter
sysctl net.ipv4.conf.ens192.rp_filter

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

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

Проверьте фильтрацию:

sudo nft list ruleset
sudo iptables -S

Если пакет виден в tcpdump на входе, но не доходит до процесса, ищите правило firewall. Если сервер маршрутизирует трафик между сетями, проверьте IP forwarding и правила транзита. Для такой схемы пригодится отдельное руководство по маршрутизации между подсетями.

Типовые ошибки при настройке нескольких интерфейсов

Ошибка	Симптом	Проверка и исправление
Неверный IP или префикс	Шлюз недоступен, connected route охватывает лишние адреса	Сверьте `ip addr`, VLAN и маску. Проверьте `ip route get` к шлюзу.
Одинаковая подсеть на двух NIC	ARP и ответы появляются на неправильном интерфейсе	Разведите подсети или настройте bonding, bridge либо осознанную multihoming-схему.
Два default route с одинаковой метрикой	Путь меняется непредсказуемо, TCP и NAT работают нестабильно	Оставьте один default route или создайте отдельные таблицы с `ip rule`.
Шлюз недостижим через выбранный NIC	`RTNETLINK` сообщает ошибку или ARP остается в состоянии `FAILED`	Проверьте connected route, префикс и L2-доступность. Не используйте `onlink` для сокрытия ошибки.
Временный маршрут исчез после перезагрузки	Схема работает до restart сетевого сервиса	Перенесите адреса и маршруты в активный профиль NetworkManager, netplan или networkd.
Конфликт сетевых менеджеров	Ручные изменения перезаписываются, профиль возвращается к старому шлюзу	Определите активный менеджер и отключите дублирующее управление.
Приложение использует другой исходный адрес	`ip route get` показывает ожидаемый путь, но сервис выходит через другой IP	Проверьте `ss -tnp`, bind/listen-параметры, настройки приложения и IPv4/IPv6.
Нет обратного маршрута	Запрос доходит до сервера, ответ не возвращается клиенту	Проверьте маршруты на удаленной стороне, NAT, conntrack, firewall и `rp_filter`.
Тестируется IPv4, а приложение использует IPv6	Пакет уходит по другой схеме, чем показывает `ip route`	Проверьте `ip -6 route`, AAAA-записи и настройки клиента.

Итоговый чек-лист проверки конфигурации

Минимальный набор команд для финальной проверки

Команда	Какой вопрос закрывает
`ip -br link`	Все ли интерфейсы включены и поднят ли link
`ip -br addr`	Правильные ли IP-адреса и префиксы назначены
`ip route`	Какие connected routes и default route находятся в main
`ip rule`	В каком порядке применяются policy rules
`ip route show table all`	Есть ли маршруты в дополнительных таблицах
`ip route get DESTINATION from SOURCE_IP`	Какой dev, via и src выберет ядро
`ip neigh`	Разрешается ли MAC-адрес шлюза и соседних узлов
`ss -tnp`	Какой процесс создал соединение и какой локальный адрес использован
`ping -I SOURCE_IP DESTINATION`	Проходит ли базовая проверка с конкретного источника
`curl --interface SOURCE_IP --connect-timeout 5 service-hostname`	Может ли прикладной клиент использовать заданный адрес
`tcpdump -ni INTERFACE`	Через какой NIC фактически проходят пакеты

Что проверить после перезагрузки

Все интерфейсы имеют ожидаемое состояние UP.
IP-адреса и префиксы совпадают с проектной схемой.
Подключенные сети не пересекаются без специальной причины.
Локальные назначения используют нужные интерфейсы.
Основной default route выбран осознанно, а резервный имеет понятную метрику.
ip route get показывает ожидаемые dev, via и src.
Правила ip rule загружены с правильными приоритетами.
Шлюзы находятся в состоянии REACHABLE или корректно обновляются после первого запроса.
Ответный трафик возвращается через тот же канал, что и входящий запрос.
Firewall, NAT и rp_filter не отбрасывают легитимные пакеты.
DNS работает через ожидаемый интерфейс и не уводит приложение на IPv6-маршрут без проверки.
После имитации отказа основного канала новые соединения используют резервный маршрут.
После восстановления канала система возвращает основной маршрут согласно заданной политике.

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