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

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

 ,


2

1

Доброго времени суток!

Да я знаю что не первый и не второй и даже не 10 кто создаёт подобную тему, так что заранее прошу прощения за свой плач Ярославны!

Для начала исходные данные, имеется два провайдера, к обоим подключение через PPPoE.
Подключения делаются на роутере, за роутером локальная сеть, на данный момент для тестов подключен только один компьютер.
На роутере никаких серверов имеющих доступ снаружи нет, более того доступ снаружи вообще заблокирован (ну по крайней мере сейчас).
Решил сделать балансировку исходящего трафика, что от роутера, что из локалки.

Для понимания чего и куда лепить использовал много ссылок, но в основном код заимствовал с двух мест тут и тут.(с маркировкой пакетов, структура цепочек взята из второй ссылки, нужное место можно найти по тексту «tprov1»)

rt_tables

100 static
101 prov1
102 prov2


ip rule

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 route

default nexthop via 109.195.208.69 dev ppp0 weight 1 nexthop via 212.57.162.84 dev ppp1 weight 1
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 show table static

109.195.208.69 dev ppp0 scope link
192.168.0.0/24 dev enp4s0f0 scope link
212.57.162.84 dev ppp1 scope link


ip route show table prov1

default via 109.195.208.69 dev ppp0


ip route show table prov2

default via 212.57.162.84 dev ppp1


выбор провайдера

iptables -t mangle -N select_prov
iptables -t mangle -A select_prov -j CONNMARK --set-mark 2
iptables -t mangle -A select_prov -m statistic --mode nth --every 2 --packet 0 -j RETURN
iptables -t mangle -A select_prov -j CONNMARK --set-mark 4
iptables -t mangle -A select_prov -m statistic --mode nth --every 2 --packet 1 -j 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 -I OUTPUT -j sort_connect
iptables -t mangle -I FORWARD -j sort_connect


В общем то всё работает, но я не пойму как принудительно заставить какой-либо трафик идти через определённого провайдера, скажем чтобы все запросы HTTP (или какой-то определённый IP) шли только через второго провайдера, а весь остальной трафик балансировался как обычно?!

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

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

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

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

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

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

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

Да забыл строку 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
Метка запрос веб страниц всё равно идёт по двум провайдерам.

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

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

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

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

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

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

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

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

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

Не совсем понял где там 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

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

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

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

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 сделать в вызывающей цепочке

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

То есть получается что 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 ?

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

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

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

Короче сейчас у меня код в той цепочке такой
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.

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

Неверная логика. А при учете приведенных команд вдвойне.
Начну с конца, -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 нет.

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

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

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

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

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

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

Неа, не надо. Я же написал об этом. Достаточно 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11: from all fwmark 0x4 lookup prov2

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

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

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

Важно: если есть реальные ip, замаскируйте в выхлопе.

Чую что-то где-то не так.

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

На счёт 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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Текущий 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


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

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

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

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

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

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

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

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

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