Шлюз в инет на основе FreeBSD

[RoomBot]

Всем добрго дня :)

 

Собираю шлюз в инет на локальную сеть примерно из 1.5к абонентов.

Планирую использовать сервер на FreeBSD с Intel PRO/1000 PT Dual Port - em0 в Интернет, em1 - в Локальную сеть. В дополнение к этому ng_car, ng_netflow, ipfw nat и сам ipfw. Каждому абону ставится номер contract ID (cid) который используется в обрезалке скорости. Такде предоставляем безлимитные тарифы и реальный IP адрес.

 

Базовый конфиг ipfw

00001 nat 1 ip from any to any in via em0

00002 allow tcp from table(5) to xx.xx.xx.251,xx.xx.xx.100 dst-port 22

00003 allow tcp from xx.xx.xx.18 to xx.xx.xx.251 dst-port 4567

00004 deny tcp from any to xx.xx.xx.251,xx.xx.xx.100 dst-port 22,4567

00005 skipto tablearg ip from any to table(1)

00006 skipto tablearg ip from table(2) to any

00007 allow ip from any to xx.xx.xx.251,xx.xx.xx.100

00008 allow ip from xx.xx.xx.251,xx.xx.xx.100 to any

00009 deny ip from any to any

# Блок обработки входящего трафа серых ip адресов (безлимитчики)

00500 netgraph tablearg tag 1 ip from any to table(11) out via em1

00501 ngtee 65534 ip from any to any out via em1

00502 allow ip from any to any

# Блок обработки исходящего трафа серых ip адресов (безлимитчики)

01000 netgraph tablearg tag 1 ip from table(12) to any in via em1

01001 ngtee 65534 ip from any to any in via em1

01002 nat 1 ip from any to any out via em0

01003 allow ip from any to any

# Блок обработки входящего трафа реальников (безлимитчики)

01500 netgraph tablearg tag 1 ip from any to table(11) out via em1

01501 ngtee 65534 ip from any to any out via em1

01502 allow ip from any to any

# Блок обработки исходящего трафа реальников (безлимитчики)

02000 netgraph tablearg tag 1 ip from table(12) to any in via em1

02001 ngtee 65534 ip from any to any in via em1

02002 allow ip from any to any

# Блок обработеи входящего трафа серых ip адресов

02500 ngtee 65534 ip from any to any out via em1

02501 allow ip from any to any

# Блок обработеи исходящего трафа серых ip адресов

03000 ngtee 65534 ip from any to any in via em1

03001 nat 1 ip from any to any out via em0

03002 allow ip from any to any

# Блок обработки входящего трафа реальников

03500 ngtee 65534 ip from any to any out via em1

03501 allow ip from any to any

# Блок обработки исходящего трафа реальников

04000 ngtee 65534 ip from any to any in via em1

04001 allow ip from any to any

65535 allow ip from any to any

 

В 1 таблицу пишется номер правила на которое прыгать, в соответствии с типом ip адреса (реальник, "серый", лимитчик или безлимитчик) для входящего трафа, а в таблицу 2 - для исходящего трафа. В 65534 хук дублируются пакеты для обсчёта трафа.

в 11 и 12 таблицы пишется номера хука ng_ipfw, соединённых с соответствующей нодой ng_car, в которой режется скорость.

 

Стартовая конфигурация netgraph для обсчёта трафика

mkpeer ipfw: netflow 65534 iface0

name ipfw:65534 netflow

msg netflow: setdlt { iface = 0 dlt = 12 }

msg netflow: setifindex { iface = 0 index = 1 }

mkpeer netflow: ksocket export inet/dgram/udp

msg netflow:export connect inet/xx.xx.xx.23:1670

 

Нода ng_car конфигурится следующими командами:

mkpeer ipfw: car $сid upper

name ipfw:$i_сid rate_$сid

connect rate_$сid: ipfw: lower $o_сid

Далее конфигурируется пропускная способность.

 

На данный момент через этот шлюз подключены примерно 350 абонентов. Трафик мизерный - 4-7Мбайт входящего в ЧНН. Нагрузка на проц 2-3% (cтоит Core-Quad).

Тем не менее мне схема кажется не очень хорошей, в первую очередь из-за ограничения в ngctl, что нельзя посмореть больше 1000 но командой ngctl list, а во вторых некоторая сложность конфигурационных скриптов при заведении абонента. И (по моему мнению) кривое прохождение трафа в системе - ipfw -> netgraph -> ipfw -> netflow (через netgraph). Просто ничего пооптимальнее придумать не смог (через pf например и ng_nat) :(

К тому же я не могу предсказать, что будет при заведении например 10000 нод в netgraph?? И как поведёт себя ng_car на больших скоростях ~12-20Мбит??

 

Использовал ли кто netgraph подобным образом со стольким количеством нод?

Заранее спасибо за ответы ))

[hmd]

не совсем понятно зачем мешать сюда NG

посмотри в сторону Ipfw mask

[RoomBot]

не совсем понятно зачем мешать сюда NG

посмотри в сторону Ipfw mask

А как с помощью ipfw mask-src/dst организовать выдачу абонам 2-3... IP адреса? Подсетку /29 выдавать?

И помом, dummynet задерживает пакеты (шейпит), а ng_car именно ограничивает скорость (rate-limit), что ИМХО работает побыстрее :)

 

Edited November 4, 2008 by RoomBot

[jab]

 

При такой нагрузке можно хоть по две трубы на рыло создавать в dummynet и обсчитывать это все через ipcad netflow, проц прожует и не заметит. При таком запасе по производительности нужно выбирать простейшие решения.

[RoomBot]

При такой нагрузке можно хоть по две трубы на рыло создавать в dummynet и обсчитывать это все через ipcad netflow, проц прожует и не заметит. При таком запасе по производительности нужно выбирать простейшие решения.

Ну да - dummynet было первым, что я пробовал: всё работало в принципе неплохо, пока dummynet вместе с сервом не стали зависать из-за syn флуда. Подозреваю конечно, что дело было в моих кривых руках и можно было бы проблему как-то решить, оптимизировав переменные ядра (память, mbuf и т.п.), но не стал.

ng_car понравился больше, в первую очередь из-за того, что при его соответствующей настройке tcp трафик режется правильно, а udp и icmp проходят без задержек и почти без потерь.

Ipcad не юзал никогда - сразу почему-то взялся за kernel решение...

 

Посмотрим как шлюз будет себя вести когда навешу на него все 1.5 абонентов...

[snark]

(по моему мнению) кривое прохождение трафа в системе - ipfw -> netgraph -> ipfw -> netflow (через netgraph)

а где у Вас возвращение пакетов из нетграфа? у Вас не:

 

ipfw -> netgraph -> ipfw -> netflow

а

 

ipfw -> ng_car
+
ipfw -> ng_netflow

[TiFFolk]

skipto tablearg ip from

 

Не кэшируется, пробегает по всем правилам. Переделывайте на статические skipto.

 

 

netgraph tablearg tag 1 ip from any to table(11) out via em1

 

Зачем вы ставите тег?

[photon]

Здесь не нужен Netgraph, если нет PPPoE и прочего. Для шейпинга достаточно банального dummynet с динамическими пайпами и таблицами.

Ну да - dummynet было первым, что я пробовал: всё работало в принципе неплохо, пока dummynet вместе с сервом не стали зависать из-за syn флуда. Подозреваю конечно, что дело было в моих кривых руках и можно было бы проблему как-то решить, оптимизировав переменные ядра (память, mbuf и т.п.), но не стал.

SYN-flood направлен на DoS-атаку сервисов, использующих TCP-протокол. Шейпер TCP-заголовки не парсит, ему по барабану, какие там флаги в пакетах установлены.

ng_car понравился больше, в первую очередь из-за того, что при его соответствующей настройке tcp трафик режется правильно, а udp и icmp проходят без задержек и почти без потерь.

Это какие-то галлюцинации. Dummynet и ng_car -- реализации одного и тот же алгоритма token bucket. Они работают просто с пакетами как таковыми, а не с сетевыми протоколами. То, о чем вы пишете, называется приоритезация трафика. Edited February 11, 2010 by photon

[Ivan_83]

некропостеры

[TiFFolk]

Это все snark =)

[snark]

это все гугл виноват :)

этот топик обычно в первых 3-х ссылках