LINUX.ORG.RU
решено ФорумAdmin

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

 , ,


0

2

Допустим, есть 3 интерфейса, eth0, eth1, eth2.
eth0 и eth1 с интернетами, на eth2 нужно раздать, сделать NAT.

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

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

Rule-based routing?

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)

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

Так?

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

ZeroNight ()
Ответ на: комментарий от ZeroNight

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

iliyap ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

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

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

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

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

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

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

Отдельная виртуалка? Проще? Месье знает толк. 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, только она тебе ничем не поможет, если ты оным не пользуешься.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

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

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

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

  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 <много>
    
intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Выглядит, как какие-то костыли. Видимо, 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

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

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

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

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

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

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

TheAnonymous ★★★★★ ()
Ответ на: комментарий от TheAnonymous

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.