1. если трафик загоняется в коллектор через фаерволл, то снимать статистику в любом случае надо на интерфейсе смотрящем внутрь.
не все так просто. Пользуясь случаем, настрочу небольшую лекцию, ибо доку никто не читает. Было бы полезно это прочитать всем, чтоб понимать в чем же соль подсчета трафика.
Классифицировать трафик - это на самом деле нетривиальная задача, как ни странно. Почему странно - ведь сетевые технологии развиваются дофига лет, значит должны были все предусмотреть. Фишка в том, что в домашних сетях есть особый нюанс, который отличает их от всемирного подхода, если так выразиться. А именно:
1) в сетевых технологиях принято считать весь трафик
2) в домашних сетях в подавляющем количестве случаев считают только тот трафик, который разрешено считать. А именно: если клиент в заблокированном состоянии, то пусть он хоть дос-атаку устраивает, мы не должны считать этот трафик. Ессно, блокируем, но это иной вопрос.
Так вот, вы наверное слышали такой постулат, особенно в нетфлоу, - считается только входящий трафик. Применяя этот принцип, все сходится офигенно - мы регистрируем абсолютно весь трафик, ничего не теряем т.к. регистрируем до фаервола. С другой стороны, никакой трафик не регистрируется дважды - ведь чтобы это произошло (двойная регистрация) мы должны один и тот же пакет посчитать на входе в систему и на выходе.
Так вот. Это не работает в концепции домашних сетей, где повторяюсь, мы не должны считать трафик, который пришел от клиента, если клиент в заблокированном состоянии.
Поэтому просто так повесить на интерфейс коллектор - не катит. Вы можете это сделать, будет работать, но главное условие не будет выполняться. Более того, поскольку трафик еще и натится, на интерфейсе, смотрящем в мир, пакеты не будут нести информацию о наших клиентах, ибо на роутер трафик приходит с подмененным ip этого роутера. Т.е. даже на этом этапе не может выполняться условие "считаем только входящий трафик". Приходится вешать на интерфейс, смотрящий на клиента и слушать трафик в обоих направлениях.
Но и здесь, кроме основной проблемы с подсчетом блокированного трафика, возникает вторая, с которой многие, в основном маленькие сети, не сталкиваются - при наличии 2х и более клиентских интерфейсов трафик будет считаться дважды. Почему? А очень просто. Допустим клиент 10.0.0.1 посылает пакет на 10.1.0.1, пакет проходит роутер, регистрируется на входе и на выходе как "пакет от 10.0.0.1 на 10.1.0.1 столько-то байт". В коллекторе эти записи абсолютно ничем не отличаются. В ipcad можно регистрировать имя интерфейса, но это требует подсказки ядру какая сеть на каком интерфейсе находится. Это, кстати, есть в настройках, в админке. Обычно там стоит звездочка-подчеркивание-звездочка, и я думаю мало кто вникал, что это за фигня вообще))
Более того, когда сеть состоит из кучи маршрутизаторов, настроить без ошибок по предыдущей схеме все труднее и труднее.
Несколько лет назад, я задался вопросом как же построить универсальное решение, не зависящее от топологии сети и корректно считающее трафик по нашим условиям. Я пообщался с многими "щарящими людьми", которые сначала выдавали фразу "элементарно", но после уточнения всех нюансов сдавались. Но, тем не менее, схему я такую разработал.
Минусом такой схемы является то, что обычно в ней никто нихрена не понимает. Да, там всего несколько строк фаервола, но его апгрейд обычно делается по образу и подобию, не вникая в сам принцип, поэтому и появляется т.н. "неучтенный трафик".
Повторюсь, что означает "неучтенный трафик" - это информация, полученная от коллекторов, которую ядро не смогло идентифицировать с клиентом. Обратите внимание - трафик может быть связан с клиентом, но ядро не смогло по мною заложенным правилам правильно однозначно расшифровать эту информацию.
Принцип, на самом деле простой. Нодени нужно знать всего один параметр - имя интерфейса, который не связан с клиентом. На основе этого, он строит такие предпосылки:
1) трафик идущий на сервер с не_внешнего_интерфейса - засчитывается клиенту как исходящий
2) трафик идущий на клиента с не_внешнего_интерфейса - засчитывается клиенту как входящий
3) трафик идущий на клиента с не_внешнего_интерфейса и при этом вошел в роутер с не_внешнего_интерфейса - это трафик между клиентами, засчитывается обоим.
Самое трудное для понимания правило 3 - в фаерволе это правило обеспечивается ${f} add 400 skipto 450 ip from any to any recv ${ifOut} (только это инверсия правила - делает пропуск следующего правила подсчета трафика ).
Вот это, кто делает апгрейд логики NoDeny должен учитывать. По умолчанию - это все учтено, если вы хотите добавить своей изюминки - будьте добры, изучите эти сраные несколько строк в фаерволе. Именно изучите, а не клонируйте по образу и подобию.
Да, надеюсь, понятно, что фраза
если трафик загоняется в коллектор через фаерволл, то снимать статистику в любом случае надо на интерфейсе смотрящем внутрь
не имеет смысла в NoDeny?
