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

balance на базе iptables

 ,


0

2

Только начинаю осваивать linux. После прочтения статьи http://help.ubuntu.ru/wiki/ip_balancing возникло много вопросов.

По первому способу:

  1. В чем смысл создавать отдельную цепочку NEW_OUT_CONN, почему нельзя правила сразу реализовать таблицах mangle цепочек PREROUTING и OUTPUT?
  2. Что дают нам эти правила (понятно, что это применение политик по умолчанию, но зачем это прописывают явно):
    iptables -t mangle -A PREROUTING -d $l_net -j RETURN
    iptables -t mangle -A PREROUTING -d $li_net -j RETURN
    
    или
    iptables -t mangle -A OUTPUT -d $l_net -j RETURN
    iptables -t mangle -A OUTPUT -d $li_net -j RETURN
    
  3. Почему мы не используем save-mark для того, чтобы помечать все пакеты, относящиеся к данному соединению?
  4. Как я понимаю, данный способ балансировки распределяет пакеты одного соединения (сессии) между 2мя интерфейсами, таким образом все пакеты, принадлежащие данному соединению, пройдут только через один интерфейс. А как реализовать балансировку в рамках одной допустим tcp (или ftp) сессии на 2 интерфейса?
  5. Как реализовать динамическое распределение исходящих пакетов между двумя интерфейсами при изменении канала пропускания (например ширина канала 1 резко упала в 2 раза в момент установленного соединения и нам надо распределять уже не 50/50, а 25/75)?


Последнее исправление: beastie (всего исправлений: 1)

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

anc ★★★★★
()

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

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

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

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

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

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

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

пп. 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 для оценки текущей латентности, может еще есть какие-нибудь идеи, буду рад

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 интерфейсах это прекрасно работает.

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

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

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

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

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

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

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

spybond08
() автор топика
Ответ на: комментарий от Turbid

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

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

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

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

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

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

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

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

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

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

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

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

anc,

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

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

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

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

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

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

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

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

spybond08
() автор топика

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?

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

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

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

Тут вы не совсем понимаете механизм, почитайте хотя бы 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 ★★★★★
()
Ответ на: комментарий от anc

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

spybond08
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.