Перейти к содержимому
Калькуляторы

DPI СКАТ поделитесь опытом

с другой сервер Linux.

 

:) тогда я бы проверил физику

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

Поделиться сообщением


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

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

Новая версия. А воз и ныне там. Как портил rpm post-install script /etc/yum.conf, так и продолжает портить.

 

Дмитрий, обещанного исправления инсталятора ждать столько-же, как и IPv6? (Его жду уже третий год.)

Теперь не портит, однако фикс кривой яки турецкая сабля:

 

/bin/grep -q '^exclude=' /etc/yum.conf || /bin/sed -i -e '$a\' -e 'exclude=kernel\*' /etc/yum.conf

 

Т.е., наличие ЛЮБОГО эксклуда рассматривается как отсутствие необходимости добавлять эксклуд ядра. :-)

 

Тогда-уж лучше так:

/bin/grep -q '^exclude=.*kernel' /etc/yum.conf || /bin/sed -i -e '$a\' -e 'exclude=kernel\*' /etc/yum.conf

Поделиться сообщением


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

Вопросы по времени. Как быстро Скат при рестарте получит из облака список ? Как быстро применяются правила из облачного списка при нормальной работе ? Не загрузка правил, а именно применение нового списка.

Поделиться сообщением


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

Как быстро Скат при рестарте получит из облака список ?

Зачем из облака? Они-же были уже скачаны до рестарта.

# ls -l /var/lib/dpi

Как быстро применяются правила из облачного списка при нормальной работе ? Не загрузка правил, а именно применение нового списка.

Судя по сегодняшнему отчету ревизора, полное время рестарта у меня ~8 секунд, что совпадает с журналами на самом СКАТе.

~3 секунды - стоп, ~3 секунды - старт и инициализация, ~2 секунды - загрузка фильтров.

Журналы смотреть тут: /var/log/dpi

Поделиться сообщением


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

Судя по сегодняшнему отчету ревизора, полное время рестарта у меня ~8 секунд, что совпадает с журналами на самом СКАТе.

~3 секунды - стоп, ~3 секунды - старт и инициализация, ~2 секунды - загрузка фильтров.

А вот это любопытно.

Дмитрий, вы можете уточнить схему и время обновления списков?

У меня на этой неделе в отчетах зафиксировано два пропуска, примерно в 5-6 секундном интервале.

Рестарт СКАТ в 8 секунд это хорошо объясняет.

Поделиться сообщением


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

Зачем из облака? Они-же были уже скачаны до рестарта.

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

Поделиться сообщением


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

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

Есть подозрение, что оно == 0, если все по-уму сделали:

 

1) Создаем новую область данных с обновленными списками

2) Просим writelock

3) При доступности меняем указатель активной на новую

4) Старую высвобождаем

Поделиться сообщением


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

Есть подозрение, что оно == 0, если все по-уму сделали

 

так и есть :)

Поделиться сообщением


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

Есть подозрение, что оно == 0, если все по-уму сделали

 

так и есть :)

 

Я бы так и написал код. Лишний расход памяти - ерунда при текущем списке запросов.

Поделиться сообщением


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

так и есть

То есть обновления списков применяются мгновенно?

Тогда непонятно, чем объяснить 5-6 секундные пропуски в отчетах Ревизора.

Поделиться сообщением


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

так и есть

То есть обновления списков применяются мгновенно?

Тогда непонятно, чем объяснить 5-6 секундные пропуски в отчетах Ревизора.

 

Пока старые запросы не отработают, это белый лок. Но если сбросить все отработки на время переключения - клиентам не понравится. Ну или Эльбрус ставить в качестве проца и ОС, и он не справится...

Поделиться сообщением


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

Лицензия СКАТ - ENTRY

Настроена только блокировка по спискам.

Списки берет из облака.

 

В логах:

 

 

Cluster #1 : IF dna4:

Absolute Stats Rcvd: [1293843 pkts][347097217 bytes][0 pkts dropped]

Send: [1368342 pkts][555249439 bytes]

Esnd: [0 err_pkts][0.00 %]

Drop: [138588 pkts][25910621 bytes]

Pthr: [0 pkts][0 bytes]

Emit: [95298 pkts][15788214 bytes]

Eemt: [0 err_pkts][0.00 %]

Actual Stats Rcvd: [642661 bytes][0.34 Mbit/sec]

[5018 pkts ][334.53 pkt/sec]

Send: [3187080 bytes][1.70 Mbit/sec]

[4973 pkts ][331.53 pkt/sec]

Esnd: [0 err_pkts][0.00 %]

Drop: [196589 bytes][30.59 %]

[1131 pkts ][22.54 %]

Pthr: [0 bytes][0.00 %]

[0 pkts ][0.00 %]

Emit: [131113 bytes][0.07 Mbit/sec]

[758 pkts ][50.53 pkt/sec]

Eemt: [0 err_pkts][0.00 %]

Cluster #1 : IF dna5:

Absolute Stats Rcvd: [1279154 pkts][540009639 bytes][0 pkts dropped]

Send: [1207687 pkts][325276292 bytes]

Esnd: [0 err_pkts][0.00 %]

Drop: [6110 pkts][548414 bytes]

Pthr: [0 pkts][0 bytes]

Emit: [52432 pkts][4089696 bytes]

Eemt: [0 err_pkts][0.00 %]

Actual Stats Rcvd: [3056681 bytes][1.63 Mbit/sec]

[4223 pkts ][281.53 pkt/sec]

Send: [476258 bytes][0.25 Mbit/sec]

[4274 pkts ][284.93 pkt/sec]

Esnd: [0 err_pkts][0.00 %]

Drop: [714 bytes][0.02 %]

[8 pkts ][0.19 %]

Pthr: [0 bytes][0.00 %]

[0 pkts ][0.00 %]

Emit: [30186 bytes][0.02 Mbit/sec]

[387 pkts ][25.80 pkt/sec]

Eemt: [0 err_pkts][0.00 %]

 

 

 

По какой причине/причинам он может дропать пакеты и влияет ли это на общий трафик через СКАТ?

Поделиться сообщением


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

так и есть

То есть обновления списков применяются мгновенно?

Тогда непонятно, чем объяснить 5-6 секундные пропуски в отчетах Ревизора.

байпассом только можно объяснить он у вас есть.

Поделиться сообщением


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

Лицензия СКАТ - ENTRY

Настроена только блокировка по спискам.

Списки берет из облака.

По какой причине/причинам он может дропать пакеты и влияет ли это на общий трафик через СКАТ?

проверьте protocols.dscp м.б. что то осталось от тестового периода.

если там нет ничего, напишите SD и прикрепите архив /etc/dpi/*

Поделиться сообщением


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

байпассом только можно объяснить

Да, байпас есть.

Я правильно понял — при обновлении списков из облака СКАТ несколько секунд не работает и не фильтрует трафик (пускает его через байпас)?

Поделиться сообщением


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

Лицензия СКАТ - ENTRY

Настроена только блокировка по спискам.

Списки берет из облака.

По какой причине/причинам он может дропать пакеты и влияет ли это на общий трафик через СКАТ?

проверьте protocols.dscp м.б. что то осталось от тестового периода.

если там нет ничего, напишите SD и прикрепите архив /etc/dpi/*

 

Нет файла /etc/dpi/protocols.dscp

и тестового периода не было.

Поделиться сообщением


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

Absolute Stats Rcvd: [1293843 pkts][347097217 bytes][0 pkts dropped]

 

на интерфейсах дропов нет, так что переживать не о чем,

а значение Drop в общей статистике - это те пакеты, что dpi сам отбрасывает в

в процессе работы полисинга, блокировки по черным спискам, защиты от DDOS и т.п.

 

 

Я правильно понял — при обновлении списков из облака СКАТ несколько секунд не работает и не фильтрует трафик

 

вчера уже отвечал на этот вопрос: при обновлении и применении списков перерыва в обслуживании нет

 

Естественно при рестарте dpi перерыв есть т.к. при этом ПО некоторое время не работает:

примерно 1,5 секунды занимает останов и 3 секунды старт.

Поделиться сообщением


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

Естественно при рестарте dpi перерыв есть т.к. при этом ПО некоторое время не работает:

примерно 1,5 секунды занимает останов и 3 секунды старт.

Может тогда Ревизор прикручивать к свободному ethernet порту сервака со СКАТОМ? USB есть, пару Ethernet есть. Перед рестартом DPI принудительно класть порт(или нужный vlan) на какое-то время, Ревизор не будет получать никакого трафика...

Поделиться сообщением


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

Да, байпас есть.

Я правильно понял — при обновлении списков из облака СКАТ несколько секунд не работает и не фильтрует трафик (пускает его через байпас)?

не правильно, если СКАТ работает списки обновляются мгновенно.

а вот если СКАТ обновляли на новую версию, то в момент обновления может байпасс повлиять, но если все разумно делается время переключения до 1 с.

Изменено пользователем Bigmazy

Поделиться сообщением


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

а вот если СКАТ обновляли на новую версию

Нет, версию я не обновлял более месяца или двух, а пропуски появились около недели назад.

Поделиться сообщением


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

а вот если СКАТ обновляли на новую версию

Нет, версию я не обновлял более месяца или двух, а пропуски появились около недели назад.

Глюки я бы объяснил кривым реестром.... Версию не обновляю, до официального обновления. Как кстати - на свой реестр переходить, или скатовским облаком далее жить ? Техподдержка оплачена. Свой реестр сдох по причине искончания ресурсов на тазике. Нее, забор есть, а вот парсинг на перле сломался....

Поделиться сообщением


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

И, кстати по времени - этра хрень синхронизуется по ntp с каким-то буржуйским сервером, посему время можно оспорить в суде. Где блин гарантия, что у них наше время и наша таймзона ?

Поделиться сообщением


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

Нет, версию я не обновлял более месяца или двух, а пропуски появились около недели назад.

Ревизор недавно обновился. Не должно конечно влиять, но стало больше обращений в ТП. Ревизор пишет отсутствие блокировки по факту при ручной проверке все норм.

Скрины сайтов от ревизора есть, руками проверяли?

И еще мониторим нескольких операторов, на 05.01 например, только у одного есть пропуск 2х https урлов, которые блочатся по ip+port (версия у него еще стоит 4.6 без новых способов блокировки). В ручную запросы по этим урлам не проходят.

Изменено пользователем Bigmazy

Поделиться сообщением


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

Глюки я бы объяснил кривым реестром.... Версию не обновляю, до официального обновления. Как кстати - на свой реестр переходить, или скатовским облаком далее жить ? Техподдержка оплачена. Свой реестр сдох по причине искончания ресурсов на тазике. Нее, забор есть, а вот парсинг на перле сломался....

В проблемы в РКН реестре, правим, сделано в автоматическом и ручном виде. И естественно если, что обнаружили у одного, то всем это исправление отдаем.

Можете самостоятельно это все делать конечно, если есть время. Некоторые в дополнение свои списки РКН грузят, вместе с облачными, как вариант.

Поделиться сообщением


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

Приветствую,

собственно сабж: кто нить обновлялся до 5.5.1? всё там хорошо? а то я как то обновился, не поинтересовавшись у умных людей,, так пришлось откатываться...

Поделиться сообщением


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.