balance на базе iptables

Ссылку почти не читай сразу отвечай. Если речь о двух разных провах:
1. Что бы два раза одно и тоже не писать.
2. RETURN - Завершают обработку цепочки правил.
3. хз, в инструкцию не вникал.
4. Никак. Нужна поддержка с двух сторон.
5. Не самая «лучшая» идея перекидывать активные соединения между разными интерфейсами.

1. Чтобы не было дублирования правил, будет неудобно читать, если FreeNet большой.

2. -j RETURN в этом случае особо ничего не даёт, можно было -j ACCEPT прописывать, главное сделать, так, чтобы не маркировать пакеты в локальнкую сеть.

3. Потому что save-mark помечает соединенение, а не пакеты.

4. Когда два интерфейса смотрят в одну точку (trunk), то там уж проще балансировать просто все пакеты, чем пакеты одной tcp-сессии.

5. Крутить --probability, только как вы собрались измерять ширину канала?

Ребята, большое спасибо за ваши ответы.

пп. 1 Честно, не совсем понял.

пп. 3 Я правильно понимаю, save-mark используют для того, чтобы помечать входящие пакеты, относящиеся к данному соединению, restore-mark -для ответных ACK и т.д.?

iptables -t mangle -A PREROUTING -s $l_net -m state --state new,related -j NEW_OUT_CONN iptables -t mangle -A PREROUTING -s $l_net -j CONNMARK --restore-mark

Тогда за счет чего здесь маркируются пакеты в рамках установленного соедининия (ESTABLISHED)?

пп. 4 Вы имеете ввиду, что мы объединяем несколько физических интерфейсов в один логический? Можете по подробнее описать, как это делать.

пп. 5 К примеру через периодическую отправку icmp для оценки текущей латентности, может еще есть какие-нибудь идеи, буду рад

5. Не самая «лучшая» идея перекидывать активные соединения между разными интерфейсами.

Как раз такая задача и стоит. Точнее, балансировка пакетов с учетом динамики изменения латентности каналов. Как ее возможно реализовать?

балансировка пакетов

точно пакетов, а не соединений?

Предположим на выходе у вас два ip x.x.x.x и y.y.y.y установлено соединение от адреса x.x.x.x (например файло качаем с ftp) и внезапно к серверу с которого качаем прилетает пакет не от адреса x.x.x.x а y.y.y.y как думаете что будет? правильно тупо соединение разорвется и начинаем все сначала. Еще из реалий жизни (сам не сталкивался добрые люди рассказывали), предположим у вас стоят ip телефоны которые регистрируются «где-то там в интете» так под при каждом изменении ему надо будет перерегистрироваться заново т.е. обычно это пользователю вручную вырубить у него питание и включить заново, т.е. только в тот момент когда ему понадобиться позвонить или ему каким-нибудь другим образом сообщат что у него не работает телефон он об этом узнает, это уже не работа а ебля какая-то получается.
ЗЫ Ну и всякие инетбанкинги, банкклиенты, сдача отчетности &etc тут на вас уже бухгалтерия очень не добро посмотрит и могу предположить что «забудет» вам зарплату начислить :)

У меня более специфичная задача. Упрощенно балансировка на сервере, на котором запущен 1 сервис. То, что MAC/IP source будет разный для установившегося соединения, полностью согласен, но вроде это решается через подмену MAC. В целом знаю, что данная задача решаемая, но навыков очень мало, т.к. только начинаю погружаться в сис. администрирование.

Turbid, пакетов.

1. Цепочка NEW_OUT_CONN вызывается из двух мест, для проходящих через сервер соединений и для исходящих с него (допустим, на сервере стоит proxy).

3. На уровен iptables есть метка пакета (packet mark) и метка соединения (connection mark). На уровне принятия решения о маршрутизации есть только метка пакета.

4. https://habrahabr.ru/post/58218/

5. Нет у меня идей на этот счёт и не понятно, куда именно вы хотите слать ping, но поробуйте.

но вроде это решается через подмену MAC.

MAC дальше провайдера вобще не идёт, он ведь только на уровне сегмента ethernet. Опишите задачу полностью.

Turbid, пакетов.

balance на базе iptables (комментарий)

MAC дальше провайдера вобще не идёт, он ведь только на уровне сегмента ethernet. Опишите задачу полностью.

У клиента есть 3 интерфейса (1-eth c публичным адресом, 2,3- 4G модем)

Есть сервер с одним интерфейсом с публичным адресом. С клиента на сервер отправляем различный трафик (rtp, ftp, торренты и т.д.). Сейчас задачу немного скорректировал: нужна балансировка между тремя интерфейсами клиента в рамках каждой сессии, если устанавливается логическое соединение, и балансировка по каждому пакету, если udp.

P.s. Как я понимаю ftp создает сразу несколько tcp сессий для передачи даты.

1.Можно ли тогда каждую tcp сессию одного ftp соединения передать через разные интерфейсы?

2.Можно ли увеличить количество одновременных tcp сессий для ftp, уменьшив размер отправляемого куска файла?

4. https://habrahabr.ru/post/58218/ Пробовал linux bonding. При попытке объединить eth, wwan0, wwan1 вылетает ошибка «нет wwan интерфейса» (он безусловно есть с выданным адресом). А вот на eth интерфейсах это прекрасно работает.

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

нужна балансировка между тремя интерфейсами клиента в рамках каждой сессии

Нет ни одной адекватной причины так делать. В 99% случаев ты поломаешь протокол.

Нормальные люди используют бондинг и/или PPC на основе SRC||DST. Но за размазывание соединений одного протокола по разным маршрутам - за такое надо бить колотушкой по фалангам.

Имел в виду 1 сессия=1 интерфейс, но только для TCP, как писал выше UDP распределяем между всем интерфейсами, можно последовательно.

Как iptables поймет, что данное соединение в рамках сессии FTP-протокола X, а не Y?

Turbid, пока сам не знаю, поэтому и спрашиваю). У нас есть возможность маркировать и раскидывать по интерфейсам несколько tcp сессии в рамках установленного ftp соединения? А далее на прикладном уровне ftp собирает в правильной последовательности отправляемый файл(ы)

как писал выше UDP распределяем между всем интерфейсами, можно последовательно.

Не будет работать по той же причине что и tcp. Пофиг что нет syn/etc зато есть конкретные сервера, которые форкнутся для конкретного сокета, пакет от другого сокета уже будет рассматриваться как новый.

У нас есть возможность маркировать и раскидывать по интерфейсам несколько tcp сессии в рамках установленного ftp соединения?

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

Как iptables поймет, что данное соединение в рамках сессии FTP-протокола X, а не Y?

Или я вас не понял или RELATED для этого и существует.

Не будет работать по той же причине что и tcp. Пофиг что нет syn/etc зато есть конкретные сервера, которые форкнутся для конкретного сокета, пакет от другого сокета уже будет рассматриваться как новый.

anc,

На самом деле работает, я просто пытаюсь повторить аналог. Да и в принципе есть стандартные средства работы например с rtp датой, которые позволяют разбивать поток на несколько интерфейсов.

Я не рассматриваю сферичиский в ваккуме «два пакета туда, два обратно, отсоединились». Запустите nc и посмотрите что будет, давайте предугадаю, опятьтаки ничего. Или посложнее например openvpn.
Тут уместнее вообще-то отправить читать теорию. Но попробую описать на пальцах. Вот есть у меня банальный эхосервер («школьный» курс програмирования) работающий на 1.1.1.1:1234 , прилетел мне пакет от 2.2.2.2:4321, ок я форкнулся и теперь буду читать отвечать только на эту связку. Представьте себе если бы я читал отвечал вообще всем, что бы получилось? Правильно, что-то типа варианта конференц связи только где все говорят одновременно.

Если сервер ваш, то делайте между ним и клиентом тунели, и по ним раскидывайте пакеты как угодно.

Меньше всего мне хочется спорить)

udp пакеты можно слать с разных интерфейсов и все прекрасно работает. Это доказано практикой и стандартом)

iptables -t mangle -A PREROUTING -s $l_net -m state --state new,related -j NEW_OUT_CONN

iptables -t mangle -A PREROUTING -s $l_net -j CONNMARK --restore-mark

iptables -t mangle -A NEW_OUT_CONN -j CONNMARK --set-mark 1

iptables -t mangle -A NEW_OUT_CONN -m statistic --mode random --probability 0.50 -j RETURN

iptables -t mangle -A NEW_OUT_CONN -j CONNMARK --set-mark 2

Не могу сообразить, каким образом здесь происходит восстановление метки из соединения для пакетов --restore-mark, если мы это самое соединение нигде не помечаем через--save-mark? У нас получается помечают только первый исходящий пакет из LAN для соединений new related?

Ну и ладно, живите в своем уютном мирке. Хотя как примеры я вам уже приводил.

Тут вы не совсем понимаете механизм, почитайте хотя бы man. Для вашего случая приведу только кусок без использования маски
save-mark - Copy the packet mark (nfmark) to the connection mark (ctmark)
restore-mark - Copy the connection mark (ctmark) to the packet mark (nfmark)
В вашем примере, помечается соединение: -j CONNMARK --set-mark.
Метка соединения копируется для пакета: restore-mark
Т.е. все новые соединения (включая related например ftp) получат метку 1 или 2. В дальнейшем все пакеты в этом соединении (соединениях related) будут помечены ей.

anc, спасибо, теперь понял. Запутался из-за большого числа модулей: что-то помечает пакеты, что-то соединение.