Распределение трафика на шлюзе

или все распределение грамотно можно сделать по мануалу http://www.lartc.org/howto/

Ну вот, сам спросил, сам и ответил. Будут конкретные трудности в реализации, описывайте с подробностями, возможно :) поможем.

:) ну да, буду покурить...

ЗЫ Могу нагло гнать но..., вроде был какой-то проект автоматизирующий создание правил iproute2, емнип здесь пролетало о нем упоминание не так давно.

Кроме «древнего» htb удалось отыскать более свежую обвязку к iptables-iproute2-tc: http://www.shorewall.net. Думаю, это то что надо, ибо как-то не хочется на неделю нырять в курение манов. Можно будет отложить и поразбираться потом с удовольствием и без спешки.

Все проще, опишите задачу и что не получается в реализации. И возможно даже vel поможет, хоть вы и «обкакали» nDPI, что сделали очень не в тему.

Но вот появился второй канал наружу и захотелось

kldload if_lagg

пользовался FreeBSD
а его bigov не умеет

/fixed

все ждал, когда-же кто-нибудь заступится за Фрю. К сожалению, из мануала: «The lagg interface allows aggregation of multiple network interfaces as one virtual lagg interface for the purpose of providing fault-tolerance and high-speed links.»

Нужна МАРШРУТИЗАЦИЯ, а не агрегирование.

а его bigov не умеет

и сходу грубить незнакомым людям.. странно как-то.

простите, не хотел никого оскорбить. Просто не нашел его в пакетах дистрибутива, потому и использовал термин «костыль».

да ладно тебе, даже не грубо получилось

Нужна МАРШРУТИЗАЦИЯ, а не агрегирование.

ничего не понятно, что там нужно:

1. был один канал
2. всё «вполне себе динамично и стабильно»
3. стало два канала
4. сделай один канал
5. вернись к пункту 2

логично же, не?
хотя бог с ним, решай вопрос выбором другой ОС

Чисто абстрактно ты конечно прав. Но «по большому счету» не хватает настройки маршрутизации на основе адреса отправителя, что умеет делать iproute2.

Или во FreeBSD это тоже можно реализовать? Наверно надо было этот вопрос в заголовке поста озучить, только не нашел такой фичи во Фре.

не хватает настройки маршрутизации на основе адреса отправителя

имеется ввиду направление трафика в разные шлюзы в зависимости от адреса отправителя?
если нет, то я опять не понимаю, чего нужно
если да, то реализовать можно, например setfib или divert, но во фре три фаервола минимум

логично. Но это по сути будет не маршрутизация, а уже фильтрация трафика. Хотя, может я и «капризничаю» - результат практически тот-же, что и при использовании policy-routing в iproute2.

не хватает настройки маршрутизации на основе адреса отправителя
Или во FreeBSD это тоже можно реализовать?

В pf (и в OpenBSD) это есть, но как-то была тема про FreeBSD, выяснилось что в некоторых случаях не все так просто Source based routing

На всякий случай вот мануал для pf как разбросать исходящий трафик по двум каналам https://www.openbsd.org/faq/pf/pools.html , см. «Load balance outgoing traffic»

Но BSD is dying, лучше конечно переходить на линукс

Если опустить холивар, то я пока так-же рассуждаю. Надо «пробовать на вкус». Все прояснится после боевой обкатки.

давай с терминами определимся?

Но это по сути будет не маршрутизация, а уже фильтрация трафика

когда ты берешь пакет из одной сети и отправляешь его в другую — это маршрутизация, а не «фильтрация»

маршрутизации на основе адреса отправителя

это оксюморон применительно к IP, такого не бывает, оставим на совести Игоря Чубина
далее:
то, что ты имеешь в виду Policy-based routing это правила, «проходя» через которые пакет будет обработан и только в результате маршрутизирован
правила != маршрутизация
правила != фильтрация
это всё не касаясь таких вещей как netgraph, где вообще своя атмосфера
через это, когда ты говоришь:
мой_любимый_фаервол если пакет от подсеть/24 тогда отправь его в шлюз№2
это маршрутизация, потому, что пройдя все испытания и очереди, пакет ядром отправиться в шлюз№2, а не в /dev/null

зачет! :-D

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

HTB/CBQ - это настройка QoS для траффика (по сути шейпер) задачи маршрутизации он не решает совсем.

В 99% случаев iproute 2 более чем достаточно, иногда в помощь к iproute2 используют iptables - с помощью iptables маркируют пакеты а уже на основе установленого маркера iproute2 выбирает таблицу маршрутизации для пакета.

HTB/CBQ - используют совсем для другого, когда вам нужно управлять исходящим траффиком на интерфейсе (приоритищация, резервирование, лиметирование и тд) - тоесть управление TX потоком какого либо интерфейса.

Спасибо за уточнение. Вопрос как раз и возник из-за расширения задач маршрутизации на работающем динамическом шейпере. Имхо, участники дискусси в курсе.

Кстати, iproute2 это ip+tc+ss а не только маршрутизация, как можно предположить по тексту вашего уточнения.

Добавил в ядро поддержку setfib и остался на фре. Спасибо, добрый человек, не дал «сойти с пути истиннго»!

### Опции ядра
options ROUTETABLES=4  # max 16. 1 is back compatible.

### /etc/rc.conf
setfib1_enable="YES"
setfib1_defaultroute=...