Linux Advanced Routing: несколько аплинков (PBR) + port forwarding

А для rtk src в dgw специально не задан ?

а портфорвардинг на 192.168.255.2 точно работает ?

Может попробовать dual-nat ?

на первом канале

-t nat PREROUTING -d 95.84.198.125 -p tcp --dport X1 -j DNAT --to-destination 10.196.254.2:X1
-t nat POSTROUTING -d 10.196.254.2 -j SNAT --to-source 95.84.198.125

-t nat PREROUTING -d 192.168.255.2 -p tcp --dport X1 -j DNAT --to-destination 10.196.254.2:X1
-t nat POSTROUTING -d 10.196.254.2 -j SNAT --to-source 192.168.255.2

Но тогда 10.196.254.2 не узнает реальный внешний адрес (если вообще оно будет работать).

IMHO CONNMARK как раз нормальное решение, а не хак.

А для rtk src в dgw специально не задан ?

Так сгенерировал OpenWRT.

Меня это тоже напрягло, но ведь если preferred-src нет, то используется первый адрес на интерфейсе, с которого уходит пакет. Он там правильный, 192.168.255.2. Я попытался придумать пример, когда это не будет работать, но ничего не придумал. Можешь привести такой пример?

а портфорвардинг на 192.168.255.2 точно работает ?

Да, в каком-то смысле работает (так, как я описал выше).

Может попробовать dual-nat ?
...
Но тогда 10.196.254.2 не узнает реальный внешний адрес (если вообще оно будет работать).

Это должно работать, но да, тоже криво.

Просто вот в чём дело: когда роутер делает DNAT, он запоминает настоящий адрес назначения (т. е. свой адрес со стороны WAN) где-то в conntrack. Когда на роутер приходит ответ, он должен сделать ему «комплементарный» SNAT (заменить адрес отправителя со стороны локалки на свой адрес из WAN). В какой момент это происходит? До routing decision или после?

До routing decision или после?

А вам «POSTROUTING» ни о чём не намекает? Вначале произойдёт рутинг, с src «серым адресом», то есть зачастую там будет по дефолту, потом уже snat.

IMHO CONNMARK как раз нормальное решение, а не хак.

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

Я не совсем понимаю, как это работает.

Когда я явно делаю маскарад или SNAT, он происходит в POSTROUTING, это понятно. А когда на роутер приходит ответ на заDNAT-енный пакет, он ему делает обратный SNAT автомагически или это на самом деле всё тот же маскарад, который явно прописан?

Я не совсем понимаю, как это работает.

У вас есть возможность включить анализатор пакетов.

он ему делает обратный SNAT автомагически

Да, потому если второй канал допускает асимметричный рутинг, то есть разрешает прохождение пакетов с src другого провайдера, то пакеты таки будут ходить. SNAT же сработает, и поменяет src на белый.

или это на самом деле всё тот же маскарад, который явно прописан?

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

UPD:

SNAT же сработает, и поменяет src на белый

, вспомнив, какой он был. У dnat автомат snat, а не маскарад к исходящему интерфейсу.

У вас есть возможность включить анализатор пакетов

Да я тут с прошлого вечера сижу с tcpdump'ом. Только tcpdump не показывает, что творится внутри ядра.

Да, потому если второй канал допускает асимметричный рутинг, то есть разрешает прохождение пакетов с src другого провайдера, то пакеты таки будут ходить. SNAT же сработает, и поменяет src на белый.

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

Так да или нет? :) Или они оба в POSTROUTING происходят?

SNAT же сработает, и поменяет src на белый

, вспомнив, какой он был. У dnat автомат snat, а не маскарад к исходящему интерфейсу.

Ну вот я об этом и говорю. Если он такой умный, почему он происходит после routing decision?

Вообще моя исходная задача — поменять провайдера, но без даунтайма для сервера, который крутится в локалке за NAT'ом. План в том, чтобы настроить port forwarding для обоих провайдеров, потом поменять DNS, подождать сутки и потушить старый аплинк.

Но хотелось бы сделать обобщённо, чтобы потом заслать это в OpenWRT и избавить будущих недоадминов от этого головняка :)

Так да или нет? :) Или они оба в POSTROUTING происходят?

Не совсем понял вопроса, но я добавил следующим постом, так что может это будет теперь понятнее.

Если он такой умный, почему он происходит после routing decision?

Чтобы не делать бесконечный цикл и руками рисовать какие-то дополнительные правила «тут играть, тут не играть, тут рыбу заворачивали» проще всего было сделать так: nat/contract отвязан от рутинга, следовательно правильнее dnat до него, а snat - после. И они же у вас срабатывают. Только вам не нравится, что автомат snat не желает поменять исходящий интерфейс.

Да, теперь понятно: автоматический SNAT на исходный адрес делается для того, чтобы соблюсти семантику соединения со стороны клиента (чтобы ответ всегда приходил с того же адреса, на который ушёл запрос), но он тоже делается в POSTROUTING, чтобы поддержать асимметричный роутинг и отвязать политику от механизма.

Сейчас я всё правильно понимаю?

Сейчас я всё правильно понимаю?

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

Я пытаюсь понять, почему всё работает именно так, как работает. Какие юзкейсы были в голове у людей, когда они это придумывали.

Не будет работать :( Что-то меня вчера совсем переклинило.

Я бы попробовал прописать на роутете статиком arp от 10.196.254.2 для 10.196.254.3, а на 10.196.254.2 сделал редирект с 10.196.254.3 на 10.196.254.2 (в nat/INPUT)

DNAT с разных каналов на разные адреса работает без проблем.

Не будет работать :(

Да? Почему?

Я бы попробовал прописать на роутете статиком arp от 10.196.254.2 для 10.196.254.3, а на 10.196.254.2 сделал редирект с 10.196.254.3 на 10.196.254.2 (в nat/INPUT)

Уж лучше с fwmark. :)

vel, vodz

Что вы скажете насчёт такого:

iptables -t mangle -A PREROUTING -m conntrack --ctstate DNAT --ctorigdst 95.84.198.125/32 --ctdir REPLY -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -m conntrack --ctstate DNAT --ctorigdst 192.168.255.2/32 --ctdir REPLY -j MARK --set-mark 2

ip rule add pref 30000 from all fwmark 1 table onl
ip rule add pref 30000 from all fwmark 2 table rtk

Это годится в качестве общего решения? Не годится — ломается hairpin NAT. Есть идеи?

Угу, я только что хотел напомнить о "-m conntrack"

Я бы добавил "-i eth0.3"

И SNAT при этом не нужен IMHO

Я бы добавил "-i eth0.3"

Зачем? eth0.3 — это WAN-интерфейс, а я пытаюсь матчить ответы из LAN.

И SNAT при этом не нужен IMHO

А где ты видишь SNAT?

Я про свой первый вариант.

Есть идеи?

У меня в продакшене своё вот это извращение: Двойная перемаркировка пакетов для работы с двумя провайдерами на прозрачном мосте

Да, я уже нашёл эту твою статью. Забавно; она почти про то же самое.

Но у тебя там сложнее сетап. Мосты ещё зачем-то.

Мосты ещё зачем-то.

Это объясняется в первой статье цикла: чтобы пакеты фильтровались централизованно как на прозрачном брандмауэре для белой подсети, но и одновременно он должен быть непрозрачным для сервисов, например для сервера vpn.

Маркировать эти соединения по первому пакету (state NEW) для входящех с eth0 пакетов, а для ответных пакетов делать метку равную метки соединения.