Jump to content
Калькуляторы

Настройка шейпера на интернет и город

Подскажите пожалуйста, не могу придумать как грамотно разрулить шейпера.

Имеем в упрощенном виде:

inet город

\ /

ROUTER

/ \

NAS1 NAS2

|||| ||||

клиенты

 

ROUTER:

FreeBSD 8.2

Bgp, ospf.

 

NAS:

FreeBSD 8.1

Mpd5(pptp), Radius.

 

Нужно настроить шейпера, чтобы скорость интернета у клиентов была согласно тарифному плану,

а городские ресурсы без ограничений. У клиентов реальные IP.

На данный момент шейпер(dummynet) висит на ROUTER на входящем интернет интерфейсе.

На каждый тарифный план выделена своя подсеть и есть несколько правил типа:

00011 pipe 1 ip from any to 111.222.333.0/24 in via eth1

00011 pipe 2 ip from 111.222.333.0/24 to any out via eth1

где eth1 смотрит в инет.

Есть желание все это перевести на таблицы, и уйти от привязки ip адреса к тарифному плану.

 

Думал перенести шейпера на NASы, и формировать таблицу через radius аттрибут mpd-table с tablearg, или шейпить

через ng_car. Но во всех этих случаях скорость ограничивается и на интернет и на город. Есть вариант,

на роутере заворачивать трафик пришедший из инета в влан, а на NASе только его шейпить, но не понятно как

шейпить исходящий, опять будет действовать и на город и на инет.

 

Если поднимать таблицы на ROUTER, то как их там формировать?

Как лучше сделать, подскажите.

Edited by vadius

Share this post


Link to post
Share on other sites

Доброго дня.

 

На роутере правила можно оформить например так (предполагается что "город" и "инет" приходят в разные интерфейсы):

fw="/sbin/ipfw"
fwa="${fw} add"
${fwa} allow ip from any to any in                                  # приходящий в роутер трафик пропускаем сразу
${fwa} skipto 300 ip from any to any recv ${inet_if} xmit ${nas_if} # разобрали входящий инетный трафик
${fwa} skipto 300 ip from any to any recv ${nas_if} xmit ${inet_if} # разобрали исходящий инетный трафик
${fwa} skipto 200 ip from any to any recv ${city_if} xmit ${nas_if} # разобрали входящий "городской" трафик
${fwa} skipto 200 ip from any to any recv ${nas_if} xmit ${city_if} # разобрали исходящий "городской" трафик

${fwa} deny ip from any to recv ${city_if} xmit ${inet_if}          # левый транзит
${fwa} deny ip from any to recv ${inet_if} xmit ${city_if}          # левый транзит

${fwa} 200 allow ip from any to any out                             # трафик пошёл в/из города

${fwa} 300 pipe tablearg ip from any to table\(${inet_in_tbl}\)     # шейпим входящий трафик с инета
${fwa} 301 pipe tablearg ip from table\(${inet_out_tbl}\) any to    # шейпим исходящий трафик в инет
${fwa} 302 allow ip from any to any                                 # кого шейпить не нада, пропускаем

Как заполнять соответствующие таблицы решать вам (если ИПы у пользователей статические, то при заведении в биллинге, если динамика из пула, то можно подумать)

Share this post


Link to post
Share on other sites

Подскажите пожалуйста, не могу придумать как грамотно разрулить шейпера.

Имеем в упрощенном виде:

 

mpd5 умеет шейпить сам. То, что "в трубе" зашейпит mpd5, всё остальное шейпить на ipfw (к примеру) или вообще не шейпить ...

читайте про mpd-filter, mpd-limit, mpd-input-acct и mpd-output-acct

у меня таким способом шепится согласно тарифу всё что в трубе учитывая с каких сетей считать трафик, а с каких не считать (опять же согласно тарифу) клиент просто перекидывается из группы в группу. группа привязана к тарифу, т.е. сменили тариф - сменилась группа, в которую включён клиент, всё на PgSQL, включайте фантазию и всё получится :)

Edited by Grey

Share this post


Link to post
Share on other sites

Шейпинг через таблицы и dummynet: http://forum.nag.ru/forum/index.php?showtopic=54379

Два правила ipfw, две таблицы, по две трубы на каждый тариф, по одной записи в двух таблицах на каждого клиента.

 

Если локальных диапазонов много, поместить их в таблицу.

Иначе проверять списком:

ipfw add 100 allow all from any to 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12

ipfw add 110 allow all from 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12 to any

Правило проверки поставить перед "ipfw pipe tablearg ...".

Если после pipe есть правила, которые надо выполнять для всех, заменить "allow" на "skipto".

Share this post


Link to post
Share on other sites

Благодарю за ответы.

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

Суть такая. По dhcp клиент получает адрес из диапазона "городских" серых адресов, по которым он может ходить по "городским" ресурсам (около 40 других городских сетей), без доступа в инет. После подключения по pptp он получает реальный ip, в этом случает доступ на все ресурсы не ограничен. Вот здесь и надо резать скорость только на инет.

 

mpd5 умеет шейпить сам. То, что "в трубе" зашейпит mpd5, всё остальное шейпить на ipfw (к примеру) или вообще не шейпить ...

читайте про mpd-filter, mpd-limit, mpd-input-acct и mpd-output-acct

у меня таким способом шепится согласно тарифу всё что в трубе учитывая с каких сетей считать трафик, а с каких не считать (опять же согласно тарифу) клиент просто перекидывается из группы в группу. группа привязана к тарифу, т.е. сменили тариф - сменилась группа, в которую включён клиент, всё на PgSQL, включайте фантазию и всё получится :)

пытался и так реализовать, но здесь как я понимаю в mpd-filter нужно перечислять с каких сетей трафик шейпить, а у меня в пиринге порядка 40 городских сетей, список ip-адресов постоянно меняется, таблицы маршрутизации строятся на роутере через bgp. Хотя не исключаю, что я где-то не врубился :)

 

Шейпинг через таблицы и dummynet: http://forum.nag.ru/...showtopic=54379

Два правила ipfw, две таблицы, по две трубы на каждый тариф, по одной записи в двух таблицах на каждого клиента.

спасибо, почитаю приведенную ветку. А если всех клиентов (~4тыс.) активных и не активных, засунуть в таблицы на роутере (с периодическим обновлением), dummynet сможет переварить их нормально? А то может я зря ищу способ как на роутере изменять таблицы при подключении клиента к NASу и его отключении.

Share this post


Link to post
Share on other sites

Благодарю за ответы.

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

Суть такая. По dhcp клиент получает адрес из диапазона "городских" серых адресов, по которым он может ходить по "городским" ресурсам (около 40 других городских сетей), без доступа в инет. После подключения по pptp он получает реальный ip, в этом случает доступ на все ресурсы не ограничен. Вот здесь и надо резать скорость только на инет.

 

mpd5 умеет шейпить сам. То, что "в трубе" зашейпит mpd5, всё остальное шейпить на ipfw (к примеру) или вообще не шейпить ...

читайте про mpd-filter, mpd-limit, mpd-input-acct и mpd-output-acct

у меня таким способом шепится согласно тарифу всё что в трубе учитывая с каких сетей считать трафик, а с каких не считать (опять же согласно тарифу) клиент просто перекидывается из группы в группу. группа привязана к тарифу, т.е. сменили тариф - сменилась группа, в которую включён клиент, всё на PgSQL, включайте фантазию и всё получится :)

пытался и так реализовать, но здесь как я понимаю в mpd-filter нужно перечислять с каких сетей трафик шейпить, а у меня в пиринге порядка 40 городских сетей, список ip-адресов постоянно меняется, таблицы маршрутизации строятся на роутере через bgp. Хотя не исключаю, что я где-то не врубился :)

Если "городские" - это серые, то их не так много и можно указать все сразу (надеюсь серые сети в инет вы не выпускаете). В своё время я долго тестил такое решение и в итоге внедрил. Нареканий нет, всё достаточно гибко и стабильно работает. Причём это без костылей в виде скриптов и т.п., работает на уровне самого mpd (т.е. на уровне ядра).

Share this post


Link to post
Share on other sites

Если "городские" - это серые, то их не так много и можно указать все сразу (надеюсь серые сети в инет вы не выпускаете). В своё время я долго тестил такое решение и в итоге внедрил. Нареканий нет, всё достаточно гибко и стабильно работает. Причём это без костылей в виде скриптов и т.п., работает на уровне самого mpd (т.е. на уровне ядра).

у меня возникает один нюанс: Пока клиент не подключился к впн серверу(pptp), ip у него серый и он свободно может лазить по городским ресурсам, резать скорость не надо, в инет доступа нет. После подключения к впн клиент получает реальный ip и он уже с этим адресом лазит и в инете и в городе. В городе анонсированы и серые и белые адреса клиентов. Поэтому фильтровать город по серым адресам не получается. Вот если бы в mpd-filter можно было указать интерфейс, было бы проще.

Share this post


Link to post
Share on other sites

Если "городские" - это серые, то их не так много и можно указать все сразу (надеюсь серые сети в инет вы не выпускаете). В своё время я долго тестил такое решение и в итоге внедрил. Нареканий нет, всё достаточно гибко и стабильно работает. Причём это без костылей в виде скриптов и т.п., работает на уровне самого mpd (т.е. на уровне ядра).

у меня возникает один нюанс: Пока клиент не подключился к впн серверу(pptp), ip у него серый и он свободно может лазить по городским ресурсам, резать скорость не надо, в инет доступа нет. После подключения к впн клиент получает реальный ip и он уже с этим адресом лазит и в инете и в городе. В городе анонсированы и серые и белые адреса клиентов. Поэтому фильтровать город по серым адресам не получается. Вот если бы в mpd-filter можно было указать интерфейс, было бы проще.

интерфейс чего? интерфейс на NAS, который один для всего (наружу)? или интерфейс на ROUTER? :) или интерфейс в сторону клиента? который ngxx и всегда разный?

Вот что было бы действительно правильно, так это при поднятии pptp передавать клиенту маршруты, но винда это дело игнорирует. Вот если NAS на винде - тогда поедит, а так не хочет. Хотя с другой стороны, если в "городе" в любой момент может приехать анонс новой подсети, то толку от маршрутов никакого ...

Edited by Grey

Share this post


Link to post
Share on other sites

А если всех клиентов (~4тыс.) активных и не активных, засунуть в таблицы на роутере (с периодическим обновлением), dummynet сможет переварить их нормально?

Сможет. У нас так и делается, количество клиентов больше.

Share this post


Link to post
Share on other sites

Сможет. У нас так и делается, количество клиентов больше.

спасибо, пошел по этому пути, уже накатал скрипты.

Share this post


Link to post
Share on other sites

интерфейс чего? интерфейс на NAS, который один для всего (наружу)? или интерфейс на ROUTER? :) или интерфейс в сторону клиента? который ngxx и всегда разный?

у меня на роутере весь трафик идущий с инета к NASу, заворачивается в влан. Сейчас это используется чтобы на NASах была возможность отделить инет от города, и вести учет трафика в биллинге только с инета. так у меня была идея шейпить этот трафик на NASe приходящий по влану с роутера

Share this post


Link to post
Share on other sites

А выдавать маршруты через dhcp "в город" нельзя?

Соответственно при поднятии pptp дается дефолтный в интернет (который шейпится и считается), но статичные маршруты через dhcp всё равно ходят через eth-интерфейс клиента.

Share this post


Link to post
Share on other sites
' timestamp='1305435004' post='613484']

А выдавать маршруты через dhcp "в город" нельзя?

Соответственно при поднятии pptp дается дефолтный в интернет (который шейпится и считается), но статичные маршруты через dhcp всё равно ходят через eth-интерфейс клиента.

верное было бы решение, если бы в "городе" было бы статичесское (или управляемое) кол-во анонсируемых сетей. Но у человека "город" может в любой момент анонсировать какую угодно сеть.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this