Компания NetUP объявляет об открытии исходных кодов коллектора статистики ndsad по лицензии GPL.Демон ndsad предназначен для сбора информации по трафику с интерфейсов PC-маршрутизатора и экспорта ее в формате NetFlow.
Проект будет базироваться на SourceForge. Получить последнюю версию
исходных кодов ndsad можно через CVS:
- cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ndsad login
- cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ndsad co -PURL: http://www.netup.ru/index.php?news=47
Новость: http://www.opennet.me/opennews/art.shtml?num=5625
Ну часть это весьма куцая, единственно в чем может быть ее применение - Netflow коллектор под Win32. Для *nix есть вещи много лучшие, например ipcad, не говоря уже про "ядерный" ng_netflow.
Обычный PR. Я этот ndsad никогда для работы UTM5 не использую - ибо дюже нестабильно.
Именно.
1)Страница http://sourceforge.net/projects/ndsad/ - не открывается.
2)
# cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ndsad co -P
cvs [checkout aborted]: must specify at least one module or directory
# cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ndsad checkout ndsad -P
cvs server: cannot find module `-P' - ignored
cvs [checkout aborted]: cannot expand modules
> Я этот ndsad никогда для работы UTM5 не использую - ибо дюже нестабильно.
Да ладно уж вам... ipcad гнило держит tun*. Кто использовал - тот знает, какие нужны для этого дополнительно телодвижения. ng_netflow подходит далеко не для всех (кстати, подкиньте кто-нить доку, как его, собственно, к ng* прикрутить - та, которая лежит в инете не прокатывает, ибо тип ng* сейчас не tee, как был раньше, а bpf - как с этим быть - ХЗ...).
А тут - простая и нормальная тулза. Я ей как раз tun* отлично считаю и радуюсь.
работает ipcad номрально с tun* - и проблем нет
Вот пример конекта к ng* из mpd.
# cat /root/bin/acct_if.sh
#!/bin/sh
# script interface inet local-ip remote-ip authname [ dns1 server-ip ] [ dns2 server-ip ]i=`echo $1 | sed -e "s/ng//"`
# connect ng0's tee to ifaceN hook
# right to upper, left iface
#ngctl connect ng$i:inet netflow: right2left iface$i
ngctl connect ng$i:inet netflow: left2right iface$i
idx=`echo $i+100 | bc`
ngctl msg netflow: setifindex { iface=$i index=$idx }
# to raw mode
ngctl msg netflow: setdlt { iface=$i dlt=12 }
==
сделано собственно по мотивам man ng_netflow.
В догонку - на mpd наложен пачт который сам вставляет tee ноду (ищется в инете легко), но с последним вариантом ng_netflow из HEAD и это не надо.
Дык, это и я могу... Пробовал - не пахало... Под чем оно у тебя работает? Вообще, у тебя show на ng* что выдает? Тип какой?
А вообще, вылези, плиз, мне в мыло. Побеседуем. :-)))
Работает на RELENG_5, начало с чего-то далеко за 5.4pre.
vpn# ngctl ls
There are 134 total nodes:
Name: ngctl4761 Type: socket ID: 000000a2 Num hooks: 0
Name: <unnamed> Type: ksocket ID: 0000009e Num hooks: 1
Name: <unnamed> Type: pptpgre ID: 0000009d Num hooks: 2
Name: <unnamed> Type: vjc ID: 00000090 Num hooks: 4
Name: <unnamed> Type: tee ID: 0000008f Num hooks: 2
Name: <unnamed> Type: bpf ID: 0000008e Num hooks: 3
Name: mpd-c_pptp19 Type: ppp ID: 0000008d Num hooks: 6
еще раз говорю - на mpd наложен патч
15866 Mar 2 10:43 patch-tee-kill.diff
это комбинация из 2-х патчей
1) который вставляет ng_tee между pptp & bpf.
2) который по радиус атрибуту снимает юзера с линии.
Оба находятся помоему через архивы freenibs или раздел патчи sf.net/projects/mpd.
Все дальше наслаждаемся жизни - прикинув направления трафика что бы в netflow небыло дублирования.
Привет.
Есть у Статей на тему билинга/поднятия ВПН-сервера один дедочет.
А имено: не написано - как соеденить подключившихся к Серверу пользователей и Инет к которому подсоеденён Сервер.
Тоесть - как и где использовать НАТ/фаер и т.д.
Лутше б эту часть нормально описывали в доках, чем ПР-разводили
VPN-сервер должен просто маскировать NAT'ом IP-адреса пользователей, выдаваемые им при подключении через VPN, под свой, смотрящий к внешнему провайдеру.
Строка, скажем, в ipnat.rules, будет выглядеть примерно так:map внешний_интерфейс from 192.168.0.0/16 ! to 192.168.0.0/16 -> IP_внешнего_интерфейса
Фаерволл, как и на шлюзе без VPN, должен резать порты, которые являются небезопасными по мнению администратора, и разрешать доступ IP-адресам на базе данных билинговой системы. То есть, если пользователю 192.168.x.y разрешено выходить в интернет, VPN-сервер получает об этом сведения и создает в динамике правило, если же нет, пользователь присоединяется к VPN-серверу, но доступ далее не получает.