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

Организовать несколько таблиц маршрутизации, помечать трафик определенных протоколов на файрволе меткой и в зависимости от метки выбирать таблицу (ip rule)?

Ну типа того..., у меня так сделано вроде, только вот маршрутизация не меняется...

Что значит не меняется?

как принудительно заставить какой-либо трафик идти через определённого провайдера

Делаешь на этот трафик CONNMARK как у тебя есть и всё. Не забудь сделать RETURN, чтобы не пошло дальше.

Я не знаю и не понимаю, потому сюда и написал.

Да забыл строку iptables -t mangle -A sort_connect -j CONNMARK --restore-mark
в конце блока кода «сортировка соединений»

Пробовал добавлять строку iptables -t mangle -A sort_connect 3 -p tcp --dport 80 -j CONNMARK --set-mark 4
Метка запрос веб страниц всё равно идёт по двум провайдерам.

В общем что не делаю трафик всегда идёт по маршруту который в default таблицы main, будет там nexthop будет всегда случайным образом выбирать маршрут из двух провайдеров, будет в дефолте один провайдер будет всегда ходить по нему игноря второго.
И да у меня net.ipv4.conf.all.rp_filter=0.

iptables -t mangle -A sort_connect 3 -p tcp --dport 80 -j CONNMARK --set-mark 4

Эм а что это за цифирка 3 после sort_connect ? Может опечатались и не -A а -I . Но даже если так вам выше написали не забудьте еще добавить правило RETURN

А.., извиняюсь, там сначала было
iptables -t mangle -I sort_connect 3 -p tcp --dport 80 -j CONNMARK --set-mark 4
просто опечатался когда сюда набивал :)

Кстати вопрос, а не может у меня быть эта проблема из-за каких то особенностей Ubuntu 18.04.LTS, может там глюк какой или ещё что?
Просто я уже неделю пытаюсь завести это, ну не получается, несколько вариантов пробовал, или я везде повторяю какую-то одинаковую ошибку или я даже не знаю что и думать...

А правило с RETURN добавили? Лучше покажите еще раз целиком что получилось, что бы не гадать.

Не совсем понял где там Return ставить, вы хотите сказать что в этой цепочке нужно в конце добавить правило с Return ?

сортировка соединений

iptables -t mangle -N sort_connect
iptables -t mangle -A sort_connect -o lo -j RETURN
iptables -t mangle -A sort_connect -o $loc_eth -j RETURN
iptables -t mangle -A sort_connect -m conntrack --ctstate NEW -j select_prov
iptables -t mangle -A sort_connect -j CONNMARK --restore-mark

Вот еще по таблицам роутинга, vel хорошо описал про main
Маршрутизация маркированных iptables пакетов. (комментарий)

А где здесь правило
iptables -t mangle -I sort_connect 3 -p tcp --dport 80 -j CONNMARK --set-mark 4
? Я его не вижу.
return следующим после него, с теме же условиями -p tcp --dport 80

iptables -t mangle -A sort_connect -o lo -j RETURN
iptables -t mangle -A sort_connect -o $loc_eth -j RETURN
iptables -t mangle -A sort_connect -p tcp --dport 80 -j CONNMARK --set-mark 4
iptables -t mangle -A sort_connect -p tcp --dport 80 -j RETURN
iptables -t mangle -A sort_connect -m conntrack --ctstate NEW -j select_prov
только --restore-mark сделать в вызывающей цепочке

Упс, можно же проще
iptables -t mangle -A sort_connect -p tcp --dport 80 -j MARK --set-mark 4
а --restore-mark оставить где было.

То есть получается что Return нужно ставить после каждой из команд
iptables -t mangle -I OUTPUT -j sort_connect
и
iptables -t mangle -I FORWARD -j sort_connect

думаю тогда команды переделать в что-то типа такого

iptables -t mangle -I OUTPUT -m conntrack --ctstate NEW -j sort_connect
iptables -t mangle -I OUTPUT -m conntrack --ctstate NEW -j RETURN
и
iptables -t mangle -I FORWARD -m conntrack --ctstate NEW -j sort_connect
iptables -t mangle -I FORWARD -m conntrack --ctstate NEW -j RETURN
тогда может лучше ACCEPT, а не RETURN ?

Ну вообще то так и есть, строку
iptables -t mangle -A sort_connect -p tcp --dport 80 -j CONNMARK --set-mark 4
я не напечатал в первом сообщении потому что в исходном коде её и не было, это я так, для теста её туда вставил.
Но как я понимаю даже без неё если я буду постоянно обновлять веб страничку (по F5) в браузере то практически через раз она должна обновляться (грузиться) с разных провайдеров, в реальности такого нет, если она выбрала первого провайдера то и будет висеть на нём пока не отключишь этого провайдера.

Короче сейчас у меня код в той цепочке такой
iptables -t mangle -A sort_connect -o lo -j RETURN
iptables -t mangle -A sort_connect -o $loc_eth -j RETURN
iptables -t mangle -A sort_connect -p tcp --dport 80 -j CONNMARK --set-mark 4
iptables -t mangle -A sort_connect -m conntrack --ctstate NEW -j select_prov
iptables -t mangle -A sort_connect -j CONNMARK --restore-mark
но он не работает, возникает такое ощущение что метки просто игнорятся, потому что маршрут всё равно выбирается в default main.

Неверная логика. А при учете приведенных команд вдвойне.
Начну с конца, -I ( I от слова insert) добавляет правило на «первое» место. Т.е. при выполнении приведенных правил у вас получиться
-t mangle OUTPUT -m conntrack --ctstate NEW -j RETURN
-t mangle OUTPUT -m conntrack --ctstate NEW -j sort_connect
обработка остановиться на первом правиле.

тогда может лучше ACCEPT, а не RETURN ?

Тоже серьезная разница. ACCEPT (как DROP, REJECT) прекращает дальнейшую обработку цепочек. RETURN прекращает обработку конкретной цепочки.
Для случая когда это написано в основной, например OUTPUT, разницы между ними никакой. Но для случая когда во вложенной цепочке, например как у вас sort_connect, разница уже есть. При RETURN продолжиться выполнение команд из вызывающей цепочки, при ACCEPT нет.

Еще раз
iptables -t mangle -A sort_connect -p tcp --dport 80 -j MARK --set-mark 4
iptables -t mangle -A sort_connect -p tcp --dport 80 -j RETURN

Я знаю как работает -I, просто банальная невнимательность и торопливость, вторую строку формировал копипастой первой и не обратил внимание что у неё там не -A, а -I.
Про Return тоже знаю, но строки
iptables -t mangle -I OUTPUT -j sort_connect
iptables -t mangle -I FORWARD -j sort_connect
находятся как раз в основных цепочках и по вашим же словам там не должно быть разницы между RETURN и ACCEPT, просто я слышал что ACCEPT меньше ресурсов или ещё чего-то потребляет :)

Но тогда правило с --restore-mark нужно вынести в основную цепочку, так ведь ?

просто я слышал что ACCEPT меньше ресурсов или ещё чего-то потребляет

Эммммм..... афтара в студию плиз.

Неа, не надо. Я же написал об этом. Достаточно MARK

iptables -t mangle -A sort_connect -o lo -j RETURN
iptables -t mangle -A sort_connect -o $loc_eth -j RETURN
iptables -t mangle -A sort_connect -p tcp --dport 80 -j MARK --set-mark 4
iptables -t mangle -A sort_connect -p tcp --dport 80 -j RETURN
iptables -t mangle -A sort_connect -m conntrack --ctstate NEW -j select_prov
iptables -t mangle -A sort_connect -j CONNMARK --restore-mark

То есть --restore-mark не обязательна, ведь получается что в вашем коде мы выйдем из цепочки sort_connect при обращении к 80 порту до её отработки ?!

ведь получается что в вашем коде мы выйдем из цепочки sort_connect при обращении к 80 порту до её отработки ?!

Именно так, вы же вроде этого хотели?

Если найду то специально для вас напишу, давно было, как минимум пару лет назад, где то в обсуждении кто-то такое написал и его самое смешное не поправили, я подумал может правда и я чего-то не знаю :)

Похоже я не до конца понимаю что делает --restore-mark
--restore-mark (копирует маркировку соединения в маркировку пакета)
Привожу описание в откуда я брал
Через цепочку select_prov мы прогоняем только новые пакеты, то есть первые пакеты каждого соединения. После этой процедуры соединение уже имеет маркировку. К сожалению, на данный момент роутинговая подсистема ядра Linux не умеет маршрутизировать пакеты на основании маркировки соединения — только на основании маркировки пакетов. Поэтому действием CONNMARK --restore-mark мы копируем маркировку соединений в маркировку пакетов.
Но вы говорите что --restore-mark не нужен, я вообще то проверял, маркировка на пакетах всё равно есть и без --restore-mark, тогда зачем он вообще нужен ?

Все верно вы описали. Не понятно что вам не понятно :)
restore-mark - копирует метку соединения в метку пакета.
iproute2 умеет оперировать только пакетами, но ничего не знает о соединении которое в conntrack.
Что делают ваши правила.
1. Мы маркируем новое соединение ( об этом знает только conntrack) но не пакет, restore-mark копирует (на самом деле не всегда, можно маску задать) маркировку соединения в каждый пакет пролетающий по этому соединению. Зачем именно так? Вот у вас два прова, вы соединяетесь к одному ресурсу, но если рандомно отсылать пакеты с разных ip в этом соединении работать скорее всего не будет. Именно поэтому сначала маркируется соединение с которого началось и в дальнейшем все пакеты полетят через того же прова.
2. В вашем запросе было отправлять все пакеты на 80 порт через конкретного прова. Тут достаточно MARK который маркирует пакеты а не соединение.

ЗЫ Да и еще имейте ввиду что состояние NEW это первый пакет отсутствующий в conntrack, а не новое соединение как многие думают.

Ну это я понимаю и всё же в большинстве случаев это и новое соединение будет, пусть и не всегда.

По поводу вашего сообщения выше..., опять моя ночная невнимательность, не сразу заметил что там MARK, а не CONMARK, от того и все дурацкие вопросы...
Доберусь утром до роутера и проверю, спасибо за терпение и простите за невнимательность...

спасибо за терпение

Да что вы, действительно не за что. Вы хорошо описываете проблему. Пусть и не полностью, но задача пока понятна. И решение ей мы найдем.

ЗЫ Не удержался. Пример полного терпения. Без мата в разговоре с тех. под.
Дано: домашний инет.
1. Был l2tp, «внезапно» поменяли на pppoe. Узнать об этой «внезапности» позволил только звонок в тех. под. И то мля не сразу об этом рассказали.
2. Перенастроил на pppoe, так эти «пидары гнойные» мне через несколько часов пароль поменяли.... опять без предупреждения. Все это было прямо «сейчас».

Матерные слова я использую только когда вешаю трубку. Ведь тех. под. первой линии не виновата. Но ооочень хочется высказаться на «русском литературном» исполнителям.

У нас такая же проблема была с перевода с VPN на PPPoE, на вопрос какого фига и без предупреждения, ответ был ну вы же всё равно к нам позвоните, зачем оповещать... :)

Так у вас все заработало?
ЗЫ Как решим проблему, потом добавлю «юмора» общения с ТП.

Проверил, нет, такая конструкция не помогает, как открывались веб странички с разных провайдеров так и открываются, да по здравому размышлению она и не должна помогать, тут мы просто заменяем CONNMARK --restore-mark на обычный MARK, а финальный результат будет тот же самый пометка всех пакетов..., а как я и писал складывается такое ощущение что все эти метки просто игнорируются или не попадают в нужные правила или таблицы.

Странно. Очень странно.
У вас

11: from all fwmark 0x4 lookup prov2

т.е. мы еще не говорим про «правильное» расположение таблиц.

Покажите плиз полный вариант.

ip r s table all
ip ru s
ip a
iptables-save  

На счёт IP не страшно, они статичные, но если что я могу их поменять :)

ip r s table all

109.195.208.69 dev ppp0 table static scope link
188.17.104.1 dev ppp1 table static scope link
192.168.0.0/24 dev enp4s0f0 table static scope link
default via 109.195.208.69 dev ppp0 table prov1
default via 188.17.104.1 dev ppp1 table prov2
default nexthop via 109.195.208.69 dev ppp0 weight 1 nexthop via 188.17.104.1 dev ppp1 weight 1
109.195.208.69 dev ppp0 proto kernel scope link src 109.195.211.10
188.17.104.1 dev ppp1 proto kernel scope link src 178.46.164.246
192.168.0.0/24 dev enp4s0f0 proto kernel scope link src 192.168.0.1
local 109.195.211.10 dev ppp0 table local proto kernel scope host src 109.195.211.10
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 178.46.164.246 dev ppp1 table local proto kernel scope host src 178.46.164.246
broadcast 192.168.0.0 dev enp4s0f0 table local proto kernel scope link src 192.168.0.1
local 192.168.0.1 dev enp4s0f0 table local proto kernel scope host src 192.168.0.1
broadcast 192.168.0.255 dev enp4s0f0 table local proto kernel scope link src 192.168.0.1
fe80::/64 dev enp4s0f0 proto kernel metric 256 pref medium local fe80::a236:9fff:fe83:5624 dev enp4s0f0 table local proto kernel metric 0 pref medium
ff00::/8 dev enp4s0f0 table local metric 256 pref medium

ip ru s

0: from all lookup local
1: from all lookup static
10: from all fwmark 0x2 lookup prov1
11: from all fwmark 0x4 lookup prov2
32766: from all lookup main
32767: from all lookup default

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever
2: enp4s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether a0:36:9f:83:56:24 brd ff:ff:ff:ff:ff:ff inet 192.168.0.1/24 brd 192.168.0.255 scope global enp4s0f0 valid_lft forever preferred_lft forever inet6 fe80::a236:9fff:fe83:5624/64 scope link valid_lft forever preferred_lft forever
3: enp4s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether a0:36:9f:83:56:25 brd ff:ff:ff:ff:ff:ff
4: enp4s0f2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether a0:36:9f:83:56:26 brd ff:ff:ff:ff:ff:ff
5: enp4s0f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether a0:36:9f:83:56:27 brd ff:ff:ff:ff:ff:ff
8: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3 link/ppp inet 178.46.164.246 peer 188.17.104.1/32 scope global ppp1 valid_lft forever preferred_lft forever
9: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3 link/ppp inet 109.195.211.10 peer 109.195.208.69/32 scope global ppp0 valid_lft forever preferred_lft forever

iptables-save

# Generated by iptables-save v1.6.1 on Sun Jun 17 09:54:18 2018 *raw
:PREROUTING ACCEPT [4787:1718654] :OUTPUT ACCEPT [1052:333805]
COMMIT
# Completed on Sun Jun 17 09:54:18 2018 # Generated by iptables-save v1.6.1 on Sun Jun 17 09:54:18 2018
*filter
:INPUT DROP [2136:126812]
:FORWARD ACCEPT [3523638:3302597942]
:OUTPUT ACCEPT [104502:22471554]
[1741:145894] -A INPUT -d 127.0.0.1/32 -i lo -j ACCEPT
[85809:10345572] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[33:2931] -A INPUT -m conntrack --ctstate INVALID -j DROP
[56301:14211026] -A INPUT -i enp4s0f0 -j ACCEPT
COMMIT
# Completed on Sun Jun 17 09:54:18 2018
# Generated by iptables-save v1.6.1 on Sun Jun 17 09:54:18 2018
*nat
:PREROUTING ACCEPT [397:23890]
:INPUT ACCEPT [229:14428]
:OUTPUT ACCEPT [163:13959]
:POSTROUTING ACCEPT [0:0]
[1200:88974] -A POSTROUTING -o ppp0 -j SNAT --to-source 109.195.211.10
[978:74625] -A POSTROUTING -o ppp1 -j SNAT --to-source 178.46.164.246
COMMIT
# Completed on Sun Jun 17 09:54:18 2018
# Generated by iptables-save v1.6.1 on Sun Jun 17 09:54:18 2018
*mangle
:PREROUTING ACCEPT [48565:38766485]
:INPUT ACCEPT [4483:885089]
:FORWARD ACCEPT [44074:37869396]
:OUTPUT ACCEPT [1813:526592]
:POSTROUTING ACCEPT [45887:38395988]
:select_prov - [0:0]
:sort_connect - [0:0]
[152:9096] -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu
[131:7860] -A FORWARD -o ppp1 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu
[44074:37869396] -A FORWARD -j sort_connect
[1813:526592] -A OUTPUT -j sort_connect
[630:46854] -A select_prov -j CONNMARK --set-xmark 0x2/0xffffffff
[315:23528] -A select_prov -m statistic --mode nth --every 2 --packet 0 -j RETURN
[315:23326] -A select_prov -j CONNMARK --set-xmark 0x4/0xffffffff
[157:11421] -A select_prov -m statistic --mode nth --every 2 --packet 1 -j RETURN
[4:570] -A sort_connect -o lo -j RETURN
[29204:36961311] -A sort_connect -o enp4s0f0 -j RETURN
[630:46854] -A sort_connect -m conntrack --ctstate NEW -j select_prov
[94:5640] -A sort_connect -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -j CONNMARK --set-xmark 0x4/0xffffffff
[187:11223] -A sort_connect -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW -j CONNMARK --set-xmark 0x4/0xffffffff
[16679:1434107] -A sort_connect -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
COMMIT
# Completed on Sun Jun 17 09:54:18 2018

Вот я дебил.... уж простите, сам не знаю как не обратил внимание, а потом убеждал что все должно работать. :(
Таблица же не FORWARD а PREROUTING должна быть.
iptables -t mangle -I PREROUTING -j sort_connect

PREROUTING и OUTPUT ?

Ага. OUTPUT это для локальных процессов. PREROUTING - для проходящих через роутер. (на самом деле нет, PREROUTING и для INPUT)

Хм.., ну по крайней мере сейчас (после переноса в PREROUTING) метки хоть на что-то влияют, теперь половина сайтов открывается, а половина нет, открываются именно те которые идут через провайдера с меткой 4, остальные нет..., похоже надо ещё что-то подправить...

Опять-таки в теории такое возможно. Т.к. при открытии сайта на самом деле происходит много соединений. А современные сайты это отдельная песня.
Если не сложно скинте плиз несколько ссылок на те которые «а половина нет».
Не обещаю что быстро проверю, только когда будет время. Но раз взялись за задачу, то надо ее решить.

Да нет, тут дело точно не в этом, понимаете, такое ощущение что мы где то ещё какую то мелочь забыли вот скажем (nat). Складывается ощущение что когда сайт и так был должен открыться через второго провайдера (метка 4) он открывается быстро и полностью, а когда он хотел пойти по маршруту через второго провайдера, но мы ему принудительно выставили метку 4 что-то ломается в маршрутизации и именно ответ приходит не туда куда надо...

Давайте еще раз посмотрим на iptables-save
Остальное думаю вы не меняли.
Повторюсь, уж простите быстрого ответа не обещаю, но место для тестового стенда есть. Не прям-прям как у вас, но близко к вариантам.

Сейчас глянул tcpdump-ом, повесил его на оба интерфейса провайдеров, так вот видно что на с ppp0 уходят запросы с адресом ppp1, а ответы приходят только на ppp1.

Глупость конечно, но уберите default gw
Реально глупость. Ну так, с горя как говориться.
Но и iptables-save свежий всетаки скиньте.

Да, и по итогам кастануть бы vel, я тоже вот упустил FORWARD может свежий взгляд и большой гугу что-то заметит.

Текущий iptables-save

# Generated by iptables-save v1.6.1 on Mon Jun 18 09:27:18 2018
*mangle
:PREROUTING ACCEPT [1775:421232]
:INPUT ACCEPT [565:88933]
:FORWARD ACCEPT [1210:332299]
:OUTPUT ACCEPT [516:207804]
:POSTROUTING ACCEPT [1726:540103]
:select_prov - [0:0] :sort_connect - [0:0]
[251:31186] -A PREROUTING -m conntrack --ctstate NEW -j sort_connect
[39:2340] -A FORWARD -o ppp1 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu
[2:120] -A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu
[2838:815957] -A OUTPUT -j sort_connect
[389:42635] -A select_prov -j CONNMARK --set-xmark 0x2/0xffffffff
[535:45503] -A select_prov -m statistic --mode nth --every 2 --packet 0 -j RETURN
[194:22536] -A select_prov -j CONNMARK --set-xmark 0x4/0xffffffff
[265:23175] -A select_prov -m statistic --mode nth --every 2 --packet 1 -j RETURN
[149:11369] -A sort_connect -o lo -j RETURN
[29823:37219242] -A sort_connect -o enp4s0f0 -j RETURN
[1068:93241] -A sort_connect -m conntrack --ctstate NEW -j select_prov
[108:6480] -A sort_connect -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -j CONNMARK --set-xmark 0x4/0xffffffff
[213:12783] -A sort_connect -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW -j CONNMARK --set-xmark 0x4/0xffffffff
[17209:1487448] -A sort_connect -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
COMMIT
# Completed on Mon Jun 18 09:27:18 2018
# Generated by iptables-save v1.6.1 on Mon Jun 18 09:27:18 2018
*nat
:PREROUTING ACCEPT [668:45220]
:INPUT ACCEPT [385:25117]
:OUTPUT ACCEPT [383:31377]
:POSTROUTING ACCEPT [34:2277]
[1317:98385] -A POSTROUTING -o ppp0 -j SNAT --to-source 109.195.211.10
[1088:82815] -A POSTROUTING -o ppp1 -j SNAT --to-source 178.46.164.246
COMMIT
# Completed on Mon Jun 18 09:27:18 2018
# Generated by iptables-save v1.6.1 on Mon Jun 18 09:27:18 2018
*filter
:INPUT DROP [2210:134993]
:FORWARD ACCEPT [3524888:3302933863]
:OUTPUT ACCEPT [105527:22760919]
[1886:156693] -A INPUT -d 127.0.0.1/32 -i lo -j ACCEPT
[86479:10459605] -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[56:4207] -A INPUT -m conntrack --ctstate INVALID -j DROP
[56625:14268585] -A INPUT -i enp4s0f0 -j ACCEPT
COMMIT
# Completed on Mon Jun 18 09:27:18 2018
# Generated by iptables-save v1.6.1 on Mon Jun 18 09:27:18 2018
*raw
:PREROUTING ACCEPT [7273:2246423]
:OUTPUT ACCEPT [2077:623170]
COMMIT
# Completed on Mon Jun 18 09:27:18 2018

Если убираю default gw в main вообще пропадает всякая связь, то есть как я понял он по любому используется.

Давайте я вам страшную тайну открою. Чтобы образовалось соединение, необходимо чтобы у него был локальный IP:порт и удаленный IP:порт. Потому без маршрута соединение не может быть сделано подсистемой, отвечающей за IP-стек как таковой ещё до подсистемы маршрутизации. Потому, для исходящих от локального хоста пакетов надо либо прямо в настройках конкретной программы выставить source IP для желаемого маршрута, либо отдать подсистеме socket адреса маршрута по умолчанию, но потом реализовать source-routing с сетевой трасляцией адреса. (Вариант с PI не рассматриваем).

Ииии, что вы хотели этим сказать...?

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

Ииии, что вы хотели этим сказать...?

Я вам разжевал принцип работы IP-стека при нескольких маршрутах. Почему у вас ничего не работает без default-gw, почему пакеты имеют всегда один и тот же IP вне зависимости от ручного назначения исходящего интерфейса... Если вы ничего не поняли, то нет смысла разговора дальше.