Такое чувство сервер отвечает всегда с дефолтного интерфейса

Ну дак возмите tcpdump и проверьте чувство. Так какой смысл гадать, может вобще ответных udp-пакетов нет.

"-j CONNMARK --set-mark" - это ctmark, "-j MARK --set-mark" - это nfmark. Читай про "--restore-mark"

«ip rule add fwmark 1 lookup» работает nfmark.

man 2 bind

«man 2 bind» это для программеров и в сервере оно обязательно уже есть.

Если оба канала работают независимо (т.е. policy-routing настроен), то проблем с сервисом не должно быть.

Если оно просто слушает 0.0.0.0:<port>, то отвечать оно будет с адреса на который обратились, т.е. проблем совсем не должно быть.

А иначе можно забиндить его на какой-нибуль локальный адрес и DNAT-ом заворачивал на него пакеты.

Биндить его на адреса динамических интерфейсов или адреса получаемых через dhcp - не очень удобно.

Спасибо за отклик. udp сервис запускается на 0.0.0.0 Почитал про первое второе третье и не могу осознать какой механизм мне нужен чтоб все пакеты и сессии приходящие на eth4 маркировать и отвечать

ip rule add fwmark 2 lookup ky

iptables -t mangle -A PREROUTING -i eth4 -j MARK --set-mark 2

Проверил tcpdump действительно ответ идёт от дефолтного ипишника

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.eth4.rp_filter=0
net.ipv4.ip_forward=1

ip route add default via 134.*.*.* dev eth4 table ky
ip rule add fwmark 2 lookup ky

#ip ru
0:      from all lookup local
32764:  from all fwmark 0x2 lookup ky
32766:  from all lookup main
32767:  from all lookup default

iptables -t mangle -A INPUT -i eth4 -j CONNMARK --set-xmark 0x2/0xffffffff
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff

гм. С MARK у тебя получается вообще полная хрень.

Этот вопрос здесь обсуждается регулярно - воспользуйся поиском.

Это более похоже на правду, только в таблице ky маловато маршрутов. Туда тужно продублировать все прямые маршруты (ip ro ls scope link) ну или хотя бы прямой маршрут связанный с eth4.

Сделать udp сервис доступным с двух и более провайдеров одновременно (комментарий) Из этого поста с одним маршрутом работает web и пинг,а udp Отвечает с дефолта из Main Таблицы..

Допустим маркировка входящих будет так

iptables -t mangle -A INPUT -i eth4 -j MARK --set-mark 2

Если оно просто слушает 0.0.0.0:<port>, то отвечать оно будет с адреса на который обратились, т.е. проблем совсем не должно быть

Откуда такая уверенность?

Про проблемы или про адрес ?

А что у тебя в таблице nat ?

В данном случае это одно и то же, отвечай.

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

Сервер привязанный только к номеру порта будет использовать в качестве src ip адрес интерфейса через который пакет отправиться назад в случае, если сервер не указал явно src ip. А при привильной настройке PBR это будет адрес интерфейса через который пришел запрос.

По хорошему, multihomed udp-сервер должен слушать несколько сокетов прибитых к ip:port, не один сокет прибитый только к порту, тогда не будет неопределенностей. Но это требует определенного уровня знаний от разработчика сервера.

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

Весь вопрос и состоит в том, насколько сервер в ОП стандартный.

Сервер привязанный только к номеру порта будет использовать в качестве src ip адрес интерфейса через который пакет отправиться назад в случае, если сервер не указал явно src ip.

Не распарсил.

По хорошему, multihomed udp-сервер должен слушать несколько сокетов прибитых к ip:port, не один сокет прибитый только к порту, тогда не будет неопределенностей. Но это требует определенного уровня знаний от разработчика сервера.

Поэтому я и посоветовал пойти ман почитать. Мало того, в некоторых случаях это не спасет, так как в пинуксе weak end system model. Вот тут человек мучался.

У меня есть еще раздача в локалку но от этого могу и отказаться и пробовал без этого

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o ppp0 -j MASQUERADE
iptables -t mangle -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu

TC и разработчики сервера - разные люди.

Большая часть простых серверов слушает 1 сокет, а сделать бинд на несколько адресов для 1 сокета нельзя.

Для «кривого сервера» придется делать DNAT.

forward на input/output не влияет.

Есть подзрение, что udp-сервер писали пионеры и в таком случае возможно будет работать вариант с DNAT.

udp серверу нужно в настройках явно указать слушать локальный адрес (но не 127.0.0.1). В nat/prerouting добавить соответствующие правила DNAT с указанием локального адреса и порта udp-сервера для обоих каналов. Не забыть исключить трафик udp-сервера из nat/postrouting/MASQUERADE

Могу поднять на eth0 10.8.1.1 который смотрит в локалку или лучше на eth6 который пуст без кабеля?

imho без разницы.

Заработало после того как поднял сервак на локальном eth0 + dnat оба внешних порт:ип + маркировка

ip route add default via 134.*.*.* dev eth4 table ky
ip rule add fwmark 2 lookup ky

iptables -t mangle -A INPUT -i eth4 -j CONNMARK --set-mark 2
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark

как правильно запретить или если можно разрешить пакеты из локалки eth0 10.8.1.0/24 на внешние eth4 и ppp0

в смысле ? Обращение к адресам интерфейсов eth4 и ppp0 или распределение трафика между каналами ?

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

Аналогично добавил третьего провайдера ppp1. Такое решение нюанса записи динамического dgw pppoe в таблицу: Создать скрипт в /etc/ppp/ip-up.d

ip route add default dev ppp1 table ***

На данном этапе раздаётся инет с ppp0 в локалку eth0. Хотелось бы иметь доступ из локалки к другим двум внешним ипишникам компа. Насколько я понимаю нужно завернуть весь траф с локалки на gw ppp0

сейчас есть только этот маршрут связаный с локалкой
10.8.1.0/24 dev eth0  proto kernel  scope link  src 10.8.1.1
добавить 
ip r add 10.8.1.0/24 dev ppp0 ?

Точнее другие провайдеры пингуются в <1ms c машины из локалки, но нет коннекта на какой либо сервис

нет. Нужно продублировать прямые маршруты из main в о все доп. таблицы. Если у тебя больше двух провайдеров, то удобнее делать так:

Из main убираем шлюз по-умолчанию

правила должны быть организованы так:

0:      from all lookup local 
100:    from all lookup main
200:    from all fwmark 0x1 lookup 11
201:    from all fwmark 0x2 lookup 12
202:    from all fwmark 0x3 lookup 13
300:    from all lookup XXX
32766:  from all lookup main 
32767:  from all lookup default

В таблицах 11,12,13 помещаем только маршруты по-молчанию

Вместо XXX указываем таблицу(11,12,13) , которая будет по-умолчанию

Тогда все локальные адреса роутера будут доступны из локальной сети.

Если пинги есть, а сервис не отвечает - смотри tcpdump-ом куда уходит ответ.

Это слишком замудрено, я на локальной машине(10.8.1.2) подключался к впн немецкому и в итоге видел локалку (eth0 10.8.1.1) + два других своих провайдера(eth4,ppp1). Вот нужно чтоб локальная тачка обращалась к провайдерам не напрямую через локалку а через расшареный ppp0

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

я на локальной машине(10.8.1.2) подключался к впн немецкому и в итоге видел локалку (eth0 10.8.1.1) + два других своих провайдера(eth4,ppp1).

«видел два других своих провайдера» это как в аватаре «Я тебя вижу»!?

Пакеты могут ходить разными машрутами, они нафига не видят :) Чтобы ответ пришел нужно правильно выбрать адрес источника. Задача выбора адреса источника пакета - это как раз PBR.

Если ты под видимостью понимаешь доступность сетей провайдера, то эта проблема решается статическими маршрутами в таблице main.

Вот нужно чтоб локальная тачка обращалась к провайдерам не напрямую через локалку а через расшареный ppp0

нихрена не понял, но все равно это решается маршрутами.

Было решено

Случайно решилось Было

iptables -t nat -A PREROUTING -d IP/32 -i ppp0 -p udp --dport PORT -j DNAT --to-destination LOCAL_IP:PORT