2 провайдера, балансировка...и т.д.

Хорошо, признаю я мало что понял из того что вы написали, и если вы не хотите ничего толком обьяснить, тогда желаю вам всего хорошего...:)

Вроде всё сделал...

Изменил следующее:

iptables -t mangle -A PREROUTING -m mark --mark 0 -j sort_connect
iptables -t mangle -A OUTPUT -m mark --mark 0 -j sort_connect

iptables -t mangle -N sort_connect
iptables -t mangle -A sort_connect -o lo -j RETURN
iptables -t mangle -A sort_connect -o enp4s0f0 -j RETURN
iptables -t mangle -A sort_connect -m mark --mark 0 -m conntrack --ctstate NEW,RELATED -j select_prov
# две строки чтобы веб трафик принудительно проходил через второго провайдера
iptables -t mangle -R sort_connect 5 -p tcp --dport 443 -m mark --mark 0 -j CONNMARK --set-mark 4
iptables -t mangle -R sort_connect 4 -p tcp --dport 80 -m mark --mark 0 -j CONNMARK --set-mark 4
iptables -t mangle -A sort_connect -j CONNMARK --restore-mark

По крайней мере с вебом это работает.

Выкурил это посмотрев внимательно на выхлоп tcpdump.

Было две консоли в одной команда
tcpdump -i ppp0 -n host 195.201.201.32 and port 443
в другой
tcpdump -i ppp1 -n host 195.201.201.32 and port 443

В первой выхлоп:
14:18:12.496543 IP 178.46.164.246.57832 > 195.201.201.32.443: Flags [.], ack 4226121129, win 16652, options [nop,nop,TS val 2285825 ecr 3143180406], length 0
14:18:12.496861 IP 178.46.164.246.57832 > 195.201.201.32.443: Flags [P.], seq 0:215, ack 1, win 16652, options [nop,nop,TS val 2285825 ecr 3143180406], length 215

Во второй выхлоп:
09:01:11.412390 IP 178.46.164.246.58256 > 195.201.201.32.443: Flags [ S ], seq 4069162483, win 8192, options [mss 1452,nop,wscale 2,sackOK,TS val 383668 ecr 0], length 0
09:01:11.499910 IP 195.201.201.32.443 > 178.46.164.246.58256: Flags [S.], seq 3229446148, ack 4069162484, win 28960, options [mss 1460,sackOK,TS val 3138425155 ecr 383668,nop,wscale 9], length 0
09:01:12.548462 IP 195.201.201.32.443 > 178.46.164.246.58256: Flags [S.], seq 3229446148, ack 4069162484, win 28960, options [mss 1460,sackOK,TS val 3138425418 ecr 383668,nop,wscale 9], length 0

То есть по нужному маршруту уходил только SYN, получался в ответ SYN-ACK (смотреть первую и вторую строки второго выхлопа), а вот ответ на SYN-ACK, мы опять посылали с первого провайдера (смотреть первую строку первого выхлопа) после чего всё и переставало работать...

Я думал он после первого SYN пакета соединение будет помечено метой 4, мы будем переводить эту метку на пакеты командой
iptables -t mangle -A sort_connect -j CONNMARK --restore-mark
и всё, а получается что ответ ACK корректно не помечался потому что он RELATED и он шёл через default main, а там уж как повезёт если везло попадал к нужному провайдеру, если не везло всё останавливалось.

ip rule add priority 3 from all table main

Ерунду написали. Обратите внимание что у вас это два разных соединения.
178.46.164.246.57832
и
178.46.164.246.58256
но добавление RELATED это правильно. Хотел об этом написать. Но вы опередили :)

Я вот тоже ничего не понял. Вы конечно всегда косноязычны, но в данном примере превзошли себя :)

По крайней мере с вебом это работает.

А не должно. Вот эти две строки просто не будут «добавлены»
iptables -t mangle -R sort_connect 5 -p tcp --dport 443 -m mark --mark 0 -j CONNMARK --set-mark 4
iptables -t mangle -R sort_connect 4 -p tcp --dport 80 -m mark --mark 0 -j CONNMARK --set-mark 4

Причина в -R и цифирках 4 и 5

Да я опять проглядел, просто у меня есть черновик, текстовый файл, я там правила набиваю чтобы их в уже существующие добавить, или заменить, те строки как раз из этого черновика, я ими менял уже существующие правила, а сюда хотел строки ниже добавить
iptables -t mangle -A sort_connect -p tcp --dport 443 -m mark --mark 0 -j CONNMARK --set-mark 4
iptables -t mangle -A sort_connect -p tcp --dport 80 -m mark --mark 0 -j CONNMARK --set-mark 4

vel может что подскажите?
Что бы вам все не перечитывать. Основные моменты здесь:
2 провайдера, балансировка...и т.д. (комментарий)
за минусом iptables-save он вот здесь
2 провайдера, балансировка...и т.д. (комментарий)
ну и после него все оставшиеся комментарии

Неа, не ерунду, в том то и дело что это хоть и RELATED (связаное), но всё же другое соединение, потому и исходный порт другой.

Походу или я что-то пропустил или лыжи. С чего бы оно стало RELATED ? Это просто другое соединение.
RELATED у вас будет например при ftp соединении, мухи отдельно команды на 21 порт, котлеты отдельно данные другой порт. Но этим занимаются отдельные модули исследующие пакетики. Для случая https оно не проканает.

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

Зачем так сложно? У вас не миллион правил. Проще в одном скрипте в начале которого очистить все правила/удалить цепочки.
iptables -F
iptables -F -t nat
iptables -F -t mangle
iptables -F -t raw
iptables -X
iptables -X -t nat
iptables -X -t mangle
iptables -X -t raw

Но это просто логично, сами подумайте, как тогда обьяснить что после добавления к NEW ещё RELATED всё заработало и ответ с ACK пошёл по нужному маршруту, само собой напрашивается ответ что это соединение было RELATED.
Или у вас есть другое обьяснение ?

Вы опять не поняли. Это два разных соединения и ack от другого соединения. Что такое веб сайт как таковой? Это куча файликов которые скачиваются на ваш комп, каждый файлик это отдельное соединение. Далее вы однозначно маркируете пакеты на 443 и 80 т.е. про NEW, RELATED выше тут просто можно забыть.

Да я знаю..., просто дело привычки, я не слишком часто настраивал до этого Linux системы с нуля, до этого пользовался Микротиком и PFsense, хоть я и знаю основы, но далеко не идеально, по сути это моя первая полностью чистая настройка Ubuntu в качестве роутера..., ничего, привыкну... Кстати, большое спасибо вам за помощь! :)

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

Вот смотрите что происходит (ваша копипаста так что будем считать не -R а -A :) )
# переходим в цепочку select_prov где маркируется соединение как получиться
iptables -t mangle -A sort_connect -m mark --mark 0 -m conntrack --ctstate NEW,RELATED -j select_prov
# Возвращаемся из цепочки. И далее мы однозначно маркируем соединение на 443-й и 80-й порты, т.е. пофигу что было до того
iptables -t mangle -R sort_connect 5 -p tcp --dport 443 -m mark --mark 0 -j CONNMARK --set-mark 4
iptables -t mangle -R sort_connect 4 -p tcp --dport 80 -m mark --mark 0 -j CONNMARK --set-mark 4

Ух. Причем здесь левые соединения? Посмотрите на туже главную страницу лора, куча картинок, стили &etc. Все это отдельные файлики, адын файл - адын соединений. Т.е. соединений чуть больше одного просто при открытии страницы. Вам не один файлик прилетает.

Блин..., наверно надо было не по две-три строки выкладывать...
Смысл в том что после после второй строки во втором выхлопе ничего более не было, вернее вторая строка просто повторялась раз за разом, то есть сервер присылал и присылал мне SYN/ACK, и не мог получить мой ответ (АCK), потому что тот шёл с другого провайдера.
Понимаете я вам там выложил по сути первых 5 строк начала обмена данными с сервером, то есть сервер не открывался потому что даже «рукопожатие» не смог завершить (syn,syn/ack,ack), там до закачек файлов даже не дошло, всё вставало на первых трёх пакетах :)

Не читал, но «ip ru» кривовата.

Зачем что-то дублировать в static (да еще и не до конца (про src)) ? нужно просто выкинуть dgw из main и main обязательно просматривать после local.

типа

0: from all lookup local
10: from all lookup main
20: from all fwmark 0x2 lookup prov1
30: from all fwmark 0x4 lookup prov2
40: from all lookup static
50: from all lookup prov1
32766: from all lookup main
32767: from all lookup default

в static добавлять маршруты специфичные по dst ip

все остальное специфичное маркировать через ipset.

Тут кстати я вас не понял, что вы хотели сказать ?!

Эмм. Вроде описал что у вас делают ваши правила. Да и выше написал

Далее вы однозначно маркируете пакеты на 443 и 80 т.е. про NEW, RELATED выше тут просто можно забыть.

Упс. чур моя ошибка, «маркируете пакеты» - читать как «маркируете соединение»

Хорошо, чуть позже попробую сделать как вы написали, спасибо.

Я просто и так знал как они у меня работаю и не понял зачем вы мне это продублировали, думал какая то там ошибка ?! :)

А зачем строка
50: from all lookup prov1

vel правильно говорит. На первой странице этой темы я скидывал ссылку на его объяснение про таблицу main. Благодаря тому объяснению и у себя же переделал по «фэншую», после чего «волосы стали мягкими и шелковистыми». А до этого костылестроением занимался, что конечно работало но менее удобно.
Раз вы только начинаете настраивать. Рекомендую сразу сделать хорошо. Позже будет тяжелее.

Считай def route будет. Только я добавляю оба прова. Если один отвалиться будет работать второй.

Ааа..., это типа замена dgw который мы должны выкинуть из main ?!

Ага, оно самое. Вот предположим что пакеты у вас не маркируются, почему неизвестно, вот так случилось. Но dgw должен быть. Вот и получаеться дальше пойдет по правилам ниже.
Или в тему падения прова, вот у вас для 80 и 443 -set-mark 4 второй пров. Но он же может рухнуть. А работа не должна останавливаться.
50: from all lookup prov1
55: from all lookup prov2
Вот так имхо будет правильней.

Привожу вывод команд:

ip rule

0: from all lookup local
10: from all lookup main
20: from all fwmark 0x2 lookup prov1
30: from all fwmark 0x4 lookup prov2
40: from all lookup static
50: from all lookup prov1
60: from all lookup prov2
32766: from all lookup main
32767: from all lookup default

ip route

109.195.208.69 dev ppp0 proto kernel scope link src 109.195.211.10
192.168.0.0/24 dev enp4s0f0 proto kernel scope link src 192.168.0.1
212.57.162.84 dev ppp1 proto kernel scope link src 178.46.164.246

ip route s t prov1

default via 109.195.208.69 dev ppp0

ip route s t prov2

default via 212.57.162.84 dev ppp1

таблица static пока такая, даже не знаю понадобиться она мне или нет позже, может её вообще удалить?

ip route s t static

192.168.0.0/24 dev enp4s0f0 scope link

Я вот тоже ничего не понял. Вы конечно всегда косноязычны, но в данном примере превзошли себя :)

Дык, жизнь борьба, надо тренироваться. Вот как добьетесь своими mark-ами, чтобы пакеты имели src-ip второго прова, а не первого=default, так приходите, поговорим, кто тут косноязычный.

и если вы не хотите ничего толком обьяснить,

Вот неплохая статья. Обратите внимание, почему там default-ы оба провайдера и зачем собственно (и надо ли вам) вообще служит --restore-mark.

Вообще то если вы не заметили, у нас уже всё получилось и всё работает :)!

Вообще то если вы не заметили, у нас уже всё получилось и всё работает :)!

Я рад за вас. Комменты тут были сумбурные и не оставили чувства, что у вас действительно «всё работает». Ну да не важно: a) был неотвеченный коммент б) статья может кому и пригодится.

Эмм вы snat не заметили?

Отмечайте как решенную. А то действительно среди кучи коментов не понятно, решили или нет.

Эмм вы snat не заметили?

Он нужен по новым веяниям только для nat для локалки.