По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Да – да, CUCM умеет собирать CDR (Call Detail Record). А в статье мы покажем, как включить данный функционал, который по умолчанию, отключен.
Включение CDR
Подключаемся к интерфейсу Cisco Unified CM Administration:
Переходим по пути System → Service Parameters и выбираем следующее:
Server - 192.168.1.1 (Active), например. Тут мы выбираем ноду, на которой проведем работы. У вас, конечно, IP будет другой. А может и такой же :)
Service - отметьте сервис Cisco CallManager (Active);
Листаем на появившейся страницу параметры и находим сегмент System, в котором отмечаем вот что:
CDR Enabled Flag * - True. Этим параметром мы говорим колл – менеджеру, создавать и хранить CDR – записи по каждому звонку, который пройдет через этот UCM;
CDR Log Calls with Zero Duration Flag * - True. Включая этот параметр, мы говорим, чтобы сервер сохранял звонки, которые не состоялись, или длительность которых менее 1 секунды (это полезно для траблшутинга);
Не забывайте сохранить изменения. Повторите данные процедуры для каждой ноды в кластере (если на этапе выбора в сегменте System → Service Parameters → Server у вас больше одного сервера).
Дополнительная настройка
После этого, давайте познакомимся с дополнительными параметрами. Для этого, в меню настройки нажмите на кнопку Advanced:
Выставьте следующие параметры:
Call Diagnostics Enabled - Enabled Only When CDR Enabled Flag is True. Параметр отвечает за включение так называемых Call Management Records (CMR), которые очень полезны при диагностике проблем и траблшутинге;
Display FAC in CDR - True. Отображать ли Forced Authorization Code (FAC) в CDR записях. То есть, отображаться ли код доступа в CDR – записях. В целом, данный параметр зависит от ваших политик безопасности. Мы отображаем :);
Show Line Group Member DN in finalCalledPartyNumber CDR Field - True. Если коротко – параметр в таком положении, будет показывать DN (directory number) человека, который ответил на звонок внутри группы, а не номер самой группы;
Show Line Group Member Non Masked DN in finalCalledPartyNumber CDR Field: Required Field - по факту, почти тоже самое, что и выше;
Переходим в интерфейс Cisco Unified Serviceability, переходим в раздел Tools → CDR Analysis and Reporting. Далее, во вкладке CDR можете воспользоваться поиском или выгрузкой данных. Enjoy :)
В этой статье рассмотрим как решить следующие неисправности:
Виртуальная машина не может подключиться к сети
Нет связи между сетью и одной виртуальной машиной
Невозможно подключиться к сети Интернет
Сбой подключения к или от одной виртуальной машины через TCP/IP
Вы видите одну или более из ошибок:
Destination Host Unreachable
Network error: Connection Refused
Network cable is unplugged
Ping request could not find host (IP address/hostname). Please check the name and try again
Unable to resolve target system name (IP address/hostname).
Решение
Убедитесь, что каждый из последующих шагов подходит для вашей среды. Шаги включают в себя инструкции для выполнения и ссылки на документы для подтверждения шагов и дополнительных корректирующих мер, если они потребуются. Шаги выстроены в наиболее подходящем порядке для выявления и решения проблем. Не пропускайте шаги.
Проверьте, что имя или имена Port Group, связанные с сетевыми адаптерам(и) виртуальной машины, существует и задано правильно. Если нет, то исправьте это с помощью Edit Settings на виртуальной машине, проверьте есть ли галочка напротив Connected.
Удостоверьтесь в отсутствии проблем с хранилищем или ресурсами, так как это может вызывать неполадки с сетью на виртуальной машине. Это можно проверить на консоли виртуальной машины в ESX/ESXi or Virtual Center/vCenter Server через VI/vSphere Client.
Убедитесь, что виртуальный сетевой адаптер присутствует и подключён.
Проверьте правильно ли настроена сеть в гостевой системе на виртуальной машине.
Проверьте правильно ли работает стек TCP/IP.
Если данная виртуальная машина была создана из физической системы, то следует убедиться в отсутствии скрытых сетевых адаптеров.
Убедитесь, что vSwitch на достаточно портов для виртуальной машины.
Убедитесь, что конфигурация IPSec виртуальной машины выполнена правильно и не повреждена.
Наличие двух виртуальных сетевых интерфейсных карт (vNIC) на виртуальной машине поможет исключить проблемы с сетевой интерфейсной картой (NIC) и физической конфигурацией. Чтобы найти возможную проблему:
Если политика балансировки загрузки в режиме Default Virtual Port ID на уровне vSwitch и vDS - оставьте одну виртуальную сетевую интерфейсную карту (vNIC) подключённой к vSwitch или vDS и протестируйте различные комбинации виртуальных(vNIC) и физических (pNIC) сетевых интерфейсных карт, чтобы найти виртуальную машину с отсутствующим соединением.
Если политика балансировки загрузки в режиме IP Hash:
Убедитесь, что порты физического коммутатора настроены как порт-канал.
Прты, к которым подключены сетевые интерфейсные карты (NICs), кроме одного и переключайтесь между всеми портами, включая за раз только один порт. Обратите внимание на комбинации портов и сетевых интерфейсных карт (NIC) при которых виртуальные машины теряют соединение.
Также вы можете проверить выходные данные о работе сети с помощью команды esxtop с параметром n, чтобы найти используемую виртуальной машиной физическую сетевую интерфейсную карту (pNIC). Попробуйте отключать порты физического свитча по одному, чтобы определить, когда виртуальная машина теряет подключение к сети. Это также исключает неправильные настройки физического порта(-ов).
В сегодняшней статье поговорим о том, как защитить IP-АТС от несанкционированного доступа и дадим несколько простых советов, следуя которым, можно существенно повысить безопасность вашей телефонной станции. Примеры, которые будут приведены в данной статье, относятся к IP-АТС на базе Asterisk, однако многие из них распространяются на все без исключения VoIP-АТС.
Для начала, давайте разберёмся, чем же грозят “дыры” в безопасности и какие последствия грозят бизнесу, если злоумышленник получит доступ к IP-АТС.
Угроза взлома
В отличие от взлома персонального компьютера или почты, взлом АТС – это бесплатные для взломщика звонки, за которые придется заплатить владельцу АТС. Известно немало случаев, когда хакеры тратили колоссальные суммы, проведя на взломанной АТС всего несколько часов.
Как правило, целями злоумышленников становятся IP-АТС, которые доступны из публичной сети. Используя различные SIP-сканнеры и исследуя системные уязвимости, они выбирают места для атаки. Дефолтные (default) пароли, открытые SIP-порты, неправильно управляемый firewall или его отсутствие - всё это может стать причиной несанкционированного доступа.
К счастью, все эти уязвимости можно устранить и причём совершенно бесплатно.
Простые шаги к повышению безопасности
Первое правило, которое необходимо соблюдать – это не афишировать адрес своей IP-АТС и следить за тем, чтобы доступ к сети имели только авторизованные пользователи. Разумеется, это правило распространяется и на физический доступ к серверу, на котором установлена IP-АТС.
Второе и самое очевидное – не использовать дефолтные (default) пароли, которые будет легко подобрать или угадать – “1234”, “admin”, “password”, название компании и так далее.
Одной из самых распространённых ошибок, является создание внутренних номеров (Extension), у которых и номер и пароль совпадают. В sip.conf это выглядит примерно так:
sip.conf
[101]
username=101
secret=101
host=dynamic
Допускать такого, категорически нельзя. Тем более что при создании внутреннего номера через интерфейс FreePBX 13, автоматически генерируется 32-значный надёжный пароль.
При настройке внутренних номеров также следует ограничивать IP-адреса, которые могут быть на них зарегистрированы вплоть до пула адресов локальной подсети. IP-АТС Asterisk имеет встроенные ACL (Access Control List), в настройке sip.conf. При помощи команд permit/deny можно разрешить лишь опредёленное количество IP-адресов для регистрации.
Другой важной мерой по усилению безопасности, является ограничение удалённого доступа к IP-АТС при помощи firewall. Будьте внимательны, так как в данном случае, главное грамотно настроить правила, по которым будет отрабатывать firewall. Убедитесь, что настройка не блокирует порты, которые использует ваша IP-АТС и не позволяет анонимно посылать ICMP запросы из публичной сети. Если вы планируете предоставлять удалённый доступ для авторизованных сотрудников, лучше всего организовать его при помощи VPN сервера (например, Open VPN).
Если это возможно, то желательно использовать NAT (Network Address Translation). При помощи NAT’а, можно присвоить IP-АТС приватный IP-адрес и существенно усложнить доступ к ней из Интернета.
Ещё одним очень важным фактором, является разделение входящих и исходящих маршрутов (Inbound Routes и Outbound Routes). Необходимо, чтобы каждый маршрут принадлежал собственному контексту обработки вызова.
Отключите каналы и сервисы, которые не используются. Например, если вы не используете протокол MGCP или skinny. Отключить эти модули можно в /etc/modules.conf как показано ниже:
noload => chan_mgcp.so
noload => chan_skinny.so
noload => chan_oss.so
Чтобы усложнить работу всевозможным SIP-сканнерам, необходимо в настройках sip.conf выставить следующее условие - alwaysauthreject=yes. Это будет препятствовать получению информации об использующихся внутренних номерах на вашей IP-АТС.
Рекомендуем создавать отдельные маршруты на звонки за рубеж (по сути, международное направление 810). Ставьте ограничения на звонки в таких маршрутах или закрывайте их PIN – кодом, который могут знать только сотрудники вашей организации.
Как видите, защитить IP-АТС от внешних вторжений не так уж трудно, следуя предложенным советам, можно достаточно серьёзно повысить безопасность и надёжность системы.