_J_ 0 Опубликовано: 2006-11-30 23:21:34 Share Опубликовано: 2006-11-30 23:21:34 Поставил STG-2.402, система FreeBSD 5.4, Celeron2.4GHz, 1G Ram И во всём этом стоит rlt8139 Так вот что, скачиваю по первому направлению 12 метров, а в билинг попадает около 7 метров. Вот сижу, перекурил весь форум. А может то сетевушка так глючит что пропускает трафик? Или куда нада копать? ЗЫ: Направления все в порядке, т.к. скачивание идет с одного ип Ссылка на сообщение Поделиться на других сайтах
egor2fsys 5 Опубліковано: 2006-12-01 05:08:05 Share Опубліковано: 2006-12-01 05:08:05 Надо попробывать включить модуль подсчета cap_divert вместо cap_bpf. Для этого в конфиге сервера надо сделать так: # <Module cap_bpf> # # </Module> <Module cap_divert> </Module> Ссылка на сообщение Поделиться на других сайтах
_J_ 0 Опубліковано: 2006-12-01 08:08:11 Автор Share Опубліковано: 2006-12-01 08:08:11 Это значит что ядро нада пересобирать с поддержкой divert`а? Ссылка на сообщение Поделиться на других сайтах
stg-34 0 Опубліковано: 2006-12-01 08:25:09 Share Опубліковано: 2006-12-01 08:25:09 Да Ссылка на сообщение Поделиться на других сайтах
_J_ 0 Опубліковано: 2006-12-01 10:26:36 Автор Share Опубліковано: 2006-12-01 10:26:36 Получается что в cap_bpf не успевает просто обсчитать трафик с такой скоростью? Скачивается около 2 мегов в секунду. Или попробовать зафильтровать весь левый трафик на/через рутер правилами нижестоящего брандмауэра? Ссылка на сообщение Поделиться на других сайтах
egor2fsys 5 Опубліковано: 2006-12-01 10:32:25 Share Опубліковано: 2006-12-01 10:32:25 Попробуйте зафильтровать. Ссылка на сообщение Поделиться на других сайтах
_J_ 0 Опубліковано: 2006-12-09 22:48:59 Автор Share Опубліковано: 2006-12-09 22:48:59 Вопщи проделал следующее 1. зафильтровал весь лишний трафик, на рутер разрешен только icmp и 22 tcp и 5555 tcp/udp 2. Сменил сетевые карты на em - intel gogabit 3. Максимально облегчил ядро, выкинул всякие usb. sata и таму-подобную лабуду что не нужна в данном случае 4. Отправл в rules весь халявный трафик в NULL, тоесть всё 192.168.0.0/16 в NULL, а 0.0.0.0/0 DIR1 Чтож - ситуация не изменилась, процентов 20 "пролетает" Сегодня попробовал divert 1. Пересобрал ядрос divert'ом 2. Добавил что надо в конфиг, /sbin/ipfw add `expr $4 '*' 10 + 29001` allow ip from $2 to any // user $1 cat /etc/stargazer/OnConnect /sbin/ipfw add `expr $4 '*' 10 + 28000` divert 15701 ip from $2 to any via em0 // user $1 /sbin/ipfw add `expr $4 '*' 10 + 28001` divert 15701 ip from any to $2 via em0 // user $1 /sbin/ipfw add `expr $4 '*' 10 + 29000` allow ip from any to $2 // user $1 Диверт не возвращает в ядро пакеты, тоесть работа невозможна. Пробовал 15701 как указано в сырцах, так и другие порты. Тоесть сейчас работаю по первой схеме. Что можете посоветовать в данной ситуации? Или есть какието альтернативные сборщики трафика совместимые с freebsd 5.4? Готов оплатить денежку за рабочую версию коллектора. Ссылка на сообщение Поделиться на других сайтах
_J_ 0 Опубліковано: 2006-12-16 21:41:04 Автор Share Опубліковано: 2006-12-16 21:41:04 Установил Slackware Linux 11, на нем stg 2.402.9.7 Скачивал со скоростью около 7-8 мегов в секнду - чтож, результаты похожи на правду. На такой скорости FreeBSD "ловит" примерно около 30% трафика, а линукс справился зачётно. На BSD стояло cap_bpf на Linux cap_ether. Испытания проходили на одном железе (celeron 2.4, 256mb ram, lan rtl8139) при одном пользователе в онлайне. Ссылка на сообщение Поделиться на других сайтах
JenyaP 0 Опубліковано: 2006-12-18 04:36:24 Share Опубліковано: 2006-12-18 04:36:24 Вчера тоже попробовал divert Сервер - Freebsd 5.4 stg 2.402.9.7 rl0 -наружу rl1 - внутрь В stargazer.conf <Module cap_divert> iface=rl1 15701 </Module> В OnConnect /sbin/ipfw add `expr $id '*' 10 + 29000` divert 15701 ip from $ip to any /sbin/ipfw add `expr $id '*' 10 + 29001` divert 15701 ip from any to $ip /sbin/ipfw add `expr $id '*' 10 + 28002` allow ip from $ip to any /sbin/ipfw add `expr $id '*' 10 + 28003` allow ip from any to $ip Странно - если у клиенской машины OS - PCBSD то divert возвращает пакеты и работает безупречно , а если WinXP - то вообще не возвращает. попробовал /sbin/ipfw add `expr $id '*' 10 + 29000` tee 15701 ip from $ip to any /sbin/ipfw add `expr $id '*' 10 + 29001` tee 15701 ip from any to $ip тогда считает примерно в 1,5 раза больше, если WinXP и ровно в 2 раза больше если PCBSD Ссылка на сообщение Поделиться на других сайтах
XoRe 0 Опубліковано: 2006-12-18 04:42:48 Share Опубліковано: 2006-12-18 04:42:48 Возможно, такая фишка изза разных размеров пакетов или ещё каких-то особенностей в служебных данных. Ссылка на сообщение Поделиться на других сайтах
JenyaP 0 Опубліковано: 2006-12-18 04:47:01 Share Опубліковано: 2006-12-18 04:47:01 Менял MTU и ttl на клиентах - не помогает хотяб как нибудь заставить cap_divert вообще не возвращать - проблемма бы решилась, но как? Ссылка на сообщение Поделиться на других сайтах
XoRe 0 Опубліковано: 2006-12-18 07:43:33 Share Опубліковано: 2006-12-18 07:43:33 Попробуй такой способ: В файле: stg-2.402.9.7\projects\stargazer\plugins\capture\divert_freebsd\divert_cap.cpp Ищи функцию int DIVERT_CAP::DivertCapRead(char * b, int blen, char ** iface, int n) В ней есть такая функция: sendto(cddiv.sock, buf, bytes, 0, (struct sockaddr*)&divertaddr, divertaddrSize); Как я понимаю, это отсыл пакета обратно. Так вот, попробуй её закомментировать, перекомпилировать бинарник stg и использовать tee вместо диверта. Только перед компиляцией удали объектные и прочие временные файлы от предыдущей компиляции. Тогда на диверт к STG отсылаться будет копия пакета, а обратно возвращаться не будет. Сам не пробовал, но если интересно, попробуй Ссылка на сообщение Поделиться на других сайтах
JenyaP 0 Опубліковано: 2006-12-18 16:25:41 Share Опубліковано: 2006-12-18 16:25:41 попробовал - к клиенту идет уже один пакет а не два одинаковых, а считается все-равно два Ссылка на сообщение Поделиться на других сайтах
digim 0 Опубліковано: 2006-12-19 01:52:56 Share Опубліковано: 2006-12-19 01:52:56 JenyaP сказав: попробовал - к клиенту идет уже один пакет а не два одинаковых, а считается все-равно два имхо это ты в диверте лишнего надивертил надо не забывать что пакет попадает в фаервол на каждом интерфейсе, плюс ко всему можно задавать уточняющие директивы in out recv xmit для более точной ловли пакетов в нужных местах, и по идее если просто указать from any to any то в системе с двумя сетевухами он может 4 раза посчитать один и тот же трафик. так что курите маны по ипфв, он клевый и вполне этого заслуживает. Ссылка на сообщение Поделиться на других сайтах
JenyaP 0 Опубліковано: 2006-12-19 06:26:42 Share Опубліковано: 2006-12-19 06:26:42 В файле: stg-2.402.9.7\projects\stargazer\plugins\capture\divert_freebsd\divert_cap.cpp есть такая строка #define BUFF_LEN (16436) /* max mtu -> lo=16436 */ а уменя во FreeBSD root@server# ifconfig lo0 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 . . . Ссылка на сообщение Поделиться на других сайтах
digim 0 Опубліковано: 2006-12-19 07:06:53 Share Опубліковано: 2006-12-19 07:06:53 максимальный буфер для приема пакета, с учетом максимального МТУ+запас, причем тут переполнение? вот бы автора диверта сюда... Ссылка на сообщение Поделиться на других сайтах
JenyaP 0 Опубліковано: 2006-12-19 07:40:37 Share Опубліковано: 2006-12-19 07:40:37 digim сказав: JenyaP сказав: попробовал - к клиенту идет уже один пакет а не два одинаковых, а считается все-равно два имхо это ты в диверте лишнего надивертил надо не забывать что пакет попадает в фаервол на каждом интерфейсе, плюс ко всему можно задавать уточняющие директивы in out recv xmit для более точной ловли пакетов в нужных местах, и по идее если просто указать from any to any то в системе с двумя сетевухами он может 4 раза посчитать один и тот же трафик. так что курите маны по ипфв, он клевый и вполне этого заслуживает. почему-же тогда у клиентов XP и BSD счетчики по разному считают. Не понимает mod_cap_divert на stg в bsd виндовые пакеты :tongue: хоть tee хоть divert прикручиваю у знакомого на линухе SUSE 10.0 все ОК c дивертом и у него мту кольцевого 16436 а у меня 16384 Ссылка на сообщение Поделиться на других сайтах
JenyaP 0 Опубліковано: 2006-12-19 08:28:31 Share Опубліковано: 2006-12-19 08:28:31 у клиента WIN ipfw -a list 10080 2921 2917535 tee 15701 ip from any to 192.168.2.3 in via tun0 10082 1647 71602 tee 15701 ip from 192.168.2.3 to any 10087 5859 5835750 allow ip from any to 192.168.2.3 10088 1647 71602 allow ip from 192.168.2.3 to any inetaccess 16154/4315083 у клиента PCBSD ipfw -a list 10010 2558 3685363 tee 15701 ip from any to 192.168.2.2 in via tun0 10012 1732 91240 tee 15701 ip from 192.168.2.2 to any 10017 5116 7370726 allow ip from any to 192.168.2.2 10018 1732 91240 allow ip from 192.168.2.2 to any inetaccess 97154/3734787 О КАК !!! Ссылка на сообщение Поделиться на других сайтах
XoRe 0 Опубліковано: 2006-12-19 12:27:42 Share Опубліковано: 2006-12-19 12:27:42 Советую обратить внимание на 3 колонку в выхлопе ipfw. В условии "from any to 192.168.2.2" трафика после tee становится больше ровно в 2 раза (+-0,00001%). До allow доходят и простые пакеты и их копии. Т.е. делаем вывод, что приходящий к клиенту трафик stg-divert выпускает обратно дальше проверяться правилами фаерволла. А в условии "from 192.168.2.3 to any" трафика на allow после tee ровно столько, сколько его на tee. А ведь до allow доходит не сам пакет, а его копия. Следовательно, исходящий от клиента трафик stg-divert не возвращает в фаерволл. Отсюда приходит решение ситуации (раз уж пошли юзать tee): Для исходящего трафика (from client to any) правило подсчета должно быть tee. Для входящего трафика (from any to client) правило должно быть divert. Правила для проверки для ситуации предыдущего топика должны быть такими: ipfw add 10080 divert 15701 ip from any to 192.168.2.3 in via tun0 ipfw add 10082 tee 15701 ip from 192.168.2.3 to any ipfw add 10087 allow ip from any to 192.168.2.3 ipfw add 10088 allow ip from 192.168.2.3 to any ipfw add 10010 divert 15701 ip from any to 192.168.2.2 in via tun0 ipfw add 10012 tee 15701 ip from 192.168.2.2 to any ipfw add 10017 allow ip from any to 192.168.2.2 ipfw add 10018 allow ip from 192.168.2.2 to any Ссылка на сообщение Поделиться на других сайтах
vop 370 Опубліковано: 2006-12-19 19:16:30 Share Опубліковано: 2006-12-19 19:16:30 Что ж так не везет этой фре Все ж таки, какой способ счета трафика для фри лучше? Ссылка на сообщение Поделиться на других сайтах
asphix 0 Опубліковано: 2006-12-19 20:53:33 Share Опубліковано: 2006-12-19 20:53:33 vop сказав: Что ж так не везет этой фре Все ж таки, какой способ счета трафика для фри лучше? netflow :00: Ссылка на сообщение Поделиться на других сайтах
JenyaP 0 Опубліковано: 2006-12-20 04:45:24 Share Опубліковано: 2006-12-20 04:45:24 XoRe сказав: Советую обратить внимание на 3 колонку в выхлопе ipfw. В условии "from any to 192.168.2.2" трафика после tee становится больше ровно в 2 раза (+-0,00001%). До allow доходят и простые пакеты и их копии. Т.е. делаем вывод, что приходящий к клиенту трафик stg-divert выпускает обратно дальше проверяться правилами фаерволла. А в условии "from 192.168.2.3 to any" трафика на allow после tee ровно столько, сколько его на tee. А ведь до allow доходит не сам пакет, а его копия. Следовательно, исходящий от клиента трафик stg-divert не возвращает в фаерволл. Отсюда приходит решение ситуации (раз уж пошли юзать tee): Для исходящего трафика (from client to any) правило подсчета должно быть tee. Для входящего трафика (from any to client) правило должно быть divert. Правила для проверки для ситуации предыдущего топика должны быть такими: ipfw add 10080 divert 15701 ip from any to 192.168.2.3 in via tun0 ipfw add 10082 tee 15701 ip from 192.168.2.3 to any ipfw add 10087 allow ip from any to 192.168.2.3 ipfw add 10088 allow ip from 192.168.2.3 to any ipfw add 10010 divert 15701 ip from any to 192.168.2.2 in via tun0 ipfw add 10012 tee 15701 ip from 192.168.2.2 to any ipfw add 10017 allow ip from any to 192.168.2.2 ipfw add 10018 allow ip from 192.168.2.2 to any просто трафик два раза проходит через фаервол, а в tee направляю только один поток если ipfw add 10017 allow log ip from any to 192.168.2.2 то Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:62597 in via tun0 Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:62597 out via rl1 Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:62597 in via tun0 Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:62597 out via rl1 Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:52158 in via tun0 Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:52158 out via rl1 Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:52158 in via tun0 Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:52158 out via rl1 но кажется диверт заработал!!! в строке 308 файла divert_cap.cpp заменил if ((bytes = recvfrom (cddiv.sock, buf, BUFF_LEN, 0, (struct sockaddr*) &divertaddr, &divertaddrSize)) > 50) на if ((bytes = recvfrom (cddiv.sock, buf, BUFF_LEN, 0, (struct sockaddr*) &divertaddr, &divertaddrSize)) > 10) и пакеты стали выходить из диверта не только клиентам BSD но и XP в полном об'еме ipfw: 10010 40 28304 divert 15701 ip from any to 192.168.2.2 10017 40 28304 allow ip from any to 192.168.2.2 10018 21 2011 allow ip from 192.168.2.2 to any inetaccess : 0/28304 согласен, правила фаервола оставляют желать лучшего, но не все-же сразу ... Ссылка на сообщение Поделиться на других сайтах
XoRe 0 Опубліковано: 2006-12-20 15:08:47 Share Опубліковано: 2006-12-20 15:08:47 2JenyaP: Траффик через фаерволл проходит 2 раза, но стоит различать, в каком виде он ходит. Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:62597 in via tun0 Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:62597 out via rl1 Советую обратить внимание на концы строк: in via tun0 out via rl1 Фаерволл просто обраьатывает пакет на каждом интерфейсе. Так как пакет проходит 2 интерфейса, то он и обрабатывается 2 раза. Ссылка на сообщение Поделиться на других сайтах
JenyaP 0 Опубліковано: 2006-12-20 15:56:03 Share Опубліковано: 2006-12-20 15:56:03 XoRe сказав: 2JenyaP:Траффик через фаерволл проходит 2 раза, но стоит различать, в каком виде он ходит. Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:62597 in via tun0 Dec 19 12:20:19 e-server kernel: ipfw: 10017 Accept TCP 195.69.84.160:80 192.168.2.2:62597 out via rl1 Советую обратить внимание на концы строк: in via tun0 out via rl1 Фаерволл просто обраьатывает пакет на каждом интерфейсе. Так как пакет проходит 2 интерфейса, то он и обрабатывается 2 раза. да, теперь уже ОБРАБАТЫВАЕТ после перекомпиляции Цитата if ((bytes = recvfrom (cddiv.sock, buf, BUFF_LEN, 0, (struct sockaddr*) &divertaddr, &divertaddrSize)) > 50) на if ((bytes = recvfrom (cddiv.sock, buf, BUFF_LEN, 0, (struct sockaddr*) &divertaddr, &divertaddrSize)) > 10) ну само сабой теперь уже такие строки root@e-server#cat OnConnect fwcmd="/sbin/ipfw -q" ext_if="tun0" ip=$2 name=$1 id=$4 in_if=`cat /var/stargazer/users/$name/conf | grep 'Userdata0=' | cut -d "=" -f2` spddown=`cat /var/stargazer/users/$name/conf | grep 'Userdata1=' | cut -d "=" -f2` spdup=`cat /var/stargazer/users/$name/conf | grep 'Userdata2=' | cut -d "=" -f2` ${fwcmd} pipe `expr $id '*' 10 + 100` config bw ${spddown}Kbit/s ${fwcmd} pipe `expr $id '*' 10 + 101` config bw ${spdup}Kbit/s ${fwcmd} add `expr $id '*' 10 + 10000` divert 15701 ip from any to $ip out via $in_if ${fwcmd} add `expr $id '*' 10 + 10001` divert 15701 ip from $ip to any in via $in_if ${fwcmd} add `expr $id '*' 10 + 10002` fwd 127.0.0.1,3128 tcp from $ip to any 80 ${fwcmd} add `expr $id '*' 10 + 10005` pipe `expr $id '*' 10 + 100` ip from any to $ip out via $in_if ${fwcmd} add `expr $id '*' 10 + 10006` pipe `expr $id '*' 10 + 100` ip from any to $ip in via $ext_if ${fwcmd} add `expr $id '*' 10 + 10007` pipe `expr $id '*' 10 + 101` ip from $ip to any in via $in_if echo 'C18B11' > /dev/speaker ... Ссылка на сообщение Поделиться на других сайтах
bigkit 0 Опубліковано: 2006-12-22 11:17:18 Share Опубліковано: 2006-12-22 11:17:18 А то что cap_bpf в 2.402 пропускает пакеты - официально подтверждено или это у кого как ? И на каких скоростях это становится заметным ? Пробовали ли увеличить буфер bpf ? У меня просто сейчас нет возможности всесторонне этот вопрос исследовать. Может уже кто-то это делал ? Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас