Перейти до

Freebsd 7.4+Tpdoxy Stg неправильно считает


Рекомендованные сообщения

Доброго времени суток!

 

Установлена FreeBSD 7.4, ipfw nat(kernel nat), Squid Version 3.1.18 - прозрачный прокси, stg с базой pgsql(postgresql).

Конфиги:

 

 

IPFW:

 

em0-внутренний интерфейс

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

10.0.0.0/8 -внутрення подсеть

 

 

 

ipfw add 7000 allow udp from внутренний_IP 5555 to 10.0.0.0/8 via em0

ipfw add 7001 allow udp from 10.0.0.0/8 to внутренний_IP 5555 via em0

ipfw add 8000 allow all from any to any via lo0

ipfw add 8001 allow udp from me to any domain keep-state

ipfw add 9000 fwd внутренний_IP,3128 tcp from 10.0.0.0/8 to any 80,8080 out via em1

ipfw nat 1 config ip внешний IP log

ipfw add 10000 nat 1 ip from any to any via em1

 

 

SQUID

 

#squid -v

Squid Cache: Version 3.1.18

configure options: '--with-default-user=squid' '--bindir=/usr/local/sbin' '--sbindir=/usr/local/sbin' '--datadir=/usr/local/etc/squid' '--libexecdir=/usr/local/libexec/squid' '--localstatedir=/var/squid' '--sysconfdir=/usr/local/etc/squid' '--with-logdir=/var/log/squid' '--with-pidfile=/var/run/squid/squid.pid' '--enable-removal-policies=lru heap' '--disable-linux-netfilter' '--disable-linux-tproxy' '--disable-epoll' '--disable-translation' '--enable-auth=basic digest negotiate ntlm' '--enable-basic-auth-helpers=DB NCSA PAM MSNT SMB squid_radius_auth' '--enable-digest-auth-helpers=password' '--enable-external-acl-helpers=ip_user session unix_group wbinfo_group' '--enable-ntlm-auth-helpers=smb_lm' '--without-pthreads' '--enable-storeio=ufs diskd' '--enable-disk-io=AIO Blocking DiskDaemon' '--disable-ipv6' '--disable-snmp' '--disable-htcp' '--enable-arp-acl' '--enable-ipfw-transparent' '--disable-ecap' '--disable-loadable-modules' '--disable-kqueue' '--with-large-files' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=i386-portbld-freebsd7.4' 'build_alias=i386-portbld-freebsd7.4' 'CC=cc' 'CFLAGS=-O2 -fno-strict-aliasing -pipe' 'LDFLAGS=' 'CPPFLAGS=' 'CXX=c++' 'CXXFLAGS=-O2 -fno-strict-aliasing -pipe' 'CPP=cpp' --with-squid=/usr/ports/www/squid31/work/squid-3.1.18 --enable-ltdl-convenience

 

squid.conf

 

#порт прозрачного прокси

http_port внутренний_IP:3128 intercept

 

##DNS

check_hostnames off

dns_nameservers xx.xx.xx.xx

##DNS

 

# список слов, которые будучи обнаруженными в URL

# вызывают обработку без кэширования

#hierarchy_stoplist cgi-bin ?

 

# список ACL которые вызывают несовпадение с кэшем,

# и, запрос с ответом кэшироваться не будут

#acl QUERY urlpath_regex cgi-bin \?

 

# собственно - правило что не кэшируем

#no_cache deny QUERY

 

# сколько отдаём ему памяти

cache_mem 64 MB

 

# пределы для включения механизма очистки кеша от устаревших данных, в процентах

# кеш при достижении 95% заполнения начинает очищаться

cache_swap_low 90

cache_swap_high 95

 

#Этот тэг задает размер объекта который может хранится в памяти. Объекты

#больше этого размера, сохранятся в памяти не будут. Объекты из памяти

#достаются быстрее, поэтому там должны содержатся только объекты, которые

#часто запрашиваются клиентами. Увеличение значения этого тэга приводит к снижению производительности сервера.

maximum_object_size_in_memory 8 KB

 

 

# минимальный размер файл для сохранения в кеше

#minimum_object_size 0 KB

# максимальный размер файл для сохранения в кеше

maximum_object_size 4096 KB

 

 

 

# Директория для кэша, числа - размер кэша в Mb,

# число директорий первого уровня, число директорий второго

# уровня в каждой директории первого.

cache_dir ufs /home/squid/cache 10000 16 256

 

# лог доступа - первый параметр путь, второй - формат

# форматы описаны в дефолтовом файле.

access_log /home/squid/logs/access.log

 

# лог активности менеджера хранилища. Показывает, какие

# объекты были сохранениы/удалены из кэша и как долго.

# мне он не нужен, а места занимает прилично.

cache_store_log none

 

# директория где хранятся HTML c текстами ошибок

error_directory /usr/local/etc/squid/errors/ru

cache_log /home/squid/logs/cache.log

 

pid_filename /home/squid/logs/squid.pid

 

 

#Эти тэги устанавливают докачку объектов в кэш, если клиент оборвал

# соединение.

quick_abort_min 0

quick_abort_max 0

 

shutdown_lifetime 5 seconds

 

 

#-----------------ACL rules________________

 

acl all_net src 10.0.0.0/8

 

http_access allow all_net

http_reply_access allow all_net

 

#-----------------ACL rules~~~~~~~~~~~~~~~

 

cache_mgr xxxxxxx@xxxxx.xx.xx

 

refresh_pattern ^ftp: 1440 20% 10080

refresh_pattern ^gopher: 1440 0% 1440

refresh_pattern -i (/cgi-bin/|\?) 0 0% 0

refresh_pattern . 0 20% 4320

 

cache_effective_user squid

cache_effective_group squid

 

stargazer.conf

провожу только модуль захвата трафика

 

<Module cap_bpf>

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

iface = em0

</Module>

rules

 

ALL 0.0.0.0/0 DIR0

ALL 10.0.0.0/8 DIR1

 

Проблема следующего характера : если в IPFW включено правило

ipfw add 9000 fwd внутренний_IP,3128 tcp from 10.0.0.0/8 to any 80,8080 out via em1

stg ошибаеться в подсчете трафика на 30-35% в минус, т.е. например при закачке файла 204Мб stg подсчитывает только 167Мб, да и в момент закачки squid грузит проц от 5 до 15 %. Тачка 2-х процесорная 4-х ядерные процы 4 Гб оперативы. При этом в логах сквида число правильное и в IPFW тоже все верно.

Через НАТ без прозрачной прокси считает верно.

Помогите люди добрые а то уже неделю колупаюсь, заранее спасибо!!!

Ссылка на сообщение
Поделиться на других сайтах

2 Polo

<module cap_bpf="">

Этим все сказано. Переходите на cap_nf - он считает очень быстро и точно практически любые скоростя.

 

2 Roman Pogosyan

закачке файла 204Мб stg подсчитывает только 167Мб
может те 30% есть кеш сквида который идет с lo интерфейса ?

Частичное кеширование одного файла? :D

 

Кроме того действительно какая разница - iface = em0 таки идет к юзерам всеравно, тобишь всеравно весь трафик пролетает по нему. Суть проблемы тут только в том что bpf пропускает пакеты когда ему кажется "ой не успелось".

Ссылка на сообщение
Поделиться на других сайтах
добавил в модуль захвата трафика lo интерфейс. Ы теперь из 204Мб считает 186Мб ... гадство!

Вы еще раз пять разные интерфейсы продублируйте чтобы весь трафик считался по полтора раза :D

 

Грю же - bpf нормально считает при скоростях <10mbit/s и при pps стремящемся к 0. Будьте человеком - используйте нормальные каунтеры.

Ссылка на сообщение
Поделиться на других сайтах

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

И опять же таки на НАТе без прозрачной прокси он считает верно.

Ссылка на сообщение
Поделиться на других сайтах
Я тут неспорю модуль действительно неочень, но как-то привык я к нему уже 3 года пользуюсь.

Думаю придется отвыкать - я вот отвык еще лет 5 назад, тогда еще пакетные тарифы были в моде.... когда он начал привирать на каких-то 50-60% :D

 

Все ваше

 

<Module cap_bpf>
iface = em0
</Module>

 

Елементарно можно заменить на

 

  <Module cap_nf>
	TCPPort = 42111
	UDPPort = 42111
  </Module>

+ softflowd -i em0 -n 127.0.0.1:42111

 

И опять же таки на НАТе без прозрачной прокси он считает верно.

В чудеса не верю - прозрачная прокся и nat с точки зрения интерфейска em0 - ничем не отличаються. Единственное что могу предположить в случае с nat-ом bpf чуть пожже начинает пугаться ситуации "ой не успею - давай скипну".

Ссылка на сообщение
Поделиться на других сайтах

Софтовый сенсор netflow

 

# cd /usr/ports/net-mgmt/softflowd && make install

 

Даже не знаю что еще можно придумать удобнее. Ценен кстати тем, что в отличии от cap_bpf (врун он) и скажем cap_divert (тот еще тормоз) можно собирать стату где угодно. Скажем с бордера.

Ссылка на сообщение
Поделиться на других сайтах

а скрипт стг onconnect у меня в нем сейчас:

 

# Login

LOGIN=$1

 

#user IP

echo $2

IP=$2

 

#cash

CASH=$3

 

#user ID

ID=$4

 

echo "C `date +%Y.%m.%d-%H.%M.%S` $IP $CASH" >> /var/stargazer/users/$LOGIN/connect.log

 

 

ipfw add `expr $ID + 11000` allow tcp from $IP to any in recv em0

ipfw add `expr $ID + 11000` allow tcp from any to $IP out xmit em0

 

 

 

как нуна его поменять?

Ссылка на сообщение
Поделиться на других сайтах

нет нужды шейпить ...если бы правильно считало на bpf меня бы все устроило

кстати сейчас живая система freebsd 6.4+stgу+ipfw+natd+tproxy(squid) у меня работает и правильно считает на bpf при скорости 50mbit/s

 

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

Ссылка на сообщение
Поделиться на других сайтах
кстати сейчас живая система freebsd 6.4+stgу+ipfw+natd+tproxy(squid) у меня работает и правильно считает на bpf при скорости 50mbit/s

Ну, средний домашний тариф на одного юзера сейчас :D

 

Поверьте - проще заменить три строчки в конфиге старгейзера изначально и не иметь потом проблем на скоростях до 10Гиг чем играться в ручную подгонку трафика методом считания его дважды на всех возможных интерфейсах. Хотя да - не отрицаю, можно и сексом с кондиционером заняться, только зачем?

Благо установка нормального сенсора (softflowd/fprobe) из портов - занимает 15 секунд и 1 строчку в шелле.

Ссылка на сообщение
Поделиться на других сайтах
так всетаки для ipfw+tproxy как правильно наваять скрипт onconnect под netflow

Зачем?!

 

Просто запустить сенсор один раз руками или из rc.local и забыть на всегда.

 

Вы что собирались его из OnConnect на каждого юзера стартовать? Чтобы получить количество_трафика*количество_юзеров?

Ссылка на сообщение
Поделиться на других сайтах

может я чего-то недогоняю!

но если я не открою скриптом onconnect пользователю доступ к серверу то как он попадет в инет при закрытом IPFW?!

Ссылка на сообщение
Поделиться на других сайтах

А это ваше

ipfw add `expr $ID + 11000` allow tcp from $IP to any in recv em0
ipfw add `expr $ID + 11000` allow tcp from any to $IP out xmit em0

чем не устраивает?

 

Вобще не понимаю какое отношение к подсчету трафика имеет то как выглядит ваш OnConnect.

Ссылка на сообщение
Поделиться на других сайтах

Ну если быть совсем точным, то вместо cap_bpf можно использовать cap_divert и в файрволе добавить правила для tee.

А если использовать cap_nf то TCPPort можно не указывать, все равно вы не используете NetFlow-proxy.

А так все верно сказано, BPF может пропускать пакеты.

Ссылка на сообщение
Поделиться на других сайтах

поставил Softflowd изпортов FreeBSD, включил в конфиге СТГ Module: 'CAP_NF v. 0.4'

кусок конфига:

<Module cap_nf>

#TCPPort = 42111

UDPPort = 42111

</Module>

 

IPFW закрыт по умолчанию(65535 deny ip from any to any):

 

em0-внутренний интерфейс

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

10.0.0.0/8 -внутрення подсеть

 

ipfw add 7000 allow udp from внутренний_IP 5555 to 10.0.0.0/8 via em0

ipfw add 7001 allow udp from 10.0.0.0/8 to внутренний_IP 5555 via em0

ipfw add 8000 allow all from any to any via lo0

ipfw add 8001 allow udp from me to any domain keep-state

ipfw add 9000 fwd внутренний_IP,3128 tcp from 10.0.0.0/8 to any 80,8080 out via em1

ipfw nat 1 config ip внешний IP log

ipfw add 10000 nat 1 ip from any to any via em1

 

запустил softflowd -i em0 -n 127.0.0.1:42111

 

в stg rules:

ALL 0.0.0.0/0 DIR0

 

кароче ненаю де и что я делаю нетак, но считает оно очень медленно и невсегда верно откуда что берет непонятно в inetaccess перезапись результатов за сесию приходит через несколько минут после окончания закачки. Вопрос --- почему?

Ссылка на сообщение
Поделиться на других сайтах

Все очень просто. Так работает NetFlow. softflowd - "сенсор" в терминологии NetFlow - считает трафик и аггрегирует его в потоки ("flow"), которые потом сливает на коллектор, в роли которого выступает Stargazer. Соответственно, информация о трафике доходит до него с задержкой, равной времени жизни одного flow. Это регулируется настройками сенсора, но все равно задержка будет. Есть еще, к стати, и принудительный сброс "потоков", но как его сделать в softflowd я не знаю.

Ссылка на сообщение
Поделиться на других сайтах
IPFW закрыт по умолчанию(65535 deny ip from any to any)

Довольно нехороший вариант. Лучше делать deny ip from users_subnet/cidr to any via em0 + обратно

 

но считает оно очень медленно

Что значит медленно?

Если вы о том что он статистику скидывает не моментально - дык он так и должен работать. Сначала накапливает сессии после чего их скидывает коллектору и флушит у себя. Хотите участить сброс сессий к коллектору? Крутите max_flows и timeout_name. То с какой частотой stargazer запись статы в базу - тоже крутиться в stargazer.conf. В норме netflow подразумевает что сенсор дожидается либо експайра либо нормального завершения сессии перед сбросом. Также сессия автоматом сбрасывается сенсору если ее размер привысил 2Гб.

 

Если очень хочется посмотреть чего он там и как насчитал можете сделать softflowctl statistics и посмотреть глазами как оно.

 

к стати, и принудительный сброс "потоков", но как его сделать в softflowd я не знаю.

softflowctl там прилагается для таких штук

 

PS madf подлец, опередил на 4 секунды :rolleyes:

Ссылка на сообщение
Поделиться на других сайтах

медленно значит медленно! у мя канал то входящий может и небольшой всего лишь 50 Мб/с но я юзверю в месяц выделяю 1Гб и поентому если cap_nf мне не отдаст с той же скоростью что и cap_bpf то у юзверя не гиг будет а 10Гб -- утрирую, да а stargazer.conf я приводил вначале темы там все гуд.

Так что если мона поподробнее о max_flows и timeout_name.

И еще как у Вас работает softflowd через libpcap или ng_netflow.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...