Про варианты подсчета траффика хорошо сказано тут
hxxp://www.unixfaq.ru/index.pl?req=qs&id=247 . Все варианты работают на 100%, но все это действует для маршрутизаторов в случае когда нет прокси. При установке прокси все не так просто.
Предположим простую сетку стоит маршрутизатор eth0 в инет eth1 в лан.
Пусть народ ходит через проксю в инет и через нат качает почту. Стандартный минимум короче.
Теперь думаем как считать, предпологая получить статистику типа ip1 - трафик1, ip2 - трафик2 и при этом сумма значений трафиков по каждой ипке в сумме должна дать трафик по внешнему интерфейсу(предпологаем что сам роутер в инет не ходит, а его служебный траффик кардинально не изменяет ситуацию)
Любым из способов описанных Глебом Смирновым. Можно посчитать сколько каждая ипка сожрала трафика напрямую, без прокси (почта в нашем примере).
Любым анализатором можно посмотреть скока каждый прокачал через проксю.
Но за счет экономии траффика проксей при сложении трафика сделанного почтой и траффика из анализатора прокси по всем ипкам из лана мы не получим траффика на внешнем интерфейсе.
Если еще проще задача стоит простая. в лане 100 челове пров выставил счет где указал 10 гиг. Вопрос какая ипка сколько из этих 10 гиг съела.
Как решить такую задачу комплексно я не знаю, получается есть частные решения но нет общего. Если есть кто-то кто знает решение - поделитсь опытом!
Вотв ам ответ:
http://www.opennet.me/openforum/vsluhforumID1/63572.html#5
Прочитайте пост полностью, думаю поймете что и как.
>Вотв ам ответ:
>http://www.opennet.me/openforum/vsluhforumID1/63572.html#5
>Прочитайте пост полностью, думаю поймете что и как.
Написано вссе правильно.
Но даже если роутер не будет генерировать траффика, и даже если пров не посчитает "паразитный траффик", вроде тех пакетов которые ушли от него, но не дошли до меня например. Все равно вылезет разница именнно из-за экономии траффика проксей.
Допустим:
Пользователь обращается к проксе, прокся обращается к своему кэшу берет оттуда x Mb и обращается к инету откуда скачивает еще y Mb. Затем пользователю отдается x+y Mb. Получается что при подсчете по внутреннему ифейсу пользователь скачал x+y Mb, но реально посчитано провом (ну или скачено с public) только y Mb (не учитываем сопутствующий служебный траффик, вроде днс, исмп и пр). Разница получается x Mb. Как ее отслеживать? вот в чем вопрос.
Я со сквидом мало работал, но если мне не изменяет память, то он в логах пишет с какого ip сколько качалось, при этом указывается бралось из кэша или из инета. Пишешь свой простенький скрипт и все!
>Я со сквидом мало работал, но если мне не изменяет память, то
>он в логах пишет с какого ip сколько качалось, при этом
>указывается бралось из кэша или из инета. Пишешь свой простенький скрипт
>и все!Да, так оно и есть . Детально можно глянутьь или в документации или здесь:
http://bog.pp.ru/work/squid.html
Итого
Предлагается взять готовую систему учета траффика, хранящую данные скажем в скуле. К ней дополнительно написать парсер логов сквида, который будет обманывать систему учета добавляя к ней в базу дополнительные данные взятые из логов сквида и может быть вырезАть данные соответствующие обращению клиентов на порт прокси, если система не умеет сама их отбрасывать.У кого то есть опыт написания такого парсера? есть ли где-то готовая связка?
Ситуация нат+прокси - это стандарт де-факто для небольших/средних фирм (не провайдеров), неужели никто не озадачивался такой проблемой?
>Итого
>Предлагается взять готовую систему учета траффика, хранящую данные скажем в скуле. К
>ней дополнительно написать парсер логов сквида, который будет обманывать систему учета
>добавляя к ней в базу дополнительные данные взятые из логов сквида
>и может быть вырезАть данные соответствующие обращению клиентов на порт прокси,
>если система не умеет сама их отбрасывать.
>
>У кого то есть опыт написания такого парсера? есть ли где-то готовая
>связка?
>Ситуация нат+прокси - это стандарт де-факто для небольших/средних фирм (не провайдеров), неужели
>никто не озадачивался такой проблемой?есть тут статья на opennet, там описан ldap + firebird + ulog-acct + java. Так вот в этой статье как раз и приводится твой парсер который считает по ип трафло котрое прошло через squid и через nat. Статья около полугодичной давности.
http://npj.ru/cake
и убейте сквид в плане подсчета, он криво считает