stargazer+divert как считать трафик?

[asphix 0]

Я не зря постил ссылку на опеннет. Ещё раз привожу выдержку из man:

---8<-------

After translation by natd, packets re-enter the firewall at the rule

number following the rule number that caused the diversion (not the

next rule if there are several at the same number).

---8<---------

 

В твоём случае получается, что после ната, пакет(уже преобразованный) доходит до правила диверта и.. неудовлетворяет правилам последнего.

 

Попробуй делать нат после диверсии чтоли

 

-- Пока писал XoRe опередил с ответом

покажи в каком месте он ему неудовлетворяет? там на счетчиках явно видно сколько раз правило сработало. ты видно сам плохо разбираешься как работает диверт

Да, я тоже newbie в этом деле и до конца не осмыслил технологию, но в данном случае я понял так, как написал и если я не прав - укажите где, буду благодарен.

 

Попробуй просто напросто сначала задивертить пакет на порт divert_cap, а потом его нать, а не наоборот. И напиши - будет ли результат.

 

Для верности можешь tcpdump'ом посмотреть что куда и как идёт.

 

З.Ы.: сорри, детально разбираться в ситуации нет времени сейчас. Если не получится, можно чуть позже рассмотреть более подробно.

[digim 0]

Я не зря постил ссылку на опеннет. Ещё раз привожу выдержку из man:

---8<-------

After translation by natd, packets re-enter the firewall at the rule

number following the rule number that caused the diversion (not the

next rule if there are several at the same number).

---8<---------

 

В твоём случае получается, что после ната, пакет(уже преобразованный) доходит до правила диверта и.. неудовлетворяет правилам последнего.

 

Попробуй делать нат после диверсии чтоли

 

-- Пока писал XoRe опередил с ответом

покажи в каком месте он ему неудовлетворяет? там на счетчиках явно видно сколько раз правило сработало. ты видно сам плохо разбираешься как работает диверт

Да, я тоже newbie в этом деле и до конца не осмыслил технологию, но в данном случае я понял так, как написал и если я не прав - укажите где, буду благодарен.

 

Попробуй просто напросто сначала задивертить пакет на порт divert_cap, а потом его нать, а не наоборот. И напиши - будет ли результат.

 

Для верности можешь tcpdump'ом посмотреть что куда и как идёт.

 

З.Ы.: сорри, детально разбираться в ситуации нет времени сейчас. Если не получится, можно чуть позже рассмотреть более подробно.

после ната в пакете меняется адрес назначения на адрес из сетки 192.168.2.0/24 , его я и отлавливаю своим дивертом, у фаервола есть счетчики - первый это количество пакетов попавших под правило, второй - количество байт, отсюда видно что диверт срабатывает.

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

 

2 ребята из stg груп - вам по теме сказать нечего вообще чтоли?

[digim 0]

ха, я тут такое интересное раскопал в механизме работы СТГ-диверт что обхохочетесь...инфа будет сегодня чуть позже

[digim 0]

так вот - поковырявшись в исходниках выяснилось что текущий код документации не соответствует совершенно.

то что указано в http://www.stargazer.dp.ua/doc20/conf_divert.html просто не будет работать на диверт-портах отличных от 15701, для задания порта оказывается используется директива Port в секции конфигурации cap_divert.

и похоже никакого намека на то что для каждого направления должен быть свой порт

хотя чему удивляться - документации под 2.4 на сайте до сих пор нет.

но даже с учетом этого диверт как следует у меня не заработал...

[Max 0]

не дока то по 2.4 есть в пдфе

[asphix 0]

так вот - поковырявшись в исходниках выяснилось что текущий код документации не соответствует совершенно.

то что указано в http://www.stargazer.dp.ua/doc20/conf_divert.html просто не будет работать на диверт-портах отличных от 15701, для задания порта оказывается используется директива Port в секции конфигурации cap_divert.

и похоже никакого намека на то что для каждого направления должен быть свой порт

хотя чему удивляться - документации под 2.4 на сайте до сих пор нет.

но даже с учетом этого диверт как следует у меня не заработал...

Т.е. как правильно должно быть??

 

У меня 3 интерфейса: внутренний(em0), контент-сервера(em1) и внешний(fxp0).

 

Нужно считать внутренний трафик, трафик с контент-серверов и инет-трафик. Соответственно 3 направления указаны в rules

 

У меня сейчас так:

 

<Module cap_divert>

 

iface = em0 15701

 

</Module>

 

т.е. пытаюсь собирать всё, что в итоге идёт внутрь сети..

 

Что значит - "..для каждого направления должен быть свой порт.." ?

 

Как тогда должна выглядеть секция описания модуля?

[digim 0]

не дока то по 2.4 есть в пдфе

есть, но там ни слова про диверт

[digim 0]

так вот - поковырявшись в исходниках выяснилось что текущий код документации не соответствует совершенно.

то что указано в http://www.stargazer.dp.ua/doc20/conf_divert.html просто не будет работать на диверт-портах отличных от 15701, для задания порта оказывается используется директива Port в секции конфигурации cap_divert.

и похоже никакого намека на то что для каждого направления должен быть свой порт

хотя чему удивляться - документации под 2.4 на сайте до сих пор нет.

но даже с учетом этого диверт как следует у меня не заработал...

Т.е. как правильно должно быть??

 

У меня 3 интерфейса: внутренний(em0), контент-сервера(em1) и внешний(fxp0).

 

Нужно считать внутренний трафик, трафик с контент-серверов и инет-трафик. Соответственно 3 направления указаны в rules

 

У меня сейчас так:

 

<Module cap_divert>

 

iface = em0 15701

 

</Module>

 

т.е. пытаюсь собирать всё, что в итоге идёт внутрь сети..

 

Что значит - "..для каждого направления должен быть свой порт.." ?

 

Как тогда должна выглядеть секция описания модуля?

вот попробуй ради интереса укажи другой порт и посмотри что будет

в твоем случае можно сделать три диверта по трем направлениям на один порт, порт указывается так - Port = xxxx но его можно просто не указывать - тогда по дефолту будет 15701

 

а что такое "..для каждого направления должен быть свой порт.." и почему должно быть так я сам не знаю - так сказано в той доке по дивертам которая лежит на сайте стг.

[XoRe 0]

2digim:

Начиная с версии FreeBSD 5.0 (может и раньше), открытые divert порты можно посмотреть командой:

sockstat -4l | grep div

 

Насчет того, что divert СТГ не возвращает пакеты - была такая фича в версиях 2.0х.

Я по этому поводу давно провел исследования и обнародовал их на форуме.

Но в твоем случае, имхо, пакеты дивертуются в неоткрытый порт, т.е. вникуда.

Поэтому не обрабатываются СТГ и не возвращаются назад.

 

Для исследований можешь попробовать директиву tee - тот же divert, только в порт отправляется копия пакета.

А сам пакет продолжает идти по правилам.

И копия после обработки может вернуться и дальше путешествовать )

Т.е. запросы от юзера будут удваиваться, но считать СТГ будет только половину )

Если будет считать, конечно )

[asphix 0]

Экспериментировал 2 дня на тему.. попробовал разные варианты правил.. нифига ( Трафик считается, но не весь и неправильно(иногда вообще не считается) Наверняка ошибка в правилах, но не пойму точно где :muu:

 

Может быть многоуважаемый all поможет найти истину?

 

 

---8< RULES >8----

# Пинги

ICMP 0.0.0.0/0 NULL

 

# Локальные ресурсы

ALL 10.101.0.0/24 DIR0

 

# Трафик на роутер

ALL 10.101.0.1 DIR0

ALL 10.101.1.1 DIR0

 

# Трафик с файл-сервера

ALL 10.101.1.2 DIR1

 

# Трафик с игрового сервера

ALL 10.101.1.3 DIR2

 

# Интернет-трафик

ALL 0.0.0.0/0 DIR3

--------8<------------

 

---8< STARGAZER.CONF >8----

<Module cap_divert>

iface = em0 15701 -- Внутренний интерфейс, чтобы считать только входящие к юзерам (или этого не достаточно??)

#iface = em1 15701 -- файл-сервер, игровой сервер

#iface = fxp0 15701 -- интернет

</Module>

--------8<------------

 

Правила файрволла такие:

 

# Описания интерфейсов

ext="fxp0" -- инет

int="em0" -- юзеры

srv="em1" -- контент

admin="10.101.1.5"

 

# Сброс текущих правил

ipfw -f flush

 

ipfw add 10 pass all from any to any via lo0

ipfw add 20 deny all from any to 127.0.0.0/8

ipfw add 30 deny all from 127.0.0.0/8 to any

 

# divert all

ipfw add 50 divert natd ip from any to any out via ${ext}

ipfw add 60 divert natd ip from any to me in via ${ext}

 

# Statefull

ipfw add 70 check-state

 

# icmp for all without authorization

ipfw add 80 pass icmp from any to any icmptype 0,3,4,8,11,12

 

# Разрешаем раздачу адресов по DHCP без авторизации

ipfw add 90 pass udp from 0.0.0.0 68 to 255.255.255.255 67 via ${int}

 

# Разрешаем админу коннектица конфигуриратором и по ssh

ipfw add 100 pass tcp from ${admin} to me 5555 in via ${srv}

ipfw add 110 pass tcp from ${admin} to me 22 in via ${srv}

 

# Разрешаем юзерам подключатся к серверу для авторизации

ipfw add 120 pass udp from 10.101.0.0/24 to me 5555 in via ${int}

 

# Разрешаем dns-запросы для всех

ipfw add 130 pass udp from any to any 53,123

ipfw add 140 pass udp from any 53,123 to any

 

# Правила юзеров (Добавляются из OnConnect)

ipfw add 30010 divert 15701 all from any to any via ${int} -- считаю только пакеты, проходящие через внутренний интерфейс, т.е. входящий для юзеров.

ipfw add 30020 pass all from any to any keep-state -- разрешаем всё юзерам

 

# Разрешаем исходящий трафик от сервера для всех

ipfw add 65520 pass ip from me to any out

 

# Запрещаем всё остальное

ipfw add 65530 deny all from any to any

 

-------------------------

Помогите плиз разобраться?

[digim 0]

2digim:

Начиная с версии FreeBSD 5.0 (может и раньше), открытые divert порты можно посмотреть командой:

sockstat -4l | grep div

 

Насчет того, что divert СТГ не возвращает пакеты - была такая фича в версиях 2.0х.

Я по этому поводу давно провел исследования и обнародовал их на форуме.

Но в твоем случае, имхо, пакеты дивертуются в неоткрытый порт, т.е. вникуда.

Поэтому не обрабатываются СТГ и не возвращаются назад.

 

Для исследований можешь попробовать директиву tee - тот же divert, только в порт отправляется копия пакета.

А сам пакет продолжает идти по правилам.

И копия после обработки может вернуться и дальше путешествовать )

Т.е. запросы от юзера будут удваиваться, но считать СТГ будет только половину )

Если будет считать, конечно )

вобщем все проверил на 10 раз уже - не работает диверт в старгейзере под моей системой и точка. после применения диверт-правила секунд десять он возвращает пакеты в ядро и я даже успеваю увидеть это в статистике СТГ - потом связь с сервером рвется, пакеты перестают возвращаться старгейзером.

финита ля комедия

[asphix 0]

В связи с этим появилось несколько вопросов:

 

1. Какова вероятность того, что баг не в системе, а в модуле?

 

2. Если уж на то пошло, то кто-нибудь может сказать относительно проблемы потери пакетов при использовании cap_bpf - какая должна быть скорость или нагрузка на роутер, чтобы stg начал терять пакеты?

[_J_ 0]

Такая же проблема, cap_bpf пропскает трафик, а divert не отдаёт после старгазера

система FreeBsd5.4,

Тут пришёл к выводу что потеря начинается не из-за больших потоков, а из-за большого голичества пользователей в онлайне.

При одном пользователе у меня нормально обсчитывается поток гдето около 20 мегабит, больше просто нету. А рабочая лошадка тянет около 20-30 юзеров в онлайне и поток через сервер в средном полмегабита - начинает врать.

[asphix 0]

Такая же проблема, cap_bpf пропскает трафик, а divert не отдаёт после старгазера

система FreeBsd5.4,

Тут пришёл к выводу что потеря начинается не из-за больших потоков, а из-за большого голичества пользователей в онлайне.

При одном пользователе у меня нормально обсчитывается поток гдето около 20 мегабит, больше просто нету. А рабочая лошадка тянет около 20-30 юзеров в онлайне и поток через сервер в средном полмегабита - начинает врать.

Polling? Железо? Сетевухи? Должно же быть какое-то разумное объяснение проблеме потери?..

 

Интересно, а что думают разработчики по поводу диверта? :loop:

[_J_ 0]

При поллинге пропуск только увеличивается

Железо вроде не слишком убогое

Celeron 2.4, 1G Ram, lan 2 x intel gigabit ( em*)

Причём вкупе со старгазером работает trafd у которого всё более-менее зер гуд.

Может раасуждения ламака, но ведь судя по названию и модуль cap_bpf и trafd используют этот самый беркли пакет фильтр. Может существуют разные версии этого самого bpf? попробовать думаю на четверке - может там что то другое будет. Также подумываю о линуксе, сйчас завел без нагрузки на slackware11, думаю на днях заменть рутер с фрёй на рутер с линухом - может поможет

[Max 0]

я давно всем говорю пользуйте нетфлоу, но почему то меня никто не слушает, может 25 баксов жалко? Ну тогда теряйте дальше и больше.

[XoRe 0]

2Max:

"На что только не идут русские, чтобы не покупать cisco" ©

Здесь тот же случай.

 

2all:

Если есть интерес к решению этой задачи, попробуйте заменить divert на tee.

Раз отдавать пакеты не хочет, то может быть хоть считать будет )

[digim 0]

я давно всем говорю пользуйте нетфлоу, но почему то меня никто не слушает, может 25 баксов жалко? Ну тогда теряйте дальше и больше.

зачем платить 25 баксов за нетфлоу от старгейзера если есть более другие рабочие решения(netams, abills), тем более что у нетфлоу своя специфика и он подходит далеко не всем.

да и общая волна у СТГ какая-то неработоспособная, нетфлоу то не косячит случаем?

[digim 0]

2Max:

"На что только не идут русские, чтобы не покупать cisco" ©

Здесь тот же случай.

 

2all:

Если есть интерес к решению этой задачи, попробуйте заменить divert на tee.

Раз отдавать пакеты не хочет, то может быть хоть считать будет )

а зачем мусорить в системе дубликатами пакетов? еще неизвестно какие после этого можно поиметь дополнительные глюки(я про tee)

я уже адаптирую под свои нужды другое решение, жаль что эксперимент с СТГ неудался, по простоте развертывания он мне подходит, но видать не за теми зайцами надо гнаться...

[Max 0]

2Max:

"На что только не идут русские, чтобы не покупать cisco" ©

Здесь тот же случай.

 

2all:

Если есть интерес к решению этой задачи, попробуйте заменить divert на tee.

Раз отдавать пакеты не хочет, то может быть хоть считать будет )

я про модуль нетфлоу имел ввиду

 

зачем платить 25 баксов за нетфлоу от старгейзера если есть более другие рабочие решения(netams, abills),

У этих других рабочих решений есть куча минусов, не присущих старгейзеру.

 

тем более что у нетфлоу своя специфика и он подходит далеко не всем

С этим согласен не совсем, в 99% случаев нетфлоу спасает...

 

да и общая волна у СТГ какая-то неработоспособная, нетфлоу то не косячит случаем?

Нет он нами написан и за 3 месяца глюков не было не одного

[Max 0]

я уже адаптирую под свои нужды другое решение, жаль что эксперимент с СТГ неудался, по простоте развертывания он мне подходит, но видать не за теми зайцами надо гнаться...

а по мне дак все остальные биллинги (из бесплатных) не подходят, по причине что это или набор пхп скриптов (abils) или слишком громоздкое и сложное в настройке чудо (netams)

[_J_ 0]

я давно всем говорю пользуйте нетфлоу, но почему то меня никто не слушает, может 25 баксов жалко? Ну тогда теряйте дальше и больше.

Нетфлоу, так ведь это просто замечательно, дайте две

Нет, 25 баксов не жалко.

Вы принмаете WMZ, WMR?

как с вами связаться? А то вместо сведений по профилю - чистый лист.

Моя ася 156821658

[digim 0]

конечно он спасает, в таких вот случаях, когда другие механизмы просто не работают

 

его потоковая специфика непозволяет отключать своевременно и обеспечивать полноценные авансовые условия работы

[Max 0]

я давно всем говорю пользуйте нетфлоу, но почему то меня никто не слушает, может 25 баксов жалко? Ну тогда теряйте дальше и больше.

Нетфлоу, так ведь это просто замечательно, дайте две

Нет, 25 баксов не жалко.

Вы принмаете WMZ, WMR?

как с вами связаться? А то вместо сведений по профилю - чистый лист.

Моя ася 156821658

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

[Max 0]

конечно он спасает, в таких вот случаях, когда другие механизмы просто не работают

 

его потоковая специфика непозволяет отключать своевременно и обеспечивать полноценные авансовые условия работы

да тут, согласен, но помоему тот же ipcad позволяет сделать минимальным интервал слива статы на билинг, хотя точно не скажу сам ng_netflow&cisco пользую