форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Хочу проверить правильно ли идет подсчет траффика через ipta..."
Сообщение от teebot on 27-Фев-03, 10:50  (MSK)
Здраствуйте. Настроил я подсчет трафика. Я не стал ставить разные проги для этого, были мои знания, немного почитал статей и получилось НЕЧТО. Но у меня такое впечатление что я что-то упустил, нет четкого представления о том как все должно выглядеть (это теоретические знания), все как-то туманно. Так вот решил я проверить считалку, обнулил счетчик и решил закачать песню размер которой я точно знаю. Разница в цифрах получилась где-то в 2 КБ. (эта погрешность на 3 МБ, так пару песен закачал смотришь и лишний метр набежал) Так должно быть или я что-то намутил? Особенности я считаю как общий трафик приходящий от прова, так и трафик розданый мои юзерам. Так вот разница в показаниях в подсчете клиентского траффика. (проверить общий не удалось т.к. туда попала и почта и много всего другого). Если это ненормально я готов предоставить скрипты на ваш суд. Спасибо.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
Сообщение от teebot on 27-Фев-03, 13:52  (MSK)
наверное всех уже достал вопрос о подсчете траффика. другого объяснения я не вижу.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
Сообщение от Sampan on 27-Фев-03, 22:03  (MSK)
Посредством iptables НИКОГДА не будет правильного подсчета трафика.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Xen on 28-Фев-03, 00:45  (MSK)
	>Посредством iptables НИКОГДА не будет правильного подсчета трафика. Это еще почему?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от bass on 28-Фев-03, 06:53  (MSK)
	>>Посредством iptables НИКОГДА не будет правильного подсчета трафика. > >Это еще почему? это видимо от отчаяния :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Sampan on 28-Фев-03, 12:35  (MSK)
	>>>Посредством iptables НИКОГДА не будет правильного подсчета трафика. >> >>Это еще почему? > >это видимо от отчаяния :) Ошибаешься! Это просто от понимания семиуровневой модели OSI iptables работает на 3-ем уровне (сетевой). До того как IP пакет попадет в правила iptables возможны множественные перезапросы битых пакетов (CRC, ошибки выравнивания, в общем случае - коллизии, jabering, etc). Это так-же траффик, но он не может быть учтен iptables по сути. Канальный (2-ой) уровень пропускает дальше только "правильные" пакеты. В зависимости от качества канала и организации топологии погрешность может составлять до 20-30 %. Ты не отчаивайся :-)) Хороших книжек по основам сетей много. Не все потеряно :-))
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от teebot on 28-Фев-03, 13:14  (MSK)
	Ну вы глубоко капнули!!!!!!! Это все конечно круто, 1 уровень, второй, CRC, но ведь к iptables попадают уже нормализованные пакеты без ошибок, тоесть та информация которая потом превратится в тот mp3-файл который я так усердно качал для проверки. Так почему же размер файла один а iptables показыает другое? Я так понял большенство систем подсчета базируется именно на iptables/ipcahince/ipfw, вот меня собственно и интересует они тоже выдают такую погрешность. Этого вопроса не было бы если б я себе четко представлял что входит в понятие входящий траффик. Были примеры в которых подсчет идет по цепочке INPUT (тут все понятно) и по цепочке FORWARD (вот тут не понятно). Может еще по какой-то, а может что-то лишнее? (отсюда и погрешность)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Sampan on 28-Фев-03, 13:31  (MSK)
	> >Так почему же размер файла один а iptables показыает другое? В размер файла не входят заголовки пакетов. А это совсем не мало. iptables не в состоянии учесть заголовки канального уровня (они снимаются при передаче на 3-й уровень). Зато, он учитывает заголовки 3-го уровня, которые в размер файла не входят. > >Я так понял большенство систем подсчета базируется именно на iptables/ipcahince/ipfw, Именно по этому не затихает поток вопросов по подсчету траффика :-(
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от teebot on 28-Фев-03, 13:47  (MSK)
	Не поверишь я тоже об этом думал. Сразу обращает на себя внимание колонка pkts (кол-во пакетов) при iptables -L -v -x -n. Сразу понятно что iptables оперирует пакетами. Но так как знания мои неособо подкреплены практикой, у меня весьма туманно представление обо всем об этом. Я крайне благодарен тебе за объяснения. Думаю у меня еще возникнут вопросы, но об этом в следующих топиках. Большое спасибо.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Xen on 28-Фев-03, 22:21  (MSK)
	Ну насчет OSI вы загнули, конечно... ведь реально используемая в сетях  модель далеко не семиуровневая, скажем так ;-) Насчет неучета битых пакетов можно было и не объяснять, вопрос в том, что подразумевается под _правильным_ трафиком. То есть надо смотреть, что считает провайдер, например, eth фреймы или только IP с вычетом ICMP, IGMP и т.д... в общем, возможны варианты. При большинстве из них подсчитывать ВЕСЬ трафик смысла не имеет.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Sampan on 01-Мрт-03, 02:39  (MSK)
	>Ну насчет OSI вы загнули, конечно... ведь реально используемая в сетях   >модель далеко не семиуровневая, скажем так ;-) Это, в общем то, совсем не откровение, что модель OSI - абстракция (т.е. в реальности не существует ни одной реализации). Другое дело, что эта абстракция способна удобно и наглядно демонстрировать не совсем очевидные вещи. > >Насчет неучета битых пакетов можно было и не объяснять, вопрос в том, >что подразумевается под _правильным_ трафиком. То есть надо смотреть, что считает >провайдер, например, eth фреймы ..... Сдается мне, что провайдер "eth фреймы" не считает. Редко у кого соединение с провайдером по ethernet'y (ограничение 100 метров не позволяет ;-) IMHO, подсчет трафика осуществляется на интерфейсе маршрутизатора. А т.к. чаще всего маршрутизатор еще и бридж (преобразователь интерфейсов 2-го уровня), например eth <--> v.35, то и получается, что пров считает полный трафик (вместе с заголовками канальных фреймов, "битыми" IP пакетами и прочей лабудой)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	28. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от appc on 03-Мрт-03, 20:50  (MSK)
	>>>>Посредством iptables НИКОГДА не будет правильного подсчета трафика. >>> >>>Это еще почему? >> >>это видимо от отчаяния :) > >Ошибаешься! Это просто от понимания семиуровневой модели OSI > >iptables работает на 3-ем уровне (сетевой). До того как IP пакет попадет >в правила iptables возможны множественные перезапросы битых пакетов (CRC, ошибки выравнивания, >в общем случае - коллизии, jabering, etc). Это так-же траффик, но >он не может быть учтен iptables по сути. Канальный (2-ой) уровень >пропускает дальше только "правильные" пакеты. > >В зависимости от качества канала и организации топологии погрешность может составлять до >20-30 %. > > >Ты не отчаивайся :-)) Хороших книжек по основам сетей много. Не все >потеряно :-)) а что на маршрутизаторах железячных трафик считают на канальном уровне, или на физическом? Я думал что там все происходит абсолютно также, только занимается эти не программа а железка.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от teebot on 28-Фев-03, 10:10  (MSK)
	>Посредством iptables НИКОГДА не будет правильного подсчета трафика. На этом сайте в разделе "программы" можно найти проги для подсчета траффика, большенство из них используют именно правила iptables/ipchaince/ipfw. Говорю большенство так все не смотрел, а те что смотрел работают именно так. Вот я и подумал зачем я буду использовать всякие приблуды если я сам могу наваять правила.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	12. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Lamer on 01-Мрт-03, 08:24  (MSK)
	Вот у нас соединение с провайдером по Ethernet, но наверняка провайдер считает наш трафик на маршрутизаторе, а уже после подсчета этот трафик "обертывается" в Ethernet и приходит к нам, так что это хорошо, что iptables не считает Ethernet. Я тоже использую для посдчета iptables, у меня после отсева трафик из FORWARD попадает в цепочку users, которая делится на каждого юзера по направлению(типа ivanov_in ivanov_out), трафик из INPUT попадает на linuxbox_in. Потом складываю все эти _in и получаю трафик. Как я думаю,пакеты, которые отвергнуты моим iptables уже посчитались у провайдера, их тоже надо учесть. Но когда я поставил прокси сервер squid и пустил на него весь www-trafik,он сразу обезличился в iptables(весь пошел через linuxbox _in), но зато легко анализируется средствами squid. А www это 90% всего трафика. Вывод: 100% точно все равно считать замучаешься, а с небольшой погрешностью ничего страшного. А несовпадение размера файла с трафиком думаю произошло из-зи того, что посчитались какие-то дополнительные запросы на пересоединение и прочяя служебная фигня.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

13. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
Сообщение от teebot on 01-Мрт-03, 10:16  (MSK)
До последних постов в эту ветку, я думал что знания мои систематизируются, раскладываются по полочкам, картина начинает проясняться. Напрасно я так думал. Хочу коротко описать как я понимаю все эти процесы, и прошу вас поправить меня если я ошибаюсь, наставить на путь истенный как говориться. И так. Задача считать весь приходящий траффик (то за что платятся денги) и трафик розданный моим юзерам. При подсчете общего траффика мне надо учесть пакеты проходящие по цепочке INPUT (это и есть собственно мой основной траффик) и по цепочке FORWARD (это траффик который проходит через мой роутер и тоже вроде принадлежит мне, и тарификуется провайдером). Сложив эти два показателя я должен получить мой реальный траффик за который я должен заплатить. Так? Или я что-то упустил? Теперь траффик для моих юзеров. Так как они юзают только www мне надо счить что получил юзер от моего squid. Я делаю это через цепочку OUTPUT --sport 3128 -d IP_юзера. Это и будет траффик юзера. Я прав? Дополнительных цепочек тут не надо? Мне очень нужно занть ваше мнение.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	14. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Lamer on 01-Мрт-03, 10:35  (MSK)
	>И так. Задача считать весь приходящий траффик (то за что платятся денги) >и трафик розданный моим юзерам. Мне кажется тут правильно. >При подсчете общего траффика мне надо учесть пакеты проходящие по цепочке INPUT >(это и есть собственно мой основной траффик) и по цепочке FORWARD >(это траффик который проходит через мой роутер и тоже вроде принадлежит >мне, и тарификуется провайдером). Сложив эти два показателя я должен получить >мой реальный траффик за который я должен заплатить. Так? Или я >что-то упустил? Мне кажется тут тоже правильно. Но есть еще отвергнутые пакеты, которые ты уже получил, но они не пошли дальше юзерам или на INPUT, а "сброшены" iptables. Пусть это только заголовки, но это тоже трафик и для точности его тоже надо бы посчитать >Теперь траффик для моих юзеров. >Так как они юзают только www мне надо счить что получил юзер >от моего squid. Я делаю это через цепочку OUTPUT --sport 3128 >-d IP_юзера. Это и будет траффик юзера. Я прав? Дополнительных цепочек >тут не надо? Теоретически тут тоже правильно. Но а почему нельзя проанализировать логи squid? Там этот трафик (www)очень подробно расписан, есть масса анализаторов, я пользуюсь sarg, очень приятная штука, выдает гору инорфмации-общий трафки, % из кэша, деление по пользователям, трафик по часам и датам, топ сайты, и т.д. и т.п. p.s а вообще смотри мой ник :-))
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	15. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от teebot on 01-Мрт-03, 10:45  (MSK)
	>Мне кажется тут тоже правильно. Но есть еще отвергнутые пакеты, которые ты >уже получил, но они не пошли дальше юзерам или на INPUT, >а "сброшены" iptables. Пусть это только заголовки, но это тоже трафик >и для точности его тоже надо бы посчитать Насколько я понимаю пакет проходит цепочки и если его отвергли он прекращает движение. Если а ставлю правило для подсчета траффика первым то пакеты будет попадать сперва на него а потом передаваться дальше(что и требовалось) и кто знает может потом его отвергнут. А тут я прав? Правило для подсчета должно стоять первым.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	16. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Lamer on 01-Мрт-03, 10:57  (MSK)
	Опять же теоретически верно, а практически пришли (или запости) что у тебя выдается по команде iptables -L -v, тогда будет более наглядно
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	17. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от teebot on 01-Мрт-03, 11:05  (MSK)
	>Опять же теоретически верно, а практически пришли (или запости) что у тебя >выдается по команде iptables -L -v, тогда будет более наглядно Chain global_IN (2 references)     pkts      bytes target     prot opt in     out     source               destination           125393 98265863 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           Chain oleg_chain (3 references)     pkts      bytes target     prot opt in     out     source               destination                0        0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           Chain serg_chain (3 references)     pkts      bytes target     prot opt in     out     source               destination           104268 59859041 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           Chain teebot_chain (3 references)     pkts      bytes target     prot opt in     out     source               destination            37468 23650112 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	18. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Lamer on 01-Мрт-03, 11:10  (MSK)
	Ты весь вывод запости, а не три цепочки. Или скрипт , который устанавливает правила. ПО этим 4-м цепям ничего непонятно, откуда и куда, INPUT OUTPUT FORWARD давай..
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	19. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от teebot on 01-Мрт-03, 11:23  (MSK)
	>Опять же теоретически верно, а практически пришли (или запости) что у тебя >выдается по команде iptables -L -v, тогда будет более наглядно Chain INPUT (policy DROP 845 packets, 187266 bytes) pkts bytes target prot opt in out source destination 121681 92732480 global_IN all -- ppp0 * 0.0.0.0/0 0.0.0.0/0 10841 700990 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpt:53 6251 1124384 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 dpts:1024:65535 46 15120 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp spts:67:68 dpts:67:68 1011 65809 ACCEPT icmp -- * * xxx.xxx.xxx.0/24 0.0.0.0/0 0 0 ACCEPT icmp -- * * xxx.xxx.xxx.0/24 xxx.xxx.xxx.0/24 1035 560695 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp flags:!0x16/0x02 reject-with icmp-port-unreachable 106686 11475683 ACCEPT tcp -- * * xxx.xxx.xxx.0/24 xxx.xxx.xxx.0/24 tcp spts:1024:65535 dpt:3128 1451 1855671 ACCEPT tcp -- * * xxx.xxx.xxx.0/24 xxx.xxx.xxx.0/24 tcp spts:1024:65535 dpt:25 2908 120514 ACCEPT tcp -- * * xxx.xxx.xxx.0/24 xxx.xxx.xxx.0/24 tcp spts:1024:65535 dpt:110 14 840 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:113 17 680 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:113 dpts:1024:65535 0 0 ACCEPT tcp -- * * xxx.xxx.xxx.100 0.0.0.0/0 tcp spt:22 0 0 ACCEPT udp -- * * xxx.xxx.xxx.100 0.0.0.0/0 udp spt:22 2383 207360 ACCEPT udp -- * * xxx.xxx.xxx.0/24 0.0.0.0/0 udp dpt:137 2324 543627 ACCEPT udp -- * * xxx.xxx.xxx.0/24 0.0.0.0/0 udp dpt:138 530101 46106175 ACCEPT tcp -- * * xxx.xxx.xxx.0/24 0.0.0.0/0 tcp dpt:139 16 799 LOG icmp -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 112075 87684332 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 1943 109488 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:25 dpts:1024:65535 3882 3826082 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:110 dpts:1024:65535 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 3712 5533383 global_IN all -- ppp0 * 0.0.0.0/0 0.0.0.0/0 3712 5533383 teebot_chain all -- * * 0.0.0.0/0 xxx.xxx.xxx.50 0 0 serg_chain all -- * * 0.0.0.0/0 xxx.xxx.xxx.49 0 0 oleg_chain all -- * * 0.0.0.0/0 xxx.xxx.xxx.35 3712 5533383 ACCEPT all -- ppp0 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 3943 159763 ACCEPT all -- eth0 ppp0 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy DROP 1103 packets, 313255 bytes) pkts bytes target prot opt in out source destination 33756 18116729 teebot_chain tcp -- * * 0.0.0.0/0 xxx.xxx.xxx.50 tcp spt:3128 0 0 teebot_chain udp -- * * 0.0.0.0/0 xxx.xxx.xxx.50 udp spt:3128 104268 59859041 serg_chain tcp -- * * 0.0.0.0/0 xxx.xxx.xxx.49 tcp spt:3128 0 0 serg_chain udp -- * * 0.0.0.0/0 xxx.xxx.xxx.49 udp spt:3128 0 0 oleg_chain tcp -- * * 0.0.0.0/0 xxx.xxx.xxx.35 tcp spt:3128 0 0 oleg_chain udp -- * * 0.0.0.0/0 xxx.xxx.xxx.35 udp spt:3128 6290 419398 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpt:53 10841 1488253 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 dpts:1024:65535 161 20228 ACCEPT icmp -- * * xxx.xxx.xxx.0/24 0.0.0.0/0 0 0 ACCEPT icmp -- * * xxx.xxx.xxx.0/24 xxx.xxx.xxx.0/24 138024 77975770 ACCEPT tcp -- * * xxx.xxx.xxx.0/24 xxx.xxx.xxx.0/24 tcp spt:3128 dpts:1024:65535 643 32511 ACCEPT tcp -- * * xxx.xxx.xxx.0/24 xxx.xxx.xxx.0/24 tcp spt:25 dpts:1024:65535 4019 4569848 ACCEPT tcp -- * * xxx.xxx.xxx.0/24 xxx.xxx.xxx.0/24 tcp spt:110 dpts:1024:65535 17 1020 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:113 14 560 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:113 dpts:1024:65535 0 0 ACCEPT tcp -- * * 0.0.0.0/0 xxx.xxx.xxx.100 tcp dpt:22 0 0 ACCEPT udp -- * * 0.0.0.0/0 xxx.xxx.xxx.100 udp dpt:22 553 43638 ACCEPT udp -- * * 0.0.0.0/0 xxx.xxx.xxx.0/24 udp spt:137 219 52779 ACCEPT udp -- * * 0.0.0.0/0 xxx.xxx.xxx.0/24 udp spt:138 276743 21817547 ACCEPT tcp -- * * 0.0.0.0/0 xxx.xxx.xxx.0/24 tcp spt:139 131471 15273479 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 2139 2968409 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:25 3833 214590 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:110 Chain global_IN (2 references) pkts bytes target prot opt in out source destination 125393 98265863 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 Chain oleg_chain (3 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 Chain serg_chain (3 references) pkts bytes target prot opt in out source destination 104268 59859041 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 Chain teebot_chain (3 references) pkts bytes target prot opt in out source destination 37468 23650112 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	20. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Lamer on 01-Мрт-03, 11:50  (MSK)
	Наворочено будь здоров, без 100 г не разберешь :-) МОи соображения: 1) вроде в GLOBAL_IN должен считаться правильный входящий трафик 2)ты разрешаешь netbios (137-139) из Интернета, так надо? 3)в FORWARDE трафик на  serg_chain и пр. идет как входящий, так и исходящий. Кажись тут явная ошибка... 4) не легче в INPUT тоже использовать ESTABLISHED RELATED для всего входящего по ppp, а потом открыть доступ к тем портам на сервере какие нужны???
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	22. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от teebot on 01-Мрт-03, 12:13  (MSK)
	>Наворочено будь здоров, без 100 г не разберешь :-) >МОи соображения: > >1) вроде в GLOBAL_IN должен считаться правильный входящий трафик > Вот и здорово :-)) >2)ты разрешаешь netbios (137-139) из Интернета, так надо? > Это отдельная история, там все нормально >3)в FORWARDE трафик на  serg_chain и пр. идет как входящий, так >и исходящий. Кажись тут явная ошибка... > Ну как мы выяснили FORWARD для юзеров надо убрать. >4) не легче в INPUT тоже использовать ESTABLISHED RELATED для всего входящего >по ppp, а потом открыть доступ к тем портам на сервере >какие нужны??? Легче для чего?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	24. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Lamer on 01-Мрт-03, 12:25  (MSK)
	>>3)в FORWARDE трафик на  serg_chain и пр. идет как входящий, так >>и исходящий. Кажись тут явная ошибка... >> >Ну как мы выяснили FORWARD для юзеров надо убрать. > я не убирал, у меня прокси прозрачный , юзеры его не видят, а он кеширует только запросы к 80 порту. Все что не по 80 порту, идет от юзеров минуя прокси. >>4) не легче в INPUT тоже использовать ESTABLISHED RELATED для всего входящего >>по ppp, а потом открыть доступ к тем портам на сервере >>какие нужны??? > >Легче для чего? Легче для понимания. И чем меньше чепочек тем лучше быстродействие.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	26. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от teebot on 01-Мрт-03, 12:38  (MSK)
	>Легче для понимания. И чем меньше чепочек тем лучше быстродействие. Чего ж тут легкого, добавится еще одна цепочка?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	27. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от teebot on 01-Мрт-03, 12:59  (MSK)
	>>Легче для понимания. И чем меньше чепочек тем лучше быстродействие. >Чего ж тут легкого, добавится еще одна цепочка? Я и так открыл только те порты которые нужны. Одни открыты только для локальных пользователей, друге для глобальных, третьи  для тех и для других. Ведь политика по умолчанию у меня DROP. Принцип зпретить все и открыть тольк то что нужно.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	21. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от Lamer on 01-Мрт-03, 11:54  (MSK)
	хотя может про chain_all я неправ, там ведь написано all, но не видно, этих цепочек, а нельзя ли скрипт целиком, смотреть тяжело на такой вывод..
		Рекомендовать в FAQ | Cообщить модератору | Наверх

23. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
Сообщение от Lamer on 01-Мрт-03, 12:19  (MSK)
Перечитал вопрос еще раз. Из-за чего сыр-бор?? Не может вошедший трафик равняться точно скачанному файлу. Помимо самого файла идет обмен служебной информацией, всякие подтверждения, поэтому полученный трафик всегда будет больше чем скачанный файл. Если у тебя на 3 мегабайта сверху получается 2 килобайта, это около пол процента, наверное так и должно быть. Но скрипт все равно интересно посмотреть целиком..
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	25. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
	Сообщение от teebot on 01-Мрт-03, 12:33  (MSK)
	>Перечитал вопрос еще раз. Из-за чего сыр-бор?? Не может вошедший трафик равняться >точно скачанному файлу. Помимо самого файла идет обмен служебной информацией, всякие >подтверждения, поэтому полученный трафик всегда будет больше чем скачанный файл. Если >у тебя на 3 мегабайта сверху получается 2 килобайта, это около >пол процента, наверное так и должно быть. >Но скрипт все равно интересно посмотреть целиком.. Сыр-бор из-за того, что без четкого понимания того что делаешь в голову лезут всякие мысли глупые, которые заставляют усомниться в результат проделаного. Я точно не знал, какие именно цепочки надо считать это раз. Во-вторых с одной стороны я понимаю что пакет состоит из заголовка+данные, но были сомнение как все это переваривается в iptables, хотя сомнений не должно быть в iptables -L -v черко написано pkts - тоесть пакеты (заголовок+данные). К тому же надо учесть как ты правильно говоришь, идет обмен служебной информацией (установка соединения SYN, SYN/ACK, ACK и т.д.) но опять же я не знаю как себя ведет iptables при всем при этом. Такой вот СЫР, понимаешь БОР. :-))
		Рекомендовать в FAQ | Cообщить модератору | Наверх

29. "RE: Хочу проверить правильно ли идет подсчет траффика через ..."
Сообщение от appc on 03-Мрт-03, 21:02  (MSK)
>Здраствуйте. >Настроил я подсчет трафика. Я не стал ставить разные проги для этого, >были мои знания, немного почитал статей и получилось НЕЧТО. >Но у меня такое впечатление что я что-то упустил, нет четкого представления >о том как все должно выглядеть (это теоретические знания), все как-то >туманно. >Так вот решил я проверить считалку, обнулил счетчик и решил закачать песню >размер которой я точно знаю. Разница в цифрах получилась где-то в >2 КБ. (эта погрешность на 3 МБ, так пару песен закачал >смотришь и лишний метр набежал) >Так должно быть или я что-то намутил? >Особенности я считаю как общий трафик приходящий от прова, так и трафик >розданый мои юзерам. Так вот разница в показаниях в подсчете клиентского >траффика. (проверить общий не удалось т.к. туда попала и почта и >много всего другого). >Если это ненормально я готов предоставить скрипты на ваш суд. > >Спасибо. Помоему, проверить правильно ли считается трафик твоем фаерволом можно так: Дать ему правило выпускать наружу пинг с определенной машины, потом пинговать машину вне сети, и посмотреть на сколько увеличелись счетчики на цепочках. Велечина пакета ICMP ECHO REQUES (ECHO REPLY) известна (ясам забыл правда, но думаю нетрудно найти)и смотришь правильно ли твой фаервол посчитал . Помоему как-то так. (если ошибся не закидывайте помидорами, просто не так часто приходится общаться с этим)
	Рекомендовать в FAQ | Cообщить модератору | Наверх

30. "RE: Замучили уже путать котлеты и мухи"
Сообщение от Dron on 05-Мрт-03, 11:04  (MSK)
Тема поднятая тут не нова и в принципе интересна. Но меня убивают умники считающие, что провайдер считает трафик на каком-то ином уровне OSI, а не на IP. Товарищи вы где-нить видели маршрутизатор разруливающий пакеты на Ethernet уровне ?! Вы совсем чтоли... Подсчет трафика не может опускаться ниже IP, если провайдер предоставляет именно услуги интернета. Если же это магистральный провайдер, то естественно он может считать трафик ниже, так как допустим по каналам может идти IPX и вообще что-то не относящееся к IP совершенно. Но это все равно не правильно. Конечный пользователь не должен платить за огрехи технологий, за инкапсуляцию пакетов и разрастающиеся заголовки, за повторную передачу пакетов из-за шумовых потерь или из-за перегрузки канала. Это все надо обговаривать с провайдером. И не надо говорить, что iptables для этого не подходит. Все сервера (и у провайдера тоже) работают на *nix, у них тот же iptables. Только возможно цепочки составлены более грамотно (или не в пользу конечного пользователя). Я конечно не упоминаю о Cisco и IOS, но смысл от это не меняется. Трафик должен считаться на уровне IP а не на другом уровне.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

31. "RE: Цитата из FAQ для пользователей провайдера КОМКОР"
Сообщение от Dron on 05-Мрт-03, 11:06  (MSK)
Вопрос: Мы в интернете не работали, компьютеры были выключены, а Ваша система учета насчитала нам трафик. Ответ: Возможны несколько случаев. 1. Несмотря на то, что компьютеры пользователей были отключены, в сети присутствует сервер (WWW, mail, DNS, proxy), работающий, как правило, круглосуточно. Соответственно, он служит получателем входящего трафика. 2. В силу технологии протокола TCP/IP и топологии построения интернет-сетей, запрос, посланный на ресурс Клиента, проходит через центральные маршрутизаторы КОМКОР, несмотря на то, что ресурс Клиента в данный момент может быть недоступен. Соответственно, будучи полученным, данный трафик относится маршрутизаторами КОМКОР к трафику Клиента. 3. В силу технологии протокола TCP/IP, при сильной загруженности канала Клиента, возникает так называемый переприем - несколько попыток передачи одних и тех же данных. Вследствие этого, при передаче, например, 10МБ реальных данных возникает 30МБ трафика. Для устранения данной проблемы Клиенту следует либо расширить пропускную способность канала, либо уменьшить его пиковую загрузку. 4. Некоторые Клиенты используют собственные средства подсчета трафика, встроенные в firewall, proxy и т.д. Данные. полученные с них, могут расходиться с данными КОМКОР. Часто эти средства ведут подсчет реально прошедших через них данных, без учета инкапсуляции, служебных пакетов. КОМКОР использует для подсчета трафика общепринятый у провайдеров механизм, встроенный в IOS CISCO, регистрирующий все пакеты, адресованные Клиенту.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	32. "RE: Цитата из FAQ для пользователей провайдера КОМКОР"
	Сообщение от teebot on 05-Мрт-03, 11:42  (MSK)
	>Вопрос: Мы в интернете не работали, компьютеры были выключены, а Ваша система >учета насчитала нам трафик. > >Ответ: Возможны несколько случаев. > >1. Несмотря на то, что компьютеры пользователей были отключены, в сети присутствует >сервер (WWW, mail, DNS, proxy), работающий, как правило, круглосуточно. Соответственно, он >служит получателем входящего трафика. > >2. В силу технологии протокола TCP/IP и топологии построения интернет-сетей, запрос, посланный >на ресурс Клиента, проходит через центральные маршрутизаторы КОМКОР, несмотря на то, >что ресурс Клиента в данный момент может быть недоступен. Соответственно, будучи >полученным, данный трафик относится маршрутизаторами КОМКОР к трафику Клиента. > >3. В силу технологии протокола TCP/IP, при сильной загруженности канала Клиента, возникает >так называемый переприем - несколько попыток передачи одних и тех же >данных. Вследствие этого, при передаче, например, 10МБ реальных данных возникает 30МБ >трафика. Для устранения данной проблемы Клиенту следует либо расширить пропускную способность >канала, либо уменьшить его пиковую загрузку. > >4. Некоторые Клиенты используют собственные средства подсчета трафика, встроенные в firewall, proxy >и т.д. Данные. полученные с них, могут расходиться с данными КОМКОР. >Часто эти средства ведут подсчет реально прошедших через них данных, без >учета инкапсуляции, служебных пакетов. КОМКОР использует для подсчета трафика общепринятый у >провайдеров механизм, встроенный в IOS CISCO, регистрирующий все пакеты, адресованные Клиенту. > Это цитат из другой вети посвященной учету траффика. "Считаю трафик с помощью ipfw counters,cisco cache-flow и cisco ip-accounting(одновременно). На объемах ~50-70Gb расхождение 0.7-0.8% Так что - или вы или провайдер считают неправильно.Считать по логу squid-это летать по пачке беломора...Должна быть точка раздела ответственности и считать надо в этой точке. Кстати-если у вас есть статический роут на провайдера, то при пропадании канала начинается пинг-понг, один пакет может посчитаться до TTL раз... " Прошу обратить внимание на последние строчки "...при пропадании канала начинается пинг-понг, один пакет может посчитаться до TTL раз..." Теперь читаем твой пост "Конечный пользователь не должен платить за огрехи технологий, за инкапсуляцию пакетов и разрастающиеся заголовки, за повторную передачу пакетов из-за шумовых потерь или из-за перегрузки канала", и вырезка из КОМКОР "3. В силу технологии протокола TCP/IP, при сильной загруженности канала Клиента, возникает так называемый переприем - несколько попыток передачи одних и тех же данных. Вследствие этого, при передаче, например, 10МБ реальных данных возникает 30МБ трафика. Для устранения данной проблемы Клиенту следует либо расширить пропускную способность канала, либо уменьшить его пиковую загрузку. " Получается виноват клиент. Подитожим. Если я возьму и просто наберу ifconfig eth1 и посмотрю цифру в RX: поле я увижу что реально пришло на мой интерфейс смотрящий к прову. Предположим я поставлю ту же киску, но ведь и она получит ровно столько сколько прийдет на интерфейс. Так где правда?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	33. "to teebot: правда гдето рядом (С) Агент Малдер"
	Сообщение от appc on 05-Мрт-03, 12:02  (MSK)
	Правда у того кто определяет правила по которым он хочет считать трафик, а если ты не согласе то можешь найти себе другого провайдера или попробовать покачать права. У меня знакомый говорил что у них в конторе был случай когда провайдер начал присылать счета на трафик явно завышенные (по мнению тамошнего сисадмина) так он договорился с провайдером до того, что теперь та контора ежемесячно платит только за входящий или исходязий трафик, взависимости от того какой меньше.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

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