NAT через другой интерфейс

Как всё настроить так, чтобы на хосте трафик шел через eth0, а с NAT через eth1?

Rule-based routing?

Допустим, дефолтный маршрут через eth0, но тогда и через NAT всё будет идти туда?

Два дефолтных маршрута, каждый с правилами по source IP.

Допустим, дефолтный маршрут через eth0, но тогда и через NAT всё будет идти туда?

Так?

iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth1 -j MASQUERADE

-o не назначает выходной интерфейс, а матчит выходной интерфейс. В таблице nat цепочке POSTROUTING выходной интерфейс уже определен по таблице маршрутизации и изменению не подлежит. На то он и *POST*ROUTING. Intelfx прав, надо делать rule based routing.

Понял. Спасибо за разъяснение.

А есть какая-нибудь более-менее простая инструкция, как это всё настроить в современных линуксах (например, debian)?

И чтобы потом всякие умные системд не сбросили всё так, как им показалось более лучше, и внезапно не пустили трафик туда, куда не надо, например, когда что-то отвалилось

TBH, без понятия. Вообще man ip-rule (ну или google://linux policy-based routing), а куда это прописывать в твоём дистрибутиве — я не расскажу, потому что дебианом не пользуюсь.

И чтобы потом всякие умные системд не сбросили всё так, как им показалось более лучше, и внезапно не пустили трафик туда, куда не надо, например, когда что-то отвалилось

Конкретно «всякие умные системд» ничего никуда не сбросят, если ты не попросишь.

В общем, я так прикидываю, более-менее простой вариант будет - сделать отдельную виртуалку, туда прокинуть нужные интерфейсы, и сделать NAT через неё.

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

дебиан для примера, в принципе, хоть пойдёт рач

ничего никуда не сбросят, если ты не попросишь

а хз, вот в resolved где-то гугловские сервера захардкожены, и в каких-то случаях может тихо фоллбечить на них. Может и тут какие сюрпризы.
Ну и под «всякие умные systemd» я здесь понимаю не только сам инит и обвязку, а ещё всякие разные network manager и прочие поделки

Отдельная виртуалка? Проще? Месье знает толк. Rule-based routing в твоём случае уложится в две команды (в теории, не проверял):

ip rule add iif eth2 table 42
ip route add default table 42 via ... dev eth1
ip route add default via ... dev eth0 # обычный дефолтный маршрут, должен быть добавлен твоим сетевым менеджером

А куда это класть — не знаю. Арч для примера не подойдёт, потому что у него нет никаких «штатных» утилит управления сетью. Могу привести конфигурацию для systemd-networkd, только она тебе ничем не поможет, если ты оным не пользуешься.

Вот, если eth1 отрубается, маршрут из таблицы выкидывается, и будет роутиться через дефолтный шлюз eth0.
Конечно, можно прибить это через iptables, разрешить только явно форвардинг, но может, есть более нормальное решение?

Три решения на выбор, в порядке убывания субъективной красоты:

1. Добавить unreachable-правило для iif eth2 с меньшим (т. е. численно большим) приоритетом:

   ip rule add iif eth2 priority 10 table 42 # было
   ip rule add iif eth2 priority 11 unreachable # новое
   

2. Добавить основной default-маршрут не в таблицу main, а в отдельную таблицу:

   ip rule add iif lo table 43
   ip route add default table 43 via ... dev eth0 # заставить сетевой менеджер пихать дефолтный маршрут сюда
   

3. Добавить в таблицу 42 unreachable-маршрут с большей метрикой:

   ip route add unreachable default table 42 metric <много>
   

Выглядит, как какие-то костыли. Видимо, iptables более нормальный вариант, тем более, всё равно нужно использовать для поднятия самого NAT.

Но само решение рабочее, благодарю.
А чтобы прописать маршруты в debian, можно указать команды в post-up к соответствующим интерфейсам, примерно так

iface eth2...
...
  post-up ip rule add iif eth2 table 42

iface eth1...
...
  post-up ip route add default table 42 via ... dev eth1

Выглядит, как какие-то костыли. Видимо, iptables более нормальный вариант

iptables медленнее (и что-что, а использовать iptables для управления маршрутизацией — точно костыль).

А ещё можно удалить умолчальное правило, направляющее трафик в таблицу main, и добавить вместо него точно такое же правило с iif lo. Это будет означать, что любые маршруты в main таблице будут использоваться только для локально сгенерированных пакетов.

По-моему, это как раз «правильный» путь и есть.

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

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

Как хочешь. ИМХО, использовать для этих целей таблицы маршрутизации — правильнее.