Адреса групп в таблицы ipfw

[dark]

Доброго пребывания!
Подскажите пожалуйста как можно ip-адреса пользователей разных групп раскидать по разным таблицам ipfw?

это нужно для разной маршрутизации разных групп пользователей.

версия биллинга 49.32, nofire.pl находится на одной машине с базой.

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

[elite]

Доброго пребывания!
Подскажите пожалуйста как можно ip-адреса пользователей разных групп раскидать по разным таблицам ipfw?

это нужно для разной маршрутизации разных групп пользователей.

версия биллинга 49.32, nofire.pl находится на одной машине с базой.

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

расскажи
надо nofire.pl править

p.s. to стас >> неплохо было бы, если бы инсталятор не заменял файл nofire.pl при обновление биллинга )

[Efendy]

p.s. to стас >> неплохо было бы, если бы инсталятор не заменял файл nofire.pl при обновление биллинга )

я уже думал об этом. Только нужно разрулить ситуации, когда таки нужно поменять,

[blackjack]

Доброго пребывания!
Подскажите пожалуйста как можно ip-адреса пользователей разных групп раскидать по разным таблицам ipfw?

это нужно для разной маршрутизации разных групп пользователей.

версия биллинга 49.32, nofire.pl находится на одной машине с базой.

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

расскажи
надо nofire.pl править

p.s. to стас >> неплохо было бы, если бы инсталятор не заменял файл nofire.pl при обновление биллинга )

+1

[dark]

Компилируем ядро с параметрами:
options         ROUTETABLES=8
options         LIBALIAS

далее примеры конфигов:

# cat /etc/rc.local

Код:

setfib -1 route add default 10.1.1.1  (шлюз 1 прова)
setfib -2 route add default 172.1.1.1 (шлюз 2 прова)
setfib -3 route add default 192.168.1.1 (шлюз 3 прова)
setfib -4 route add default 10.10.5.1 (дополнительная маршрутизация на пров. локалку )

cat /etc/pf.conf

Код:

#нат на 1 прова
nat pass on vr1 from 172.0.0.0/8 to any -> (vr1)
#нат на 2 прова
nat pass on vr2 from 172.0.0.0/8 to any -> (vr2)
#нат на 2 прова
nat pass on vr3 from 172.0.0.0/8 to any -> (vr3)

добавленные строки (некоторые изменены, начиная с 200 правила по 2050, остальное такое же как в примере)
cat /etc/rc.firewall  

Код:

${f} add 200 skipto 500 ip from any to any via ${ifOut}
${f} add 200 skipto 500 ip from any to any via ${ifOur}
#${f} add 200 skipto 500 ip from any to any via ${ifTree}

${f} add 300 setfib 1 ip from 172.2.2.0/24 to not "table(30)" in
${f} add 310 setfib 2 ip from 172.3.3.0/24 to not "table(30)" in
${f} add 320 setfib 3 ip from 172.4.4.0/24 to not "table(30)" in
${f} add 330 setfib 4 ip from 172.0.0.0/8 to "table(30)" in
${f} add 350 skipto 4500 ip from any to any in

${f} add 400 skipto 450 ip from any to any recv ${ifOut}
${f} add 400 skipto 450 ip from any to any recv ${ifOur}
#${f} add 400 skipto 450 ip from any to any recv ${ifTree}

${f} add 420 tee 1 ip from any to any
${f} add 450 tee 2 ip from any to any
${f} add 490 allow ip from any to any

${f} add 500 skipto 32500 ip from any to any in
${f} add 510 tee 1 ip from any to any
${f} add 540 allow ip from any to any


${f} add 1000 allow udp from any 53,7723 to any
${f} add 1010 allow tcp from any to any setup keep-state
${f} add 1020 allow udp from any to any keep-state
${f} add 1100 allow ip from any to any

${f} add 2000 check-state
${f} add 2010 allow icmp from any to any
${f} add 2020 allow tcp from any to any 80,443
${f} add 2050 deny ip from any to any via ${ifOut}
${f} add 2050 deny ip from any to any via ${ifOur}
#${f} add 2050 deny ip from any to any via ${ifTree}

где

ifOur='vr0'
ifOut='vr1'
ifTree'vr30'

кстати в table(30) прописаны подсти провайдерской локалки, формируется из "Операции - настройки -направления" примерно как на вложении.


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

[dark]

в фряхе всего неделю, по быстрому разобрался с системой и ipfw, поэтому дополнения приветствуются  

ой кстати забыл написать, заменил в правилах ipfw все диверты на tee , то же самое проделал и в конфиге ipcad ( спасибо за идею Elite)

[Efendy]

tee или divert - 2 стороны медали. Divert считает гарантированно, поэтому может тормозить тот трафик, который не успевает посчитать, tee работает независимо, но может пропускать пакеты. Что выбрать - это зависит от требований. В документации я предпочел точность

[elite]

tee или divert - 2 стороны медали. Divert считает гарантированно, поэтому может тормозить тот трафик, который не успевает посчитать, tee работает независимо, но может пропускать пакеты. Что выбрать - это зависит от требований. В документации я предпочел точность

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

[elite]

Компилируем ядро с параметрами:
options         ROUTETABLES=8
options         LIBALIAS

зачем тебе стока много таблиц? 
ну и либалиас тут ни при чем, можно смело его убирать

p.s. у тебя много-много ого? есть и более красивые решения, чем ручное распределение пользоватлей

[dark]

зачем тебе стока много таблиц?  

собрал с ROUTETABLES=2 - оказалось мало, сделал с запасом на будущее..

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

точно, помоему без него не собиралось ядро при включении опции DEVICE_POLLING

p.s. у тебя много-много ого? есть и более красивые решения, чем ручное распределение пользоватлей

НАпример? раскидывать пакеты типа nexthop сразу по 2-3 провайдерам? в моем примере это как дополнение к текущей маршрутизации реализуется без проблем. ну только проблемы могут возникнуть на некоторых сайтах, типа разлогина, ну или на примере вконтакте: не работает видео, не отправляются сообщения, - это то с чем меня ЗАДОЛБАЛИ пользователи...;  плюсы в таком методе при скачке в несколько потоков (торренты, качалки) - скорость складывается.

[Maks]

Так роутинг подсетей контакта на один канал. Я также реализвал, только на Тике.
P.S Проблемы были только с Контактом, а точнее игры не работали.
А С Ютуба или чего либо еще все ок.

[elite]

НАпример? раскидывать пакеты типа nexthop сразу по 2-3 провайдерам? в моем примере это как дополнение к текущей маршрутизации реализуется без проблем. ну только проблемы могут возникнуть на некоторых сайтах, типа разлогина, ну или на примере вконтакте: не работает видео, не отправляются сообщения, - это то с чем меня ЗАДОЛБАЛИ пользователи...;  плюсы в таком методе при скачке в несколько потоков (торренты, качалки) - скорость складывается.

есть варианты:
1) динамически распределять пользователей по разным каналам, при этом запонимать source-ip - канал
2) сервер в инете - до него стоим впн и объединяем все
второй вариант очень красивый, позволяет получить скорость практически Nx8 (для N-адсл ого по 8 мбит) и, что очень немаловажно, суммирует аплоад, что особенно важно при использовании нескольких ого
ну и еще реальный статический ип получаем бонусом

p.s. есть кое-какие мысли по поводу размещения такого рода сервера

[Maks]

Только интересна примерная цена аренды такого сервера?

[dark]

elite, можно пример по первому пункту?
по второму я бы сказал это хорошо, но вот какие в сумме задержки будут?
к примеру у меня сейчас 15-30 мс до яндекса, с таким линком примерно 40-50 будет, это как бы не очень хорошо в моем случае, ибо народ в CS'ы играет, спложной трезвон начнется изза увеличения...

[Maks]

У меня 40-55, Это канал одного из местных провайдеров
Это в пол первого ночи, при свободном канале. Да и когда был около 100 люди не сильно кричали. И скайп и все остальное норм работает.
P.S  Возможно у меня не такие балованные абоны.