x666xx Цитата: P.S. Кстати всеми любиый тметр считает по порту...........
...
Я не знал что Нат ездит мимо порта.........
...
НАТ ездит по физическому порту который называется MAC-адрес сетевой платы.....
И после этого ты говоришь
Цитата: А как работает НАТ я прекрасно понимаю.
Ну что ж, может быть ты понимаешь. А я, вот, знаю, как он работает, и очень хорошо знаю. И я тебе говорю, что практически все, что ты тут написал -- неформатированный поток сознания. Ты все в кучу сгреб. Без обид.
GhostOld Если ты посчитал трафик на своем внешнем интерфейсе, то весь исходящий трафик, прошел ли он через NAT или через прокси на твоем компьютере или нет, будет подсчитан, и весь ответный входящий трафик также должен быть подсчитан. Давай разберем случай с оборванными сессиями. Допустим прокси стоит где-то внутри твоей сети, да пусть хоть даже на шлюзовом компьютере, все равно весь трафик будет учтен TMeter'ом при условии, что TMeter считает трафик на внешнем интерфейсе шлюзового компьютера и правила подсчета настроены правильно. Пусть клиент оборвал соединение, пусть прокси настолько глупый, что продолжает тащить контент из Интернета, но этот трафик все равно проходит через внешний интерфейс твоего шлюза и будет подсчитан. Т.е. не учитываемые тобой оборванные сессии -- миф.
Теперь давай подумаем о возможных технических причинах, приводящих к неучтенному трафику.
Во-первых, причиной этого может быть firewall, который ты используешь на той же шлюзовой машине. Способов реализации файрволов под Windows существует несколько (TDI filters, NDIS intermediate drivers, NDIS hooks и т.д.) и файрволы, реализованные с использованием различных схем, по-разному влияют на функционирование TMeter, а вернее -- на функционирование драйвера WinPcap, используемого в TMeter. В документации WinPcap прямо написано, что с некоторыми файрволами WinPcap не работает или работает неправильно. Но допустим, что WinPcap и твой файрвол нормально функционируют на одной машине, не конфликтуя друг с другом. Также допустим, что файрвол функционирует на более низком уровне, чем драйвер протокола WinPcap, например, если он реализован с использованием NDIS хуков. В этом случае все пакеты, фильтруемые твоим файрволом, не попадут к драйверу WinPcap и, соответственно, не будут посчитаны TMater'ом. В этом случае не спасет даже включение primiscuous режима работы сетевой карты (то, что, по всей видимости, имеет в виду
x666xx, говоря о том, что "ты должен считать по MAC-адресу"). Т.е. для полного подсчета трафика, файрвол должен отбрасывать пакеты только после того, как они попали в драйвер протокола WinPcap и, соответственно, были подсчитаны TMeter'ом.
Во-вторых, подобные же эффекты могут наблюдаться и при использовании NAT на машине с TMeter'ом, т.к. NAT реализуется с использованием тех же самых технологий, что и файрволы в Windows. Более того, чаще всего NAT является подсистемой или одной из функций установленного файрвола. Поэтому практически все, изложенное выше, справедливо и для NAT.
В-третьих, не учитываемый TMeter'ом трафик может появиться даже если ты не используешь файрвол на своем шлюзовом компьютере. Правда, возможность его появления напрямую зависит от технологии подключения к провайдеру и топологии сети между внешним интерфейсом твоего шлюза и интерфейсом провайдера, на котором происходит подсчет трафика. Допустим, ты подключен через обычный Ethernet. В этом случае возможно, что ты будешь получать Ethernet-кадры с MAC-адресом твоего интерфейса, но с чужим IP-адресом получателя в заголовке IP-пакета. Это допустимо, но имеет смысл только если твой шлюз является маршрутизатором на этот чужой IP-адрес. Если твой провайдер считает трафик по MAC-адресам, то он его посчитает (если он прошел через его "счетчик"), а TMeter скорее всего нет (в зависимости от настроек фильтров). Также возможна обратная ситуация -- т.е. IP-адрес твой, но MAC чужой. Этот пакет в обычных условиях просто пройдет мимо твоего сетевого интерфейса, т.е. не будет принят им, но может быть посчитан провайдером, если он считает пакеты по IP-адресам. Правда, опять же, этот пакет должен пройти через "счетчик" провайдера, т.е. либо он сам (твой провайдер) и сформировал такой "кривой" пакет, либо имели место другие достаточно специфичные условия (например, кто-то ищет включенные сниферы), так что пример достаточно искусственный.
В общем, ты видишь, что различных факторов, влияющих на то, будет подсчитан какой-то трафик или нет, достаточно много. И мы должны знать их все, чтобы с уверенностью сказать, что происходит.
