Иванов Денис

Благодарю! Подскажите пожалуйста, возможно ли удалённо считывать с данного устройства журнал входящих/исходящих вызовов, с их длительностью и временем ожидания? Также интересует, где его можно приобрести.

Прошу помощи в выборе достойной замены VoIP GSM шлюза Allvoip AV3103. У нас имеется пара шлюзов AV3103 связанных с Asterisk. В принципе всё устраивает, но то ли из-за круглосуточного режима работы, то ли из-за сглаза :) шлюзы периодически зависают, а то и вовсе выходят из строя превращаясь в бесполезные мигающие коробочки. Надоело их перезагружать и менять, поэтому хотелось бы приобрести более надёжный аналог, и желательно с возможностью подключения выносной антенны. Заранее спасибо! :)

Фантастика... Сработало следующее Bypass правило: transport type: UDP, arrive from either side, subscriber-side IP: any, network-side IP: any, subscriber-side port: 5060-5061, network-side port: 5060-5061 Что странно, т.к. до этого пробовал добавить Bypass правило для любого трафика подписчика-телефониста: transport type: any, arrive from either side, subscriber-side IP: IP подписчика, network-side IP: any, subscriber-side port: any, network-side port: any и оно не работало. В результате добился того, что SCE тупо пропускает SIP пакеты. Хоть что-то...

Т.к. не помогает даже добавление Bypass правил для подписчиков-телефонистов в Service Configuration Editor -> Policies -> Filtered Traffic, решил попробовать еще что нибудь: В Service Configuration Editor -> Classification -> Configuration -> Classification -> Zones добавил зону SIP Servers, в которую добавил несколько IP наших SIP серверов. В Service Configuration Editor -> Classification добавил службу SIP Servers (протокол - любой, инициирующая сторона - любая, зона - SIP Servers, flavor - любой). И в каждом Package добавил правило c действием Control the flow's characteristics для службы SIP Servers. В результате телефоны больше не отключаются. Но как понимаете, доступны только перечисленные в зоне SIP сервера. :(

Попробовал "поиграться" с определениями протокола SIP в Subscriber Configuration Editor -> Classification -> Configuration -> Classification -> Protocols -> SIP В Protocol Elements попробовал убрать сигнатуру SIP, оставив сигнатуры Generic - не помогло. Затем наоборот: убрал Generic, оставил SIP - не помогло. И наконец вообще удалил протокол SIP - не помогло.

Так и не разобрался, почему после блокировки и разблокировки подписчика, у последнего не хочет работать SIP телефония. Поэтому создал отдельную тему - http://forum.nag.ru/forum/index.php?showtopic=82567

Cisco SCE 2020 против SIP телефонов Имеется Cisco SCE 2020 3.8.0-classic Build 127 в режиме full functionality, через который подключена сеть из нескольких ПК и аппаратных SIP телефонов. (inline topology) Для каждого ПК и телефона в SCE добавлены подписчики. Всё работает, но если любому из подписчиков сменить package на тот, в котором установлено действие block the flow для default rule, а затем сменить package на тот, в котором нет никаких ограничений (например default package), то SCE не пропускает UDP пакеты от подписчика с портом назначения 5060 (SIP), но при этом пропускает все остальные. (в т.ч. UDP) Это видно в WireShark, которым я собирал трафик до и после SCE. В результате, если подписчик является телефоном, то он больше не работает. А если подписчик является ПК, то всё что касается сети работает, кроме программных телефонов. (twinkle например) Даже спустя сутки SCE продолжает блокировать SIP пакеты от упомянутых выше подписчиков. Однако, если с ПК попинговать АТС, то через некоторое время SCE перестаёт блокировать SIP пакеты от этого ПК. Также, сли в ethernet розетку аппартного телефона подключить ноутбук и с него попинговать АТС, то и этот телефон через некоторое время начинает работать. Если выключить и включить интерфейс LineCard 0, то SCE перестаёт блокировать SIP пакеты от проблемных подписчиков. SCE2000(config if)#>shutdown SCE2000(config if)#>no shutdown Даже если в Service Configuration Editor -> Policies -> Filtered Traffic добавить Bypass правило для любых пакетов проблемного подписчика в обе стороны, то как и задумано SCE пропускает любые пакеты этого подписчика, но всёравно блокирует его SIP пакеты. От отчаяния начал пробовать всё, что по моему может быть связано с работой SIP пакетов: В Service Configuration Editor -> Policies -> Service Security выключил All atack filter, Anomaly detection, Spam detection and mitigation - не помогло. Попробовал убрать SIP порты 5060 и 5061 из Service Configuration Editor -> Classification -> Configuartion -> Policies -> System Settings -> Advanced Options -> CLassification -> UDP ports for which flow should be opened on first packet Не помогло. Отключил flow filter SCE2000(config if)#>no flow-filter partition all Не помогло. Переключил Flow Open Mode c Enhanced на Classical SCE2000(config if)#>shutdown SCE2000(config if)#>flow-open-mode classical SCE2000(config if)#>no shutdown Не помогло. Активировал Subscriber Operation Log Messages (config)#> management-agent sce-api logging Воспроизвёл "смерть" телефона и посмотрел все логи SCE2000#>more user-log Ничего криминального по IP телефона, его подписчику, SIP, 5060 и UDP SCE2000#>more line-attack-log Никаких записей после того как отключил All atack filter, Anomaly detection, Spam detection and mitigation (cм. ывше) SCE2000#>logger get debug-log file-name debug.log SCE2000#>more debug.log Ничего криминального по IP телефона, его подписчику, SIP, 5060 и UDP Удалил все упоминания о VoIp из Service Configuration Editor -> Policies -> Global Policies и всех Package - не помогло. Текущий конфиг:

Воспроизвёл - телефоны отключились. Убрал SCE - телефоны тут же заработали. :(

Решил поэкспериментировать на офисной сети... Попробовал сделать: Сработало как должно, но произошла парадоксальная ситуация: Аппаратные SIP телефоны, которые "попали" в Unknown Subscriber Package, как и нужно было отключились, но после того как убрал Block the Flow из Unknown Subscriber Package, аппаратные телефоны не подключаются к АТС (Asterisk), но программные (Twinkle и т.п.) работают. Перезагрузка телефона не помогает, а когда телефоны пытаются подключиться к АТС, на ней не видно пакетов от телефонов. Если отключить телефон из RJ45 розетки, и подключить в неё ПК с IP адресом телефона, то АТС пингуется, и на ней видно пакеты. Как бы смешно не звучало, но после такой нехитрой процедуры (подключение ПК вместо телефона и пингование АТС), если вернуть телефон на место, то он начинает работать. :) Я один такой везучий? :) Я не уверен что дело в SCE, поэтому позже еще раз воспроизведу ситуацию, и после того как отключатся телефоны, уберу из схемы SCE и посмотрю заработают ли они.

shicoy, snark, благодарю! :)

Стоит задача: 1. Ограничить доступ к управляющим (managment) интерфейсам. 2. Полностью блокировать неизвестных подписчиков, при этом не блокировать некоторый транзитный трафик: DNS, OSPF, RIP, наши сети и сервера. 3. В любом случае (даже, если отключим блокировку неизвестных подписчиков) блокировать некоторый транзитный трафик: SMB/NETBIOS, нежелательные сети и сервера. Думаю решать следующим образом: 1. Настроить ACL, чтобы ограничить доступ к управляющим интерфейсам. 2. В Unknown Subscriber Package выбрать действие Block the Flow для Default Rule, а в Filtered Traffic добавить Bypass правила для DNS, OSPF, RIP, наших сетей и серверов. 3. В Classification создать новую службу NETBIOS c протоколами netbios-dgm, netbios-ns и netbios-ssn (предварительно удалив их из Naming Services), и в каждом pakage добавить действие Block the Flow для NETBIOS. Вопрос к бывалым: правильный ли путь я выбрал, или имеются более рациональные? Какие могут быть подводные камни?

flow, благодарю! Надеюсь, еще кто-нибудь поделится своими методами "включения/выключения Интернета" subscriber'ам. :)

Тоже интересно, т.к. в данный момент решаем как "включать/выключать Интернет" subscriber'у. На ум пришло два способа: 1) Блокировать неизвестных subscriber'ов. В Unknown Subscriber Package выбрать действие Block the Flow для Default Rule. При "включении Интернета" добавлять subscriber'a (login), а при "выключении" удалять subscriber'а (logout). 2) Создать Offline Package, и для его Default Rule выбрать действие Block the Flow. При "включении Интернета" устанавливать subscriber'у его package, а при "выключении" устанавливать subscriber'у Offline Package. Коллеги, пожалуйста подскажите, какой способ используете Вы. P.S.> У нас 3.8.0

Рад, что разобрались. :) rzs.sql - это самый обычный дамп заполненной БД (т.е. сценарий уже с ней работал), который был сформирован следующим образом mysqldump rzs > rzs.sql

Andrei, завтра загружу архив прикреплённый к моему выше опубликованному сообщению и попробовать запустить сценарий. Возможно я где-то допустил ошибку, когда собирал архив. ;)

Andrei, получается ли вручную получить описание сервиса? wget http://www.zapret-info.gov.ru/services/OperatorRequest/?wsdl -O rzs.wsdl

В rzs.sql пришлось в начало добавить create database rzs; use rzs; Иначе get.php ругался, что нет такой базы. Хотя назначение этого файла непонятно, ведь в нем дальше идет INSERT INTO `sites` и перечисление кучи url-ов. Что это и зачем? Я рассчитывал, что люди немного почитают этот простой и достаточно подробно прокомментированный код, и сами догадаются внести в него необходимые правки и создать БД: mysql -e 'create database rzs' mysql rzs < rzs.sql Необходимо произвести правки в некоторых строках get.php $writable_dir = '/tmp'; // директория доступная для записи $openssl = "/opt/openssl-1.0.0e/bin/openssl"; // команда вызова openssl // данные оператора: // наименование в кодировке cp1251 $operator = iconv ('utf-8', 'cp1251', 'ООО "Какойтотелеком"'); $inn = 0000000000; // ИНН $ogrn = 0000000000000; // ОГРН $mail = 'some@mail.org'; // e-mail Существует ли директория $writable_dir? Доступна ли она для записи? Проверьте путь к openssl. Ваш openssl поддерживает pkcs11-gost? Пытались ли Вы получить РЗС вручную? Как Вы это делали? Такая ошибка возникает когда нет связи с веб-сервисом РЗС, или он отключен/перегружен.

Благодарю! :)

Коллеги, может кто интересовался/сталкивался и поможет разъяснить некоторые моменты. :) Например, я увеличиваю значения параметров nf_conntrack CONNTRACK_MAX и HASHSIZE echo 14588928 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max echo 14588928 > /sys/module/nf_conntrack/parameters/hashsize Правильно ли я понял, что в таком случае под хеш-таблицу и записи CONNTRACK должно быть выделено от 2.7 до 5.0 ГБ памяти? Методика расчёта: http://wiki.khnet.info/index.php/Conntrack_tuning 14588928 * 352 + 14588928 * 2 * 8 = 5368725504 (5.0 ГБ) 14588928 * 192 + 14588928 * 2 * 8 = 3034497024 (2.7 ГБ) (размер указателя для x86_64 равен 8 байтам) Правильно ли я понял, что хеш-таблица CONNTRACK - это статическая структура фиксированного размера, поэтому после существенного увеличения HASHSIZE, сразу же должен существенно уменьшится объём свободной памяти?

Как и обещал: PHP сценарий выгрузки РЗС (реестра запрещённых сайтов) в базу данных rzs-get.tar.gz

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

Я добился нормального решения. Описываю как: ... Респект и уважуха! :) Когда обратился по данному вопросу в техническую поддержку КриптоПро, то эти добрые ребята ответили что не понимают о чём я.

Нужно собрать сообщения ядра в момент падения, тогда может быть хоть что-то будет понятно. Можно сфотографировать экран, но данных на нём может быть недостаточно. :) Более разумное решение: http://www.cyberciti.biz/tips/linux-netconsole-log-management-tutorial.html

Должно хватать. :) Была возможность взять для экспериментов целый свободный сервер на Core i7 975 3.33GHz + 3GB RAM + SSD. Как уже писал выше, установил на этот сервер Ubuntu и VLC 2. Так что все свободные ресурсы в распоряжении одного экземпляра VLC.

+1