FreeBSD: Я научил natd считать пакеты.

[Micah'GF]

Недавно в своей домашней сети столкнулся с проблемой учета трафика через несколько каналов в интернет. Проблема была в том, что пакеты, после изменения адреса натом уже нельзя было обрабатывать программами учета трафика, такими как trafd, ipacctd, ipcad. Я внес процедуры обработки пакетов из ipacctd в natd и демон стал считать все проходящие через него пакеты включая пакеты до замены адреса.

статистика сохраняется в указанный файл командой killall -USR2 natd. Файл указывается в командной строке ключом -logfile /var/log/natd.ed0 в стиле логов Cisco.

Программа компилируется и копируется на место прежнего в /sbin/

 

Взять исходники можно здесь - http://200mb.yalutorovsk.ru/files/c_natd.rar

[Guest]

бред какой-то

ipcad ставишь на все интерфейсы и считаешь. прекрасно он видит пакеты до ната...

херней занимаешся какой-то... ВСЕ (100%) сетей юзают нат. и все 100% считают трафик.

 

Не занимайся ерундой, а лучше спроси как настроить

[Micah'GF]

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

 

Вы наверное никогда не использовали несколько каналов для доступа в интернет.

[Guest]

А мне мысель понравилась :) на выходных попробую собрать, интересный вариант!

[Skylord]

Наверное я тупой. У меня два маршрутизатора под фрибздей (обычный и VPN), которые имеют по два канала наружу - трафиковый и анлим. NAT и роутинг в целях повышения производительности организован средствами pf (тот, который из OpenBSD импортировали), скорость на анлимах пользователям режется ipfw dummynet - в целях гибкости. Вопроса как все считать, даже не возникало: на внутренний интерфейс (или интерфейсы - при VPN) садится считалка (конкретно - ndsad) и считает все без напрягов. Зачем вообще считать на внешних фейсах? Так никто никогда не делает!

Или автором ставились какие-то особенные задачи при подсчете трафика? Тогда подробности в студию.

[Guest]

А у меня вот сложный траф - хттп с одного канала, все остальное с другого, на раздаче еще прокся кеширует, просто хочется знать РЕАЛЬНЫЕ цифры по потреблению.

imho идея интересная, и БРАВО автору за усилия в расширении горизонтов (мне бы в голову не пришло рихтовать NATD)

!Perfect!

[Skylord]

А у меня вот сложный траф - хттп с одного канала, все остальное с другого, на раздаче еще прокся кеширует, просто хочется знать РЕАЛЬНЫЕ цифры по потреблению.

Дык и как это все связано с тарификацией? На внутренних интерфейсах будут все пакеты, через какие бы каналы они не ходили.

[Micah'GF]

Описяю подробности =)

в моем случае маленькая домашняя сеть своими возможностями ходит в инет; один сетевой интерфейс на сервере напрямую соединен с ADSL-модемом, трафик через который продается по 2.4р; второй интерфейс соединен с сервером, в котором установлена DVB-карта и трафик со спутника стоит 1р.

Т.к. пинг через спутник от 400мс до 2сек в часы пик, то онлайн-игроки включают ADSL и играют нормально, а сёрферы включают SAT и экономят.

Я не завышаю цены и не собираюсь на этом спекулировать, поэтому трафик нужно учитывать по реальным ценам.

[Guest]

а , ну тогда понятно...

 

Но можно и без патчей, немного по другому..

в линуксе так:

 

маркируем пакеты iptablesом на внешних интерфейсах

через iptables считаем..

[Guest]

а , ну тогда понятно...

 

Но можно и без патчей, немного по другому..

в линуксе так:

 

маркируем пакеты iptablesом на внешних интерфейсах  

через iptables считаем..

 

В линуксе не обязательно через маркировку интерфейсы ловить. Там нормально NAT считается. Так-что через трафик-селектор по наружным eth-ам разбраcываем по категориям и считаем. Под фрей похоже, что немного гиморойно.

[Guest]

ничего гиморойного не вижу, просто создаются две группы динамически меняющиеся какимто внешним скриптом, и соответственно разнае счётчики на каждую из них...

[UglyAdmin]

Чего только не придумают, лиш бы циску не ставить? :)