stargazer+divert как считать трафик?

[AlexeyD 0]

Привет всем.

Вобщем что я имею

FreeBSD 4.9

ipfw

natd

192.168.250.1 rl0 - смотрит в локалку

195.хх.хх.хх - смотрит на ISP

 

squid - transparent proxy

 

натом пускаю в мир почту и игрухи (110, 25, 5003, 2593, etc...)

 

как stgz заставить считать все что дивертится?

Тоесть весь диверт у меня идет на fxp0, а по rl0 http без диверта.

 

что нужно писать в ruls и в stargazer.conf

 

слышал в stargazer.conf нужно писать что что-то типа interf= rl0, fxp0 8668

 

Ваши предложения...

[RSR 0]

Привет всем.

Вобщем что я имею

FreeBSD 4.9

ipfw

natd

192.168.250.1 rl0 - смотрит в локалку

195.хх.хх.хх - смотрит на ISP

 

squid - transparent proxy

 

натом пускаю в мир почту и игрухи (110, 25, 5003, 2593, etc...)

 

как stgz заставить считать все что дивертится?

Тоесть весь диверт у меня идет на fxp0, а по rl0 http без диверта.

 

что нужно писать в ruls и в stargazer.conf

 

слышал в stargazer.conf нужно писать что что-то типа interf= rl0, fxp0 8668

 

Ваши предложения...

дивер должен работать на rl0! тоесть interf= rl0 8668, fxp0

[AlexeyD 0]

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

 

Может кто подкинет свои конфиги фаервола и старгазера а???

[XoRe 0]

1. Советую прочитать http://stg.dp.ua/doc/conf_divert.html

2. Советую почитать man по ipfw и вникнуть в его работу.

Можно организовать подсчет траффика через диверт на любом из двух интерфейсов.

Правило divert - это просто отправка пакета на обработку другой программе.

=>

Как будет считаться траффик через диверт, зависит не от настройки параметра interf=..., а от настройки файрволла.

 

В указанной выше статье есть примеры, как можно настроить ipfw.

От себя могу лишь добавить, что пакет должен дивертиться в stargazer прежде, чем в natd.

[digim 0]

1. Советую прочитать http://stg.dp.ua/doc/conf_divert.html

2. Советую почитать man по ipfw и вникнуть в его работу.

Можно организовать подсчет траффика через диверт на любом из двух интерфейсов.

Правило divert - это просто отправка пакета на обработку другой программе.

=>

Как будет считаться траффик через диверт, зависит не от настройки параметра interf=..., а от настройки файрволла.

 

В указанной выше статье есть примеры, как можно настроить ipfw.

От себя могу лишь добавить, что пакет должен дивертиться в stargazer прежде, чем в natd.

и почему же прежде чем в натд? мы тогда никогда не узнаем кому этот пакет адресован, будет вестись только общий подсчет траффика!

 

ЗЫ считаю крайне необходимым выложить на сайт СТГ рабочий пример с конфигами, полным списком правил фаервола и топологией сети.

[asphix 0]

В моём случае использование nat вообще не планируется. т.к. биллинговый сервак с stg внешним интерфейсом смотрит непосредственно в интерфейс другого сервера, раздающего инет с использованием nat (извращение в связи со спецификой оборудования). Как в таком случае быть? Дивертить пакеты в правиле до или после? т.е.:

 

${fw} add `expr $id '*' 10 + 29000` tcp from $ip to any via ${int_if}

${fw} add `expr $id '*' 10 + 29001` divert 15701 ip from $ip to any via ${int_if}

 

или же наоборот

 

${fw} add `expr $id '*' 10 + 29001` divert 15701 ip from $ip to any via ${int_if}

${fw} add `expr $id '*' 10 + 29000` tcp from $ip to any via ${int_if}

[digim 0]

В моём случае использование nat вообще не планируется. т.к. биллинговый сервак с stg внешним интерфейсом смотрит непосредственно в интерфейс другого сервера, раздающего инет с использованием nat (извращение в связи со спецификой оборудования). Как в таком случае быть? Дивертить пакеты в правиле до или после? т.е.:

 

${fw} add `expr $id '*' 10 + 29000` tcp from $ip to any via ${int_if}

${fw} add `expr $id '*' 10 + 29001` divert 15701 ip from $ip to any via ${int_if}

 

или же наоборот

 

${fw} add `expr $id '*' 10 + 29001` divert 15701 ip from $ip to any via ${int_if}

${fw} add `expr $id '*' 10 + 29000` tcp from $ip to any via ${int_if}

имхо дивертить надо ДО, потому что когда пакет проходит правило allow(у тебя кстати это не указано) он больше в фаервол не попадает.

[asphix 0]

От балды набросал, конечно allow нужен..

 

Значит если диверт указать до(хотя в примере стоит после), то пакет зайдёт в порт и divert_cap его обратно вернёт для дальнейшей обработки?

[digim 0]

От балды набросал, конечно allow нужен..

 

Значит если диверт указать до(хотя в примере стоит после), то пакет зайдёт в порт и divert_cap его обратно вернёт для дальнейшей обработки?

строго говоря - так должно быть

[asphix 0]

Подтверждение в студию (статьи, примеры, описания)

 

 

Откуда такая уверенность?

[digim 0]

Подтверждение в студию (статьи, примеры, описания)

 

 

Откуда такая уверенность?

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

 

выдержки из мана:

divert port

Divert packets that match this rule to the divert(4) socket bound

to port port. The search terminates.

 

PACKET DIVERSION

A divert(4) socket bound to the specified port will receive all packets

diverted to that port. If no socket is bound to the destination port, or

if the divert module is not loaded, or if the kernel was not compiled

with divert socket support, the packets are dropped.

 

Packets diverted to userland, and then reinserted by a userland process

may lose various packet attributes. The packet source interface name

will be preserved if it is shorter than 8 bytes and the userland process

saves and reuses the sockaddr_in (as does natd(8)); otherwise, it may be

lost. If a packet is reinserted in this manner, later rules may be

incorrectly applied, making the order of divert rules in the rule

sequence very important.

[asphix 0]

Короче всё понятно..

 

Значит, поднял схему на виртуальной машине:

FreeBSD 6.0

stg-2.402.9.7

1 iface - lnc0

 

Поднял сервер, запустил, конфигуратором добавил юзера, прописал ему в

OnConnect:

ipfw add `expr $ID '*' 10 + 29000` divert 15701 ip from $IP to any via lnc0

ipfw add `expr $ID '*' 10 + 29001` allow ip from $IP to any via lnc0

 

Наоборот не пробовал

 

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

 

Субъективно сложилось впечатление что трафик всё же считается

[digim 0]

Короче всё понятно..

 

Значит, поднял схему на виртуальной машине:

FreeBSD 6.0

stg-2.402.9.7

1 iface - lnc0

 

Поднял сервер, запустил, конфигуратором добавил юзера, прописал ему в

OnConnect:

ipfw add `expr $ID '*' 10 + 29000` divert 15701 ip from $IP to any via lnc0

ipfw add `expr $ID '*' 10 + 29001` allow ip from $IP to any via lnc0

 

Наоборот не пробовал

 

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

 

Субъективно сложилось впечатление что трафик всё же считается

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

[asphix 0]

Кстати, насчет диверта и ната могу порекомендовать прочитать это:

 

http://www.opennet.ru/openforum/vsluhforumID1/40424.html

 

Может быть прояснит ситуацию?

 

От себя добавлю, как понял: если считать входящий трафик, то дивертить на нат нужно на внешнем интерфейсе(для выпуска наружу клиентов), а считать траффик нужно на внутреннем, когда нат уже выполнил обратное преобразование адреса, предварительно задивертив его в divert_cap (входящий трафик)

 

Поправьте меня, если не так понял.

[digim 0]

в данной конкретной ситуации трафик надо считать на внутреннем интерфейсе, а дивертить на нат нужно входящие и исходящие пакеты, там интерфейсы в принципе непричем.

[asphix 0]

Короче всё понятно..

 

Значит, поднял схему на виртуальной машине:

FreeBSD 6.0

stg-2.402.9.7

1 iface - lnc0

 

Поднял сервер, запустил, конфигуратором добавил юзера, прописал ему в

OnConnect:

ipfw add `expr $ID '*' 10 + 29000` divert 15701 ip from $IP to any via lnc0

ipfw add `expr $ID '*' 10 + 29001` allow ip from $IP to any via lnc0

 

Наоборот не пробовал

 

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

 

Субъективно сложилось впечатление что трафик всё же считается

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

Верно, схема тестовая - по этому особо не следил за смыслом.

 

У меня в реале такая ситуация, если рассматривать более конкретно:

 

em0 (10.101.0.1) - смотрит на юзеров

em1 (10.101.1.1) - смотрит в контент сервера (игры(1.5), софт(1.6))

fxp0 (192.168.0.1) - смотрит в машину, на которой nat'ом раздаётся инет

 

Считать нужно только входящий трафик, соответственно divert'ить нужно пакеты, входящие на em0, т.е.:

 

..

add divert 15701 ip from any to $IP via em0 -- Считаем

add allow ip from any to $IP via em0 -- Пропускаем до юзера

..

 

а уже непосредственно в rules указать необходимые направления, например:

 

# Пинг

ICMP 0.0.0.0/0 NULL

 

# Локальный трафик

ALL 10.101.0.0/24 DIR0

 

# Трафик на роутер

ALL 192.168.0.1 DIR0

ALL 10.101.0.1 DIR0

ALL 10.101.1.1 DIR0

 

# Трафик с контент-серверов (разный по цене для игр и софта)

ALL 10.101.1.5 DIR1

ALL 10.101.1.6 DIR2

 

# Мир

ALL 0.0.0.0/0 DIR3

 

Я лично свою ситуацию понимаю так.. поправьте, если ошибся где?

[asphix 0]

в данной конкретной ситуации трафик надо считать на внутреннем интерфейсе, а дивертить на нат нужно входящие и исходящие пакеты, там интерфейсы в принципе непричем.

Позволю уточнить: дивертить на нат нужно входящие и исходящие пакеты, проходящие через ext_if - так что имхо интерфейс как раз причем.

[digim 0]

в данной конкретной ситуации трафик надо считать на внутреннем интерфейсе, а дивертить на нат нужно входящие и исходящие пакеты, там интерфейсы в принципе непричем.

Позволю уточнить: дивертить на нат нужно входящие и исходящие пакеты, проходящие через ext_if - так что имхо интерфейс как раз причем.

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

не хочет работать собака и все тут...что ему не так не пойму

[digim 0]

кто-нибудь вообще скажет как работает диверт-механизм в СТГ? по аналогии с натд или нет?

вот что у меня получается:

---кусок с натд - чисто для демонстрации что натд на машине работает отлично

00050 106448 14170118 divert 8668 ip from 192.168.2.0/24 to any out xmit fxp0

00060 150893 72147124 divert 8668 ip from any to x.x.x.x

------а вот тут самое интересное

00065 177 19823 divert 9999 ip from any to 192.168.2.2

00066 0 0 allow ip from any to 192.168.2.2

как видите после диверта в фаерволе шиш с маслом, почему так может быть?

 

в конфиге СТГ:

<Module cap_divert>

# Интерфейс(ы) на котором нужно производить подсчет трафика

iface = nve0 9999

# iface = nve0, 15001

</Module>

[asphix 0]

кто-нибудь вообще скажет как работает диверт-механизм в СТГ? по аналогии с натд или нет?

вот что у меня получается:

---кусок с натд - чисто для демонстрации что натд на машине работает отлично

00050 106448 14170118 divert 8668 ip from 192.168.2.0/24 to any out xmit fxp0

00060 150893 72147124 divert 8668 ip from any to x.x.x.x

------а вот тут самое интересное

00065 177 19823 divert 9999 ip from any to 192.168.2.2

00066 0 0 allow ip from any to 192.168.2.2

как видите после диверта в фаерволе шиш с маслом, почему так может быть?

 

в конфиге СТГ:

<Module cap_divert>

# Интерфейс(ы) на котором нужно производить подсчет трафика

iface = nve0 9999

# iface = nve0, 15001

</Module>

Затора не может быть в других правилах?

 

Может быть попробовать сначала на 2-3-х самых простых и всё разрешающих правилах добится диверта? Потом донаворачивать?

 

Можно посмотреть полностью набор правил?

[digim 0]

кто-нибудь вообще скажет как работает диверт-механизм в СТГ? по аналогии с натд или нет?

вот что у меня получается:

---кусок с натд - чисто для демонстрации что натд на машине работает отлично

00050  106448  14170118 divert 8668 ip from 192.168.2.0/24 to any out xmit fxp0

00060  150893  72147124 divert 8668 ip from any to x.x.x.x

------а вот тут самое интересное

00065    177      19823 divert 9999 ip from any to 192.168.2.2

00066      0          0 allow ip from any to 192.168.2.2

как видите после диверта в фаерволе шиш с маслом, почему так может быть?

 

в конфиге СТГ:

    <Module cap_divert>

        # Интерфейс(ы) на котором нужно производить подсчет трафика

        iface = nve0 9999

#        iface = nve0, 15001

    </Module>

Затора не может быть в других правилах?

 

Может быть попробовать сначала на 2-3-х самых простых и всё разрешающих правилах добится диверта? Потом донаворачивать?

 

Можно посмотреть полностью набор правил?

да причем тут другие правила - видно же что диверт и allow идут друг за другом и маска у них совершенно одинаковая, диверт отрабатывает а allow нет - это говорит имхо только об одном - пакеты пропадают после диверсии(во блин как в точку выразился)

ну на всякий случай вот весь рулесет:

 

00010 9905 799571 allow ip from any to me dst-port 22

00050 107729 14237080 divert 8668 ip from 192.168.2.0/24 to any out xmit fxp0

00060 153222 72382848 divert 8668 ip from any to x.x.x.x

00065 1970 198865 divert 9999 ip from any to 192.168.2.2 in

00066 0 0 allow ip from any to 192.168.2.2 in

00070 1224 59324 deny tcp from any to me dst-port 137,138,139 via fxp0

00070 31 2418 deny udp from any to me dst-port 137,138,139 via fxp0

65535 2296983 1577776701 allow ip from any to any

[XoRe 0]

Можно посмотреть полностью набор правил?

А ещё расшифровку, какой интерфейс куда ведет.

 

Проведу некоторый ликбез:

Вот есть шлюз.

Представим его в виде сетевух и ядра.

 

----|in0|----|CORE|----|out0|----

 

in0 смотрит внутрь в сетку 192.168.0.0/24, имеет адрес 192.168.0.1, шлюза нету

out0 смотрит наружу в сетку 100.100.100.0/24, имеет адрес 100.100.100.2, а шлюзом имеет машину провайдера: 100.100.100.1

CORE - это, соответственно ядро ОС.

 

Обработка фаерволом пакетов идет на in0 и на out0.

Т.е. любой пакет, идущий насквозь через комп, проходит фаерволл 2 раза.

 

Пакет от клиента вида 192.168.0.2 -> 200.200.200.200, идет сначала через in0.

Сейчас он приходящий, т.е. подчиняется условию in.

Проходит фаерволл, заканчивая путешествия по правилам фаерволла на каком-нибудь allow.

 

Проходит через ядро в таком же виде, т.е. 192.168.0.2 -> 200.200.200.200.

 

На out0 он nat'ится и получает вид: 100.100.100.2 -> 200.200.200.200.

Сейчас он исходящий, т.е. подчиняется условию out.

Правилом allow он уходит.

Тут следует учесть, что allow должен быть не на 192.168.0.2 -> 200.200.200.200, а на 100.100.100.2 -> 200.200.200.200.

 

Потом приходит ответ от сервера в виде пакета: 200.200.200.200 -> 100.100.100.2.

Сейчас он приходящий, т.е. подчиняется условию in.

Пакет поступает на фаерволл на in0, попадает в natd и становится пакетом вида: 200.200.200.200 -> 192.168.0.2.

Потом первое же подходящее правило allow его пуляет дальше.

 

Пакет 200.200.200.200 -> 192.168.0.2 проходит ядро, не меняясь.

 

На интерфейсе in0 пакет не меняется, т.е. он выглядит как 200.200.200.200 -> 192.168.0.2.

Сейчас он исходящий, т.е. подчиняется условию out.

И первое подходящее правило пуляет его в локалку.

 

Выводы:

1. Отправлять на диверт к СТГ можно и на внешнем и на внутреннем интерфейсе.

НО, трафик локалки удобнее считать на внутреннем интерфейсе.

Нет мороки с адресами и можно считать локальный трафик до шлюза, если надо.

 

2. Отправлять на диверт СТГ только отфильтрованные пакеты.

Например, сначала зарезать весь бродкаст, мультикаст и прочую фигню.

Т.е. deny на такой трафик должен идти до divert на СТГ.

 

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

Т.е. allow на такой трафик должен идти до divert на СТГ.

 

4. Диверт СТГ пакета не меняет, в отличие от divert nat.

 

5. Если вы хотите иметь диверт СТГ и диверт nat на одном интерфейсе, то опишите правила так, чтобы пакеты отправлялись к СТГ ДО ната, если они идут в мир, и ПОСЛЕ ната, если это ответ из мира.

Чтобы был виден локальный айпишник.

Т.е. например такая конструкция:

divert 7777 ip from 192.168.0.0/24 to any via out0

divert natd ip from any to any

divert 7777 ip from any to 192.168.0.0/24 via out0

 

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

Поэтому я описал это максимально подробно.

По себе знаю, что пока вот так подробно не представишь движение пакетов, с правилами играться довольно трудно.

[asphix 0]

Я не зря постил ссылку на опеннет. Ещё раз привожу выдержку из man:

---8<-------

After translation by natd, packets re-enter the firewall at the rule

number following the rule number that caused the diversion (not the

next rule if there are several at the same number).

---8<---------

 

В твоём случае получается, что после ната, пакет(уже преобразованный) доходит до правила диверта и.. неудовлетворяет правилам последнего.

 

Попробуй делать нат после диверсии чтоли

 

-- Пока писал XoRe опередил с ответом

[digim 0]

Я не зря постил ссылку на опеннет. Ещё раз привожу выдержку из man:

---8<-------

After translation by natd, packets re-enter the firewall at the rule

number following the rule number that caused the diversion (not the

next rule if there are several at the same number).

---8<---------

 

В твоём случае получается, что после ната, пакет(уже преобразованный) доходит до правила диверта и.. неудовлетворяет правилам последнего.

 

Попробуй делать нат после диверсии чтоли

 

-- Пока писал XoRe опередил с ответом

покажи в каком месте он ему неудовлетворяет? там на счетчиках явно видно сколько раз правило сработало. ты видно сам плохо разбираешься как работает диверт

[digim 0]

Можно посмотреть полностью набор правил?

А ещё расшифровку, какой интерфейс куда ведет.

 

fxp0 это сетевуха во внешний мир(x.x.x.x), nve0 это локальный адаптер(192.168.2.0/24).

 

я в случае чего тоже могу почитать лекции на тему как работает ipfw, но пока что мне неучу такому никто не сказал в какой хромосоме моя проблема, а информации для выводов я имхо достаточно предоставил.