Счетчик трафика на IPTаbles считает намного больше трафика, чем провайдер

[Zelenev]

Есть две локальные сети 192.168.0.0/24 (eht0) и 192.168.0.1/24 (eth2)и глобальная 10.0.0.0/24 (eht1). Провайдер - MTУ. С помощью IPTables создал цепочки для подсчета трафика. Обнаружилась странная картина - входящий трафик , показанный IPTables отличается от МТУ в большую сторону примерно на 100 мб в день (при расходе -

300мб в день). Звонил в МТУ - говорят, что учитывают весь трафик

Никто не сталкивался с этой проблемой? При необходимости напишу цепочки.

Андрей

[SignFinder]

прокси стоит?

[Zelenev]

нет

настроен маскарадинг

[Zelenev]

я чесно говоря не знаю, является ли маскарадинг прокси-сервером?

[SignFinder]

нет не является. Возможно просто вы учитываете трафик который не уходит к прову

[vpk_vpk]

"Есть две локальные сети 192.168.0.0/24 (eht0) и 192.168.0.1/24 (eth2)"

IMHO, тут чего-то неправильно.

[SignFinder]

vpk

не имхо - там действительно неправильно, если это не опечатка.

Zelenev

вывод ifconfig с сервера покажите (перенаправить в файл можно так ifconfig >111.txt)

[Ineu]

И цепочки iptables.

[Zelenev]

цепочки iptables выводить так?

: iptables_save > /etc/iptables.rules

По поводу IP адресов - я описался:

192.168.0.0/24 - eth0

192.168.1.0/24 -eth2

eth1 - внешний интерфейс

[Ineu]

Zelenev писал(а) Fri, 27 October 2006 13:19

цепочки iptables выводить так? : iptables_save > /etc/iptables.rules

Я бы предпочел

iptables -t filter -nL

iptables -t mangle -nL

iptables -t nat -nL

[Zelenev]

iptables -t filter -nL

(но этот листинг не отражает входящие/исходящие интерфейсы )

Chain INPUT (policy ACCEPT)

target prot opt source destination

TRAFFIC all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT)

target prot opt source destination

DROP all -- 192.168.0.0/24 192.168.1.0/24

DROP all -- 192.168.1.0/24 192.168.0.0/24

TRAFFIC_FW all -- 0.0.0.0/0 192.168.0.0/24

TRAFFIC_FW all -- 0.0.0.0/0 192.168.1.0/24

TRAFFIC_FW all -- 192.168.0.0/24 0.0.0.0/0

TRAFFIC_FW all -- 192.168.1.0/24 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

TRAFFIC all -- 0.0.0.0/0 0.0.0.0/0

Chain TRAFFIC (2 references)

target prot opt source destination

TRAFFIC_TCP_INBOUND tcp -- 0.0.0.0/0 81.81.81.81

TRAFFIC_TCP_OUTBOUND tcp -- 81.81.81.81 0.0.0.0/0

RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain TRAFFIC_FW (4 references)

target prot opt source destination

TRAFFIC_TCP_INBOUND_FW tcp -- 0.0.0.0/0 192.168.0.0/24

TRAFFIC_TCP_INBOUND_FW tcp -- 0.0.0.0/0 192.168.1.0/24

TRAFFIC_TCP_OUTBOUND_FW tcp -- 192.168.0.0/24 0.0.0.0/0

TRAFFIC_TCP_OUTBOUND_FW tcp -- 192.168.1.0/24 0.0.0.0/0

RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain TRAFFIC_TCP_INBOUND (1 references)

target prot opt source destination

RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain TRAFFIC_TCP_INBOUND_FW (2 references)

target prot opt source destination

all -- 0.0.0.0/0 192.168.0.2

all -- 0.0.0.0/0 192.168.0.3

all -- 0.0.0.0/0 192.168.0.4

all -- 0.0.0.0/0 192.168.0.5

all -- 0.0.0.0/0 192.168.0.15

all -- 0.0.0.0/0 192.168.0.6

all -- 0.0.0.0/0 192.168.0.7

all -- 0.0.0.0/0 192.168.0.9

all -- 0.0.0.0/0 192.168.0.11

all -- 0.0.0.0/0 192.168.0.12

all -- 0.0.0.0/0 192.168.0.10

all -- 0.0.0.0/0 192.168.0.100

all -- 0.0.0.0/0 192.168.0.13

all -- 0.0.0.0/0 192.168.0.1

all -- 0.0.0.0/0 192.168.1.1

all -- 0.0.0.0/0 192.168.1.21

all -- 0.0.0.0/0 192.168.1.11

all -- 0.0.0.0/0 192.168.1.12

all -- 0.0.0.0/0 192.168.1.10

RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain TRAFFIC_TCP_OUTBOUND (1 references)

target prot opt source destination

RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain TRAFFIC_TCP_OUTBOUND_FW (2 references)

target prot opt source destination

all -- 192.168.1.10 0.0.0.0/0

all -- 192.168.1.12 0.0.0.0/0

all -- 192.168.1.11 0.0.0.0/0

all -- 192.168.1.21 0.0.0.0/0

all -- 192.168.1.1 0.0.0.0/0

all -- 192.168.0.2 0.0.0.0/0

all -- 192.168.0.3 0.0.0.0/0

all -- 192.168.0.4 0.0.0.0/0

all -- 192.168.0.5 0.0.0.0/0

all -- 192.168.0.15 0.0.0.0/0

all -- 192.168.0.6 0.0.0.0/0

all -- 192.168.0.7 0.0.0.0/0

all -- 192.168.0.9 0.0.0.0/0

all -- 192.168.0.10 0.0.0.0/0

all -- 192.168.0.11 0.0.0.0/0

all -- 192.168.0.13 0.0.0.0/0

all -- 192.168.0.12 0.0.0.0/0

all -- 192.168.0.1 0.0.0.0/0

RETURN all -- 0.0.0.0/0 0.0.0.0/0

------------------------------

[root@linux root]# iptables -t nat -nL

Chain PREROUTING (policy ACCEPT)

target prot opt source destination

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

---------------

mangle - пустой

[Zelenev]

DROP all -- 192.168.0.0/24 192.168.1.0/24

DROP all -- 192.168.1.0/24 192.168.0.0/24

это написано, чтобы пользователи из одной локальной сетки не видели другую

[Ineu]

Zelenev писал(а) Fri, 27 October 2006 14:23

iptables -t nat -nL ... Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 ...

1. Зачем Вы маскируете все подряд?

2. С каких счетчиков Вы снимаете статистику?

[Hans R. Steiner]

iptables -t mangle -F

iptables -t filter -F

iptables -t nat -F

iptables -t filter -P FORWARD DROP

iptables -t filter -A FORWARD -s 192.168.0.0/24 -d 192.168.1.0/24 -j DROP

iptables -t filter -A FORWARD -s 192.168.1.0/24 -d 192.168.0.0/24 -j DROP

iptables -t filter -A FORWARD -j ULOG --ulog-nlgroup 1 --ulog-cprange 48 --ulog-qthreshold 50 --ulog-prefix "COMMENT"

iptables -t filter -A FORWARD -s 192.168.x.x -j ACCEPT

iptables -t nat -A POSTROUTING -s 192.168.0.0/23 -j SNAT --to-source ${IPADDR}

соответственно, надо еще ulog поставить...

[Zelenev]

1. Зачем Вы маскируете все подряд?

2. С каких счетчиков Вы снимаете статистику?

Я складываю значения, возвращаемые TRAFFIC_TCP_INBOUND_FW и TRAFFIC_TCP_INBOUND и высчитываю общую статистику.

М.б. можно делать как-нибудь иначе?

[Ineu]

Zelenev писал(а) Sat, 28 October 2006 09:39

М.б. можно делать как-нибудь иначе?

Сделайте так, как указал Ганс. После этого Вам останется установить ulogd. Можно настроить его на работу с СУБД, а там уже обрабатывать трафик. Правда, ulog логирует каждый пакет, поэтому нужно будет периодически трафик в базе обрабатывать. Скрипт для этого пишется за час, запускаете его по крону, частота запуска зависит от кол-ва трафика. Когда он станет достаточно велик, лучше перейти на netflow/sflow.

ЗЫ. При достаточно хорошем знании Вашей СУБД можно всю логику засунуть в саму базу.

[Hans R. Steiner]

В принципе, я не думаю, что есть смысл переходить на netflow так,

как в зависимости от организации сети и обьемов трафика, при

использовании netflow, возможны потери + дополнительная нагрузка

на сеть (пусть даже не значительная, но все-таки).

Если требуется жестко задать предел потребляемого трафика для

пользователя, можно использовать iptables limit.

[Ineu]

Hans R. Steiner писал(а) Sun, 29 October 2006 13:56

В принципе, я не думаю, что есть смысл переходить на netflow так, как в зависимости от организации сети и обьемов трафика, при использовании netflow, возможны потери + дополнительная нагрузка на сеть (пусть даже не значительная, но все-таки).

Ну... имхо, сам принцип работы нетфло предполагает сбор и предварительную агрегацию статистики на промежуточных узлах между клиентом и сервером учета/биллинга. Это позволяет избавиться от потерь при достаточно большом потоке трафика. Но при такой схеме, как у Zelenev смысла в этом нет, согласен.

[Hans R. Steiner]

Более того, при варианте учета трафика средствами iptables и

т.д., нет никакой потери трафика, а при учете с помощью netflow, все зависит от загрузки сети, а данные отправляются по udp...

т.е., в случае не прохождения пакета, теряются. Вариант поднятия

того же ulogd на каждом из узлов и слияния его в одну базу, все-

таки вернее.

Но вот для тех же маршрутизаторов cisco или другого железа, что

держжит netflow, netflow действительно хороший вариант.

ЗЫ: мне просто не нравится сама возможность потери информации,

не учитывая обьемы этих потерь.

ЗЫ: извентиляюсь за очепятки, замэрз

[Ineu]

Hans R. Steiner писал(а) Sun, 29 October 2006 22:23

Более того, при варианте учета трафика средствами iptables и т.д., нет никакой потери трафика, а при учете с помощью netflow, все зависит от загрузки сети, а данные отправляются по udp... т.е., в случае не прохождения пакета, теряются.

Ну... есть ведь номер пакета... Любой уважающий себя коллектор при потерях начинает жутко ругаться

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

Цитата:

Вариант поднятия того же ulogd на каждом из узлов и слияния его в одну базу, все- таки вернее.

Согласен. Правда, каждый из узлов должен сам иметь достаточную мощность, чтобы не терять записей в СУБД. Ведь логируется каждый (!) пакет. При трафике в мегабит со средним размером пакета в 600 байт получим 1 000 О00 / 8 / 600 == 208 INSERT'ов в секунду. Агрегировать придется достаточно часто. Огромный плюс нетфло - в преагрегации самим сенсором.

Цитата:

ЗЫ: мне просто не нравится сама возможность потери информации, не учитывая обьемы этих потерь.

Обратите внимание на технологию sflow, основанную на намеренной потере информации

ЗЫ. Повторюсь - я целиком и полностью согласен, что для указанной конфигурации ulog явл. лУчшим выбором, нежели netflow.

ЗЗЫ. 2Ганс

Очень интересный тред, не совсем по теме, но много полезного:

http://forum.nag.ru/index.php?showtopic=28947

[Zelenev]

спасибо большое за цепочки

А где можно почитать про ulog?

[Ineu]

Zelenev писал(а) Mon, 30 October 2006 13:02

спасибо большое за цепочки А где можно почитать про ulog?

/usr/share/doc/ulogd*

google.com

удачи

[Zelenev]

У меня ulogd не установлен, где его можно скачать?

(версия ядра 2.4.20)

[Ineu]

Zelenev писал(а) Mon, 30 October 2006 14:09

У меня ulogd не установлен, где его можно скачать? (версия ядра 2.4.20)

Я с Вас прямо удивляюсь... Помимо того, что его можно поставить при помощи менеджера пакетов дистрибутива, есть же еще и Гугль!