STG-2.402 пропускает трафик

[_J_ 0]

Поставил STG-2.402, система FreeBSD 5.4, Celeron2.4GHz, 1G Ram

И во всём этом стоит rlt8139

Так вот что, скачиваю по первому направлению 12 метров, а в билинг попадает около 7 метров. Вот сижу, перекурил весь форум. А может то сетевушка так глючит что пропускает трафик?

Или куда нада копать?

ЗЫ: Направления все в порядке, т.к. скачивание идет с одного ип

[egor2fsys 5]

Надо попробывать включить модуль подсчета cap_divert вместо cap_bpf.

Для этого в конфиге сервера надо сделать так:

 

# <Module cap_bpf>

#

# </Module>

 

<Module cap_divert>

 

</Module>

[_J_ 0]

Это значит что ядро нада пересобирать с поддержкой divert`а?

[stg-34 0]

Да

[_J_ 0]

Получается что в cap_bpf не успевает просто обсчитать трафик с такой скоростью?

Скачивается около 2 мегов в секунду.

Или попробовать зафильтровать весь левый трафик на/через рутер правилами нижестоящего брандмауэра?

[egor2fsys 5]

Попробуйте зафильтровать.

[_J_ 0]

Вопщи проделал следующее

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]

Установил 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]

Вчера тоже попробовал 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]

Возможно, такая фишка изза разных размеров пакетов или ещё каких-то особенностей в служебных данных.

[JenyaP 0]

Менял MTU и ttl на клиентах - не помогает

хотяб как нибудь заставить cap_divert вообще не возвращать - проблемма бы решилась, но как?

[XoRe 0]

Попробуй такой способ:

 

В файле:

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]

попробовал - к клиенту идет уже один пакет а не два одинаковых, а считается все-равно два

[digim 0]

попробовал - к клиенту идет уже один пакет а не два одинаковых, а считается все-равно два

имхо это ты в диверте лишнего надивертил

надо не забывать что пакет попадает в фаервол на каждом интерфейсе, плюс ко всему можно задавать уточняющие директивы in out recv xmit для более точной ловли пакетов в нужных местах, и по идее если просто указать from any to any то в системе с двумя сетевухами он может 4 раза посчитать один и тот же трафик.

так что курите маны по ипфв, он клевый и вполне этого заслуживает.

[JenyaP 0]

В файле:

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]

максимальный буфер для приема пакета, с учетом максимального МТУ+запас, причем тут переполнение?

вот бы автора диверта сюда...

[JenyaP 0]

попробовал - к клиенту идет уже один пакет а не два одинаковых, а считается все-равно два

имхо это ты в диверте лишнего надивертил

надо не забывать что пакет попадает в фаервол на каждом интерфейсе, плюс ко всему можно задавать уточняющие директивы 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]

у клиента 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]

Советую обратить внимание на 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 366]

Что ж так не везет этой фре

Все ж таки, какой способ счета трафика для фри лучше?

[asphix 0]

Что ж так не везет этой фре

Все ж таки, какой способ счета трафика для фри лучше?

netflow :00:

[JenyaP 0]

Советую обратить внимание на 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]

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]

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]

А то что cap_bpf в 2.402 пропускает пакеты - официально подтверждено или это у кого как ? И на каких скоростях это становится заметным ? Пробовали ли увеличить буфер bpf ?

У меня просто сейчас нет возможности всесторонне этот вопрос исследовать. Может уже кто-то это делал ?