По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В том случае, если на вашем предприятии организован мощный отдел продаж и ежедневно вы обрабатываете большое количество вызовов, то база данных, в которую складываются записи CDR (Call Detail Record) начинается переполняться и наращивать объем. Со временем, это может негативно сказаться на производительности сервера, приводя к замедлению обработки процессов резервного копирования и обновления системы.
Если вы не хотите удалять старые записи в базе данных, то элегантным решением данной проблемы будет перемещение базы данных для CDR на отдельный сервер. О том, как это осуществить мы расскажем в этой статье.
Рабочие условия
Предположим, что в нашем корпоративном контуре имеются следующие виртуальные машины:
192.168.1.2 - сервер IP – АТС Asterisk с графической оболочкой FreePBX;
192.168.1.3 - сервер, на котором развернута база данных MySQL;
Поддерживаемые типы баз данных это MySQL (MariaDB) и PostgreSQL;
Предварительно, настройте разрешения на подключения с IP – адреса АТС (файл pg_hba.conf в PostgreSQL и командно через консоль в случае MySQL) и создайте пользователя freepbxuser. Произведем тест на связность. Дадим команду с консоли сервера Asterisk:
mysql --host=192.168.1.3 -ufreepbxuser -p asteriskcdrdb
Введите пароль для подключения. Если все ОК, переходим к настройке FreePBX.
Настройка FreePBX
Переходим в раздел Settings → Advanced Settings. Убеждаемся, что параметры Display Readonly Settings и Override Readonly Settings установлены в значение Yes.
Remote CDR DB Host - IP – адрес хоста, на котором развернута база данных. В нашем примере это 192.168.1.3;
Remote CDR DB Name - имя базы данных. Укажите здесь asteriskcdrdb;
Remote CDR DB Password - пароль для подключения к MySQL от пользователя freepbxuser;
Remote CDR DB Port - порт, на котором база данных на удаленном хосте слушает запросы;
Remote CDR DB Table - таблица, внутри БД, с которой мы будет работать. Указываем здесь cdr;
Remote CDR DB Type - тип базы данных. Мы указываем MySQL;
Remote CDR DB User - имя пользователя, под которым мы производим подключение;
Более подробно почитать про базу данных asteriskcdrdb вы можете почитать в этой статье;
Сохраняем изменения и переходим в консоль сервер АТС. Останавливаем FreePBX:
fwconsole stop
Редактируем файл odbc.ini. Там, в параметре server, нам необходимо указать IP – адрес хоста, на котором у нас развернута внешняя БД:
vim /etc/odbc.ini
[MySQL-asteriskcdrdb]
Description=MySQL connection to 'asteriskcdrdb' database
driver=MySQL
server=192.168.1.3 //замену производим вот тут
database=asteriskcdrdb
Port=3306
Socket=/var/lib/mysql/mysql.sock
option=3
Charset=utf8
Сохраняем изменения в файле и запускаем FreePBX:
fwconsole start
Теперь остается только проверить функционал. Сделайте пару тестовых звонков и проверьте их наличие в БД на удаленном хосте.
Безопасность транспортного уровня (TLS), также известная как Secure Socket Layer (SSL), является протоколом безопасного транспортного уровня, развернутым по умолчанию в большинстве веб-браузеров. Когда пользователи видят маленький зеленый замок, указывающую на то, что веб-сайт "безопасен", это означает, что SSL-сертификат действителен, а трафик между хостом (на котором работает браузер) и сервером (на котором работает веб-сервер) шифруется. TLS-это сложный протокол с большим количеством различных опций; в этом разделе будет представлен приблизительный обзор его работы. На рисунке 3 показаны компоненты пакета TLS.
На рисунке 3:
Протокол рукопожатия отвечает за инициализацию сеансов и настройку параметров сеанса, включая начальный обмен закрытыми ключами.
Протокол предупреждений отвечает за обработку ошибок.
Изменение спецификации шифра отвечает за запуск шифрования.
Протокол записи разбивает блоки данных, представленные для транспортировки, на фрагменты, (необязательно) сжимает данные, добавляет Message Authentication Code (MAC), шифрует данные с помощью симметричного ключа, добавляет исходную информацию в блок, а затем отправляет блок в Transmission Control Protocol (TCP) для транспортировки по сети.
Приложения, работающие поверх TLS, используют специальный номер порта для доступа к службе через TLS. Например, веб-службы, использующие протокол передачи гипертекста (HTTP), обычно доступны через TCP-порт 80. Протокол HTTP с шифрованием TLS обычно доступен через порт 443. Хотя служба остается той же, изменение номера порта позволяет процессу TCP направлять трафик, который должен быть незашифрован, чтобы конечное приложение могло его прочитать.
MAC, который в этом контексте будет означать код аутентификации сообщения, используется для обеспечения аутентификации отправителя. В то время как некоторые криптографические системы предполагают, что успешное шифрование данных с помощью ключа, известного получателю, доказывает, что отправитель действительно тот, за кого он себя выдает, TLS этого не делает.
Вместо этого TLS включает MAC, который проверяет отправителя отдельно от ключей, используемых для шифрования сообщений в сети. Это помогает предотвратить атаки MitM на потоки данных, зашифрованные с помощью TLS.
На рисунке 4 показано рукопожатие запуска TLS, которое управляется протоколом рукопожатия.
На рисунке 4:
Приветствие клиента отправляется в виде открытого текста и содержит информацию о версии TLS, которую использует клиент, 32 случайных октета (nonce), идентификатор сеанса (который позволяет восстановить или восстановить предыдущий сеанс), список алгоритмов шифрования (наборов шифров), поддерживаемых клиентом, и список алгоритмов сжатия данных, поддерживаемых клиентом.
Приветствие сервера также отправляется в виде открытого текста и содержит ту же информацию, что и выше, с точки зрения сервера. В приветственном сообщении сервера поле алгоритма шифрования указывает тип шифрования, который будет использоваться для этого сеанса. Обычно это "лучший" алгоритм шифрования, доступный как на клиенте, так и на сервере (хотя он не всегда "лучший").
Сервер отправляет свой открытый ключ (сертификат) вместе с nonce, который клиент отправил на сервер, где nonce теперь шифруется с помощью закрытого ключа сервера.
Сообщение сервера hello done (принятие приветствия) указывает, что теперь у клиента есть информация, необходимая для завершения настройки сеанса.
Клиент генерирует закрытый ключ и использует открытый ключ сервера для его шифрования. Это передается в сообщении обмена ключами клиента на сервер.
После того, как это было передано, клиент должен подписать что-то, что известно, как серверу, так и клиенту, чтобы убедиться, что отправитель является правильным устройством. Обычно до этого момента подпись присутствует во всех сообщениях обмена. Как правило, криптографический хеш используется для генерации проверки.
Сообщение об изменении спецификации шифра по существу подтверждает, что сеанс запущен и работает.
Готовое сообщение (завершение) еще раз аутентифицирует все предыдущие сообщения рукопожатия до этого момента.
Затем сервер подтверждает, что сеанс шифрования установлен, отправив сообщение изменения спецификации шифра.
Затем сервер отправляет готовое сообщение, которое аутентифицирует предыдущие сообщения, отправленные в рукопожатии таким же образом, как и выше.
Примечание. Дополнительные шаги в рукопожатии TLS были исключены из этого объяснения для ясности.
После того, как сеанс запущен, приложения могут отправлять информацию принимающему хосту по правильному номеру порта. Эти данные будут зашифрованы с использованием предварительно согласованного закрытого ключа и затем переданы TCP для доставки.
Привет! Для удобства, мы структурировали все материалы по графическому интерфейсу FreePBX в нашей базе знаний в единый файл. Само собой, нами был выбран многофункциональный формат для хранения и распространения электронных публикаций - PDF. Получившееся руководство администратора FreePBX можно получить по ссылке ниже:
Скачать