Захотелось сегодня с маркета попробовать установить пару приложений. Но столкнулся с этой ошибкой. Гугл выдавал разные варианты решения. Но ни один из вариантов мне не помогал. Потом методом тыка заметил, что не устанавливается, если выбран отличный от системного диска (То есть если ставил не в С диск). Потратив еще минут 10 нашел причину. Проблема была в галочке "Сжимать содержимое диска". После снятия галочки и удаления директорий, который Windows Store создал при установке этих приложений, все пошло.
Тихая гавань
понедельник, 12 сентября 2016 г.
вторник, 23 августа 2016 г.
Отображение доменов посещенных https ресурсов в логе Squid
Есть замечательные инструкции по поднятию прозрачного прокси Squid с фильтрацией https ресурсов. В частности https://habrahabr.ru/post/272733/. Все бы хорошо (сам использую, все прекрасно работает), но кое-что меня сильно раздражало. В логах сквида вместо адреса посещенного https ресурса указывался ip адрес. В век, когда каждый второй сайт переходит на https это становится проблемой, так как не понятно, что за ресурс посещает юзер и нужно ли блокировать этот ресурс. Потратив полдня на чтение мануалов нашел правильное решение для исправления ситуации. Суть в том, что мы создаем 2 ACL и 2 logformat параметра. Отдельно для логирования запросов на 80 порт и 443. logformat для 80 порта не будет заносить в лог записи о https соединениях. А второй logformat наоборот, пишет в лог только о запросах на 443 порт. Зачем это? дело в том, что для отображения SNI записи в логе надо добавить параметр %ssl::>sni. Но тут появляется другая проблема. Для https ресурсов в логе появляется и имя домена и его IP адрес. За занесение в лог ip адреса отвечает %ru. Вот его то мы и уберем в logformat для запросов на 443 порт. В итоге у нас получаются строки:
Теперь в логе порядок и можно любимым парсером строить отчеты и не бояться встретить там IP адрес вместо домена (за исключением случаев когда пользователь заходит именно по IP, а не по доменному имени)
acl https_port port 443
logformat https %ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ssl::>sni %[un %Sh/%<a %mt
cache_access_log /var/log/squid3/access.log https https_port
acl http_port port 80
logformat http %ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru %[un %Sh/%<a %mt.
cache_access_log /var/log/squid3/access.log http http_port
Теперь в логе порядок и можно любимым парсером строить отчеты и не бояться встретить там IP адрес вместо домена (за исключением случаев когда пользователь заходит именно по IP, а не по доменному имени)
четверг, 31 марта 2016 г.
Dr.Web Esuite Server + Active Directory + Bind
Решил попробовать Dr.Web Esuite Server у себя в домене. Имею тестовый домен AD. В качестве DNS сервера используется bind9. При развертывании Dr.Web server сразу столкнулся с проблемой при предложении установщика зарегистрировать сервис в AD. Постоянно ругался на ошибку админа домена (мол не неправильно я его указал). Хотя логин и пароль были правильными. После 2-3 часов поиска проблем (гугл на это ничего не ответил) взял в руки tcpdump/wireshark и стал смотреть что происходит при попытке продолжить установку. И сразу увидел, что установщик пытается послать данные на порт 135 моего bind сервера. Но bind не открывает 135 порт. Его открывает процесс svhost на контроллере домена. Дело в том, что установщик смотрит, какие DNS серверы указаны в настройках подключения, так как считает, что DNS сервер находиться на контроллере домена. И в стандартной ситуации так и бывает. Но я по некоторым причинам отказался от DNS сервера Microsoft и использовал Bind. Видимо разработчики Dr.web не учитывали такой поворот. Но вернемся к проблеме. Не долго думая я перенаправил просто все запросы на 135 порт на сервер AD с помощью правил iptables
iptables -t nat -I PREROUTING -p tcp -d <dnsservip> --dport 135 -j DNAT --to-destination <adserverip>:135
iptables -t nat -A POSTROUTING -p tcp --dst <adserverip> --dport 135 -j SNAT --to-source <dnsservip>
Где
<dnsservip> IP адрес нашего сервера DNS
<adserverip> IP адрес контроллера домена.
Сразу после добавления правил установка пошла дальше.
среда, 28 октября 2015 г.
Обход ограничения при переносе больших файлов плагином datadir в Rutorrent
Кто пользуется Rutorrent в 32 битных системах наверное сталкивались с проблемой, при которой нельзя переносить торренты размером больше 2/4 Gb. Все основные предложения по обходу этой проблемы заключались в переходе на 64 битную ОС. Я же не мог взять и так просто перейти (домашний шлюз вот уже долгое время крутился на 32 битной Ubuntu, а заниматься переустановкой и настройкой шлюза с нуля не было никакого желания). В одном из постов автор Rutorrent предложил заменить вызовы php функции переноса/копирования на sh. Но до дела так и не дошло. В итоге решил заняться этим сам (к слову с php до этого никогда не работал, поэтому код может быть не идеальным, но зато рабочий). Изменения надо вносить в файл util_rt.php, который находиться в директории ../rutorrent/plugins/datadir. Надо найти строки
Вот и все. Теперь плагин может переносить файлы любого размера.
function rtMoveFile( $src, $dst, $dbg = false )
{
$ss = LFS::stat($src);
if( !rename( $src, $dst ) )
{
if( $dbg ) rtDbg( __FUNCTION__, "from ".$src );
if( $dbg ) rtDbg( __FUNCTION__, "to ".$dst );
if( $dbg ) rtDbg( __FUNCTION__, "move fail, try to copy" );
if( !copy( $src, $dst ) )
{
if( $dbg ) rtDbg( __FUNCTION__, "copy fail" );
return false;
}
if( !unlink( $src ) )
if( $dbg ) rtDbg( __FUNCTION__, "delete fail (".$src.")" );
}
// there are problems here, if run-user is not file owner
if($ss!==false)
touch( $dst, $ss['mtime'], $ss['atime'] );
return true;
}
И привести к виду function rtMoveFile( $src, $dst, $dbg = false )
{
$ss = LFS::stat($src);
$src = escapeshellarg($src);
$dst = escapeshellarg($dst);
exec ("/bin/mv -f $src $dst", $output, $retval);
$err = implode ($output);
if (!empty ($err))
{
if( $dbg ) rtDbg( __FUNCTION__, "from ".$src );
if( $dbg ) rtDbg( __FUNCTION__, "to ".$dst );
if( $dbg ) rtDbg( __FUNCTION__, "erorr ".$err );
if( $dbg ) rtDbg( __FUNCTION__, "move fail, try to copy" );
exec ("/bin/cp -r -f $src $dst 2>&1", $output, $retval);
$err = implode ($output);
if (!empty ($err))
{
if( $dbg ) rtDbg( __FUNCTION__, "copy fail ".$err );
return false;
}
}
// there are problems here, if run-user is not file owner
if($ss!==false)
touch( $dst, $ss['mtime'], $ss['atime'] );
return true;
}
Вот и все. Теперь плагин может переносить файлы любого размера.
среда, 26 августа 2015 г.
nShaper. Динамический шейпер для Linux.
Рано или поздно у многих встает вопрос грамотного распределения трафика в сети. А точнее шейпинга. Особенно если в сети есть участники, качающие по протоколу bittorrent. Во времена, когда интернет у меня раздавал роутер DIR-320 с Олеговской прошивкой, этот вопрос особенно остро и для меня встал, так как канал у меня был слабый. И вот однажды нашел на форуме, посвященному этой прошивке, замечательный скрипт с названием nShaper (тема тут). Это был динамический шейпер, суть которого сводилась в динамическом распределении ширины канала в зависимости от типа и источника/назначения трафика. То есть он сам распределял скорость, в зависимости какой трафик проходит. И не надо было отключать торрент клиент, если кому-то в сети захотелось посидеть в ютубе или послушать музыку. Шейпер урезал скорость торренту и оставлял гарантированную полосу для остального трафика.
Но вот роутер отправился на заслуженный покой, а на смешу пришел полноценный Linux шлюз с Ubuntu. Конечно захотелось и на нем использовать этот шайпер. Сразу он работать отказался. Тогда я уже взял в руки "напильник" и стал заниматься "адаптацией", а после и тестированием. По ходу так же немного расширил функционал, добавив создание правил с использованием nDpi и iptables, и приоритезация трафика на основе маркировки трафика (через тот же ndpi или iptables). Скрипт в 2 версиях, с nDpi и без, если кому-то nDpi не нужен.
Скрипт состоит из 3 файлов. 2 конфиг. файла (nshaper.conf и ip_z1.lst) и самого скрипта (nshaper.sh). Первые 2 лежат в /etc/nshaper, второй в /etc/init.d/ соответственно (естественно надо дать права на запуск и закинуть в автозагрузку при желании).
Конфиг достаточно простой. Основные параметры:
WAN_IF — интерфейс интернет соединения (eth0, ppp0 и т.п)
LAN_IF — интерфейс локальной сети
Если провайдер использует так называемый Russian PPTP, то так же указываем
pptp_ip — сервер подключения pptp
PPTP_IF – название сетевого интерфейса, который смотрит в сеть провайдера (интерфейс, куда воткнут кабель провайдера)
В противном случае их нужно закомментировать.
WAN_DN_RATE — максимально возможная скорость. Не физическая! Например если есть локальные ресурсы, то та самая скорость в локальной сети (если она к примеру выше, чем скорость интернет тарифа). Если же локальных ресурсов нет, то выставляем максимальную скорость интернет соединения. (К примеру, у меня тариф 40мбит Интернет и пиринговые зоны со скоростью 100мбит. Мне надо выставить 100000. Значения в кбит)
WAN_UP_RATE — тоже самое, но для исходящего канала.
WAN_ZONES – название зон. Первая зона всегда остается inet. Вторая уже на Ваш вкус. Если таких зон нет, то оставляем только inet
ZONE_PATH – каталог с файлами зон. (по умолчанию там же, где и сам конфиг, /etc/nshaper)
WAN_ZONES_DN_RATE, WAN_ZONES_UP_RATE – скорость интернет соединения (входящая и исходящая). Значения в кбит. Первая цифра, это скорость интернет соединения. Вторая и последующая - для пиринговых зон. Если зон нет, то указываем только скорость тарифа. Например WAN_ZONES_UP_RATE="40000 100000" или WAN_ZONES_UP_RATE="40000" если нет локальных ресурсов.
В этом же блоке настраиваются скорости для тарифов с ночным увеличением. По комментариям в конфиге думаю все понятно.
RATES="10 10 20 40 15 5"
INET_NAMES="200 201 202 203 204 205"
Приоритеты. % от максимальной ширины канала и их названия. % в принципе редактировать нет необходимости. В данном случае для первого и второго приоритета резервируется 10% канала, для второго 20%, для третьего 40%, для четвертого 15% и для самого низкого 5%. Если в какой-то очереди трафика нет, то его ширина «отдается» остальным. Но если канал забит, то каждый получает свой минимум. То есть запусти вы хоть 100 закачек торрента, свои 40% ширины веб трафик получит. Если же торрентов нет, то веб возьмет все что свободно.
Второй параметр это название приоритетов. Видны при просмотре статуса. Можно как угодно называть. Например Prio, Web, Torrent и т. д.
Синтаксис правил в конфиге подробно описан. Если будут вопросы, отвечу в комментариях.
Теперь требования для работы скрипта.
Во первых (и самое главное) нужна поддержка IMQ. Для этого нужно патчить ядро. В принципе ничего сложного нет. Инструкция тут же в блоге. Она же включает и сборку nDpi (не обязательно).
Во вторых модуль nDpi (если он нужен конечно)
В третьих gawk, conntrack и ipcalc (для корректной работы скрипта).
Запуск скрипта /etc/init.d/nshaper start либо start2 (если нужен полный вывод статистики, подробней читать в nshaper.conf). Просмотр статистики /etc/init.d/nshaper status.
По CPU особых требований нет. У меня на шлюзе слабый AMD E-350 без проблем «переваривает» 40мбит/с интернет трафика + еще 50-60 пирингового.
Скрипт возможно не идеален. Но работает. Если есть замечания — буду рад исправить.
Скрипт состоит из 3 файлов. 2 конфиг. файла (nshaper.conf и ip_z1.lst) и самого скрипта (nshaper.sh). Первые 2 лежат в /etc/nshaper, второй в /etc/init.d/ соответственно (естественно надо дать права на запуск и закинуть в автозагрузку при желании).
Конфиг достаточно простой. Основные параметры:
WAN_IF — интерфейс интернет соединения (eth0, ppp0 и т.п)
LAN_IF — интерфейс локальной сети
Если провайдер использует так называемый Russian PPTP, то так же указываем
pptp_ip — сервер подключения pptp
PPTP_IF – название сетевого интерфейса, который смотрит в сеть провайдера (интерфейс, куда воткнут кабель провайдера)
В противном случае их нужно закомментировать.
WAN_DN_RATE — максимально возможная скорость. Не физическая! Например если есть локальные ресурсы, то та самая скорость в локальной сети (если она к примеру выше, чем скорость интернет тарифа). Если же локальных ресурсов нет, то выставляем максимальную скорость интернет соединения. (К примеру, у меня тариф 40мбит Интернет и пиринговые зоны со скоростью 100мбит. Мне надо выставить 100000. Значения в кбит)
WAN_UP_RATE — тоже самое, но для исходящего канала.
WAN_ZONES – название зон. Первая зона всегда остается inet. Вторая уже на Ваш вкус. Если таких зон нет, то оставляем только inet
ZONE_PATH – каталог с файлами зон. (по умолчанию там же, где и сам конфиг, /etc/nshaper)
WAN_ZONES_DN_RATE, WAN_ZONES_UP_RATE – скорость интернет соединения (входящая и исходящая). Значения в кбит. Первая цифра, это скорость интернет соединения. Вторая и последующая - для пиринговых зон. Если зон нет, то указываем только скорость тарифа. Например WAN_ZONES_UP_RATE="40000 100000" или WAN_ZONES_UP_RATE="40000" если нет локальных ресурсов.
В этом же блоке настраиваются скорости для тарифов с ночным увеличением. По комментариям в конфиге думаю все понятно.
RATES="10 10 20 40 15 5"
INET_NAMES="200 201 202 203 204 205"
Приоритеты. % от максимальной ширины канала и их названия. % в принципе редактировать нет необходимости. В данном случае для первого и второго приоритета резервируется 10% канала, для второго 20%, для третьего 40%, для четвертого 15% и для самого низкого 5%. Если в какой-то очереди трафика нет, то его ширина «отдается» остальным. Но если канал забит, то каждый получает свой минимум. То есть запусти вы хоть 100 закачек торрента, свои 40% ширины веб трафик получит. Если же торрентов нет, то веб возьмет все что свободно.
Второй параметр это название приоритетов. Видны при просмотре статуса. Можно как угодно называть. Например Prio, Web, Torrent и т. д.
Синтаксис правил в конфиге подробно описан. Если будут вопросы, отвечу в комментариях.
Теперь требования для работы скрипта.
Во первых (и самое главное) нужна поддержка IMQ. Для этого нужно патчить ядро. В принципе ничего сложного нет. Инструкция тут же в блоге. Она же включает и сборку nDpi (не обязательно).
Во вторых модуль nDpi (если он нужен конечно)
В третьих gawk, conntrack и ipcalc (для корректной работы скрипта).
Запуск скрипта /etc/init.d/nshaper start либо start2 (если нужен полный вывод статистики, подробней читать в nshaper.conf). Просмотр статистики /etc/init.d/nshaper status.
По CPU особых требований нет. У меня на шлюзе слабый AMD E-350 без проблем «переваривает» 40мбит/с интернет трафика + еще 50-60 пирингового.
Скрипт возможно не идеален. Но работает. Если есть замечания — буду рад исправить.
Версия с nDpi и без. Работоспособность проверял на Centos 7 и Ubuntu 12.04/14.04. Без проблем должно работать и в Debian.
UPD. Обновил. Теперь получение адресов и маски через ip, а не ifconfig.
UPD. Обновил. Теперь получение адресов и маски через ip, а не ifconfig.
пятница, 26 июня 2015 г.
Сборка accel-pptp под Ubuntu 14.04
Многие наверное в курсе, что родной pptp клиент в Ubuntu создает высокую нагрузку, при большом трафике. Поэтому было решено ставить accel-pptp. Поехали.
Остается только в файле настроек клиента убрать строку "pty "pptp....." и добавить
cd /usr/src
&& sudo apt-get install pptp-linux build-essential gawk cmake
sudo apt source ppp
git clone https://github.com/winterheart/accel-pptp.git
sudo ln -s /usr/src/ppp-2.4.7/pppd /usr/src/accel-pptp/src/pppd && cd ./accel-pptp/
cmake -DPPP_PREFIX_DIR=/usr -DPPP_PLUGIN_PATH=/usr/src/accel-pptp/ppp-2.4.7/pppd
make
cp /usr/src/accel-pptp/pptp.so /usr/lib/pppd/2.4.7/
modprobe pptp
echo pptp >> /etc/modules
Остается только в файле настроек клиента убрать строку "pty "pptp....." и добавить
plugin pptp.so
pptp_server XXX.XXX.XXX.XXX
где XXX.XXX.XXX.XXX адрес pptp сервера. Так же в файлах options и options.pptp комментируем все строки lockсуббота, 24 января 2015 г.
Centos, ndpi и imq. Обновлено 3.06.2015.
Сборка ядра для Centos с патчами IMQ и nDPI.
Еще один мануал сборки ядра с Ndpi и imq. Теперь для Centos 7. Проверялся только под x64! Мануал максимально подробный, на уровне "копировать-вставить".
Переходим в домашний каталог и создаем необходимые директории
Устанавливаем необходимые пакеты
Получаем исходники последнего ядра (на момент написания это 3.10.0-123.20.1) и патч подправленный (с офф сайта патч выдавал режекты) IMQ.
Подправим spec файл
Накладываем патч IMQ и включаем модуль
Networking Supportt; Networking Options; Network Packet Filtering Framework (Netfilter); Core Netfilter Configuration → "IMQ" Target Support
Копируем наши конфиги
Ну и сборка
После устанавливаем наше ядро.
Если все нормально то увидим приблизительно следующее
Теперь iptables.
Подправим iptables.spec
Теперь можем собрать и установить
Далее xtables
Следующий шаг nDpi. Использоваться будет версия nDpi без патча ядра. Недостатком этого является отсутствие возможности использовать xt_connlabel. Если кому-то будет интересно, выложу дополнение по сборке с патчем.
Проверяем с помощью lsmod | grep xt_ndpi. Если все нормально то в выводе увидите xt_ndpi
Протоколы с которыми можно работать.Переходим в домашний каталог и создаем необходимые директории
cd ~/
mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros
Устанавливаем необходимые пакеты
yum install rpm-build redhat-rpm-config asciidoc hmaccalc nano perl-ExtUtils-Embed pesign xmlto yum groupinstall "Development Tools" yum install audit-libs-devel binutils-devel elfutils-devel elfutils-libelf-devel zlib-devel yum install newt-devel numactl-devel pciutils-devel python-devel zlib-devel yum install ncurses-devel
qt-devel bc libnetfilter_conntrack-devel libnfnetlink-devel libpcap-devel net-tools wget libselinux-devel
Получаем исходники последнего ядра (на момент написания это 3.10.0-123.20.1) и патч подправленный (с офф сайта патч выдавал режекты) IMQ.
rpm -i http://vault.centos.org/7.0.1406/updates/Source/SPackages/kernel-3.10.0-123.20.1.el7.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -bp --target=$(uname -m) kernel.spec
cd ~/rpmbuild/SOURCES/ && wget https://www.dropbox.com/s/jay95g9tqbnhu29/linux-3.10-imq.diff
Переходим в каталог и копируем конфиг
cd ~/rpmbuild/BUILD/kernel-*/linux-*/
/bin/cp configs/kernel-3.10.0-x86_64.config .config
Подправим spec файл
cd ~/rpmbuild/SPECS/
/bin/cp kernel.spec kernel.spec.back
sed -i -e '5 s/^/%define buildid .IMQ\n/;' kernel.spec
sed -i -e '/Patch999999/i\Patch999998: linux-3.10-imq.diff' kernel.spec
sed -i -e '/ApplyOptionalPatch linux-kernel-test.patch/i\ApplyOptionalPatch linux-3.10-imq.diff' kernel.spec
Накладываем патч IMQ и включаем модуль
cd ~/rpmbuild/BUILD/kernel-*/linux-*/
patch -p1 < ../../../SOURCES/linux-3.10-imq.diff make menuconfig
Device Drivers; Network Device Support;
[M] IMQ (intermediate queueing device) support
[M] IMQ (intermediate queueing device) support
Подправим файл конфига
sed -i -e '1 s/^/# x86_64\n/;' .config
Копируем наши конфиги
/bin/cp ./.config ../../../SOURCES/kernel-3.10.0-x86_64.config
/bin/cp ./.config ../../../SOURCES/kernel-3.10.0-x86_64-debug.config
Ну и сборка
cd ~/rpmbuild/SPECS/ rpmbuild -bb
--without kabichk --without debug --without debuginfo --target=`uname -m` kernel.spec
После устанавливаем наше ядро.
rpm -ivh --force ../RPMS/x86_64/kernel-*.rpm
Перезагружаемся и проверяем reboot
modprobe xt_IMQ
lsmod | grep IMQ
Если все нормально то увидим приблизительно следующее
xt_IMQ 12532 0
Теперь iptables.
cd ~/ && rpm -ivh http://vault.centos.org/7.0.1406/os/Source/SPackages/iptables-1.4.21-13.el7.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -bp iptables.spec
cd ~/rpmbuild/SOURCES/ && wget https://www.dropbox.com/s/x2pvnznhq3z4jnt/imq-iptables-1.4.13.diff
cd ~/rpmbuild/SPECS/
Подправим iptables.spec
sed -i -e '/Patch1/a\Patch2: imq-iptables-1.4.13.diff' iptables.spec
sed -i -e '/%patch1 -p1/a\%patch2 -p1 -b imq-iptables-1.4.13' iptables.spec
rpmbuild -bb iptables.spec
rpm -Uvh ../RPMS/x86_64/iptables-*.rpm
Далее xtables
cd ~/
wget https://www.dropbox.com/s/l16zkc8gbubf9ae/xtables-addons-2.6.tar.xz
tar -xvf xtables-addons-2.6.tar.xz
cd xtables-addons-2.6
./configure
make
make install
Следующий шаг nDpi. Использоваться будет версия nDpi без патча ядра. Недостатком этого является отсутствие возможности использовать xt_connlabel. Если кому-то будет интересно, выложу дополнение по сборке с патчем.
cd ~/
wget http://devel.aanet.ru/ndpi/nDPI-1.5.1.20150513.tar.gz
tar -xvzf nDPI-1.5.1.20150513.tar.gz && cd ./nDPI-1.5.1.20150513/ && ./autogen.sh && cd ./ndpi-netfilter/
sed -i -e 's/net, __ndpi_free_flow, n)/net, __ndpi_free_flow, n, 0 ,0)/' src/main.c
make
make install
make modules_install
modprobe xt_ndpi
Проверяем с помощью lsmod | grep xt_ndpi. Если все нормально то в выводе увидите xt_ndpi
iptables -m ndpi -h
Как и в прошлый раз привожу ссылку на тему, с которой все началось. За патчи говорим спасибо Vel.
Полноценное тестирование не проводил. Максимум что я проверил - поднятие интерфейсов IMQ, перенаправление трафика с интерфейсов на IMQ и 1-2 правила nDpi с маркировкой. Поэтому если что-то работает не так просьба отписаться.
UPD. В новых патчах добавлен target Ndpi. Теперь можно упростить маркировки трафика или его классификацию. Например:
iptables -t mangle -A POSTROUTING -m ndpi --http -j MARK --set-mark 3
iptables -t mangle -A POSTROUTING -m ndpi --http -j RETURN
Теперь можно записать как: iptables --t mangle -A POSTROUTING -m ndpi --proto bittorrent -j NDPI --value 3 --set-mark --ret
А классификацию: iptables -t mangle -A POSTROUTING -m ndpi --bittorrent -j CLASSIFY --set-class 1:5
iptables -t mangle -A POSTROUTING -m ndpi --bittorrent -j RETURN
Можно записать как: iptables -t mangle -A POSTROUTING -m ndpi --proto bittorrent -j NDPI --value 0X10005 --set-clsf --ret
UPD2. Обновлено. Цитата Vel
Хэш включается командой modprobe xt_ndpi bt_hash_size= bt_hash_timeout= подставив нужные значения для bt_hash_size и bt_hash_timeout (Естественно если модуль уже был загружен до этого, то его надо выгрузить).
Большие изменения в BT: добавлен парсер сообщений (dht) и хеш для хранения ip:port получаемых парсером
По-умолчанию хеш отключен! Чтобы его включить нужно указать его размер 1-32 (параметр bt_hash_size). Число элементо хеша будет равно N*1024.
Кроме это можно указать время хранения данных в хеше 900-3600 секунд (параметр bt_hash_timeout)
Число хранимых элементов в хеше и другую информацию о хеше можно посмотреть в /proc/net/xt_ndpi/info
При тестировании на сети /24 с 300Мбитным трафиком число элементов было 0.8-1.2 миллиона элементов!
Каждый элемент - 24 байта!
P.S. Уважаемые копипастеры. Будьте добры указывать первоисточники. Хотя бы ссылку на тему https://www.linux.org.ru/forum/general/9685281
Подписаться на:
Сообщения (Atom)