Хотя это не указано явно, я предполагаю, что цель состоит в том, чтобы разделить трафик таким образом, чтобы:

• Трафик 172.16.0.0/24 проходит через enp1s0f1
• 10.0.0.0/24 трафик проходит через enp4s0f0

Как писал OP, для этого нужна маршрутизация на основе политики/источника -.iptables и netfilter редко бывают полезны (по крайней мере сами по себе):

• вообще говоря iptables и netfilter не маршрутизируют и не заботятся о маршрутах. Маршруты стека сетевой маршрутизации. Некоторые из действий iptables по-прежнему будут вызывать изменения решения о маршрутизации (, как описано в этой схеме )
.
• любое действие, выполненное в POSTOUTING , как следует из названия, происходит после принятия решений о маршрутизации :слишком поздно менять маршрут. Здесь, хотя правило nat/POSTROUTING необходимо, они не изменят маршрут.

Всякий раз, когда можно избежать iptables для решения проблемы маршрутизации, лучше этого не делать. Иногда этого не избежать (и тогда обычно iptables используется для добавления метки к пакетам и эта метка используется в записи ip rule).

Маршруты

Я предполагаю, чтоrp_filter=1установлено на всех интерфейсах, так как это значение по умолчанию для большинства дистрибутивов, чтобы включить Strict Reverse Path Forwarding .

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

В своем ответе я не буду отдавать предпочтение той или иной сети :каждая будет иметь свою собственную таблицу маршрутизации. Я забуду таблицу 1 и буду использовать таблицы 10 для LAN 10.0.0.0/24 и 172 для LAN 172.16.0.0/24. Сохраните правила NAT, удалите правила и дополнительные таблицы маршрутизации, а также 192.168.0.1 dev enp4s0f0 scope linkиз основного.

1. Маршруты для 10.0.0.0/24 < --> 10.0.0.6 enp4s0f0 | enp4s0f1 192.168.0.6 < --> 192.168.0.1/по умолчанию:

    ip rule add from 10.0.0.0/24 lookup 10
    ip route add table 10 10.0.0.0/24 dev enp4s0f1
    ip route add table 10 192.168.0.0/24 dev enp4s0f0 src 192.168.0.6
    ip route add table 10 default via 192.168.0.1
   

Выше, без дублированной записи маршрута для 10.0.0.0/24, система не сможет сама получить доступ к этой локальной сети :она решит, что маршрут должен проходить через шлюз по умолчанию, только для Strict Reverse Path Forwarding(Цель SRPF )затрудняет отладку. Это пример плохой вещи, если ее не добавить. Если сомневаетесь, просто продублируйте маршруты.

Другим эквивалентным вариантом могло бы быть вместо дополнительного маршрута изменить правило выше на:

    ip rule add from 10.0.0.0/24 iif enp4s0f1 lookup 10

, поэтому он не будет соответствовать локальному (не-маршрутизируемому )трафику, и будет использоваться только основная таблица.

2. Маршруты для 172.16.0.0/24 < --> 172.16.0.3 enp1s0f0 | enp1s0f1 192.168.0.3 < --> 192.168.0.1/по умолчанию:

    ip rule add from 172.16.0.0/24 lookup 172
    ip route add table 172 172.16.0.0/24 dev enp1s0f0
    ip route add table 172 192.168.0.0/24 dev enp1s0f1 src 192.168.0.3
    ip route add table 172 default via 192.168.0.1
   

3. Чтобы также изменить маршрут (ссылку )для локально инициированного исходящего трафика при изменении исходящего исходного IP-адреса в системе Linux. Это должно быть необязательным, но следующая часть о потоке ARP делает его обязательным :

   .

    ip rule add from 192.168.0.6 lookup 10
    ip rule add from 192.168.0.3 lookup 172
   

4. Любой не -особый случай, связанный с переопределенными маршрутами из правил, также должен быть продублирован

Здесь отсутствуют только маршруты между двумя специальными локальными сетями:

в таблице 10 для достижения 172.16.0.0/24
в таблице 172 для достижения 10.0.0.0/24

поскольку каждая дополнительная таблица еще не имеет маршрута для этой другой стороны, она будет использовать маршрут по умолчанию (, но будет снова заблокирована SRPF ), не позволяя каждой из двух специальных сетей взаимодействовать между собой. друг друга. Так что просто дублируйте отсутствующий маршрут для каждой таблицы:

    ip route add table 10 172.16.0.0/24 dev enp1s0f0
    ip route add table 172 10.0.0.0/24 dev enp4s0f1

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

С маршрутами все в порядке, но есть еще...

Проблема потока ARP

Linux использует модель слабого хоста . Это относится к IP-маршрутизации, а также к тому, как Linux отвечает на запросы ARP :с любого интерфейса для любого IP, но, конечно, с использованием собственного MAC-адреса интерфейса. Поскольку это может произойти на всех интерфейсах одновременно, когда несколько интерфейсов находятся в одной и той же локальной сети, обычно выигрывает самый быстрый. Затем информация ARP кэшируется на удаленной системе и остается там некоторое время. В конце концов срок действия кеша истекает, происходит то же самое, но с возможным другим исходом. Итак, как это вызывает проблему? Вот пример:

• Маршрутизатор (модем )отправляет запрос ARP для 192.168.0.6 для отправки обратно маршрутизируемого и NAT-(Linux )ответа на трафик, первоначально отправленный с 10.0.0.0/24.
• Linux отвечает на enp1s0f1(enp1s0f1 выиграл гонку ), используя MAC-адрес enp1s0f1 в ответ, чтобы сообщить, что у него есть 192.168.0.6.
• Будущие входящие IP-пакеты от маршрутизатора для адреса 192.168.0.6 в течение от нескольких секунд до нескольких минут поступают на enp1s0f1 ,
• при этом исходящие пакеты с 192.168.0.6 уходят по enp4s0f0 .

Эта асимметричная маршрутизация перехватывается Strict Reverse Path Forwarding (rp_filter), и трафик не проходит. Может даже показаться, что это работает случайным образом в течение нескольких секунд, а затем снова выходит из строя. В зависимости от общего трафика проблема может даже позже переключиться на другую ссылку (, а затем проблема переключится на другую локальную сеть ).

К счастью, для предотвращения этого в Linux предусмотрен параметр, который можно использовать только вместе с маршрутизацией на основе политик, чтобы ARP следовал тем же правилам, которые определены маршрутизацией:arp_filter.

arp_filter - BOOLEAN

1 - Allows you to have multiple network interfaces on the same subnet, and have the ARPs for each interface be answered based on whether or not the kernel would route a packet from the ARP'd IP out that interface (therefore you must use source based routing for this to work). In other words it allows control of which cards (usually 1) will respond to an arp request.

sysctl -w net.ipv4.conf.enp4s0f0.arp_filter=1
sysctl -w net.ipv4.conf.enp1s0f1.arp_filter=1

Теперь поведение ARP правильное, если настройки были только что установлены, следует принудительно -сбросить кэш ARP пиров(здесь :модем ), выполнив обнаружение дубликатов адресов с помощьюarping(из iputils / iputils -arping ), которые будут транслировать одноранговым узлам и заставлять их обновлять свой кэш:

arping -c 5 -I enp4s0f0 -D -s 192.168.0.6 192.168.0.6 &
arping -c 5 -I enp1s0f1 -D -s 192.168.0.3 192.168.0.3

Обратите внимание, что два правила в пункте 3. в предыдущей части теперь являются обязательными, поскольку IP-адреса 192.168.0.3 и 192.168.0.6 должны совпадать в правилах политик маршрутизации для правильного разрешения ARP с arp_filter=1.

Как отлаживать

ip route getочень полезно для проверки маршрутов и фильтрации обратных путей:

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

# ip route get from 10.0.0.111 iif enp4s0f0 172.16.0.111
172.16.0.111 from 10.0.0.111 dev enp1s0f0 table 10 
    cache iif enp4s0f0 
# ip route get from 172.16.0.111 iif enp1s0f0 to 10.0.0.111
10.0.0.111 from 172.16.0.111 dev enp4s0f1 table 172 
    cache iif enp1s0f0 

при удалении правил или маршрутов:

# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp4s0f0 table 10 
    cache iif enp4s0f1 
# ip rule del from 10.0.0.0/24 lookup 10
# ip route get from 10.0.0.111 iif enp4s0f1 8.8.8.8
8.8.8.8 from 10.0.0.111 via 192.168.0.1 dev enp1s0f1
    cache iif enp4s0f1
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
local 192.168.0.6 from 192.168.0.1 dev lo table local
    cache <local> iif enp4s0f0
# ip rule delete from 192.168.0.6 lookup 10
# ip route get from 192.168.0.1 iif enp4s0f0 192.168.0.6
RTNETLINK answers: Invalid cross-device link

Здесь показано, как меняются результаты в зависимости от (отсутствия )правил и дополнительных маршрутов. Последним результатом является сообщение об ошибке, в котором говорится, что проверка переадресации обратного пути не удалась (=> удалить ).

Затем естьip neigh(наиболее полезные в одноранговых системах )для проверки записей ARP, tcpdumpи т. д.