Телефония asterisk с нуля текстовая инструкция

Предисловие

Существенный прогресс в развитии современных цифровых систем связи с пакетной передачей данных позволяет организовать поверх широкополосного соединения не только доступ к сети Интернет, но и организовать ранее раздельных технологии как одну из услуг связи [1].

Одной из таких услуг, рассматриваемых в рамках работы, является технология VoIP (англ. Voice over IP или IP-телефония) – телефонная связь (передача голоса) по существующим сетям передачи данных, использующим протокол IP. Использование этой технологии предполагает передачу сигнала по каналу связи в цифровом виде с ее предварительным преобразованием, а именно, сжатием для удаления избыточности.

Таким образом, технология IP-телефонии позволяет использовать любую существующую сеть с пакетной коммутацией и поддержкой протокола передачи данных IP в качестве средства организации локальной, или местной, междугородней или международной телефонной связи в режиме реального времени. При этом для передачи данных в последних двух случаях можно применить термин Интернет-телефонии, описывающий частный случай IP-телефонии, когда в роли основного канала передачи телефонного трафика используется широкополосное соединение с глобальной сетью Интернет [2-3].

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

Настоящее учебно-методическое пособие содержит четыре раздела. Первый раздел учебно-методического пособия посвящен начальной конфигурации операционной системы семейства Linux в качестве основы программной АТС. В силу значимых различий с привычными ОС Windows, приведено подробное описание дейсвий, необходимых для корректного запуска ОС CentOS 8 в качестве виртуальной машины, описаны основы работы с консольным текстовым редактором Vi, удаленного подключения к виртуальной машине с использованием протокола SSH, работа с репозиториями CentOS.

Второй раздел охватывает тему поэтапной компиляции программного кода АТС Asterisk. После рассматриваются базовая конфигурация программной АТС, планов обработки вызовов и списков абонентов, протоколов SIP и RTP. Также в разделе приведены методические указания по подключению абонентов к Asterisk, проверки установления соединения.

Третий раздел посвящен конфигурации соединения между двумя и более программными АТС, переносу конфигурации в СУБД. При этом рассмотрены как принципы работы с консольной версией базы данных, так и с использованием стороннего программного обеспечения, предоставляющего возможность взаимодействия с базой данных в графическом режиме. Приведены принципы работы и конфигурации транкового соединения IAX.

Четверный раздел описывает базовые принципы конфигурации защищенного соединения в программных АТС, а именно метод защиты загрузчика ОС Linux, продвинутой конфигурации протокола удаленного доступа SSH, создание и использование ключей шифрования для доступа к программной АТС и подключения абонентов.

Раздел 1. Начальная конфигурация операционной системы CentOS

1.1. Теоретические сведения

Как отмечалось ранее, IP-телефония является технологией, использующей существующую сетевую инфраструктуру с пакетной коммутацией сообщений и для передачи голосовой информации в реальном времени. Основой этой технологии принято считать концепцию передачи голоса по компьютерной сети связи, разработанную Чарли Кляйном в 1993 года в совокупности с программным обеспечением, позволявшим совершить вызов между двумя персональными компьютерами, находившимися в одной локальной сети.

Современное представление об IP-телефонии различается с первыми наработками в этой области, изменения затронули как аппаратную, так и программную составляющии технологии. Так, схема подключения абонентов к телефонной сети общего пользования должна иметь ряд необходимого для совершения звонка оборудования: АТС на стороне телефонного провайдера и телефонного аппарата на стороне абонента, соединенных между собой сетью PSTN (Public Switched Telephone Network – телефонная сеть общего пользования). PSTN, в свою очередь, может быть организована как на базе классической аналоговой медной линии, так и с применением технологий Ethernet, оптоволоконного соединения, ISDN и др.

Указанный подход к построению телефонных сетей ограничивает абонента в использовании телефонии, поскольку зачастую телефонные аппараты являются стационарными, а существующие беспроводные аналоги имеют радиус работы вокруг базовой станции и на практике ограничены периметром жилой площади. IP-телефон же таких ограничений не имеет и может быть использован в любой точке земного шара при наличии активного соединения с глобальной сетью Интернет или, в случае использования локальной IP-телефонии, доступа к компьютерной сети.

При этом сама реализация IP-телефона может быть как программно-аппаратной, когда производитель выпускает устройство в «классическом» корпусе, так и исключительно программной. Как правило, исключительно программные продукты могут иметь свой собственный, частично или полностью отличающийся от классического, стек протоколов. Большинство из них недоступны для изучения, но существуют и полностью открытые протоколы и технологии, на базе которых возможно реализовать системы IP-телефонии.

1.2 Передача голоса по IP-сети

VoIP (Voice over IP – передача голоса по IP-сети) предполагает использование специализированных протоколов поверх существующего стека TCP/IP, но в теоретическом плане возможно рассмотреть взаимодействие протоколов и с уровнями открытой модели взаимодействия OSI. Так, если не установлены дополнительные ограничения, передача голоса начинается на прикладном уровне модели OSI, в этот момент программное обеспечение формирует данные для отправки. Стоит отметить, что в IP-телефонии возможна передача голоса исключительно в оцифрованном виде, это требование накладывается самой сетью с пакетной коммутацией.

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

1.3 Основные речевые кодеки систем IP-телефонии

Наиболее известными кодеками VoIP систем являются G.711 [ITU-T. G.711 : Pulse code modulation (PCM) of voice frequencies] и G.729 [ITU-T. G.729 : Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)], описанные в рекомендациях института ITU-T. Первый из них впервые был представлен в 1972 году и представляет собой стандарт для 8-битного сжатия предварительно оцифрованной речевой информации с использованием частоты дискретизации равной 8 кГц, что соответствует 8000 выборок в секунду. Рассматриваемый кодек формирует поток данных со скоростью 64 Кбит/с, значение получено путем умножение размерности передаваемого слова на количество выборок в секунду. Несмотря на простоту исполнения, и, фактически отсутствие сжатие данных как такового, стандарт достаточно популярен в IP-телефонии и имеет две версии: A-law и U-law.

Версия A-law, или A-закон, представляет собой алгоритм компрессии данных с потерей информации и описывается следующей формулой:

где x – исходные данные, A – параметр сжатия, типичное значение которого составляет 87,7. Такой тип кодека используется на территориях Европейских стран, а также России и стран СНГ.

Вторая вариация кодека также описана алгоритмом компрессии данных с потерей информации, но основана на другой математической базе и может быть описана через:

где u = 255. U-law тип кодека используется в основном на территории Японии и Северной Америки.

Несмотря на свою простоту G.711 имеет значимый недостаток, а именно, требует достаточно большой полосы пропускания. В современных реалиях это может быть незаметно, но при использовании высоконагруженного канала связи с глобальной сетью Интернет, или канала малой пропускной способности, передача голоса может оказывать значительное влияние на производительность сети в целом.

К достоинствам же можно отнести низкую вычислительную сложность, а значит – минимальную нагрузку на микропроцессор телефона. Также стоит отметить возможность свободного доступа к исходным данным стандарта, ввиду того что срок действия его патента уже истек.
G.729 также является широко используемым речевым кодеком, применяемым для цифрового представления телефонной речи с частотой дискретизации 8 кГц. Основное отличие этого кодека заключается в использовании принципа передачи не самого оцифрованного речевого сигнала, а его параметров, включая спектральную характеристику сигнала, количество переходов через ноль, при этом передаваемые данные должны иметь возможность последующего синтезирования исходного сигнала на приемной стороне.

В сравнении с ранее рассмотренным G.711, G,729 имеет повышенную задержку передачи, выраженную в обработке исходного сигнала частями, а именно выборками по 10 мс. Общая же задержка обработки составляет 15 мс, поскольку 5 мс необходимо для предварительного заполнения временного буфера для корректной работы алгоритма. Для сравнения, аналогичный параметр у G.711 равен 0,75 мс.
Безусловно, достоинством этого кодека является требуемая полоса пропускания, а именно, 8 кбит/с, что в 8 раз меньше чем у G.711, но также присутствуют и недостатки: худшее качество связи, высокая зажержка и повышенные требования к вычислительным ресурсам микропроцессора устройства. Несмотря на указанные недостатки, кодек G.729 весьма распространен и поддерживается большинством программных и аппаратных платформ, на данный момент является открытым, поскольку срок действия его патентных лицензия считается истекшим и имеет несколько модификаций, наиболее известными из которых являются Annex A и Annex B.

В первой модификации снижены требования к вычислительным ресурсам, ввиду использования вычислений с фиксированной точкой вместо плавающей, что приводит к незначительному ухудшению качества связи, но значительному в ресурсоемкости алгоритма. Во второй модификации применяется дополнительный модуль VAD (Voice Activity Detection – детектор голосовой активности), за счет использования которого определяются паузы в исходном речевом сигнале и заменяются шумовым сигналом, тем самым битовый поток во время пауз снижается и позволяет передавать исключительно полезный сигнал. При этом передача шума во время пауз не является технической необходимостью, ее функция заключена в устранении дискомфорта у абонента при воспроизведении абсолютной тишины.

Существует несколько подходов к классификации кодеков по используемым параметрам, например, по применяемой математической базе, типу принимаемой информации, вычислительной нагрузки на микропроцессор устройства, обеспечиваемому качеству связи.
С точки зрения телекоммуникаций, наиболее значимым является последний тип классификаций. Так, условно, все кодеки можно разделить на два класса: широкополосные и узкополосные.
Приведенные ранее кодеки G.711 и G.729, включая его ревизии G.729A и G.729B, являются узкополосными. В общем плане принадлежность определенного кодека к классу можно описать используемой частотой дискретизации, как итог, необходимой пропускной способностью для передачи данных после компрессии. К узкополосным кодекам относятся решения с частотой дискретизации менее 16 кГц, а к широкополосным наоборот, типовые значения этого параметра у них от 16 до 32 кГц.

Иногда в литературе можно встретить другое название технологии передачи голоса по IP сети с использованием широкополосного речевого кодека – HDVoIP (High Definition VoIP или VoIP высокого разрешения). При этом основная цель использования таких кодеков это повышение четкости принимаемого речевого сообщения в совокупности с уменьшением суммарной задержки на передачу сигнала. Для конечного пользователя эта разница должна быть заметна также, как при переходе с аналогового телевидения к цифровому повышенного разрешения.

К распространенным широкополосным кодекам можно отнести G.722, Speex и Opus. G.722 [ITU-T. G.722 : 7 kHz audio-coding within 64 kbit/s ] является одним из первых широкополсных кодеков и был разработан в 1989 году, как и ранее рассмотренные аналоги имеет принадлежность к стандарту ITU-T и работает со скоростями передачи 48, 56 и 64 кбит/с. В настоящий момент кодек является устаревшим и на его замену разработаны несколько ревизий: G.722.1, G.722.1 Annex C, G.722.2.

Основным отличием G.722 является применение адаптивной дифференциальной импульсно-кодовой модуляции в алгоритме, позволяющей динамически изменять параметр шага квантования при оцифровке речевого сигнала, что в итоге позволяет снизить требуемую полосу пропускания для передачи данных при заданном отношении сигнал – шум, то есть фактически при фиксированном качестве связи. Несмотря на возможность выбора скорости передачи данных, на практике используется лишь значение 64 кбит/с.

G.722.1 [ITU-T. G.722.1 : Low-complexity coding at 24 and 32 kbit/s for hands-free operation in systems with low frame loss] является более новой версией предыдущего кодека, датируемой 1999 годом. Несмотря на использование более низкой скорости передачи данных, а именно 24 и 32 кбит/с при аналогичной полосе пропускания от 50 Гц до 7 кГц, новая версия кодека позволяет передавать сигнал, по качеству воспроизведения более близкий к радио, чем к телефонии. Указанное свойство достигается за счет использования запатентованной технологии сжатия сигнала “Siren”, разработанной компанией Polycom. Аналогично предыдущему, кодек G.722.1 Annex C также использует схожий алгоритм сжатия, но новой версии под названием “Siren 14”, что позволяет еще больше повысить качество сигнала и приблизить его к качеству воспроизведения CD дисков при использовании скорости передачи данных 24, 32 и 48 кбит/с в совокупности с сверх-широкополосным речевым сигналом в 14 кГц.
G.722.2 [ITU-T. G.722.2 : Wideband coding of speech at around 16 kbit/s using Adaptive Multi-Rate Wideband (AMR-WB)] является наиболее свежим вариантом кодека, разработанным в 2002 году и позволяющим проводить быстрое изменение скорости сжатия исходного речевого сигнала в зависимости от доступной пропускной способности сети передачи данных, при этом в стандарте определяется 9 уровеней, фактически соответствующим скорости передачи от 6,6 до 23,85 кбит/с.

При этом первые три уровня, а именно 6,6 кбит/с, 8,85 кбит/с и 12,65 кбит/с, также используются в GSM и UMTS соединениях, где первые два применяются в случае недостаточного радиосоединения, а третий используется в качестве основного. При этом второй и третий уровни предоставляют возможность передачи широкополосного речевого сигнала с качеством, аналогичным для скоростей передачи 48 и 56 кбит/с в G.722.
Более высокие скорости передачи данных используются как для передачи речевого сигнала между двумя абонентами, так и для организации конференций с множеством участников, при использовании скорости передачи данных равной 23,85 кбит/с, предоставляется качество связи, аналогичное G.722 с использованием 64 кбит/c.
Speex представляет собой свободный кодек с компрессией речевого сигнала, относящийся к классу линейного предсказательного кодирования или CELP (Code Excited Linear Prediction). Указанный тип кодирования используется для аппроксимации части исходного речевого сигнала с применением цифрового фильтра авторегрессионного типа. При этом коэффициенты фильтра подстраиваются под выбранный отрезок сигнала, таким образом, кодек предусматривает наличие кодовой книги с предопределенным набором единичных импульсов.

При использовании Speex, речевой сигнал разбивается на отрезки длительностью 20 мс или 160 отсчетов при частоте дискретизации 8 кГц, но для оценки возбуждающего набора фильтра указанный отрезок дополнительно разбивается на 4 неперекрывающихся подотрезка, на каждом из которых отыскивыются требуемые наборы импульсов из кодовой книги. При этом Speex не использует алгебраические методы кодирования, ограничиваясь исключитально векторными, для избегания патентных ограничений.
Сам кодек оптимизирован для получения высококачественного речевого сигнала при низких скоростях и может быть использован с переменной степенью компрессии исходного сигнала, а также с сигналами различной полосы, а именно 8, 16 и 32 кГц.

Отметим, что после преобразований сигнала с применением указанного кодека, выходные данные могут быть сохранены для дальнейшего использования в формате .ogg, а также переданы другому абоненту с применением стека TCP/IP и протокола RTP. При этом кодек устойчив к потере пакетов, но не их искажениям, и может работать как поверх UDP, так и поверх TCP соединений.

Последним из указанных кодеков является Opus, являющийся решением компрессии речевого сигнала с потерями, разработанным сообществом IETF (Internet Engineering Task Force) в 2012 году специально для применения в системах передачи голоса по IP-сетям в режиме реального времени и описан в стандарте RFC 6716. Сам кодек распространяется с открытой лицензией BSD, а все патентные документы доступны под лицензией royalty-free.
Основным преимуществом рассматриваемого кодека является низкая задержка кодирования, имеющая значение от 2,5 до 60 мс в зависимости от конкретной конфигурации и поддержка многоканального аудио с использованием до 255 отдельных каналов.

Доступные параметры включают в себя изменяемую частоту дискретизации в диапазоне от 8 до 48 кГц, динамическую скорость кодирования данных от 6 до 510 кбит/с, при этом скорость может быть выбрана как постоянная величина, так и переменная.

Использование Opus позволяет получить высокое качество связи, сопоставимое с распространенным форматом аудиофайлов MP3, а также имеет широкое распространение в программном обеспечении для аудио и видеоконференций.
После сжатия речевого сигнала, данные передаются на сеансовый уровень, на котором также имеются несколько вариаций используемых протоколов в зависимости от конкретной реализации системы IP-телефонии, наиболее известными являются рекомендация H.323 и протоколы SIP и SDP.

1.4 Стек протоколов H.323

H.323 представляет собой рекомендации института ITU-T, определяющие набор стандартов и протоколов для проведения аудио и видео конференций через глобальную сеть Интернет в реальном времени. Отдельными стандартами рекомандации определяется, как именно конечный пользователь должен быть подключен к сети Интернет и в основном подключение описано с использованием коммутируемого телефонного соединения или сетью с негарантированной пропускной способностью (Ethernet).

Сама рекомандация H.323 не имеет связи с IP протоколом, хотя практические реализации, изначально, были базированы именно на нем. По своей сути, H.323 описывает целый стек протоколов, но нередко можно встретить его упоминание, как частного случая сигнализации, то есть отдельного протокола сеансового уровня, в системах VoIP.

Стандартом же описано разделение передачи данных на четыре компонента, каждый из которых имеет свои дополнительные рекомендации, определенные институтом ITU-T, а именно:

1. Сигнализация;
2. Управление потоковым видео и аудио;
3. Приложение передачи данных;
4. Коммуникационные интерфейсы.

Для сигнализации используется отдельный протокол согласования H.245, предусматривающий возможность выявления конечного набора функций, доступных двум и более конечным терминалам абонентов телефонной сети, а также управлением работой логических каналов связи между абонентами. Ограничением протокола является устанвление единичного экземпляра канала H.245 в каждом сеансе связи, при этом в рамках рекомендации H.323 возможно открытие отдельных сокетов для установления соединения, где под сокетом понимается классический набор IP-адреса устройства и сетевого порта.

Указанный подход достаточно прост в реализации, но для установления двух и более соединений требует наличия доступного сетевого порта для каждого из них, поскольку реальные сети передачи данных имеют ограничения в использовании адресного пространства, как следствие примение технологии трансляции сетевых адресов, установление соединения может быть затруднено. Для решения указанной проблемы существует возможность дополнительного туннелирования H.245 сессии в рамках H.255 сессии, что позволяет поддерживать несколько соединений на одном и том же сетевом сокете.

Основными сообщениями протокола являются TCS и TCSA, представляющие собой запрос и подтверждение набора функций отдельного терминала.

После инициации логического соединения между терминалами А и Б, терминал А отправляет сообщение формата TCS, с отмеченными поддерживаемыми функциями в направлении терминала Б. Терминал Б, при соответсвии функций, отправляет в ответ подтверждение формата TCSA, после чего зеркальная операция производится с терминала Б. При соответсвии наборов функций на обоих терминалах, терминал А отправляет сообщение формата OLC (Open Locical Channel – открытие логического канала) и ожидает в ответ от терминала Б сообщение OLCA, являющееся подтверждением готовности открытия логического канала, после чего процедура зеркально повторяется с терминала Б.

Аналогично открытию канала происходит и разрыв соединения с использованием сообщения формата CLC (Close Locical Channel – закрытие логического канала), в ответ на которое терминал также ожидает подтверждения сообщением CLCA. При этом двусторонняя отправка сообщений при закрытии канала не требуется, достаточно передачи двух сообщений. После чего Абонент А отправляет запрос формата EndSessionCommand или ESC для закрытия сессии и ждет в ответ от абонента Б аналогичный запрос.

Если сессия H.245 открывается внутри сессии H.225, перед отправкой сообщений требуется дополнительная передача сообщений формата H.225.0 Setup с одного из терминалов, после чего указанный терминал ожидает получения сообщений формата H.225.0 Alerting и H.225.0 Connect. При завершении соединения также требуется дополнительная передача сообщений типа H.225.0 ReleaseComplete. Описанный алгоритм представлен на рисунке 1.1.

Рис 1.1. Процесс соединения абонентов с использованием H.323

Помимо описанных протоколов в стеке H.323 также используются рекомендацию Q.931 для установления и контроля за соединением, который условно сопоставим с протоколом TCP, но находится на другом уровне модели OSI, RTP/RTCP для оптимизации доставки потоковой речевой информации, RAS для взаимодействия с устройством привратником.
H.323 описывает несколько типов устройств:

1. терминал;
2. шлюз;
3. привратник;
4. сервер многосторонней конференции.

Каждое из устройств имеет свой набор функций и поддерживаемых протоколов, рассмотрим каждое из них подробнее.

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

Минимальный набор поддерживаемых протоколов, стандартов и рекомендаций для устройства терминала описан следующим списком: H.245, Q.931, RAS, RTP, G.711, H.450, где последний используется для поддержки обязательных для H.323 дополнительных видов обслуживния. На практике набор протоколов может отличаться и иметь дополнительную поддержку речевых и видео кодеков.

Шлюзом называется устройство, позволяющее установить соединение с терминалом, использующим отличный от H.323 стандарт в качестве основного. Таким образом, основная функция шлюза заключается в трансляции сообщений H.323 в другой стек протоколов IP-телефонии или для связи с аналоговыми коммутируемыми телефонными соединениями, при этом само устройство не входит в обязательный набор компонентов системы телефонии H.323.

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

Список услуг устройства привратника можно условно разделить на два типа: основные и дополнительные. К основным услугам отностятся фунции трансляции внутренних адресов и телефонных номеров в сетевые адреса, управления доступом и авторизацией в H.323 сети и управления полосой пропускания.

К дополнительным функциям можно отнести управление процессом установления соединений при использовании двусторонней конференцсвязи, как следствие работу с сообщениями Q.931, их обработку и ретрансляцию, авторизацию входящего соединения, а также управление активными соединениями, как следствие выделением необходимой полосы пропускания, а также переадресацией вызовов на терминалы и шлюзы.

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

Помимо указанной рекомендации H.323, существуют и аналоги для использования с различными типами коммуникационных интерфейсов, от модемных соединений до радиоканала разрабатываемые с 1990 по 1998 года и имеющие нумерацию H.320, H.321, H.322, H.324, H.324/C и H.310.

В настоящий момент времени H.323 не имеет широкого распространения на практике и чаще заменяется на SIP, но обратная совместимость с ним имеется в большинстве оборудования для IP-телефонии.

1.5 Протокол SIP

Упомянутый протокол SIP (Session Initiation Protocol – протокол установления сеанса) является альтернативой H.323 и описывает способ установки и завершения логического канала связи между устройствами системы IP-телефонии. На самом деле, помимо передачи потоковой аудио и видеоинформации, SIP позволяет также передавать мгновенные сообщения или данные приложений.

В отличие от рекомендации H.323, SIP не имеет монолитной архитектуры, за счет чего имеет более гибкую масштабируемость и полностью базирован на протоколах стека TCP/IP, следовательно, требует наличия широкополосного интернет соединения или подключения к локальной сети. SIP описывает каким именно образом приложение должно запрашивать начало соединение у собеседника, а также определяет способ согласования режимов установления логического канала с использованием сторонних протоколов, например, протокола RTP.

Аналогично H.323, а именно протоколам H.245 и H.225, SIP предполагает использование сокетов для установления соединений, но в отличии от первых, имеет стандартизированный порт для осуществления этого функционала. Так, традиционно SIP использует порт 5060 для TCP и UDP соединений отдельных компонентов сети. Основной задачей протокола является регистрация абонентов в сети, установление и завершение вызовов.

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

Помимо указанного сетевого порта, используемого протоколом SIP, для него установлена уникальная схема адресации, в которой указывается идентификатор отдельного абонента и фрагмента, характеризующего отдельное сетевое устройство. При этом пара идентификатор-фрагмент всегда разделена с использованием символа «@», а в качестве идентификатора определен используемый телефонный номер или логин для авторизации конкретного абонента, для фрагмента IP-адрес устройства или его доменное имя.

Реализация протокола SIP имеет четко выраженную клиент-серверную архитектуру, при которой клиент формирует запрос с указанием конкретных данных, которые необходимо запросить с устройства сервера, после чего сервер обрабатывает входящий запрос и направляет ответ, содержащий информацию об успешном выполнении запроса вместе с запрошенной информацией или статус ошибки.

Архитектура сети с использованием SIP предполагает налчия нескольких устройств:

1. терминального оборудования;
2. прокси-сервера;
3. сервера B2BUA;
4. сервера переадресации;
5. сервера регистрации;
6. сервера определения местоположения абонентов.

Терминальное оборудование, аналогично H.323, представляет собой програмнмое обеспечение на персональных компьютерах или программно-аппаратные устройства для передачи мультимедийной информации. Но в отличие от первого, терминалы могут быть двух видов в зависимости от установления соедиения и самого программного обеспечения: пользовательским агентским клиентом или пользовательским агентским сервером, UAC (User Agent Client) и UAS (User Agent Server) соответственно. Отличие заключается в том, что терминалы с ролью UAS могут взаимодействовать непосредственно с абонентами, а такие терминалы называют пользовательским агентом (UA – User Agent), поскольку в них присутствуют и роль UAC и UAS одновременно.

Устройства прокси-сервер выполняют функции приема и обработки запросов в сети с последующим выполнением требуемых действий. Как и терминалы UA, прокси-сервер состоит из клиентской и серверной компонент, соответственно позволяет как принимать входящие вызовы, так и формировать запросы к отдельным устройствам, при этом не изменяя исходного содержимого сообщений, поскольку для такого типа функций определено служебное поле «via» для указания адресной информации прокси-сервера.

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

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

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

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

Взаимодействие с сервером регистрации производится путем отправки сообщений установленного формата от терминального устройства, а именно – сообщения «REGISTER». При этом в зависимости от конфигурации регистратора возможно получение одного из четырех ответов на запрос регистрации:

1. 200 OK;
2. 404 Not Found;
3. 403 Forbidden;
4. 401 Unauthorized.

Сообщение первого типа означает успешную регистрацию, второго – ошибку при проверке учетной записи абонента, а именно отсутствие записи о таком абоненте в БД регистратора, третьего – запрет регистрации абонента, четвертого – запрос идентификатора пользователя.

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

Помимо рассмотренного сообщения типа «REGISTER», SIP поддерживает еще 5 сообщений в классическом наборе:

• INVITE – пришлашение абонента к сеансу связи;
• ACK – ответ на запрос приглашения абонента к сеансу связи;
• BYE – завершение сеанса связи от одного из абонентов;
• CANCEL – отмена обработки переданных запросов;
• OPTIONS – запрос информации о наборе функций сервера.

Стоит отметить, что вместе с сообщением типа «INVITE» обычно передаются данные с информацией о SDP сеансе, а сообщение типа «CANCEL» не отменит обработку уже выполненных запросов.
В процессе модификаций протокола со временем в него были внесены дополнительные типы сообщений, стандартизированные в RFC 3252, RFC 3265, RFC 3903, RFC 2976, RFC 3515, RFC 3428 и RFC 3311 поверх первоначальной версии RFC 3261:

• PRACK – временное подтверждение;
• SUBSCRIBE – сообщение об инициализации подписки на уведомления;
• NOTIFY – уведомление подписчика;
• PUBLISH – публикация информации о событии на сервере;
• INFO – передача информации;
• REFER – запрос о передаче исходного SIP запроса;
• MESSAGE – передача мгновенного сообщения;
• UPDATE – модификация состояния сессии.

Структура и некоторые типы ответов на запросы SIP напрямую унаследованны от протокола HTTP и определены шестью классами, определяемыми по первой цифре трехзначного номера ответа:

1. информационные ответы;
2. ответ об успешной обработке запроса;
3. ответ о новом местоположении абонента;
4. сообщение об ошибке запроса;
5. сообщение об отказе сервера;
6. ответ о невозможности установления соединения.

Сам процесс установления соединения отличается в зависимости от использования промежуточных устройств и предусмотрено два варианта: с использованием прокси-сервера и сервера переадресации и с использованием сервера B2BUA.

В первом варианте установление соединения между терминальными устройствами А и Б начинается с отправки сообщения типа «INVITE» устройством А в направлении сервера переадресации с целью получения актуального адреса абонента Б, после получения ответа класса «3» абонент А отправляет сообщение «ACK». Следующим шагом является отправка сообщения типа «INVITE» в направлении необходимого для установления соединения прокси-сервера, который, в свою очередь, перенаправляет сообщение «INVITE» в направлении абонента Б и отправляет абоненту А ответ класса «1» с сообщением о попытке установления соединения. Далее абонент Б направляет прокси-серверу ответ класса «1» о попытке звонка, который перенаправляется прокси-сервером в направлении абонента А, аналогично отправляется ответ класса «2» об успешной обработке запроса. При получении ответа абонентом А отправляется сообщение «ACK» и перенаправляется прокси-сервером к абоненту Б, после чего соединение считается установленным и по логическому каналу передаются мультимедийные данные непосредственно между абоентами. По окончанию передачи один из терминалов аналогичным образом передает сообщение типа «BYE» и ожидает от другого устройства ответа класса «2» об успешной обработке запроса. На этом этапе соединение считается закрытым, связь между абонентами прекращается, иллюстрация работы алгоритма отражена на рисунке 1.2.

Рис 1.2. Процесс соединения абонентов с использованием протокола SIP

Во втором случае абонент А отправляет сообщение типа «INVITE» в направлении B2BUA сервера, который формирует аналогичное сообщение к абоненту Б, после чего B2BUA отправляет абоненту А ответ класса «1» о попытке установления соединения (100 Trying) и ожидает от абонента Б два сообщения класса «1» о попытке установления соединения и совершении звонка (100 Trying и 180 Ringing), после получения которых направляет абоненту А ответ 180 Ringing. Далее абонент Б направляет B2BUA ответ класса «2» об успешной обработке запроса, а B2BUA отправляет аналогичный ответ абоненту А вместе с сообщением «ACK» абоненту Б и ожидает сообщения «ACK» от абонента А, после чего соединение считается установленным и по логическому каналу передаются мультимедийные данные на участках абонент А – B2BUA и B2BUA –абонент Б. Разрыв соедиенения происходит аналогично первому варианту, но через устройство B2BUA, иллюстрация к описанному процессу отображена на рисунке 1.3.

Рис 1.3. Процесс соединения абонентов с использованием протокола SIP и сервера B2BUA

1.6 Технологии виртуализации

В работе описаны практические рекомендации, по конфигурации программной АТС на базе ПО Asterisk с поддержкой рассмотренных ранее протоколов. Asterisk – программный сервер телефонии (программная АТС) с открытым исходным кодом, поддерживающий работу со специализированным оборудованием для аналоговых/цифровых телефонных линий, а также программные и аппаратные IP-телефоны.

Указанное ПО имеет ограничения по установке, а именно, работает исключительно на операционных системах семейства Linux. Linux – общее название ОС из семейства Unix, которых объединяет ядро, созданное Линусом Торвальдсом. На базе ядра Linux создано множество дистрибутивов различного назначения (для использования в производственной среде, домашнего использования, и т.д.), среди наиболее известных — Red Hat, CentOS, Fedora, Debian, Ubuntu, Kali, Arch. Android также базируется на Linux.

Ввиду невысокого распространения подобных операционных систем на персональных компьютерах для личного использования, в работе использованы средства виртуализации для возможности запуска Linux поверх ОС Windows или Mac.
Виртуализация – технология создания виртуального представления вычислительных ресурсов абстрагировано от аппаратного обеспечения, на базе компьютера, сервера или серверного кластера (обобщенно говоря, хоста) для возможности одновременной работы нескольких ОС. Реальные ресурсы хоста (процессор, оперативная и дисковая память и т.д.) с помощью специализированного ПО (гипервизора) распределяются между виртуальными машинами (ВМ) – программными средами, имитирующими физический компьютер, на которые устанавливаются гостевые ОС.

Гипервизор – ПО, которое управляет выделением физических ресурсов хоста для ВМ, разделяет и изолирует эти ресурсы между ними, позволяя запускать несколько ОС одновременно, также гипервизор выполняет обработку запросов прерываний процессора и запросов на доступ к памяти от гостевых ОС. Для хостовой ОС ВМ представляет собой набор файлов – обычно это файл виртуального диска, файл конфигурации ВМ и некоторые другие файлы (файлы контрольных точек и тп).

Существует два основных типа гипервизоров, первый представляет собой специализированную ОС, устанавливаемую непосредственно на сервер в качестве основной, имеющей прямой доступ ко всем аппаратным ресурсам, что является оптимальным решением для высоконагруженных сред виртуализации ввиду легковесности и оптимизированности такой ОС под конкретные задачи виртуализации. А главное – минимальной возможности возникновения ошибок ОС вследствие отсутствия ненужных компонентов, несущих сторонний функционал.

Второй тип – ПО, устанавливаемое в обычной ОС (Windows, Linux, macOS), взаимодействующее с аппаратными ресурсами через основную ОС, что подходит для быстрого развертывания тестовых стендов и выполнения лабораторных работ. В работе используется второй тип гипервизора.

1.7 Создание ВМ в VMware Workstation Player 15

Скачайте с удаленного хранилища образ операционной системы CentOS и сохраните файл на персональный компьютер, после чего откройте графический интерфейс ПО VMware Workstation Player 15 ( или Oracle VM VirtualBox). Если вы ставите виртуальную машину Oracle VM VirtualBox, то следуйте на шаг 1.7.1:

1. Нажмите Create a New Virtual Machine.
2. Выберите пункт I will install the operating system later (Рисунок 1.4).

Рис 1.4. Настройка окна установщика

1. Выберите тип и версию гостевой ОС (если в вашей версии доступен на выбор CentOS 8 или Red Hat Enterprise Linux 8 – укажите его, если нет – CentOS 7) (Рисунок 1.5).

Рис 1.5. Настройка типа и версии гостевой ОС

1. Укажите имя (рекомендуется отобразить в имени принадлежность ВМ к студенту) и папку сохранения для ВМ (рекомендуется сохранить на диск D: или F:) (Рисунок 1.6).

Рис 1.6. Настройка имени виртуальной машины

1. Укажите параметры диска для ВМ (объем 20 ГБ) (Рисунок 1.7).

Рис 1.7. Настройка параметров диска

1. Нажмите Customize Hardware… Выделите для ВМ 1 ГБ оперативной памяти (Memory), 4 ядра процессора (Processors), в New CD/DVD выберите Use ISO image file и нажав Browse, укажите путь к сохраненному ранее образу CentOS (Рисунок 1.8).

Рис 1.8. Настройка параметров ВМ

Выделенных ресурсов хватит для тестовой установки и эксплуатации CentOS без графического окружения с Asterisk, обслуживающим до 10 клиентов. Нажмите Close и потом Finish.

1. Запустите ВМ (появится слева в VMware Player), нажав Play virtual machine.

Переключение ввода внутрь ВМ производится щелчком ЛКМ по окну с запущенной ВМ, возврат в хостовую ОС – Ctrl+Alt.

1.7.1 Создание ВМ в Oracle VirtualBox

1. В левом верхнем углу нажмите кнопку «Создать»
2. Укажите имя, версию и тип ОС. В имени рекомендуется отобразить в имени принадлежность ВМ к студенту. Тип ОС, как не трудно догадаться: «Linux». Дистрибутив Cent OS Linux, основан на ПО Red Hat Enterprise Linux (RHEL) компании Red Hat, выбираем соответствующую версию.

Рис 1.8.1. Настройка параметров ВМ

1. Укажите объём оперативной памяти, который будет выделяться под виртуальную машину. 2 Гб достаточно.

Рис 1.8.2. Настройка выделения оперативной памяти

1. В параметрах Жёсткого диска выберите пункт «Создать новый виртуальный жёсткий диск»

Рис 1.8.3. Настройка параметров жёсткого диска

Далее тип диска: VDI (VirtualBox Disk Image)

Рис 1.8.4. Настройка типа диска

Формат хранения: Динамический виртуальный жёсткий диск.

Рис 1.8.5. Настройка формата хранения

Имя и размер файла.
Имя можно оставить такое же, размер рекомендуется поставить 20 Гб.

Рис 1.8.6. Настройка выделяемого объёма памяти

Далее нажмите кнопку «Создать» и запустите виртуальную машину

1. Откроется окно, где нужно указать путь к скачанному вами образу Cent OS.

Рис 1.8.5. Выбор образа Cent OS

1.8. Установка CentOS 8

1. При появлении меню загрузки, как показано на рисунке, выберите пункт Install CentOS… чтобы начать установку CentOS 8 (Рисунок 1.9).

Рис 1.9. Установка CentOS 8

1. Выберите язык системы (настоятельно рекомендуется оставить английский English (United States)) и нажмите Continue (Рисунок 1.10).

Рис 1.10. Выбор языка системы

1. В появившемся окне параметров установки перейдите в Time&Date, выберите корректный часовой пояс, нажмите Done (Рисунок 1.11).

Рис 1.11. Настройка параметра часового пояса

1. Перейдите в Software Selection и выберите подходящее базовое окружение – Minimal Install (в целом, опция Minimal Install вполне подходит для большинства случаев развертывания, установка Asterisk – в их числе) (Рисунок 1.12).

Рис 1.12. Настройка базового окружения

1. Откройте пункт Installation Destination и нажмите Done для автоматической разметки диска.
2. Перейдите в пункт Network & Host name. Включите доступные сетевые интерфейсы Ethernet (и проверьте, что им присваивается IP-адрес). В поле Host Name внизу задайте произвольно имя хоста (это имя будет установлено в ОС как имя системы) и нажмите Apply. Если текущее имя изменено, адрес успешно получен, нажмите Done (Рисунок 1.13).

Рис 1.13. Настройка используемого хоста

1. Нажмите Begin Installation чтобы начать установку. В Root Password задайте пароль пользователю root (На данном этапе возможно задать простой короткий пароль путем двойного нажатия Done). Создайте своего пользователя (User Creation) с любым удобным именем (в поле Full name можно использовать прописные буквы и длинное имя, поле User name содержит логин, под которым авторизуется пользователь, он должен быть достаточно короток и не должен содержать прописных букв. Обязательно отметьте пункт Make this user administrator для добавления пользователя в соответствующую группу администраторов (wheel). На данном этапе также возможно аналогично задать простой короткий пароль (Рисунок 1.14).

Рис 1.14. Настройка параметров пользователя

1. По окончанию установки нажмите Reboot. ВМ перезагрузится и загрузится с виртуального диска со свежеустановленной CentOS.

1.9. Первоначальная настройка CentOS

В Linux подключенные диски отображаются иначе и имеют отличные от используемых в Windows идентификаторы. В зависимости от интерфейса, через который подключен жесткий диск, название может начинаться на:

• sd – устройство, подключенное через интерфейс SCSI (SAS);
• hd – устройство, подключенное через интерфейс ATA (SATA).

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

Также подобную информацию можно получить командой

Настройка удаленного доступа по протоколу SSH
Авторизуйтесь в окне ВМ под пользователем, которого Вы создали на этапе установки. (Данная работа (и последующие в курсе) предполагает, что Вы НЕ используете учетную запись root).
Узнайте IP адрес, который был получен CentOS от DHCP сервера VMware Player, для этого выполните команду:
ip address
Первый сетевой адаптер в списке с именем lo, с адресом 127.0.0.1 (адрес указан после слова inet), также известным как адрес localhost – loopback-адаптер, используемый для обращения ОС к себе самой, трафик этого адаптера никогда не покидает ОС и не попадает в сеть, целая подсеть 127.0.0.0/8 выделена под loopback, и, соответственно, недоступна извне. Используемый для связи с “внешним миром” адрес следует искать в секции, соответствующей адаптеру с именем, начинающимся на eth или ens. Этот интерфейс необходимо перевести в режим «Сетевой мост» или «Bridge» в настройках виртуальной машины.

Рис 1.15. Настройка типа подключения

После этого необходимо перезапустить виртуальную машну, либо перезапустить сетевую службу с помощью команды

sudo systemctl restart NetworkManager

Для удаленного подключения к CentOS воспользуемся протоколом SSH (Secure SHell 2 версия), который предоставляет безопасный (защищенное криптоалгоритмами RSA или ECDSA соединение) доступ к командной оболочке. Этот протокол заменил в большинстве случаев небезопасный открытый протокол Telnet.
Запустите на хостовом ПК программу PuTTY, в поле Host Name введите полученный на предыдущем шаге IP адрес CentOS, выберите тип подключения SSH и нажмите Open (Рисунок 1.15).

Рис 1.15.1 Настройка типа подключения

Согласитесь на добавление незнакомого ключа сервера, после появления окна с приглашением login as: введите имя пользователя, нажмите Enter, введите пароль, нажмите Enter. Вы можете открыть несколько параллельных сессий от имени одного пользователя в новых окнах PuTTY, что может быть удобно, если потребуется одновременно изменять конфигурацию и отслеживать сообщения в интерфейсе какого-либо ПО.

Конфигурация пакетного менеджера yum

Стандартный способ управления ПО в Linux (установка, обновление, удаление) – через соответствующий дистрибутиву пакетный менеджер, который скачивает и устанавливает пакетные файлы из репозиториев – хранилищ данных, предназначенных для распространения пакетов ПО по сети. В deb-based дистрибутивах Linux (Debian, Ubuntu, Kali) используется пакетный менеджер apt, в rpm-based (RedHat, CentOS, Fedora) — yum, в Fedora, а также начиная с 8 версии в RedHat и CentOS, yum является алиасом (ссылкой на другую команду) для менеджера dnf, который используется в системе вместо yum. Далее по тексту работы как пакетный менеджер будут упоминаться традиционный для CentOS yum и приводиться команды и конфигурация для него, что вполне возможно благодаря наличию в CentOS 8 обратной совместимости (а вот в ранних версиях CentOS использовать команды для dnf не получится).

В случае доступа в Интернет через прокси-сервер [4] необходимо сконфигурировать yum для работы через прокси ИЛИ настроить локальные репозитории. В данном курсе работ будет использоваться первый способ.

Изменение параметров работы системного ПО в подавляющем большинстве случаев в Linux производится редактированием соответствующих конфигурационных файлов в текстовом редакторе и применением изменений/перезапуском службы. По умолчанию в CentOS установлен текстовый редактор vi, первоначально используйте его для редактирования текстовых файлов конфигурации, после получения доступа к репозиториям (в случае отсутствия прямого доступа в Интернет), можно установить удобный Вам — mc, nano и тп.
Обратите внимание, что для возможности сохранения файлов (право записи на файл) в любых директориях, кроме домашней, могут потребоваться права суперпользователя, с которыми должен быть запущен текстовый редактор (sudo vi ПУТЬ_К_ФАЙЛУ) (Рисунок 1.16).

Параметры прокси-сервера прописываются в конфигурационном файле yum /etc/yum.conf, его необходимо открыть в редакторе с правами суперпользователя для внесения изменений:

Рис 1.16. Ошибка при подключении пользователя

Если Вы получили такой вывод в терминале, значит Ваш пользователь при установке не был добавлен в группу администраторов (пользователей с привилегиями sudo). Следует под пользователем root добавить его в группу пользователей sudo (wheel) вручную командой usermod -aG wheel username (Рисунок 1.17).

Рис 1.17. Добавление пользователя в группу администраторов

Команда su переключает сессию текущего пользователя на суперпользователя root, поэтому пароль необходимо вводить от учетной записи root.
Для применения изменений требуется полностью выйти из системы с помощью команды exit и авторизоваться под Вашим пользователем заново.

Конфигурация Proxy сервера иногда не требуется, уточняйте у преподавателя!
Переведите vi в режим редактирования нажав i. Добавьте в конец секции [main]:

- proxy=http://прокси:порт
- proxy_username=логин
- proxy_password=пароль

Уточните у преподавателя, какие параметры использовать для прокси соединения, если его конфигурация необходима, при отсутствии прокси-сервера в сети пропустите этот пункт.
Выход из vi с сохранением изменений: нажать Esc ввести :wq
Выход из vi без сохранения: Esc :q!

В репозиториях, которые включены в CentOS по умолчанию (Base, AppStream, Extras) доступны далеко не все пакеты, кроме того, большинство представлено устаревшими версиями (например, MariaDB, PHP). Некоторые из требуемых в данной работе пакетов доступны в репозитории EPEL (или Extra Packages for Enterprise Linux). Если один и тот же пакет находится в нескольких репозиториях, yum (если не указана желаемая версия и не сконфигурирован репозиторий по умолчанию для пакета) установит самую последнюю версию. Чтобы добавить репозиторий EPEL в список активных репозиториев, достаточно установить пакет epel–release из базового репозитория CentOS. Добавьте репозиторий EPEL:

sudo yum install epel–release

В зависимости от используемого дистрибутива операционной системы могут быть замечены некоторые ошибки в работе пакетного менеджера yum, например, ошибка типа «Failed to synchronize cache for repo appstream». Указанную проблему можно решить последовательным выполнением сделующих команд, при выполнении последней следует отказаться от обновление пакетов нажатием кнопки «n»:

sudo cd /etc/yum.repos.d/
sudo sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*
sudo sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*
sudo yum update

По умолчанию yum автоматически НЕ устанавливает пакеты, только проверяет их наличие в активных репозиториях, составляет список всех зависимых пакетов для установки, подсчитывает объем загружаемых файлов, требуемое место на диске для установки и спрашивает, следует ли установить их (см. рисунок ниже). На вопросы об установке пакетов и обновлении GPG-ключей репозиториев (Is this ok?) следует ответить y (Рисунок 1.18).

Рис 1.18. Настройка устанавливаемых пакетов

Если yum успешно установил запрашиваемые пакеты, вывод будет подобен приведенному на рисунке ниже (все установленные пакеты и зависимости (если существуют) приведены после строк Installed: и Dependency Installed: соответственно (Рисунок 1.19).

Рис 1.19. Проверка установки пакетов

Если vi Вам неудобен для редактирования, можно установить другой текстовый редактор, например редактор файлового менеджера MidnightCommander, который помимо возможности удобно просматривать файлы и директории, предоставляет свой собственный текстовый редактор.

Устанавливается через yum:

Редактор mcedit использует ряд F-клавиш для управления, их назначение указано внизу окна на кнопках с соответствующим номером, кроме того, mc поддерживает управление мышью, можно кликнуть по верхней панели для отображения меню, а также по нижним кнопкам. Для копирования/вставки используются сочетания Ctrl-Insert/Shift-Insert соответственно (а также выделение мышью с зажатым Shift/ПКМ) (Рисунок 1.20).

Рис 1.20. Ознакомление с окном Edit

Чтобы открыть файловый менеджер в текущей директории выполните команду mc. Для редактирования файла замените vi на mcedit в вызове редактора:
sudo mcedit /etc/yum.conf
SELinux
Security-Enhanced Linux – дополнительная система безопасности Linux, реализующая мандатную систему управления доступом, позволяющая гибко разграничивать права пользователей и отдельных процессов в рамках контекстов безопасности. По умолчанию включена в CentOS в активном режиме, что без соответствующей настройки препятствует работе устанавливаемых пакетов и служб в фоновом режиме, поэтому ее требуется выключить.

Выключить SELinux немедленно до перезагрузки системы можно так:

Чтобы перевести SELinux в выключенный режим окончательно, требуется заменить

SELINUX=enforcing на SELINUX=disabled в файле /etc/selinux/config:

sudo vi /etc/selinux/config

SELinux в некоторых случаях может оказаться крайне полезен, в дальнейшем будет полезно понять принцип его конфигурирования и работы.

Установка пакетов для скачивания и сборки исходного кода

Установите пакет wget для скачивания файлов по URL ссылке, клиенты систем управления версиями git и svn, компиляторы gcc gcc -c++ и дополнительные пакеты для сборки проектов из исходного кода по Makefile:

sudo yum install wget git gcc gcc-c++ svn wget cmake make automake autoconf pkgconfig graphviz

Для управления репозиториями необходимо установить пакет утилит yum:

sudo yum install yum-utils -y

Обратите внимание, что добавление ключа -y заставит yum установить пакет без подтверждения, это может быть полезно в плане экономии времени, однако иногда все же лучше сверять пакеты и версии перед установкой.

Включите репозиторий PowerTools (добавлен в CentOS 8 по умолчанию, но выключен) и установите криптографические пакеты и библиотеки для поддержки шифрования передаваемых голосовых данных:

sudo yum-config-manager --enable PowerTools

sudo yum install openssl openssl-devel libsrtp libsrtp-devel doxygen -y

Установка требуемых для Asterisk зависимостей из репозиториев (набор пакетов приведён для конфигурации, необходимой в данной работе; некоторые ненужные в данном курсе модули Asterisk будут недоступны при сборке):

UPD (2023): Чтобы команда корректно сработала и пакет sox смог установиться, нужно предварительно установить epel более старой версии, сделать это можно выполнив команду:

sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

После этого можно устанавливать основные пакеты:

sudo yum install libedit-devel jansson-devel uuid libuuid-devel sqlite-devel libxml2-devel libcurl-devel xmlstarlet bison flex  neon-devel lua-devel uriparser-devel libxslt-devel unixODBC unixODBC-devel bluez-libs-devel radcli-devel freetds-devel  newt-devel popt-devel libical-devel spandsp-devel codec2-devel fftw-devel libsndfile-devel unbound-devel binutils-devel gsm-devel zlib-devel libtool bzip2 patch sox redhat-rpm-config kernel-devel

Прокси для wget – пакета для загрузки файлов (выполняется при наличии прокси-сервера в сети или пропускается) (Аналогично с обычным Proxy, нужен не всегда).

Прописывается в начале файла /etc/wgetrc

Вставьте следующие параметры:

http_proxy=http://прокси:порт
https_proxy=http://прокси:порт
proxy_user=логин
proxy_passwd=пароль

Также можно использовать переменные окружения для указания прокси-сервера, yum/dnf/apt и wget умеют работать с ними. Подробнее об определении прокси в /etc/environment или использовании команды export можете узнать самостоятельно.

Настройка правил сетевого экрана.

В CentOS 8 в качестве сетевого экрана (firewall) используется firewalld – пакет, представляющий собой надстройку над встроенным в ядро Linux файерволом netfilter. Является аналогом широко распространенного в Linux пакета iptables, но вместо настройки таблиц и цепочек реализует концепцию zone-based firewall (сетевые интерфейсы привязываются к зонам, правила фильтрации применяются к зоне, также при необходимости настраиваются правила между зонами) [5]. По умолчанию все доступные ОС сетевые интерфейсы принадлежат зоне public, все новые правила, если не указана зона, также автоматически применяются к этой зоне.

Согласно настроенным по умолчанию правилам, доступ по сети к CentOS разрешен по 22 порту для удаленного подключения по уже упомянутому ранее протоколу SSH. Для удобства управления правилами в firewalld присутствует возможность создать сервис и ассоциировать с ним группу правил.

Создание нового сервиса:

sudo firewall-cmd --permanent --new-service=asterisk

Добавление к сервису нужных портов:

sudo firewall-cmd --permanent --service=asterisk --add-port=5060/tcp

sudo firewall-cmd --permanent --service=asterisk --add-port=5060/udp

sudo firewall-cmd --permanent --service=asterisk --add-port=5061/tcp

sudo firewall-cmd --permanent --service=asterisk --add-port=5061/udp

sudo firewall-cmd --permanent --service=asterisk --add-port=4569/udp

sudo firewall-cmd --permanent --service=asterisk --add-port=10000-20000/udp

• где 5060 – SIP, 5061 – SIP over TLS, 4569 – IAX, 10000-20000 – диапазон для динамических портов RTP.

Теперь добавьте созданный сервис в список активных правил:

sudo firewall-cmd --permanent --add-service=asterisk

Перечитать установленные правила firewalld (применить изменения без сброса текущих сетевых соединений):

sudo firewall-cmd --reload

Так можно посмотреть правила, привязанные к сервису

sudo firewall-cmd --info-service=asterisk

Посмотреть всю конфигурацию firewalld

sudo firewall-cmd --list-all

Раздел 2. Сборка и начальная конфигурация сервера VoIP телефонии Asterisk

2.1. Установка Asterisk

Asterisk устанавливается путем сборки из исходного кода. Полная установка проходит в 3 этапа:

1. (опц) Установка DAHDI (драйвера плат FXO интерфейсов);
2. (опц) Установка LibPRI (библиотека для работы с потоковыми TDM-интерфейсами);
3. Сборка и установка Asterisk.

При использовании тестового стенда на ВМ можно пропустить первые 2 пункта, поскольку использование спец оборудования не подразумевается, поэтому сразу приступим к сборке Asterisk. Архив с исходным кодом требуемой 16 версии Asterisk asterisk-16-current.tar.gz лежит в той же директории на сервере, где Вы брали образ CentOS; скачайте архив на свой ПК. Для того, чтобы перенести файл архива с хостового компьютера в CentOS, воспользуемся протоколом передачи файлов SCP (от англ. secure copy), который работает поверх SSH. Запустите на хостовом ПК программу WinSCP, которая представляет собой клиент таких протоколов передачи данных, как FTP SFTP SCP WebDAV и тд. В окне входа выберите протокол SCP, в поле Имя хоста укажите IP адрес CentOS, укажите имя пользователя и пароль в соответствующих полях (аналогично подключению по SSH). Нажмите войти (Рисунок 2.1).

Рис 2.1. Настройка параметров соединения

В режиме Коммандер WinSCP отображает слева папки Вашего локального пользователя на хостовом ПК, а справа домашнюю директорию пользователя, под которым Вы подключились к серверу (к CentOS). В левой части перейдите в папку, в которую Вы ранее скачали архив с исходным кодом Asterisk, выберите и перетащите нужный файл мышью на правую половину, убедитесь, что он появился в домашней директории Вашего пользователя на CentOS (Рисунок 2.2).

Рис 2.2. Настройка директории пользователя

Распаковка архива и переход в папку с извлеченными файлами:

tar -xzf asterisk-*.tar.gz

Следует отметить, что в скачанном архиве с исходным кодом Asterisk есть скрипт (contrib/scripts/install_prereq) для автоматической установки всех зависимостей, но он подразумевает установку множества пакетов для невостребованных в данной работе модулей, и в целях экономии времени, дискового пространства и интернет-трафика, ранее была произведена “ручная” установка необходимых пакетов.

Для выполнения следующего шага потребуется прописать прокси для клиента системы управления версиями subversion. Создайте новый файл:

sudo touch /etc/subversion/servers

Или сразу укажите имя нового файла в вызове редактора, новый файл также будет создан.
В созданный файл /etc/subversion/servers необходимо добавить следующие строки:

[global]
http-proxy-host = прокси
http-proxy-port = порт
http-proxy-username = логин
http-proxy-password = пароль

Добавление пакетов для работы с mp3:

./contrib/scripts/get_mp3_source.sh

Если эта команда не выполняется, проверьте, что вы находитесь в папке asterisk-16. с распакованными файлами (проверка текущей директории командой pwd).

Очищение директории от существующих файлов конфигурации сборки:

Конфигурация параметров сборки Asterisk (это одна команда, параметры, начинающиеся с — — разделяются пробелами):

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib64 --with-iconv --with-libcurl --with-jansson-bundled --with-crypto --with-ssl=ssl --with-srtp

Полный перечень опций и что они означают можно посмотреть командой ./configure -h

В случае успешного конфигурирования в конце должна быть получена следующая картина (Рисунок 2.3).

Рис 2.3. Подтверждение успешной конфигурации

Меню выбора требуемых компонентов, модулей и приложений Asterisk:

Необходимые компоненты:

• Add-ons: format_mp3;
• Call Detail Recording: убрать cdr_radius, cdr_sqlite3_custom, cdr_tds;
• Channel Event Logging: убрать cel_radius, cel_sqlite3_custom, cel_tds;
• Channel Drivers: оставить только chan_iax2, chan_pjsip, chan_rtp;
• Codec Translators: добавить codec_opus;
• Resource Modules: убрать res_agi, все пункты с res_ari, res_fax, res_phoneprov, res_smdi (эти модули не нужны в данной установке и вызывают появление ошибок при запуске);
• Compiler Flags: LOW_MEMORY, G711_NEW_ALGORITHM, G711_REDUCED_BRANCHING;
• Core Sound Packages: только RU-WAV.

После этого выйдите, нажав Save & Exit.

Запуск процесса сборки:

Если сборка прошла успешно, отобразится сообщение об успешном завершении и возможности установить собранный пакет (Рисунок 2.4).

Рис 2.4. Подтверждение успешной сборки

Установка собранного пакета Asterisk:

Создание службы systemd для Asterisk и конфигурационных файлов по умолчанию:

sudo make samples && sudo make config

2.2. Базовая конфигурация и запуск Asterisk

Откройте в редакторе основной конфигурационный файл Asterisk:

/etc/asterisk/asterisk.conf

Необходимо раскомментировать (удалить и редактировать следующие пункты:

runuser = asterisk
rungroup = asterisk
defaultlanguage = ru

Создайте служебного пользователя asterisk, от имени которого будет работать служба Asterisk (этот пользователь не сможет осуществлять вход в систему):

sudo useradd -r -s /sbin/nologin asterisk

Смените владельца следующих директорий на пользователя asterisk для предоставления ему полного доступа:

sudo chown -R asterisk:asterisk /var/run/asterisk
sudo chown -R asterisk:asterisk /etc/asterisk
sudo chown -R asterisk:asterisk /var/{lib,log,spool}/asterisk
sudo chown -R asterisk:asterisk /usr/lib64/asterisk

Запуск Asterisk для проверки корректности установки и первоначальной конфигурации:

Если Asterisk успешно запустится, в конце вывода служебных сообщений появится зеленая надпись Asterisk Ready и приглашение командной строки Asterisk CLI> (возможно появление предупреждений и ошибок — это обусловлено особенностями сгенерированной конфигурации по умолчанию, которая предполагает использование некоторых не сконфигурированных в текущей установке Asterisk модулей. На работоспособность в целом не влияет).

Выход обратно в bash: Ctrl+C.
Запретите загрузку вызывающих ошибки модулей, которые не понадобятся в текущей работе:

sudo vi /etc/asterisk/modules.conf

вставить после строки autoload=yes:

noload => pbx_dundi
noload => res_config_ldap
noload => res_pjsip_phoneprov_provider

Если на предыдущем шаге Asterisk успешно запустился, можно запустить Asterisk как фоновую службу с автозапуском на старте ОС:

sudo systemctl enable asterisk && sudo systemctl start asterisk

Проверьте, что Asterisk корректно запущен в виде фоновой службы:

sudo systemctl status asterisk

Если служба корректно запущена и работает, в выводе должно быть указано active (running) (Рисунок 2.5).

Рис 2.5. Проверка корректного запуска Asterisk

Если получено иное, перезапустите службу и еще раз проверьте статус:

sudo systemctl restart asterisk

sudo systemctl status asterisk

Проверьте возможность подключения к интерфейсу CLI Asterisk:

Подключаться к Asterisk Вам потребуется позже при отладке конфигурации, пока что выйдите обратно в bash.
Если CLI Asterisk не открылся, проверьте состояние SELinux (sudo sestatus, Current mode не должен быть enforcing).

2.3. Конфигурация Asterisk для обработки вызовов

Чтобы Asterisk начал обрабатывать телефонные вызовы, необходимо сконфигурировать параметры канала связи (драйвер протокола SIP в данном случае) и план набора (dialplan). Протокол SIP представлен в Asterisk двумя драйверами канала – старым, проприетарным chan_sip и новым, открытым кроссплатформенным PJSIP. Преимущества последнего помимо кроссплатформенности в стабильности, активном развитии (исправлении багов и уязвимостей, оптимизации и обновлении), поддержке дополнительных протоколов (TURN и тд) для обеспечения лучшей проходимости трафика SIP через NAT [6-7], в возможности осуществлять множество регистраций на одну учетную запись клиента. Таким образом, для данной работы был выбран PJSIP как более функциональное современное решение. План набора конфигурируется как описание логики обработки вызовов практически одинаково для любого типа канала, отличия только в вызываемом приложении внутри записи экстеншена (пункт диалплана).

Для конфигурации Asterisk в качестве IP АТС согласно изложенному ранее, необходимо отредактировать два основных конфигурационных файла:

1. pjsip.conf, в котором указываются сведения о транспортном протоколе, разрешенных кодеках, клиентах и регистрациях SIP, пользователи с соответствующими идентификаторами-номерами, параметры регистрации и аутентификации;
2. extensions.conf, описывающий план набора — dialplan, правила обработки и маршрутизации вызовов.

После внесения изменений в любой конфигурационный файл Asterisk, служба Asterisk должна быть перезапущена для применения изменений!!!

sudo systemctl restart asterisk

Удалите файлы конфигурации, созданные по умолчанию:

sudo rm /etc/asterisk/extensions.conf
sudo rm /etc/asterisk/pjsip.conf

2.4. Конфигурация плана набора

План набора в файле extensions.conf структурирован в секции, называемые контекстами. Контекст – это независимая от остальных часть внутри диалплана. Контексты используются для разделения функций, обеспечения безопасной обработки и фильтрации вызовов между различными частями, определения класса обслуживания разных пользователей и так далее.
План набора, как было сказано ранее, состоит из одного или нескольких контекстов. Контексты используются для реализации основных функций АТС, таких как:

• безопасность – можно разрешить вызовы на определенные номера только конкретным абонентам;
• маршрутизация вызовов – маршрутизация вызовов в зависимости от номера абонента;
• многоуровневые голосовые меню – голосовые меню для службы поддержки, отдела продаж и т.д;
• авторизация – запрос пароля для вызова на некоторые номера;
• обратный вызов;
• списки доступа – занесение в черные списки нежелательных абонентов;
• виртуальные АТС – возможность создавать независимые виртуальные АТС в пределах Вашей основной АТС;
• дневной/ночной режим работы – изменение поведения АТС в зависимости от времени;
• макросы – можно создавать скрипты для решения повторяющихся задач в плане набора.

Каждый контекст – это набор расширений (extension). Каждый экстеншен в контексте имеет уникальное имя, которое обычно является числовым идентификатором, присвоенным линии, идущей к конкретному телефону.

Синтаксис расширения начинается с выражения exten => Далее указывается имя (или номер) экстеншена. В традиционных системах телефонной связи под номерами понимаются номера из цифр, которые надо набрать, чтобы позвонить определенному абоненту с этим номером. В Asterisk понятие имени (номера) намного шире, в качестве имени добавочного номера может использоваться любая комбинация цифр и букв. Полный экстеншен состоит из трех компонентов:

1. имени (или номера);
2. приоритета (каждый добавочный номер может включать множество шагов обработки вызова, порядковый номер шага называется его приоритетом);
3. приложение (или команда), которое выполняет некоторое действие над вызовом.

Эти три компонента разделяются запятыми:

exten => имя,приоритет,приложение()

Приведём пример простейшего экстеншена:

exten => 123,1,Answer()

В этом примере имя добавочного номера – 123, приоритет – 1, а приложение – Answer().

В начале диалплана также можно разместить два специальных контекста, [general] и [globals]:
[general] содержит список общих настроек диалплана;
[globals] — глобальные переменные.
Ниже приведен пример простейшего плана набора (реализует обработку звонков на любые трехзначные номера) в контексте default, который должен быть, сохранен в файле /etc/asterisk/extensions.conf

[default]

exten => _XXX,1,Dial(PJSIP/${EXTEN})

Теперь рассмотрим реализацию простого голосового меню с подробным описанием процесса маршрутизации и обработки вызовов.

[internal]

exten => 1234,1,GoTo(ivr,s,1)

[ivr]

exten => s,1,Answer()

 same => n,Playback(hello)

same => n,Background(basic-pbx-ivr-main)

 same => n,Playback(demo-thanks)


exten => 1,1,GoTo(1-otd,s,1)

[1-otd]

exten => s,1,Background(one-moment-please)

same => n,GoTo(ivr,s,4)

При звонке клиента из контекста internal на номер 1234 происходит перенаправление вызова приложением GoTo в контекст ivr на соответствующий экстеншен с именем s и приоритетом 1. Далее пошагово идёт обработка вызова: ”поднимается трубка” приложением Answer, проигрывается звуковая запись hello с помощью приложения Playback (по умолчанию Asterisk ищет записи в /var/lib/asterisk/sounds для указанного в конфигурации языка), далее проигрывается запись basic-pbx-ivr-main с помощью приложения Background. Отличие между этими двумя приложениями состоит в том, что во втором случае Asterisk во время проигрывания звукового файла прослушивает линию на предмет ввода дополнительного номера в тональном режиме (DTMF). При вводе 1 обработка вызова передается в контекст 1-otd. Если ввода не последовало, проигрывается demo-thanks и вызов завершается, поскольку больше нет настроенных экстеншенов для дальнейшей обработки вызова.
Задание. Создайте контекст с произвольным именем, настройте обработку внутренних 4-значных номеров, определите отдельно любой произвольный номер, при вызове на который Asterisk будет проигрывать запись num-was-successfully и принудительно завершать вызов с помощью приложения Hangup().

Конфигурация PJSIP

Настройки PJSIP в Asterisk производятся через текстовый файл конфигурации pjsip.conf, состоящий из секций. Общий вид секций стандартен для всех конфигурационных файлов Asterisk

• начинается с указания имени секции в скобках[]. Основное отличие в структуре конфигурационного файла PJSIP от классического драйвера chan_sip, в том, что конфигурация SIP-клиентов разбивается на логические разделы:

• Endpoint – соответствует клиенту или транку SIP, содержит описание основных параметров клиента, его принадлежность к контексту и определяет связь с остальными обязательгымиг модулями, такими как Transport, Auth и AOR;

• Transport – данный раздел описывает тип транспортного протокола для подключаемых устройств, доступны TCP, UDP, TLS, а также WebSocket. Возможно использовать один раздел для многих конечных точек (разделов Endpoint), также можно при необходимости для раздела Endpoint создать свой собственный раздел Transport;

• Auth – раздел, содержащий параметры аутентификации для исходящей или входящей регистрации SIP, с данным разделом связаны разделы Endpoint и Registrations. Одна запись раздела Auth при необходимости может использоваться несколькими разделами Endpoint и Registration (т.е. имя пользователя для регистрации совсем необязательно соответствует номеру пользователя);

• AOR (Address of Record) – раздел по своей сути является указателем для Asterisk, каким образом связаться с точкой (Endpoint). Без соответствующей записи в AOR не будет возможности вызвать подключаем конечную точку (телефонный аппарат клиента или передать вызов в транк оператора);

• Registration – раздел, отвечающий за исходящую регистрацию, например, регистрация Asterisk на сервере оператора связи. Для корректной работы данного раздела обязательно должны присутствовать две опции в которых указываются имена используемых разделов: раздел Transport (опция transport) и раздел Auth (опция outbound_auth); также обязательна опция type.

Пример конфигурации транспорта SIP и создание клиента с 3-значным номером, описанные в файле /etc/asterisk/pjsip.conf

[udp–transport]

type=transport

protocol=udp

bind=0.0.0.0

[101]

type=endpoint

transport=udp–transport

context=default

disallow=all

allow=g726,gsm

auth=101

aors=101

[101]

type=auth

auth_type=userpass

password=verysecuresupercoolencryptedpassword

username=101

[101]

type=aor

max_contacts=1

Посмотреть, какие кодеки поддерживает Asterisk можно выполнив команду:

Задание. Создайте конфигурацию для 2-х клиентов, каждому из которых соответствует 4-значный номер (номера выберите сами), привяжите к ранее созданному в плане набора контексту, разрешите использование только кодеков OPUS, G.711 A-law (корректные имена кодеков узнайте самостоятельно).
Обратите внимание, PJSIP очень чувствителен к корректности синтаксиса файла конфигурации, даже отсутствие/наличие пробела там, где он должен/не должен быть приводит к полной неработоспособности. Перезапустите службу Asterisk после изменения файлов конфигурации.
Теперь проверим, что Asterisk готов принимать вызовы, приходящие по сети, для этого нужно убедиться, что прослушивается порт SIP – 5060. Получить статистику по открытым портам и соединения можно с помощью нескольких команд, одна из них – ss:

ss – ulpn (Рисунок 2.6).

Рис 2.6. Получение статистики об открытых портах и соединениях

2.5. Протоколы SIP и RTP

Современная IP-телефония строится на связке сигнальных протоколов и протоколов передачи данных реального времени. В качестве сигнального протокола, обеспечивающего установление сессий передачи данных наибольшую популярность, обрел SIP в связке с SDP, непосредственно для передачи данных используется протокол прикладного уровня RTP и тесно связанный с ним транспортный протокол RTCP.

Session Initiation Protocol (SIP) – это клиент-серверный протокол сигнализации прикладного уровня, предназначенный для установления, модификации и окончания сеансов связи с одним или несколькими участниками для обмена мультимедийным трафиком [8]. SIP использует текстовые сообщения, в которых используется кодировка UTF-8, работает на порту 5060, как в случае использования транспортного протокола UDP, так и TCP [9]. Описан в RFC 3261.

Основными функциями SIP являются:

• определение местонахождения адресата;
• определение готовности адресата установить контакт;
• обмен данными о функциональных возможностях участников сеанса;
• изменение параметров медиапотока уже установленного сеанса;
• управление сеансом связи.

Основными функциональными элементами являются:

• абонентский терминал (User Agent). SIP-клиент, реализованный как АО (VoIP телефон/VoIP-шлюз) или ПО (PhonerLite, SIPp), с помощью которого абонент совершает вызовы;

• прокси-сервер. Узел в сети, принимающий и обрабатывающий запросы от терминалов, выполняя соответствующие этим запросам действия и возвращая ответы. Прокси-сервер может принимать вызовы, переадресовывать их, вносить изменения в передаваемые сообщения SIP (например, для преодоления NAT), инициировать запросы к клиентам;

• сервер переадресации. Узел, хранящий записи о текущем местоположении всех зарегистрированных в сети клиентах (терминалах) и прокси-серверах. Сервер переадресации только переадресует вызовы и не генерирует собственные запросы;

• сервер регистрации / определения местоположения пользователей (Register). Представляет собой базу данных адресной информации (IP-адресов). Необходим для обеспечения мобильности пользователей. Чаще всего совмещен с прокси-сервером.

Asterisk в стандартной установке совмещает все 3 последние упомянутые роли.
В протоколе SIP определено 6 основных запросовов (Табл. 2.1).

Таблица 2.1

Основные запросы в протоколе SIP

Позднее SIP был расширен введением функций обмена мгновенными сообщениями и получения информации о статусе клиента. Дополнительные методы, описаны в RFC:

• info: Расширение протокола, описанное в RFC 2976;
• notify: Расширение протокола, описанное в RFC 2848;
• subscribe: Расширение протокола, описанное в RFC 2848;
• unsubscribe: Расширение протокола, описанное в RFC 2848;
• update: Запрос на изменение параметров сеанса, описан в RFC 3311;
• message: Расширение протокола, описанное в RFC 3428;
• refer: Расширение протокола, описанное в RFC 3515.

Для SIP определено 6 кодов ответа, которыми прокси-сервер описывает состояние соединения, например: подтверждение установления соединения, передача запрошенной информации, сведения о неисправностях и пр. Все классы ответов, кроме 1 завершают выполнение запроса.

1. 1хх – Информационные ответы, сообщают о ходе выполнения запроса;
2. 2хх – Успешное окончание запроса;
3. 3хх – Информация об изменения местоположения вызываемого абонента;
4. 4хх – Информация об ошибке;
5. 5хх – Информация об ошибке сервера;
6. 6хх – Информация о невозможности вызова абонента (пользователь с таким адресом не зарегистрирован, или пользователь занят).

Непосредственным носителем голосовых или видеоданных является протокол RTP (Real-time Transport Protocol), SIP-сообщение же выполняет роль контейнера для сообщений протокола описания сеансов связи SDP (Session Description Protocol RFC 4566).

Протокол SDP используется для согласования параметров сессии передачи данных. Сообщение SDP описывает медиаданные в рамках сессии: тип медиаданных, транспортный протокол, кодек и тд. Последнее позволяет выполнять более совершенное управление голосовыми вывозами с переадресациями и продвинутой маршрутизацией. SIP поддерживает также приглашение участников к текущим сеансам наподобие многоточечных конференций, добавление к текущему сеансу или удаление из него мультимедийных данных, прозрачное распределение имён и перенаправление услуг, включая персональную мобильность пользователя.

RTP – транспортный протокол для передачи трафика реального времени (в том числе потоковой передачи мультимедийного трафика) [9]. Для передачи и контроля параметров соединения используется протокол RTCP.

2.6. Настройка клиентов

В терминале подключитесь к службе Asterisk (sudo asterisk -vvvr), оставьте открытой консоль Asterisk, чтобы там видеть информационные сообщения о регистрации клиентов и обработке вызовов. Из директории с руководством по данной работе на сервере скачайте на свой компьютер архив PhonerLite.zip, разархивируйте его в 2 разные папки для двух разных клиентов. Сначала проделайте все указанные ниже шаги для одного клиента, если клиент успешно зарегистрировался и может совершить звонок на номер Asterisk с проигрыванием записи num-was-succesfully, то сконфигурируйте и второго клиента для 2 номера.

Запустите приложение PhonerLite.exe, выберите manual configuration. В строке Proxy/Registrar укажите IP-адрес Asterisk, нажмите далее (кнопка со стрелкой влево), введите имя пользователя и пароль (из секции Auth pjsip.conf). Завершите оставшиеся этапы конфигурации клиента.

Если регистрация клиента на сервере прошла успешно, внизу окна появится соответствующая надпись и индикатор будет зелёным, а в интерфейсе Asterisk появятся сообщения о том, что прошла регистрация и клиент с номером … стал доступен (Рисунок 2.7).

Рис 2.7. Проверка успешной регистрации клиента на сервере

Во вкладке Configuration – Network снимите выделение с пункта Multicast DNS, нажмите Save.

Иначе возможны некоторые нежелательные ситуации, поскольку клиенты могут находить друг друга в сети посредством рассылки запросов и при вызове могут игнорировать Asterisk.

Первому клиенту PhonerLite поставьте первым разрешенным приоритетом кодек Opus, второму – G.711 A-law, совершите звонок. Убедитесь, что в консоли Asterisk отображается информация об обработке вызова, если нет, проверьте, что неактивен пункт Multicast DNS, закройте клиенты, перезапустите Asterisk, откройте консоль Asterisk, запустите клиенты и попробуйте заново.

2.7. Отладка SIP протокола

Модуль res_pjsip_history сохраняет в памяти историю всех отправленных и полученных SIP-сообщений, которые проходят через стек PJSIP.
Для того, чтоб начать захват, нужно выполнить следующую команду в CLI Asterisk:

Для наглядного отображения порядка проведения VoIP вызова с помощью протоколов SIP и RTP, можно использовать Wireshark — инструмента для захвата и анализа сетевого трафика. Запустите Wireshark и выберите соответствующий сетевой адаптер для захвата трафика из списка (VMnet8 для сети NAT в VMware Player).

В строке Apply a display filter введите sip || rtp для отфильтровывания в выводе пакетов соответствующих протоколов (Рисунок 2.8).

Рис 2.8. Проведение VoIP вызова с помощью протоколов SIP и RTP

Совершите вызов из PhonerLite второму клиенту, не забудьте принять вызов на втором PhonerLite. После завершения вызова (достаточно принять вызов и можно сразу же нажать отбой) нажмите на красный квадратик слева сверху, чтобы остановить захват трафика и перейти к его анализу. В пункте Telephony выберите VoIP Calls, в открывшемся окне будут отображены все захваченные звонки (сеансы SIP). Выберите один из них и нажмите внизу Flow Sequence, чтобы наглядно отобразить этапы установления и завершения соединения с помощью протокола SIP.

Сравните с историей SIP сообщений на Asterisk:

Также можно получить информацию о клиентах:

Вопрос для самоконтроля. Почему некоторые сообщения SIP (в частности INVITE при инициализации сеанса) клиент отправляет по 2 раза?

Раздел 3. Настройка канала между Asterisk серверами. Realtime конфигурация

Эту часть работы удобнее всего выполнять парами, поскольку потребуется два узла Asterisk. Для обеспечения сетевой связности между двумя ВМ, запущенными на разных ПК, потребуется внести некоторые изменения в конфигурацию каждой:

1. Откройте VMware Player, убедитесь, что ваша ВМ с CentOS выключена (State: Powered off), нажмите Edit virtual machine settings.
2. Нажмите Add…, выберите Network adapter. Отредактируйте конфигурацию нового сетевого адаптера (Network Adapter 2), укажите Bridged вместо NAT в Network connection. Сохраните изменения (Рисунок 3.1).

Рис 3.1. Настройка нового сетевого адаптера

1. После запуска ВМ настройте новый адаптер согласно инструкции ниже и убедитесь, что CentOS получает адрес из той же сети, в которой находится хостовой ПК.

Определите, какое имя получил новый адаптер в системе, выполните команду ip address, новый адаптер отобразится последним в списке.
Сгенерируйте уникальный идентификатор с помощью команды uuidgen имя_адаптера скопируйте полученное значение, его потребуется вставить в поле файла конфигурации на следующем шаге. Создайте файл конфигурации для нового адаптера в директории /etc/sysconfig/network-scripts c именем ifcfg-имя_адаптера.

В файле следует указать следующие параметры (пример актуален для подсети с DHCP):

TYPE=Ethernet
BOOTPROTO=dhcp
NAME=имя_адаптера
ONBOOT=yes
UUID=полученное_значение_от_uuidgen
NM_CONTROLLED=yes

Применение изменений в CentOS 8:

systemctl restart NetworkManager

Если новый сетевой адаптер (ens или eth) в CentOS не получил IP адрес (или получил вида 169.254.x.x), в настройках нового сетевого адаптера (Player – Removable Devices — Network Adapter 2 – Settings) выберите Configure Adapters, в появившемся окне снимите выделение со всех адаптеров, кроме того, через который хостовой ПК имеет доступ к локальной сети. Если потребуются права администратора, проконсультируйтесь с преподавателем на предмет, какие учетные данные использовать.

На одном узле Asterisk (назовем его node1) требуется добавить клиента с номером в формате 4XXX, на втором (node2) в формате 5XXX (помните, клиенты описываются в файле pjsip.conf 3 секциями – Endpoint, Auth, AOR), контекст укажите тот, который создали в предыдущей работе для внутренних вызовов. Назначьте клиенту произвольный идентификатор CallerID (см. пример ниже, как назначается идентификатор first клиенту с номером 4001).

Пример секции Endpoint из /etc/asterisk/pjsip.conf для node1

[4001]
type=endpoint
transport=udp-transport
context=internal
disallow=all
allow=alaw,opus
callerid=first<4001>
auth=4001
aors=4001

ВАЖНО! Убедитесь, что на первом Asterisk отсутствуют настроенные номера формата 5XXX, а на втором 4XXX.

3.1. Краткие сведения о протоколе IAX

Среди поддерживаемых Asterisk протоколов, особое место занимает протокол IAX. Это протокол, созданный разработчиками Asterisk (Digium Inc.), расшифровывается как Inter-Asterisk eXchange protocol – протокол обмена между Asterisk. Хотя IAX и поддерживается некоторыми VoIP-телефонами, в первую очередь он предназначен для организации между узлами Asterisk каналов типа транк, в которых осуществляется одновременная передача данных нескольких вызовов. IAX первой версии в настоящее время не поддерживается ввиду наличия проблем в плане безопасности, а говоря IAX, обычно подразумевают вторую версию IAX2. Для работы протокола используется UDP-порт 4569, который предназначается не только для обмена сигнальной информацией о сеансе связи (аналогично SIP с SDP), но и для обмена голосовой информацией (аналогично RTP), таким образом, IAX берет на себя передачу и сигнальной и голосовой информации. Дополнительно следует сказать, что IAX – протокол, использующий бинарный формат для передачи данных, в отличие от протокола SIP, передающего сообщения в открытом текстовом формате, что позволяет IAX уменьшить объем передаваемых данных в случае использования его на транк-канале с одновременной передачей множества вызовов. Помимо этого, протокол использует агрегацию параллельных сеансов связи в рамках использования одного IAX-соединения между узлами Asterisk, так что в одном UDP-пакете может одновременно передаваться служебная и голосовая информация, принадлежащая нескольким вызовам.

Основные недостатки – сложная расширяемость (внедрение новых функций) и уязвимость старых реализаций к атакам типа DoS (версии Asterisk новее 2009 года менее подвержены этой уязвимости, поскольку есть возможность ограничить число подключений и вызовов с одного адреса, использовать дополнительно при соединении токены CallToken).

Процесс регистрации клиента IAX на сервере с настроенной аутентификацией с использованием алгоритма хэширования MD5 при поддержке CallToken (Рисунок 3.2).

Рис 3.2. Алгоритм хэширования MD5 при поддержке CallToken

Первым шанрм клиент отправляет серверу сообщение REGREQ с информационными элементами ‘username’ (содержит имя пользователя, под которым нужно зарегистрироваться), ‘refresh’ (период обновления регистрации в секундах) и пустым ‘CallToken’;

Сервер отвечает сообщением CALLTOKEN, содержащим элемент CallToken с идентификатором, который должен использовать клиент;

Клиент отправляет подтверждает получение токена сообщением ACK и посылает новое сообщение REGREQ (c элементами username, refresh и CallToken c полученным от сервера значением);

Сервер отвечает сообщением REGAUTH, содержащим элементы authentication methods, username и MD5 challenge (данные для вычисления хэша пароля);

Клиент посылает финальное сообщение REGREQ с элементами username, refresh, CallToken и MD5 challenge с результатом выполнения хэш-преобразования по алгоритму MD5 над указанным в конфигурации паролем пользователя IAX;

Сервер в случае, если полученный от клиента хэш совпадает с вычисленным от хранимого на сервере Asterisk пароля, отвечает клиенту сообщением REGACK с элементами username, date time (текущие дата/время), refresh, apparent address (содержит в себе адрес клиента);

Клиент отсылает финальное сообщение ACK, если полученные данные корректны.

Для IAX регистрация означает отслеживание клиента (его адреса и порта прослушивания), все вызовы, проходящие через канал IAX, проходят аутентификацию отдельно, впрочем, как и для SIP.

Ниже приведена диаграмма обмена сообщениями при совершении вызова: клиента 1 отправляет запрос NEW с параметрами вызова (номер, кодеки, пользователь IAX, дата/время) клиенту 2, клиент 2 отвечает сообщением, содержащим CallToken для этого вызова, клиент 1 повторно отправляет то же NEW с полученным CallToken. Клиент 2 высылает параметры для аутентификации (данные для MD5/RSA преобразования пароля) в AUTHREQ. Клиент в данном представлении может быть как Asterisk, так и конечным клиентом (Рисунок 3.3).

Рис 3.3. Диаграмма обмена сообщениями при совершении вызова

Происходит разговор клиента 2 с клиентом 1 (периодически посылаются сообщения LAGRQ (Request) LAGRP (Response) для определения задержки между узлами). Вызов завершается клиентом 1 (сообщение HANGUP) (Рисунок 3.4).

Рис 3.4. Диаграмма разговора клиента 2 с клиентом 1 (периодически посылаются сообщения LAGRQ (Request) LAGRP (Response)

3.2. Настройка транка IAX в Asterisk

Приведенная ниже конфигурация предполагает, что оба клиента осуществляют взаимную регистрацию (схема peer-to-peer для равноправных узлов), в других ситуациях регистрация может быть односторонней (схема клиент-сервер), как например при подключении корпоративной АТС к провайдерской.

Удалите сгенерированный по умолчанию файл конфигурации IAX:

sudo rm /etc/asterisk/iax.conf

Конфигурация протокола IAX для данной работы должна производиться в новом файле /etc/asterisk/iax.conf, добавьте следующие строки:

На node1:

[iaxuser1]
type=friend
qualify=yes
auth=md5
context=outcall
secret=secret1
host=dynamic
trunk=yes

На node2:

[iaxuser2]
type=friend
qualify=yes
auth=md5
context=outcall
secret=secret2
host=dynamic
trunk=yes

В приведенной конфигурации создается пользователь с именем, указанным в [] и паролем, заданным параметром secret, от имени которого удаленный узел сможет зарегистрироваться на данном Asterisk. Указанный тип friend дает пользователю право отправлять и принимать вызовы (существуют также типы user и peer, первый позволяет ТОЛЬКО принимать вызовы от удаленного узла, второй — ТОЛЬКО перенаправлять их на удаленный узел).

Параметр qualify включает опрос доступности удаленного узла (отправка сообщения POKE, ожидание в ответ PONG, отправка подтверждения получения ответа PONG сообщением ACK), параметр auth определяет тип аутентификации (по умолчанию происходит аутентификация с передачей учетных данных в открытом текстовом виде) md5 — передача хешированных данных. Параметр context определяет, в какой(ие) локальный(е) контекст(ы) должен быть передан пришедший из IAX-канала вызов.

Настройка взаимной регистрации IAX-серверов. Для этого добавьте в начало файла /etc/asterisk/iax.conf :

на node1:

[general]
autokill=yes
language=ru
disallow=all
allow=opus,alaw
register => iaxuser2:secret2@A.B.C.D

где A.B.C.D IP адрес node1 (IP_node1 далее)

На node2 :
[general]
autokill=yes
language=ru
disallow=all
allow=opus,alaw
register => iaxuser1:secret1@A.B.C.D

где A.B.C.D IP адрес node2 (IP_node2 далее)

Рассмотрим конфигурацию, проделанную на node1. Она предписывает узлу node1 зарегистрироваться на узле node2 с IP-адресом IP_node2 под пользователем iaxuser2 с паролем secret2. Параметр autokill=yes завершает неудачно установленные соединения по тайм-ауту.

Для принятия изменений перезагрузите службу Asterisk:

sudo systemctl restart asterisk

Проверка состояния регистрации данного узла на удаленном:

sudo asterisk -rx 'iax2 show registry'

Данная команда демонстрирует, как можно выполнять любые команды CLI Asterisk (и получать ответный вывод) напрямую из bash.

В полученном выводе State должно быть Registered (т.е. локальный Asterisk успешно зарегистрировался на удаленном). Состояние Rejected означает, что в регистрации было отказано, следует выяснить и устранить причину (Рисунок 3.5).

Рис 3.5. Появление ошибки отказа в регистрации

Состояние регистрации удаленного узла на данном:

sudo asterisk -rx 'iax2 show peers'

Status должен быть OK, а внизу указано, что есть 1 online (Рисунок 3.6).

Рис 3.6. Данные об успешной регистрации

Вся необходимая конфигурация IAX выполнена, осталось только указать обоим узлам, вызовы на какие номера нужно передавать через IAX-подключение к другому Asterisk.

Для обработки приходящих из IAX-транка вызовов, на обоих узлах нужно добавить указанный ранее в конфигурации IAX контекст outcall в файл /etc/asterisk/extensions.conf:

На node1:

[outcall]
exten => _4XXX,1,Dial(PJSIP/${EXTEN})

На node2:

[outcall]
exten => _5XXX,1,Dial(PJSIP/${EXTEN})

В файле /etc/asterisk/extensions.conf добавьте в начало контекста, отвечающего за обработку внутренних звонков экстеншн для обработки вызовов, уходящих в IAX-транк:

на узле node1:

exten => _5XXX,1,Dial(IAX2/iaxuser2:secret2@IP_node2/${EXTEN})

И аналогично для node2:

exten => _4XXX,1,Dial(IAX2/iaxuser1:secret1@IP_node1/${EXTEN})

Перезагрузите Asterisk:

sudo systemctl restart asterisk

Настройте клиенты PhonerLite на обеих сторонах для регистрации под соответствующим номером 4XXX или 5XXX. На обоих узлах Asterisk откройте командный интерфейс Asterisk (sudo asterisk -vvvr). Совершите звонок между клиентами. Убедитесь, что на обеих сторонах в консоли Asterisk отображаются служебные сообщения PJSIP, IAX об установлении соединения и информация о задействованных при обработке вызова экстеншенах. Если вышеуказанные условия выполнены и вызов успешно совершается, можно переходить ко 2 части работы.

Используемый на текущий момент способ хранения конфигурации Asterisk в текстовых файлах имеет ряд недостатков, основной из которых – необходимость при малейшем изменении конфигурации перезагружать соответствующий модуль или вообще Asterisk в целом. В высоконагруженных средах даже субсекундный простой, вызванный этим действием, абсолютно неприемлем, не говоря о невозможности сохранить текущие звонки и очередь после перезагрузки.

Проблему динамического изменения конфигурационных параметров Asterisk решает так называемая Realtime конфигурация, при которой конфигурационные параметры хранятся в таблицах базы данных (БД) вместо текстовых файлов. Изменение значения какого-либо параметра в таблице приводит к немедленному изменению в работе Asterisk (однако не всегда хранение параметров в БД означает realtime, можно сконфигурировать статическое хранение параметров, при котором после внесения изменений в базу потребуется перезагрузить Asterisk для принятия изменений).

3.3. Установка СУБД MariaDB

MariaDB представляет собой систему управления реляционными базами данных, является свободным ответвлением (распространяется по лицензии GNU GPL) от СУБД MySQL, при этом сохраняя обратную совместимость для API.

В официальном репозитории AppStream доступна версия MariaDB 10.3, чтобы получить новее, необходимо скачать исходный код и собрать пакет самостоятельно, либо добавить репозиторий разработчика в список репозиториев для yum и установить пакет стандартным способом, что и будет сделано далее.

Для добавления репозитория MariaDB версии 10.5 создайте файл /etc/yum.repos.d/MariaDB.repo и добавьте в него следующие строки:

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.5/centos8-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
enabled=1

Строка enabled отвечает за включение/отключение репозитория, изменяя значение в файле можно включать/отключать репозиторий при необходимости.

Установите вспомогательные пакеты и саму СУБД MariaDB (для предотвращения возникновения конфликта между репозиториями придется на время установки выключить стандартный репозиторий AppStream):

sudo yum install boost-program-options -y
sudo yum --disablerepo=AppStream install MariaDB-server MariaDB-client

Запуск службы СУБД (и установка автозапуска на старте):

sudo systemctl enable mariadb && sudo systemctl start mariadb

После установки рекомендуется осуществить первичную настройку параметров безопасности MariaDB. По умолчанию пароль пользователя СУБД root не задан (требуется просто нажать Enter), в следующих шагах, кроме шага, где потребуется задать новый пароль пользователю root (это пользователь СУБД, НЕ системный root), просто нажимать Enter, поскольку подходящий ответ здесь выбран по умолчанию:

sudo mysql_secure_installation

Проверка возможности локального подключения к СУБД (Пароль вводить от пользователя root СУБД, заданный на предыдущем шаге):mysql -u root -p (Рисунок 3.7).

Рис 3.7. Проверка возможности локального подключения к СУБД

Выход в интерпретатор bash производится следующей командой: q

3.4. Теоретические сведения о реляционных БД и SQL

Реляционная БД – набор данных, организованных в виде таблиц, включающих в себя столбцы (поля/атрибуты) и строки (записи/кортежи). Строка таблицы по сути – это набор данных, относящихся к хранимому в БД объекту. Таблицы БД, также называемые отношениями (relation), имеют, согласно реляционной модели, следующие свойства:

• столбцы имеют определенный порядок, заданный при создании таблицы, которая может не иметь строк, но обязана иметь хотя бы один столбец;

• таблица не может хранить две одинаковые строки;

• каждый столбец имеет уникальное в пределах таблицы имя и хранит значения одного типа (дата, строка, число и т.д.);

• на пересечении строки и столбца (в ячейке) таблицы может быть только атомарное значение (т.е. единичное, не группа значений).

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

Первичный ключ (Primary key)
Может быть логическим (естественным — на основе поля, содержащего реальные данные объекта) или суррогатным (искусственным – на базе дополнительного поля, например, уникального ID). Рекомендуется использовать суррогатные ключи, поскольку данные объекта могут измениться, что приведет к необходимости удалять существующую запись и вносить новую, т.к. первичные ключи изменять нельзя.

Внешние ключи (Foreign key) позволяют связать строки и отдельные элементы разных таблиц.

Аспекты реляционных БД.

• SQL – (язык структурированных запросов) основной интерфейс для работы с реляционными БД, используется для добавления, обновления и удаления строк данных, а также управления работой БД в целом;

• целостность данных (через определение первичных и внешних ключей, а также ограничений (атрибутов столбца, см. в справочнике запросов SQL));

• транзакция – последовательность операций на языке SQL, представляющая собой единую логическую задачу. Она должна быть выполнена целиком, либо не должен быть выполнен ни один из ее компонентов, независимо от других транзакций.

Требования ACID к транзакциям

• атомарность – транзакция может выполниться только целиком, если не выполнена любая из частей — вся транзакция полностью отменяется;

• единообразие – все данные, записываемые в БД через транзакции, должны соответствовать всем правилам и ограничениям БД;

• изолированность – обеспечения согласованности и гарантия независимости каждой транзакции;

• надежность – все внесенные транзакцией изменения в БД на момент успешного завершения этой транзакции считаются постоянными.

Далее приведен краткий список некоторых команд SQL.

3.5. Краткий справочник запросов SQL

Отобразить все созданные БД;

Создать базу; таблицу с описанием столбцов (имя, тип данных, указание атрибутов (опционально)):

CREATE DATABASE databasename;

CREATE TABLE table_name (

    column1 datatype attribute,

    column2 datatype,

    column3 datatype,
         ...
);

Примеры атрибутов:

PRIMARY KEY – указание столбца в качестве первичного ключа (NOT NULL присваивается автоматически);

UNIQUE – указание, что столбец должен хранить только уникальные значения;

NULL и NOT NULL – указание, может ли столбец хранить значение NULL;

AUTO_INCREMENT – значение столбца столбца будет автоматически увеличиваться при добавлении новой строки.

Записать в таблицу новую строку:

INSERT INTO table_name (column1, column2) VALUES (value1,value2);

Обновить существующую(ие) строку(и), которые подпадают под условие(я):

UPDATE table_name SET column1 = value1, column2 = value2, … WHERE condition1 AND condition2;

Выбрать все строки из таблицы:

SELECT * FROM table_name;

Удалить базу, таблицу, строку из таблицы:

DROP DATABASE databasename;

DROP TABLE table_name;

DELETE FROM table_name WHERE condition;

Далее приведены команды для создания БД и ее конфигурации на языке SQL, который традиционно используется для управления реляционными БД. Обратите внимание, запрос SQL ВСЕГДА заканчивается символом «;». Команды SQL выполняются в интерфейсе СУБД (вход mysql -u root -p ).

Создайте БД с именем asteriskdb с символьной кодировкой UTF8 по умолчанию:

CREATE DATABASE asteriskdb DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

На следующем шаге создайте пользователя СУБД, под которым Asterisk будет подключаться к СУБД, имя и пароль выберите самостоятельно.

CREATE USER ‘имя_пользователя’@’localhost’ IDENTIFIED BY ‘пароль’;

Выдайте права полного доступа на базу asteriskdb созданному на предыдущем шаге пользователю, обновите действующие права.

GRANT ALL PRIVILEGES ON asteriskdb.* TO ‘имя_пользователя’@’localhost’;

FLUSH PRIVILEGES;

Выберите базу для работы (по умолчанию после входа в СУБД база не выбрана):

USE asteriskdb;

Создайте в выбранной базе таблицы, необходимые Asterisk для хранения своих данных с помощью готовых SQL-скриптов.

source ~/asterisk-16.12.0/contrib/realtime/mysql/mysql_config.sql;

Если СУБД возвращает ошибку, убедитесь, что путь до файла существует, проверьте, что версия установленного Asterisk (16.12.0 в примере) правильная, замените ~ на /home/USERNAME где USERNAME — имя вашего пользователя CentOS.

3.6. Сборка и установка коннектора ODBC

Коннектор Open Database Connectivity предоставляет API, с помощью которого сторонние сервисы (Asterisk в данном случае) могут получить доступ к БД.

Для работы коннектора требуются пакеты unixODBC unixODBC-devel, они были установлены во время выполнения предыдущей части работы среди зависимостей Asterisk.

Укажите прокси для Git:

git config --global http.proxy http://login:pass@proxy:port

Клонировать репозиторий с исходным кодом в текущую директорию и перейти в него:

cd ~
git clone https://github.com/MariaDB/mariadb-connector-odbc.git
cd mariadb-connector-odbc

Выберите версию кода 3.1.5:

Инициализация и обновление вложенных репозиториев:

git submodule init && git submodule update

Конфигурация параметров компиляции:

cmake -G "Unix Makefiles" --DCMAKE_BUILD_TYPE=RelWithDebInfo --DCONC_WITH_UNIT_TESTS=Off -DWITH_OPENSSL=true --DCMAKE_INSTALL_PREFIX=/usr

Конец вывода в терминал в случае успешного завершения сборки выглядит так (Рисунок 3.8).

Рис 3.8. Успешное завершение собрки

Сборка и установка:

В конец файла /etc/odbcinst.ini добавьте описание нового драйвера подключения к СУБД (если уже существует с именем [MariaDB], приведите к представленному ниже виду):

[MariaDB]

Description=ODBC for MariaDB

Driver=/usr/lib64/libmaodbc.so

Setup=/usr/lib64/libodbcmyS.so

UsageCount=1

В файл /etc/odbc.ini добавьте параметры подключения к базе:

[Asterisk-odbc]

Description=MariaDB connection to 'asteriskdb' database

driver=MariaDB

server=localhost

database=asteriskdb

Port=3306

Socket=/var/lib/mysql/mysql.sock

option=3

Charset=utf8

Проверка работоспособности коннектора (подключение к базе asteriskdb от имени созданного для Asterisk пользователя СУБД) (Рисунок 3.9).

isql -v Asterisk-odbc имя_пользователя пароль

Рис 3.9. Проверка работоспособности коннектора

В начало (перед строкой [asterisk]) файла /etc/asterisk/res_odbc.conf добавьте конфигурацию для ODBC коннектора:

[asteriskdb]

enabled => yes

dsn => Asterisk-odbc

username => имя_пользователя

password => пароль

pre-connect => yes

Перезапустите службу Asterisk:

sudo systemctl restart asterisk

Проверка состояния подключения Asterisk к БД (Рисунок 3.10):

sudo asterisk -rx 'odbc show'

Рис 3.10. Проверка состояния подключения Asterisk к БД

3.7. Перенос конфигурации PJSIP в БД.

В начало файла /etc/asterisk/sorcery.conf вставьте следующие строки для перевода PJSIP в режим конфигурации Realtime:

[res_pjsip]

endpoint=realtime,ps_endpoints

auth=realtime,ps_auths

aor=realtime,ps_aors

domain_alias=realtime,ps_domain_aliases

contact=realtime,ps_contacts

[res_pjsip_endpoint_identifier_ip]

identify=realtime,ps_endpoint_id_ips

В файл /etc/asterisk/extconfig.conf добавьте после строки [settings] сведения, где Asterisk должен искать конфигурацию для PJSIP:

ps_endpoints => odbc,asteriskdb

ps_auths => odbc,asteriskdb

ps_aors => odbc,asteriskdb

ps_domain_aliases => odbc,asteriskdb

ps_endpoint_id_ips => odbc,asteriskdb

ps_contacts => odbc,asteriskdb

Пример. Для вставки новых строк в таблицу используется запрос INSERT, параметр INTO указывает в какую таблицу вставить (указывается полный путь в формате БД.Таблица или просто имя таблицы при условии, что БД была выбрана ранее через USE), далее в скобках следует перечисление имен столбцов через запятую, в которые нужно вставить данные (это не обязательно все столбцы таблицы), после VALUES в скобках указываются в соответствующем перечисленным в первой скобке именам столбцов порядке значения.

Далее в качестве примера приведен процесс создания клиента PJSIP с номером 101, путем заполнения значениями трех ключевых таблиц:

-ps_aors

INSERT INTO asteriskdb.ps_aors (id, max_contacts) VALUES (101, 1);

— ps_auths

INSERT INTO asteriskdb.ps_auths (id, auth_type, password, username) VALUES (101, 'userpass', 'secret', 101);

— ps_endpoints

INSERT INTO asteriskdb.ps_endpoints (id, transport, aors, auth, callerid, context, disallow, allow, direct_media) VALUES (101, 'udp-transport', '101', '101', 'first<101>', 'internal', 'all', 'opus,alaw', 'no').

Это аналог следующей конфигурации из файла pjsip.conf:

[101]
type=endpoint
transport=udp-transport
context=internal
disallow=all
allow=alaw,opus
callerid=first<101>
auth=101
aors=101
direct_media=no

[101]
type=auth
auth_type=userpass
password=secret
username=101

[101]
type=aor
max_contacts=1

Задание. Войдите в СУБД и аналогично примеру создайте записи в таблицах ps_aors ps_auths ps_endpoints БД asteriskdb, описывающие конфигурацию для всех описанных в файле pjsip.conf клиентов. В файле /etc/asterisk/pjsip.conf удалите все секции, принадлежащие клиентам, оставьте ТОЛЬКО секцию [udp-transport] и все параметры в ней.
Проверьте, что SIP-клиент может зарегистрироваться на Asterisk после перезапуска службы.

3.8. Установка веб-интерфейса phpMyAdmin для MariaDB

Для удобства управления MariaDB можно использовать веб-интерфейс для MySQL (MariaDB) – phpMyAdmin, представляющий собой готовое веб-приложение, написанное на языке PHP. Может быть работать на базе LAMP (Linux, Apache, MariaDB, PHP) или LEMP (Linux, NGINX, MariaDB, PHP) стека. В рамках данной работы примем за основу LEMP. Поскольку MariaDB уже присутствует в системе, остаётся установка веб-сервера NGINX и интерпретатора PHP с некоторыми дополнительными пакетами.

Системные репозитории CentOS содержат модифицированную версию NGINX в плане расположения и содержания конфигурационных файлов. Для использования стандартной конфигурации можно установить NGINX из официального репозитория или собрать из исходного кода. Воспользуемся первым из указанных вариантов.

Создайте файл /etc/yum.repos.d/nginx.repo и поместите в него следующие строки:

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

Далее необходимо установить веб-сервер NGINX:

Основная конфигурация NGINX содержится в файле /etc/nginx/nginx.conf, его структура представлена ниже:

global options

events {

.......

}

http{

.......

include /etc/nginx/conf.d/*.conf;

}

Сначала идут глобальные параметры (global options), которые задают основные параметры работы NGINX, например, от какого пользователя будет запущен процесс, а также количество одновременно запущенных процессов. В секции events описывается, как NGINX должен реагировать на входящие подключения, ниже расположена секция http, объединяющая все параметры, связанные с работой протокола HTTP. Последняя директива говорит, что дополнительно в конфигурацию секции http включаются все файлы с расширением .conf из директории /etc/nginx/conf.d, эти файлы могут как содержать дополнительные параметры http, так и секции server c вложенными секциями location. По умолчанию существует файл /etc/nginx/conf.d/default.conf который ответственен за настройки сайта по умолчанию, отображение проверочной страницы NGINX после установки, его структура представлена ниже.

server {

.......

location ...{

.......

}

}

Обычно в секции http находится одна или несколько секций server, каждая секция отвечает за отдельный домен (доменное имя сайта), в секции server размещаются секции location, каждая из которых отвечает за обработку запроса с определенным URL.

Для оптимизации производительности отредактируйте и добавьте недостающие параметры в основной файл конфигурации NGINX /etc/nginx/nginx.conf:

1. Глобальные параметры. Исправьте/добавьте под параметром user:

worker_processes auto;

worker_cpu_affinity auto;

Эти параметры оптимизируют производительность рабочих процессов NGINX и их количество под число доступных ядер CPU.

2. Настройка обработки соединений, добавьте следующие параметры внутри, блока events :

multi_accept on;

use epoll;

Параметр use epoll – устанавливает оптимальный метод обработки соединений для Linux. Когда multi_accept выключен, рабочий процесс NGINX за один раз будет принимать только одно новое соединение. В противном случае рабочий процесс за один раз будет принимать сразу все новые соединения.

3. Параметры HTTP. Добавьте/скорректируйте следующие параметры:

access_log     off;
server_tokens  off;
tcp_nopush      on;
tcp_nodelay     on;
reset_timedout_connection    on;
gzip  on;
gzip_static on;
gzip_min_length     1024;
gzip_comp_level 3;

Для ускорения работы и снижения нагрузки на диск в текущей установке можно отключить ведение лога доступа к веб-серверу через директиву access_log. Директива server_tokens при выставлении параметра в off предписывает NGINX не отсылать информацию о своей версии клиентам. Это может быть полезно, если вы хотите усложнить эксплуатацию ошибок и уязвимостей конкретной версии NGINX. Директивы tcp отвечают за ускорение работы транспортного протокола TCP, keepalive_timeout и reset_timedout_connection отвечают за таймер keepalive для сетевого соединения (время, в течение которого соединение остается открытым с момента последнего ответа клиента на сообщение keepalive) и разрыв соединений с истекшим таймером. Директивы gzip включают сжатие передаваемых данных, предварительное сжатие статических файлов и минимальный размер файла, подлежащего сжатию.

Сохраните файл конфигурации и проверьте его корректность (Рисунок 3.11):

Рис 3.11. Сохранение файла конфигурации и проверка его корректности

Если на предыдущем шаге проверка пройдена, запустите службу NGINX с автозапуском на старте ОС:

sudo systemctl enable nginx && sudo systemctl start nginx

Откройте в фаерволе 80 порт для доступа к веб-интерфейсу.

sudo firewall-cmd —add-service=http —permanent

sudo firewall-cmd —reload

Проверьте, что по URL http://IP_CentOS в браузере отображается тестовая страница Nginx.
Для работы последних версий phpMyAdmin требуется веб-сервер с поддержкой PHP 7.1 или новее; пакет PHP-FPM для NGINX, отвечающий за обработку php можно установить из репозитория Remi:

sudo yum install http://rpms.remirepo.net/enterprise/remi-release-8.rpm

Проверьте, что репозиторий Remi добавлен в список разрешенных:

sudo yum repolist

Включение модуля репозитория PHP версии 7.4 и установка PHP-FPM для Nginx и дополнительных пакетов PHP для phpMyAdmin:

sudo yum module enable php:remi-7.4 -y

sudo yum install php-fpm php-pear php-gettext php-bcmath php-zip php-mysqlnd php-gd php-pdo php-json php-xml php-opcache php-mbstring php-soap php-curl

В файле /etc/php-fpm.d/www.conf измените параметры пользователя user и group, под которым будет работать php-fpm с apache на nginx и проверьте, что взаимодействие между php-fpm и сторонними приложениями осуществляется через UNIX сокет:

listen = /run/php-fpm/www.sock;

user = nginx

group = nginx

В файле /etc/php.ini найдите, раскомментируйте и отредактируйте следующие параметры (отключение автоисправления URL):

cgi.fix_pathinfo=0

Выдайте права php-fpm, на директорию для хранения данных сессий.

sudo chown -R nginx.nginx /var/lib/php/session/

Разрешите автозагрузку на старте и запустите службу php-fpm:

sudo systemctl enable php-fpm && sudo systemctl start php-fpm

3.9. Установка phpMyAdmin

Архив с файлами phpMyAdmin находится в директории с софтом для лабораторной работы. Перенесите его с помощью WinSCP в домашнюю директорию своего пользователя CentOS и распакуйте:

cd ~

tar -xzf phpMyAdmin-*

sudo mkdir /var/www/phpmyadmin

sudo cp -r ./phpMyAdmin-5.0.2-english/* /var/www/phpmyadmin

sudo mkdir /var/www/phpmyadmin/tmp

sudo chown -R nginx.nginx /var/www/phpmyadmin/tmp

В файле /etc/nginx/conf.d/default.conf найдите строку #error_page 404 и приведите конфигурацию, находящуюся ДО этой строки к следующему виду:

server {

    listen       80;

    server_name   _;

    root /var/www/phpmyadmin;

    charset utf-8;

    index  index.php index.html index.htm;

    location / {

        try_files $uri $uri/ /index.php?$args;

    }

    location ~ .php$ {

        try_files  $uri =404;

        fastcgi_pass unix:/run/php-fpm/www.sock;

        fastcgi_index index.php;

	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        fastcgi_param QUERY_STRING  $query_string;

        include fastcgi_params;
    }

/ – корень сайта, перехватывает все запросы к домену, если не найдено более точное совпадение.

~ .php$ – перехватывает запросы к файлам с расширением php. То есть если в запросе указан файл .php, то запрос отправляется на обработку к php-fpm.

Сгенерируйте произвольную последовательность, чтобы использовать в качестве криптографического ключа для алгоритма Blowfish, используемого в phpMyAdmin.

head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32; echo »

Скопируйте полученную последовательность символов и вставьте ее в конфигурацию phpMyAdmin, находящуюся в файле /var/www/phpmyadmin/config.inc.php

<?php

$cfg['blowfish_secret'] = 'generated_symbols';

?>`

Перезапустите службы для принятия изменений конфигурации:

sudo systemctl restart php-fpm

sudo systemctl restart nginx

3.10. Работа в интерфейсе phpMyAdmin

Войдите в веб-интерфейс phpMyAdmin, используя URL http://IP_CentOS в браузере. В качестве учетных данных для входа используйте пользователя root СУБД.

Для сохранения конфигурации phpMyAdmin требуется отдельная БД, чтобы создать ее, найдите внизу страницы соответствующее сообщение (приведено ниже), нажмите на ссылку Find out why и на следующей странице нажмите Create (Рисунок 3.12).

Рис 3.12. Сохранение конфигурации phpMyAdmin

Выберите слева базу asteriskdb, в ней таблицу ps_endpoints. Нажмите на… Создать представление (Create view) (Рисунок 3.13).

Рис 3.13. Создание представления

В появившемся окне укажите название ps_endpoints_view, в названия столбцов вставьте укажите id, callerid, aors, auth, context, transport, disallow, allow, direct_media (Рисунок 3.14).

Рис 3.14. Настройки параметров представления

Ниже вставьте SELECT id, callerid, aors, auth, context, transport, disallow, allow, direct_media FROM `ps_endpoints` Нажмите Format, для форматирования кода (так выглядит эталонная запись запросов на SQL).

Нажмите вперёд, после этого слева, в новом разделе для asteriskdb — Представления (Views) выберите представление ps_endpoints_view. Убедитесь, что в таблице отображается запись со всеми настроенными параметрами из раздела endpoints.

Представление (View) делает возможным отобразить выбранные данные из таблиц БД в виде настраиваемой таблицы (в отображении можно выбрать конкретные столбцы, переименовать их, соединить несколько). Данное представление ps_endpoints_view было создано для удобства отображения нужных параметров, поскольку если посмотреть, какие столбцы содержит таблица ps_endpoints, можно убедиться, что их число достаточно велико, причем большинство пустует ввиду отсутствия нужды задавать те параметры, которые эти столбцы хранят, а нужные столбцы разбросаны по всей ширине таблицы, что затрудняет читабельность. Для оставшихся таблиц ps_aors и ps_auths можно не создавать представление как можете самостоятельно убедиться, число столбцов в них невелико.

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

Для ускорения поиска данных и их сортировки, в таблице используются индексы, которые назначаются из числа столбцов таблицы (отображены слева в древовидной структуре таблицы). Индексы могут быть уникальными (все соответствующие значения столбцов во всех строках должны быть различны), составными (содержать более одного столбца – в этом случае уникальность проверяется по составной строке из всех указанных столбцов индекса), кластерными (хранятся данные записей таблицы целиком) и некластерными (хранятся только ссылки на записи таблицы). Каждая таблица должна иметь Первичный ключ, который обязан быть уникальным (среди всех значений данного столбца) и единственным (в одной таблице), первичные ключи таблиц InnoDB являются кластерными индексами. Первичный ключ может быть назначен вручную (в Структуре таблицы в phpMyAdmin будет помечен символом золотого ключа), или создан автоматически (скрыт в таком случае).

3.11. Перенос конфигурации плана набора (extensions) в БД

В файле /etc/asterisk/extconfig.conf добавьте в секцию [settings] строку:

extensions => odbc,asteriskdb

В /etc/asterisk/extensions.conf в начало каждого контекста добавьте строку:

switch => Realtime/ИМЯ_КОНТЕКСТА@extensions

Пример переноса контекста outcall на node1 в БД:

В файле /etc/asterisk/extensions.conf добавить в начало переносимого контекста строку:

[outcall]

switch => Realtime/outcall@extensions

Добавление данных об экстеншенах в таблицу extensions:

INSERT INTO extensions VALUES (1, ‘outcall’, ‘_1XXX’, ‘1’, ‘DIAL’, ‘PJSIP/${EXTEN}’);

Не забудьте выбрать базу asteriskdb, в интерфейсе СУБД.

Перезапустите Asterisk, проверьте работоспособность (вызовы совершаются успешно).

Задание. Аналогично приведенному примеру (используя SQL-запросы) или через графическую форму во вкладке Вставить (Insert) в phpMyAdmin, перенесите всю имеющуюся конфигурацию плана набора в таблицу extensions, удалите все записи об экстеншенах из файла extensions.conf (кроме параметров switch).

3.12. Перенос конфигурации IAX в БД

В файл /etc/asterisk/extconfig.conf добавьте строку

iaxfriends => odbc,asteriskdb

Пример.

В файле /etc/asterisk/iax.conf

добавьте в начало секции [general] строку:

rtcachefriends=yes;

Перенести конфигурацию пользователя IAX в БД:

INSERT INTO `iaxfriends` (`id`, `name`, `type`,  `secret`, `context`, `host`, `trunk`, `auth`, `qualify`) VALUES ('1', 'iaxuserX', 'friend', 'secretX', 'outcall', 'dynamic', 'yes', 'md5', 'yes');

Удалить всю секцию пользователя из iax.conf;

Перезапустить Asterisk, проверить работоспособность IAX.

Задание. Аналогично приведенному примеру (используя SQL-запросы) или через графическую форму во вкладке Вставить в phpMyAdmin, перенесите всю имеющуюся конфигурацию IAX в таблицу iaxfriends. Проверьте работоспособность после переноса конфигурации в Realtime.

Раздел 4. Настройка безопасного удаленного доступа к серверу Asterisk. Защита передаваемых данных

В данной работе будет проведена комплексная конфигурация безопасности доступа к серверу, сервисов Asterisk Nginx и т.д.

4.1. Защита загрузчика ОС Linux

В современных дистрибутивах Linux для загрузки ОС используется загрузчик GRUB2 (GRand Unified Bootloader 2 версии). По умолчанию загрузчик обычно не защищен, т.е. можно изменить параметры загрузки ядра при наличии локального доступа (или удалённой KVM консоли) к серверу/ВМ во время загрузки системы и, например, получить доступ с root правами.

Продемонстрируем способ получения такого доступа, не зная ни имен пользователей, ни паролей. Запустите ВМ с CentOS, когда появится меню загрузчика нажмите e. Отобразятся параметры загрузочного устройства, загрузки и инициализации ядра и тд. Найдите строку с параметрами загрузки ядра (строка начинается с linux16 или linuxefi), замените параметр ro на rw для монтирования файловой системы в режим чтения-записи, добавьте в самый конец параметров init=/bin/sh и нажмите Ctrl+X для загрузки системы с этими параметрами. CentOS загрузится в терминал от имени пользователя root. Теперь Вы можете совершать любые действия в системе, добавить или просмотреть пользователей в системе (cat /etc/passwd), сменить пароль любому пользователю (passwd username), внести любое изменение в работу ОС. ЕСЛИ в CentOS БЫЛ включен SELinux в активном режиме (это не наш случай, сведения приведены просто для справки), выполните команду touch /.autorelabel для создания в корне файловой системы пустого скрытого файла, который является маркером SELinux, что при загрузке необходимо обновить метки всех файлов (после загрузки проверьте, что этот файл удалился, иначе удалите вручную).

Для продолжения загрузки ОС введите exec /sbin/init, для перезагрузки exec /sbin/reboot.

Пароль на GRUB устанавливается следующей командой:

grub2-setpassword

Теперь для доступа к параметрам загрузки потребуется авторизоваться под именем пользователя root с заданным паролем (это не системный root, просто имя совпадает).

4.2. Смена порта SSH

Использовать SSH на стандартном 22 порту, особенно при наличии доступа к серверу из сети Интернет, не рекомендуется ввиду частого проведения атак злоумышленниками по этому порту с целью получить доступ к ОС и использовать сервер в своих целях (часто незаметно для владельца). С целью усложнения проведения атак также рекомендуется запретить доступ к системе по SSH пользователю root, не использовать стандартные имена пользователей вроде admin [10].

Для смены порта на другой, к примеру, 30000, и установления запрета на вход пользователя root, требуется отредактировать в файле /etc/ssh/sshd_config следующие параметры:

Port 30000

PermitRootLogin no

Далее для успешного прохождения сетевого трафика нужно разрешить его в firewalld:

sudo firewall-cmd --add-port=30000/tcp --permanent

Перезапустите демон sshd и перечитайте правила firewalld без разрыва текущего соединения:

sudo systemctl restart sshd && sudo firewall-cmd --reload

Существующее соединение SSH не будет разорвано, но все новые соединения будут приниматься только по новому порту. Проверьте возможность подключения, в PuTTY в поле Port смените 22 на 30000.

Если SSH сервер успешно принимает подключения, закройте 22 порт в firewalld:

sudo firewall-cmd --permanent --remove-service=ssh

Не забудьте, что теперь подключение клиента SCP также осуществляется на новый порт.

4.3. Защита сервера с помощью fail2ban

Fail2ban – утилита, отслеживающая в логах разных служб определенные события и при происшествии их определенного количества за определенное время выполняющая указанные в конфигурации действия. Используется для защиты от подбора учетных данных (атак типа bruteforce) и атак типа DoS. может отслеживать неудачные попытки подключения на указанных в конфигурации сервисах и портах и соответственно временно создавать блокирующее правило для отбрасывания трафика с IP адреса.

Установите пакет:

sudo yum install fail2ban-firewalld

Базовая настройка параметров блокирования содержатся в файле /etc/fail2ban/jail.d/00-firewalld.conf:

[DEFAULT]
maxretry = 4
findtime = 10m
bantime = 1m
banaction= firewallcmd-ipset[actiontype=<multiport>],

где:

• maxretry – количество событий, которые могут произойти до срабатывания триггера (наложение бана);
• findtime – время в секундах, в течение которого подсчитывается количество событий;
• bantime – время, на которое будет заблокирован IP-адрес;
• banaction – действия, которое будет выполняться в случае срабатывания триггера.

Для каждого сервиса обычно создается отдельная конфигурация в отдельном файле:

/etc/fail2ban/jail.d/ssh.conf

[ssh]
enabled = true
port = 30000
filter = sshd
logpath = /var/log/secure
/etc/fail2ban/jail.d/asterisk.conf

[asterisk]
enabled = true
port = 5060,5061
protocol = all
filter = asterisk
action = firewallcmd-ipset[name=asterisk, port="5060,5061", protocol=all]
logpath = /var/log/asterisk/messages
/etc/fail2ban/jail.d/phpmyadmin.conf

[phpmyadmin]
enabled = true
filter = apache-myadmin
port = http,https
action = firewallcmd-ipset[name=phpmyadmin, port="http,https", protocol=tcp]
logpath = /var/log/nginx/error.log

[nginx-http-auth]

enabled = true
filter = nginx-http-auth
action = firewallcmd-ipset[name=nginx, port="http,https", protocol=tcp]
logpath = /var/log/nginx/error.log

Просмотр настроенных правил:

и заблокированных IP:

fail2ban-client status ssh

Пример. Удалить из списка заблокированных клиентов для сервиса asterisk все адреса из подсети 192.168.0.0/16:

sudo fail2ban-client set asterisk unbanip 192.168.*

4.4. Настройка аутентификации SSH по ключу

Доступ к системе с парольной защитой хорош ввиду простоты и отсутствия особых требований к конфигурации клиента и сервера, однако он также может представлять серьезную уязвимость в системе безопасности перед атаками злоумышленников при использовании ненадежных паролей. Всегда есть шанс, что кто-то будет использовать простые короткие пароли, которые несложно подобрать методом простого перебора при достаточной вычислительной мощности. Кроме того, пароль можно забыть, его могут подсмотреть и тд. Для решения этой проблемы используется аутентификация с использованием пары ключей шифрования. Для обеспечения защиты данных, обычно шифруют защищаемые данные открытым, расшифровывают приватным ключом, в алгоритмах цифровой подписи наоборот – подписывают данные приватным, публичным расшифровывают (проверяют подпись). Исходя из вышеизложенного, повторим, что ключи в асимметричных алгоритмах шифрования используются парами:

• открытый (публичный) ключ;
• закрытый (приватный) ключ [11].

Протокол SSH использует асимметричные алгоритмы шифрования, в которых, как уже было сказано, данные/соединение передачи данных шифруется одним ключом, расшифровывается другим. открытый ключ помещается на сервер SSH, а закрытый хранится у пользователя, указывается в конфигурации клиента SSH. Как только открытый ключ будет помещен в список доверенных ключей и, если разрешено использование аутентификации по ключу в конфигурации SSH сервера, вы сможете подключиться по SSH к серверу, используя приватный ключ для аутентификации, без необходимости вводить пароль для входа в систему. Хотя пара ключей может быть сгенерирована без дополнительной защиты, лучшая рекомендация с точки зрения безопасности — использовать ключи с фразой-паролем.

Традиционно для SSH используется криптоалгоритм RSA, но в последнее время в OpenSSH по умолчанию используются криптоалгоритмы, основанные на вычислениях по эллиптических кривым Монтгомери – Curve25519 (обмен ключами) и Эдвардса – EdDSA (генерация ключей). Наиболее распространенный вариант реализации EdDSA, Ed25519 обеспечивает лучшую безопасность по сравнению с RSA при меньшей длине ключа, что также означает и большую производительность при генерации пар ключей. Из недостатков стоит отметить, что, к сожалению, нельзя использовать открытый ключ Ed25519 для шифрования/подписи файлов, как в случае с открытым ключом RSA.

Далее Вам предлагается настроить в рамках работы аутентификацию SSH по ключу без парольной фразы. Сгенерируйте новый ключ командой (после ключа С подставьте произвольный комментарий, обычно он поясняет принадлежность ключа):

ssh-keygen -t ed25519 -C "pbx server"

Не заполняйте (оставьте значения по умолчанию) запрашиваемые параметры, место сохранения и парольную фразу (passphrase) во время процесса генерации пары ключей.

Убедитесь, что оба ключа сгенерированы (есть файлы id_ed25519 id_ed25519.pub в директории ~/.ssh)

Просмотр приватного ключа:

Просмотр публичного ключа:

cat ~/.ssh/id_ed25519.pub

Для разрешения использовать данную пару ключей для аутентификации необходимо создать файл ~/.ssh/authorized_keys и скопировать в него данные публичного ключа (вывод команды cat ~/.ssh/id_ed25519.pub).

Для работоспособности аутентификации SSH по ключу требуется также обеспечить корректные права доступа на директорию и файл с публичными ключами:

chmod 700 ~/.ssh

chmod 700 ~/.ssh/authorized_keys

Перезапустите демон OpenSSH:

sudo systemctl restart sshd

Для следующего шага потребуется перенести файл приватного ключа на компьютер, с которого осуществляются подключения. Можно просто скопировать все содержимое из вывода файла приватного ключа в новый файл, но в рамках данной работы будет полезно показать, как можно передавать файлы по сети. Чтобы сделать это, воспользуемся протоколом SCP и непосредственно программой WinSCP в качестве клиента.

Загрузите на свой компьютер файл id_ed25519 из .ssh/. Формат файлов ключей, используемый OpenSSH, не подходит для PuTTY, поэтому сначала полученный приватный ключ придется сконвертировать в используемый PuTTY формат ppk. Запустите программу PuTTYgen, выберите Conversions – Import key, укажите файл с приватным ключом, нажмите Save private key, согласитесь на сохранение приватного ключа без парольной фразы, укажите размещение файла с приватным ключом в формате ppk, который будет использовать PuTTy для аутентификации (Рисунок 4.1).

Рис 4.1. Размещение файла с приватным ключом в формате ppk

Откройте новое окно PuTTY, слева в пункте Connections разверните подпункт SSH, в нем выберите подпункт Auth и в поле Private key for authentication укажите путь к сконвертированному файлу приватного ключа в формате ppk (Рисунок 4.2).

*Рис 4.2. Указание пути к сконвертированному файлу приватного ключа в формате ppk. *

Перейдите в пункт Session, введите IP адрес CentOS, укажите протокол SSH, в поле Saved Sessions укажите имя, под которым хотите сохранить это подключение, нажмите Save (Рисунок 4.3).

Рис 4.3. Настройка параметров подключения

Теперь вы можете подключаться к серверам, используя заранее настроенные параметры сессии, двойным щелчком мыши по соответствующей сохраненной сессии. Попробуйте подключиться к CentOS, если все было сделано правильно, после ввода имени пользователя появится сообщение об аутентификации с публичным ключом “комментарий вашего ключа” и вы получите доступ к системе без запроса пароля. Этот же файл закрытого ключа можно использовать и в WinSCP.

4.5. Инфраструктура открытого ключа

Приведенный выше пример использования асимметричного шифрования для защиты соединения подходит для ограниченного доступа к серверу, когды мы сами генерируем пару ключей и уверены в их идентичности. Однако такой принцип совершенно не подходит для защиты соединения к публичным сервисам, например, для защиты HTTP (использование аналогичной схемы для HTTPS приведет к необходимости заранее сохранять ключ к КАЖДОМУ сайту, который пользователь планирует посетить). Кроме того, необходимо при подключении однозначно удостовериться, что удаленная сторона является той, кем представляется (то есть дополнительно к ключу необходимо получать достоверную информацию о его владельце), что ключ не был отозван вследствие компрометации приватной части или других причин. Для решения данной проблемы используется инфраструктура открытого ключа (PKI), использование которой подразумевает создание специальных электронных документов — сертификатов, выдаваемых доверенными удостоверяющими центрами субъектам, подлинность которых необходимо удостоверить (обычно используется доменное имя, но можно использовать IP адрес или даже собственное имя для выпуска личного сертификата). Удостоверяющие центры, с помощью которых можно как выпустить сертификат, так и при необходимости проверить подлинность выпущенного ранее, являются доверенной третьей стороной.

Сертификат – это подписанный электронной подписью документ, содержащий публичный ключ, сведения о том, кому, когда и кем выдан данный сертификат, некоторую дополнительную информацию о владельце, а также срок действия сертификата, цели его использования, алгоритм подписи и тд. Поскольку от сертификата в первую очередь требуется обеспечение однозначной идентификации удаленной стороны при соединении/передаче данных, т.е. определении, что удаленная сторона действительно является тем, за кого себя выдает, необходимо, чтобы на клиентской стороне был или “правильный” сертификат, с которым будет сравниваться предложенный сервером сертификат при установлении соединения, что опять же ведет к необходимости хранить всевозможные сертификаты в локальном хранилище, либо должен использоваться способ проверить подлинность сертификата, не имея его “эталона”. Такой способ заключается в использовании локального хранилища сертификатов в ОС для хранения сертификатов доверенных удостоверяющих центров сертификации. Получив при соединении от удаленной стороны сертификат и определив на основе содержащейся в нем информации удостоверяющий центр (чаще всего корневые центры сертификации не выдают сертификаты, а удостоверяют другие центры, образуя цепочку от корневого центра до непосредственно центра, выпустившего данный сертификат), можно проверить по цепочке CA сертификат и соответственно доверять ему или нет, при условии того, что Вы доверяете или не доверяете CA в цепочке.

Назначение центра сертификации (СА) – выпуск различных сертификатов, подтверждающих принадлежность открытого ключа владельцу, указанному в сертификате, а также публикация списка отозванных сертификатов. Существуют корневые и промежуточные удостоверяющие центры сертификации. Корневые центры, как правило, не подписывают сертификаты клиентов (кроме, может быть, автономного CA для небольшой организации), они удостоверяют подлинность промежуточных CA, которые уже в свою очередь могут выпускать сертификаты или удостоверять другие CA от имени корневого, в результате чего в сертификатах содержится вся цепочка до корневого CA.

Минимальная рекомендуемая конфигурация для использования в реальной производственной среде – корневой CA и промежуточный CA, выдающий сертификаты по требованиям. Если ключ CA будет скомпрометирован, потребуется обновить ключ и, соответственно, корневой сертификат тоже. Это приведёт к тому, что все сертификаты, подписанные этим CA станут недействительны, для избежания подобной ситуации и используется многоуровневая структура, чтобы снизить риск компрометации приватных ключей корневых CA, которые строго рекомендуется развертывать на изолированных физических серверах с отсутствием (постоянного) подключения к сети (вплоть до того, что требуется вывести из строя все сетевые адаптеры).

4.6. Создание локального CA с помощью OpenSSL

Для генерации ключей RSA, создания и подписания сертификатов может использоваться OpenSSL – пакет с криптографической библиотекой со свободным и открытым исходным кодом, которая предоставляет инструменты для работы с цифровыми сертификатами. В данной работе для упрощения мы будем выдавать сертификаты конечным потребителям от имени корневого CA и не будем касаться процедуры отзыва сертификатов.

Создайте каталог, в котором будете хранить сертификаты и ключи:

В рамках данной работы мы храним сертификаты и ключи в домашней директории пользователя, но стоит отметить, что для реального CA правильнее будет хранить сертификаты и ключи в специально существующих для этого директориях /etc/pki/tls/certs:

/etc/pki/tls/private.

Сгенерируйте защищенный приватный ключ будущего CA длиной 4096 бит c помощью следующей команды:

Затем выпустите самоподписанный корневой сертификат с указанными после ключа subj параметрами (в CN вместо voip.local можете подставить hostname CentOS) с помощью следующей команды:

10000 -out rootCA.crt -subj ‘/C=RU/ST=Moscow/L=Zelenograd/O=MIET/OU=TCS/CN=voip.local CA’

Добавьте созданный корневой сертификат в список доверенных центров сертификации, для этого скопируйте его в директорию для доверенных сертификатов CA и обновите список доверенных CA:

Сгенерируйте ключ для клиентского сертификата:

Сгенерируйте запрос на подпись сертификата с указанием параметров (в CN подставьте IP адрес CentOS):

Выпустите сертификат согласно запросу, подписав его ранее выпущенным сертификатом CA:

Посмотреть данные сертификата:

Проверка, что сертификат действительно выпущен указанным CA:

*Если бы сертификат был выдан промежуточным центром, то пришлось бы добавить данные о сертификатах всех промежуточных центров, чтобы сервер отсылал клиенту корректные данные о цепочке сертификатов.*

Создайте каталог для сертификатов SSL, используемых NGINX:

Скопируйте сертификаты, предназначенные для phpmyadmin в созданную директорию:

Сгенерируйте файл параметров алгоритма обмена ключами Диффи-Хеллмана для усиления стойкости используемых шифров и использования forward secrecy. Эта технология позволяет уменьшить возможный ущерб при компрометации ключа путем генерации отдельного ключа для каждой сессии (а не использовать один общий ключ).

В файле конфигурации для сайта phpMyAdmin секцию server приведите к следующему виду:

server {

    listen       443 ssl http2;
    server_name  _;
    ssl_protocols         TLSv1.2 TLSv1.3;
    ssl_certificate     /etc/nginx/ssl/pma.crt;
    ssl_certificate_key /etc/nginx/ssl/pma.key;
    ssl_session_timeout               10m;
    ssl_session_cache      shared:TLS:10m;
    ssl_session_tickets               off;
    ssl_ciphers          HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers          on;
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;


    root /var/www/phpmyadmin;
    charset utf-8;
    index  index.php index.html index.htm;
    location / {
        try_files $uri /index.php?$args;
    }
    location ~ .php$ {

        try_files  $uri =404;

        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_index index.php;
        fastcgi_param HTTPS on;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param QUERY_STRING    $query_string;
        include fastcgi_params;
    }

В начало того же файла с конфигурацией для сайта phpMyAdmin добавьте еще одну секцию server для перенаправления всех запросов от клиентов с порта 80 (HTTP) на 443 порт (HTTPS).

server {

        listen 80;
        server_name _;
        location / {
            return 301 https://$host$request_uri;
        }
    }

Проверьте корректность файла конфигурации sudo nginx -t.
Перезапустите NGINX sudo systemctl restart nginx.

Теперь покажем, как можно проверить работоспособность сервера, использующего SSL/TLS с помощью OpenSSL клиента, это также полезно использовать при устранении ошибок/неисправностей:

openssl s_client -host localhost -port 443

При работоспособном HTTPS сервере верхняя часть вывода должна выглядеть подобно приведенному ниже, указано состояние (CONNECTED), отображена цепочка сертификации и результаты проверки валидности сертификатов (возврат 1 означает успешное прохождение) (Рисунок 4.4):

Рис 4.4. Проверка работоспособности HTTPS сервера

Для доступа к порту 443 потребуется добавить его в список разрешенных:

sudo firewall-cmd --add-service=https --permanent

Зайдите на веб-интерфейс phpMyAdmin. Браузер должен предупредить об угрозе безопасности вследствие недоверенного издателя сертификата. На данном этапе игнорируйте это предупреждение.

Если веб-интерфейс недоступен, проверьте, что прослушивается 443 порт (присутствует в выводе команды ss -tlpn), проверьте права доступа на сертификаты (владелец – nginx).

4.7. Защита сайта

Для дополнительной защиты доступа к некоторым сайтам/разделам можно использовать несколько различных механизмов аутентификации и авторизации, рассмотрим один из простейших, базовую аутентификацию HTTP. При ее использовании сервер при обращении к защищенному ресурсу будет посылать ответ 401 Unauthorized и добавлять дополнительный заголовок HTTP WWW-Authenticate с указанием схемы (Basic в данном случае) и сопутствующих параметров аутентификации. Браузер, получив такой ответ, отображает окно ввода учетных данных и потом отсылает их в незашифрованном виде, вставляя заголовок Authorization. При использовании HTTPS такая схема достаточно безопасно, поскольку заголовок шифруется вместе с данными.

Для использования базовой аутентификации с NGINX, необходимо установить пакет htpasswd для создания хэшированных скрытых одноименных файлов, содержащих имена пользователей и пароли. Пакет входит в состав утилит для веб-сервера Apache и устанавливается следующей командой:

sudo yum install httpd-tools

Создайте пользователя developer (после ввода данной команды система запросит ввод пароля для этого нового пользователя, его задайте самостоятельно):

sudo htpasswd -c /etc/nginx/conf.d/.htpasswd developer

Теперь осталось только указать NGINX, для каких сайтов/локаций требуется использовать созданный файл. Вставьте следующие строки в локацию, соответствующую phpMyAdmin внутри секции server для 443 порта:

auth_basic

«Restricted Access!»;

auth_basic_user_file

/etc/nginx/conf.d/.htpasswd;

4.8. Защита соединений SIP RTP для Asterisk

Протоколы SIP и RTP передают все данные в открытом виде, как Вы могли сами убедиться, анализируя их сообщения в Wireshark, для защиты передаваемых данных были созданы протокол Secure SIP (SIPS) для защиты сигнального трафика и протоколы Secure RTP (SRTP) и Z RTP (ZRTP) для защиты медиа трафика. Аналогично протоколу HTTPS, протоколам SIPS SRTP для безопасной передачи c шифрованием данных сигнального и медиа трафика также требуется сертификат.

Сгенерируйте ключ и сертификат для сервера Asterisk, в CN вместо IP_addr подставьте IP адрес CentOS

cd ~/ca

openssl genrsa -out asterisk.key 2048

openssl req -new -key asterisk.key -out asterisk.csr -subj '/C=RU/ST=Moscow/L=Zelenograd/O=MIET/OU=TCS/CN=IP_addr'

openssl x509 -req -in asterisk.csr -days 365 -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out asterisk.crt

Сгенерируйте ключ и сертификат для SIP-клиента с номером XXXX (подставьте существующий в Вашей конфигурации номер), он будет подписан не корневым сертификатом, а сертификатом, выданным для Asterisk.

openssl genrsa -out clientXXXX.key 2048

openssl req -new -key clientXXXX.key -out clientXXXX.csr -subj '/C=RU/ST=Moscow/L=Zelenograd/O=MIET/OU=TCS/CN=XXXX'

openssl x509 -req -in clientXXXX.csr -days 365 -CA asterisk.crt -CAkey asterisk.key -CAcreateserial -out clientXXXX.crt

Задание. Сгенерируйте таким образом сертификат для каждого клиента.

Создайте директорию для хранения ключей и сертификатов Asterisk:

sudo mkdir /etc/asterisk/keys && umask 277 /etc/asterisk/keys

Скопируйте в эту директорию ключ и сертификат для Asterisk и клиента.

Установите владельца директории и файлов на asterisk:

sudo chown -R asterisk.asterisk /etc/asterisk/keys

Для возможности клиентам использовать SIPS и SRTP, необходимо внести изменения в конфигурацию PJSIP. Для каждого клиента, описанного в таблице ps_endpoints БД asteriskdb значение параметра transport, измените на tls-transport, добавьте параметры со следующими значениями (Табл. 4.1).

Таблица 4.1

Добавьте новую секцию tls-transport в начало файла /etc/asterisk.pjsip.conf

[tls-transport]

type=transport

protocol=tls

bind=0.0.0.0:5061

direct_media=no;

cert_file=/etc/asterisk/keys/asterisk.crt

priv_key_file=/etc/asterisk/keys/asterisk.key

cipher=ADH-AES256-SHA,ADH-AES128-SHA

method=tlsv1

allow_reload=true

Перезапустите службу Asterisk для применения настроек нового транспорта.

Для проверки работоспособности осталось сконфигурировать клиент. Для установления защищенного соединения клиенту потребуется сертификат. С помощью WinSCP перенесите на хостовой компьютер сертификат, сгенерированный для клиента. Запустите клиент PhonerLite, во вкладке Конфигурация, разделе Сеть смените порт на указанный в конфигурации PJSIP для TLS, протокол смените на TLS, в разделе Кодеки отметьте пункт SRTP, в разделе Сертификаты в поле Сертификат клиента укажите путь до клиентского сертификата, сохраните параметры. Убедитесь, что клиент зарегистрировался через TLS-соединение (внизу окна рядом с индикатором регистрации появится символ ключа с надписью TLS), совершите вызов, убедитесь, что голосовой трафик передается.

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

Для того, чтобы добавить корневой сертификат в список доверенных центров сертификации, перенесите rootCA.crt на хостовой компьютер, откройте оснастку MMC Сертификаты (certmgr.msc). Аналогично приведенному ниже выполните импорт сертификата, укажите расположение файла rootCA.crt, не изменяйте остальные параметры хранилища. После успешного импорта Вы сможете найти сертификат в общем списке справа (Рисунок 4.5).

Рис 4.5. Добавление корневого сертификата в список доверенных центров сертификации

Снова попробуйте авторизовать PhonerLite на сервере Asterisk, теперь проверка должна пройти удачно.

4.9. Настройка безопасности PHP

В файле /etc/php/php.ini найдите/добавьте следующие параметры:

#Отключаем опасные функции

disable_functions = phpinfo, system, mail, exec

#Максимальное время исполнения скрипта

max_execution_time = 30

#Максимальное время, которое может потратить скрипт на обработку данных запросаtime = 30

max_input_time = 60

#Максимальное количество памяти, выделяемое каждому скрипту

memory_limit = 8M

#Максимальный размер данных, отсылаемых скрипту с помощью метода POST

post_max_size = 8M

#Максимальный размер загружаемых файлов

upload_max_filesize = 2M

#Не показывать ошибки PHP-скриптов пользователям

display_errors = Off

#Включаем Safe Mode

safe_mode = On

#Включаем SQL Safe Mode

sql.safe_mode = On

#Защищаемся от утечки информации о PHP

expose_php = Off

#Ведем логи

#Запрещаем открытие удаленных файлов

Данные параметры повышают защищенность веб-сервера, ограничивая возможности по исполнению вредоносного кода PHP.

Заключение

В данном учебно-методическом пособии рассматриваются основы конфигурации программной АТС Asterisk. Показаны основные возможности используемой АТС, локальное подключение, организация соедиения между двух и более программных АТС. Приведены принципы конфигурации с использованием локальной или внешней базы данных, а также принципы взаимодействия с БД в консольном и графическом режимах работы. Также в работе рассмотрены основы обеспечения защищенного соединения с программной АТС, использования удаленного доступа с поддержкой ключей шифрования, защита загрузчика операционной системы Linux, продвинутая конфигурация протокола SSH.

В результате выполнения описанных в учебно-методическом пособии работ, студенты (бакалавриата и магистратуры) получают понимание принципов конфигурации программной АТС и работы IP-телефонии в целом, включая основные телекоммуникационные протоколы и технологии IP-телефонии (SIP, H.323 и др.), принципы взаимодействия АТС между собой, а также основы работы с ОС Linux. Данный материал позводит сформировать базовые знания для проведения научных исследований и разработок в области телекоммуникационного оборудования и систем связи.

Библиографический список

1. Шиндер Д.Л. Основы компьютерных сетей : Пер. с англ. / Д.Л. Шиндер. — М. : Вильямс, 2002. — 652 с.
2. Сакалема Д.Ж. Подвижная радиосвязь / Сакалема Домингуш Жайме; Под ред. О.И. Шелухина. — М. : Горячая линия-Телеком, 2012. — 512 с.
3. Спортак М. Компьютерные сети и сетевые технологии : Пер. с англ. / М. Спортак, Ф. Паппас. — Киев : ТИД ДС, 2002. — 711 с.
4. Таненбаум Э. Компьютерные сети : Пер. с англ. / Э. Таненбаум. — 3-е изд. — СПб. : Питер, 2002. — 846 с.
5. Андэрсон К. Локальные сети. Полное руководство : Пер. с англ. / К. Андэрсон, М. Минаси. — СПб. : Век+ : ЭНТРОП : КОРОНА принт, 1999. — 620 с.
6. Блам Р. Администрирование почтовых серверов sendmail / Р. Блам. — 2-е изд. — М. : ИНТУИТ, 2016. — 702 с.
7. Мельников Д.А. Информационные процессы в компьютерных сетях : Протоколы, стандарты, интерфейсы, модели… / Д.А. Мельников. — М. : Кудиц-образ, 1999. — 256 с.
8. Кульгин М. Технологии корпоративных сетей : Энциклопедия / М. Кульгин. — СПб. : Питер, 2000. — 699 с.
9. Олифер В.Г. Компьютерные сети. Принципы, технологии, протоколы : Учеб. пособие для вузов / В.Г. Олифер, Н.А. Олифер. — СПб. : Питер, 2001. — 668 с.
10. Соколов А.В. Защита информации в распределенных корпоративных сетях и системах / А.В. Соколов, В.Ф. Шаньгин. — М. : ДМК Пресс, 2002. — 655 с.
11. Рябко, Б. Я. Криптографические методы защиты информации : учебное пособие / Б. Я. Рябко, А. Н. Фионов. — 2-е изд., стер. — Москва : Горячая линия-Телеком, 2013. — 229 с.