digim

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

тоесть после замены тех 50 на 10 все стало в шоколаде?

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

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

кто бы сомневался...а под freebsd?

Хм. Как-то странно. На athlon xp 2500+ и пользователь один? А железо не глючное?... пользователь один, закачка в один поток, чем проверить глючность железа? железо работает 24x7 и других глюков за ним незамечено. мать abit NF7, вторая сетевуха - intel 82559, больше там ничего нет.

у меня на 6.2prerelease без шейпинга и очередей на athlon xp 2500+ и встроенной в чипсет сетевухе от нвидиа из 700мег посчиталось 200 на bpf считалке и успевало около 1 мега на диверте прежде чем сеть отваливалась. пользователь был один

ты извини конечно, но имхо здоровая критика полезна будет - с такой поддержкой даже от бесплатного софта люди порой отворачиваются. какой-то диалог должен же поддерживаться с юзерами, иначе нафиг оно все? или все же ты работаешь не за моральное удовлетворение а за деньги с аукциона? на данный момент про работоспособность под фрей можно сказать так - работоспособно на 30% если принять мифический нетфлоу который видел всего один человек за 30% если пишется для линукса и отлаживается в первую очередь на нем то может фрю и не заявлять?

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

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

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

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

Т.е. как правильно должно быть?? У меня 3 интерфейса: внутренний(em0), контент-сервера(em1) и внешний(fxp0). Нужно считать внутренний трафик, трафик с контент-серверов и инет-трафик. Соответственно 3 направления указаны в rules У меня сейчас так: <Module cap_divert> iface = em0 15701 </Module> т.е. пытаюсь собирать всё, что в итоге идёт внутрь сети.. Что значит - "..для каждого направления должен быть свой порт.." ? Как тогда должна выглядеть секция описания модуля? вот попробуй ради интереса укажи другой порт и посмотри что будет в тво

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

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

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

а можно попросить помочь разобраться в этом вопросе? -линк

покажи в каком месте он ему неудовлетворяет? там на счетчиках явно видно сколько раз правило сработало. ты видно сам плохо разбираешься как работает диверт Да, я тоже newbie в этом деле и до конца не осмыслил технологию, но в данном случае я понял так, как написал и если я не прав - укажите где, буду благодарен. Попробуй просто напросто сначала задивертить пакет на порт divert_cap, а потом его нать, а не наоборот. И напиши - будет ли результат. Для верности можешь tcpdump'ом посмотреть что куда и как идёт. З.Ы.: сорри, детально разбираться в ситуации нет времени сейчас. Если н

А ещё расшифровку, какой интерфейс куда ведет. fxp0 это сетевуха во внешний мир(x.x.x.x), nve0 это локальный адаптер(192.168.2.0/24). я в случае чего тоже могу почитать лекции на тему как работает ipfw, но пока что мне неучу такому никто не сказал в какой хромосоме моя проблема, а информации для выводов я имхо достаточно предоставил.

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

Затора не может быть в других правилах? Может быть попробовать сначала на 2-3-х самых простых и всё разрешающих правилах добится диверта? Потом донаворачивать? Можно посмотреть полностью набор правил? да причем тут другие правила - видно же что диверт и allow идут друг за другом и маска у них совершенно одинаковая, диверт отрабатывает а allow нет - это говорит имхо только об одном - пакеты пропадают после диверсии(во блин как в точку выразился) ну на всякий случай вот весь рулесет: 00010 9905 799571 allow ip from any to me dst-port 22 00050 107729 14237080 divert

кто-нибудь вообще скажет как работает диверт-механизм в СТГ? по аналогии с натд или нет? вот что у меня получается: ---кусок с натд - чисто для демонстрации что натд на машине работает отлично 00050 106448 14170118 divert 8668 ip from 192.168.2.0/24 to any out xmit fxp0 00060 150893 72147124 divert 8668 ip from any to x.x.x.x ------а вот тут самое интересное 00065 177 19823 divert 9999 ip from any to 192.168.2.2 00066 0 0 allow ip from any to 192.168.2.2 как видите после диверта в фаерволе шиш с маслом, почему так может быть? в конфиге СТГ: <Mo

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

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

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