Какой sip proxy запустить проще всего?
Есть asterisk, работающий во внутренней сети (ну и с ограниченным количеством внешних провайдеров с фиксированными адресами).
Для остальных порт 5060 закрыт, иначе частота сообщений в логах от брутфорсеров около 10 шт в секунду.
Есть желание поднять дополнительный порт, чтобы подключаться с мобильников из случайных мест. С помощью iptables это не решить, т.к. внутри пакетов указывается настоящий порт.
Нужен самый простой sip-proxy, который был принимал пакетики на порту X и отдавал локальной машине на порт 5060, но уже на внутреннем интерфейсе. Чтобы не морочил голову ни dialplan, ни авторизацией.
Открыл документацию opensips, подумал https://youtu.be/HcfHBgUTn7I , за день не осилю.
Что порекомендуете из попроще? Ну или готовый конфиг «принял-отдал» для opensips. Насчет безопасности можно не заморачиваться, т.к. отдельные аккаунты для мобильников не могут звонить наружу, только по внутренним номерам.
Судя по вашему сообщению, ваша проблема это
Для остальных порт 5060 закрыт, иначе частота сообщений в логах от брутфорсеров около 10 шт в секунду.
Вам нужно настроить логирование, а не плодить сущности в системе.
А вообще Kamailio норм. OpenSIPS это его со-форк, так что различия между ними должны быть минимальны. Но нужно понимание того, как он работает.
Kamailio/OpenSIPS збс, но это явно не «попроще». Хотя с твоим запросом прозрачный прокси делается тривиально. Но боюсь проблема не в наличии/отсутствии прокси, а в настройках сети
Источник
Kamailio SIP proxy: пример установки и минимальной настройки
В работе системного администратора, занимающегося внедрением систем телефонии на базе Asterisk, рано или поздно может возникнуть ситуация, когда аппаратных возможностей одного сервера для обработки всех вызовов уже недостаточно. Соответственно, возникает необходимость разделить нагрузку на несколько серверов. Одним из способов решения такой задачи является использование SIP proxy, но стоит признать, что в отличие от Asterisk, информации по SIP proxy, форумов, примеров и описаний, меньше как минимум на порядок. Цель этой статьи — показать на простом примере возможность использования SIP proxy Kamailio в связке с Asterisk так, чтобы максимально облегчить освоение SIP proxy для новичков.
Все настройки в рамках данного примера мы будем производить на виртуальных машинах, размещенных в локальной сети, хотя если бы они имели публичные адреса и находились бы в облаке, принципиальной разницы бы не было.
Предположим, что в организации уже установлен Asterisk, и сотрудники обрабатывают большое количество входящих звонков, с которым сервер уже не справляется. Мы добавим еще один сервер Asterisk (точнее, клонируем существующий), а SIP proxy возьмет на себя роль «распределителя» входящих звонков.
Начнем с выбора SIP proxy. На хабре есть хорошая статья на эту тему, в которой рассмотрена история развития основных проектов. В отличие от автора этой статьи, мой выбор пал на Kamailio и web-интерфейс для него под названием Siremis.
Установим Kamailio. В качестве ОС будем использовать CentOs 6.8.
В первую очередь, необходимо отключить SELinux, обновить пакеты и установить необходимые зависимости:
Нам потребуется доступ к 80 порту для работы с web-интерфейсом и к 5060 udp для работы с sip, поэтому добавим правила IPTables:
Создаем файл /etc/yum.repos.d/kamailio.repo с содержимым:
И устанавливаем kamailio:
Не забудем добавить демоны в автозагрузку:
Отредактируем файл /etc/kamailio/kamctlrc: нужно раскомментировать строку
и указать SIP_DOMAIN. В силу того, что мы настраиваем систему в локальной сети, достаточно будет указать ip-адрес, в моем случае
Ниже можно отредактировать параметры подключения к базе данных, но в случае учебного стенда менять их не обязательно.
Запустим MySQL и сгенерируем необходимые таблицы:
На все вопросы мастера отвечаем утвердительно.
Теперь отредактируем основной конфигурационный файл /etc/kamailio/kamailio.cfg. Логически он разбит на несколько секций: глобальные параметры, загрузка модулей, установка параметров модулей и маршруты. Каждый модуль Kamailio выполняет определенную функцию, поэтому можно загружать только необходимые для конкретной задачи библиотеки. Начало файла приведем к виду:
Как понятно из комментариев ниже, эти директивы включают необходимые модули, например WITH_MYSQL, определенный в начале файла, ниже приводит к загрузке модуля mysql.so:
Безусловно, можно загрузить все модули вручную, но использование директивы гораздо удобнее. WITH_AUTH, например, дает возможность пользователям регистрироваться на Kamailio с использованием имени и пароля, а все варианты выбора вы можете посмотреть в комментариях ниже.
Для дальнейшей корректной работы web-интерфейса и статистики внесем еще несколько изменений:
После всех строк loadmodule добавим загрузку еще двух:
Перед секцией маршрутов, которая отделяется строкой ####### Routing Logic ######## добавим параметры загруженных модулей:
И добавим дополнительный маршрут после последней секции route в районе 910 строки файла:
Запускаем Kamailio и проверяем, что он запустился:
Если Kamailio не запускается, нужно посмотреть лог /var/log/messages — именно туда будут попадать ошибки Kamailio, если дополнительно не настроить rsyslog, что не представляет большой сложности.
По умолчанию используется база MySQL kamailio c пользователем kamailio c паролем kamailiorw, если конечно не изменить установки по умолчанию в файле /etc/kamailio/kamctlrc перед созданием базы данных. В том случае, если вы изменили эти установки, будет нелишним пройтись автозаменой по основному конфигурационному файлу kamailio.cfg и внести корректные данные подключения к базе.
В принципе, Kamailio может работать и без базы данных — все необходимые значения для модулей можно задавать в конфигурационном файле или хранить во внешних файлах, но использование БД, особенно на крупных проектах, гораздо удобнее, плюс именно с базой будет работать web-интерфейс Siremis, который мы сейчас установим.
Нужно скачать, разархивировать файлы, скопировать их в директорию, с которой будет работать apache и дать верные права:
В секцию VirtualHost в конфигурации apache для Siremis добавим
При дальнейшей установке последней на момент написания статьи версии Siremis 4.3.0 могут возникнуть проблемы в случае, если у вас не задан date.timezone, поэтому рекомендуется сразу внести изменения в php.ini:
Для Siremis потребуется отдельная база данных. Добавим пользователя:
Вы можете изменить параметры подключения к базе, но не забудьте тогда задать верные значения в дальнейшем.
Теперь можно перезапустить apache и перейти к завершающему этапу установки Siremis — уже через браузер. Перейдите по адресу ваш-ip/siremis
Если проверка системы пройдена, можно начинать установку.
Обратите внимание: по умолчанию под звездочками скрываются дефолтные пароли от пользователей Kamailio и Siremis, так что если вы не вносили изменений ранее, то и на этом шаге можно не забивать пароли вручную.
Обязательно поставьте галочки на всех пунктах — Create Siremus DB, Import Dafault Data, Update SIP DB, Replace DB config.
Проверьте, что указаны корректные данные.
И на этом установка завершена.
Давайте попробуем осуществить первый звонок через Kamailio. Для этого перейдем на вкладку SIP Admin menu и добавим новый домен в Domain List. Kamailio будет обслуживать только перечисленные здесь домены (или ip-адреса).
В случае, если к адресу привязан домен, и пользователи могут регистрироваться как указав ip-адрес, так и указав домен, следует добавить и доменное имя в список. В нашем случае добавляем только ip-адрес сервера, к которому будут обращаться клиенты.
Для создания внутреннего абонента или подписчика перейдем к Subscriber Services -> Subscribers и добавим два номера — 101 и 102, указав для них пароли и серый адрес в качестве домена (в нашем случае 192.168.0.237).
Теперь, используя софтфон, например Zoiper, мы можем зарегистрироваться на сервере и осуществить звонок с 101 на 102 номер или наоборот и убедиться в том, что все предыдущие действия были выполнены верно.
Перейдем к настройке распределения входящих вызовов. В локальной сети у нас есть 2 виртуальные машины с Asterisk на адресах 192.168.0.234 и 192.168.0.235, и нам нужно поровну распределить входящие звонки между ними. В данной ситуации мы будем использовать модуль dispatcher, который предоставляет необходимый функционал.
Вернемся в консоль, и добавим в kamailio.cfg в секцию загрузки модулей
а также два параметра — подключения к базе данных, в которой и будет храниться список серверов Asterisk, и частоту проверки этих серверов, чтобы звонок ни в коем случае не ушел на выключенный сервер:
Вообще, полный список модулей, их параметров и функций всегда можно посмотреть на официальном сайте. После подключения модуля перезапустим Kamailio и убедимся в том, что он запустился. В случае возникновения проблем (модули могут зависеть от других, требовать установки определенных параметров как для самого модуля, так и для тех, от которых он зависит) мы увидим ошибку в логе.
Теперь перейдем к секции маршрутов. Созданные по умолчанию маршруты в принципе обеспечивают необходимый минимум, например, при попытке зарегистрироваться с неверным паролем, Kamailio отдаст ошибку 401, а при попытке позвонить на несуществующее направление — 404. Сложность в понимании маршрутизации Kamailio представляют используемые переменные и функции, которые предоставляются различными используемыми модулями, и не всегда сходу можно понять, какая переменная или функция к какому модулю относится. Для наших учебных целей маршрут потребуется совсем простой — в самое начало главного маршрута мы добавим условие:
Если приходит запрос типа INVITE, то есть приглашение к началу разговора, то мы выбираем один из серверов, которые позже занесем в таблицу, из группы 1 по стратегии выбора 4 — round-robin. Затем посылаем ответ вызывающему и осуществляем перевод звонка на выбранное назначение. Обратите внимание, что теперь абсолютно любой INVITE будет обрабатываться таким образом, так что возможность позвонить с 101 номера на 102, которые мы создавали ранее, будет утрачена — звонки с них тоже будут улетать на один из серверов Asterisk, и поступающие извне запросы INVITE также будут напрямую уходить на Asterisk без всякой проверки источника запроса.
Для того, чтобы Asterisk мог обработать такие вызовы, нужно добавить peer следующего вида на каждый из серверов:
Теперь можно добавить сервера Asterisk в базу данных Kamailio через web-интерфейс:
Setid задаст к какой группе серверов относится новый сервер, Priority не используется в стратегии выбора round-robin, но может использоваться в других стратегиях, а Flags в данном случае устанавливает, что по умолчанию мы считаем сервер неактивным и проверяем его состояние.
После добавления серверов можно или перезапустить Kamailio, что недопустимо на продакшне, или выполнить команду kamcmd dispatcher.reload . Список команд для каждого модуля также можно посмотреть на официальном сайте.
Можно переходить к тестированию. Используя софтфон, например, Zoiper, можно осуществить вызов напрямую на Kamailio, без всяких аккаунтов и регистраций. Достаточно в поле набора ввести sip:1@192.168.0.237. Сразу после этого вызов будет переадресован на один из Asterisk и обработан в соответствии с диалпланом. Следующий вызов пойдет на второй сервер.
В принципе, стоявшую перед нами учебную задачу — распределять входящие вызовы поровну между серверами, — мы решили. Однако, далеко не каждый оператор связи готов отдавать звонки на ваш ip-адрес напрямую, без регистрации, и нужно будет посылать запросы типа REGISTER. Этот функционал реализует модуль uac. Добавим в нашу схему еще один Asterisk — он будет исполнять роль провайдера. На нем создадим какой-нибудь внутренний номер, например, 200200, который будет требовать регистрацию.
Загрузим модуль в конфигурационном файле:
И зададим пару обязательных в нашем случае параметров:
Кроме того, потребуется внести изменение в параметр другого модуля. Найдите в файле строку
Теперь можно настроить регистрацию, перезапустив предварительно Kamailio, чтобы модуль загрузился:
Обратите внимание на поле Realm. По умолчанию, вы можете ввести в него что угодно, но тогда регистрация проходить не будет, а в логе вы увидите то-то вроде:
Именно поэтому при возникновении каких-либо проблем не стоит сразу перечитывать мануал, искать другие инструкции и сомневаться в своих способностях — чаще всего объяснение можно найти в логе.
Остается только убедиться в том, что абонент 200200 зарегистрирован на Asterisk, играющем роль провайдера, и осуществить звонок с любого другого номера на 200200.
На этом пример настройки Kamailio мы заканчиваем, но обратите внимание, что в статье не рассмотрена работа за NAT, безопасность, маршрутизация исходящих вызовов и многое другое, что может потребоваться в реальной ситуации. Однако надеюсь, что эта статья облегчит для вас освоение Kamailio.
Источник
Взаимодействие клиентов SIP. Часть 2
В предыдущей статье мы рассмотрели простое взаимодействие клиентов SIP без использования Proxy-сервера. Такое взаимодействие на практике встречается чрезвычайно редко, но отлично подходит для того, чтобы понять основы SIP.
Теперь, когда мы разобрались с базовыми вещами, предлагаю перейти к реальной работе протокола.
В этой статье я планирую рассмотреть три вопроса:
- Выбор транспортного протокола и поиск Proxy;
- Работа через Proxy;
- Регистрация на Proxy-сервере.
Выбор транспортного протокола и поиск Proxy
Поскольку протокол SIP поддерживает несколько транспортных протоколов (UDP, TCP, SCTP, TLS), необходимо каким-то образом определять, какой протокол использовать. Для этого существет несколько способов.
Первый способ предполагает явное указание транспорта в SIP URI (кроме TLS). Выглядит это вот так:
Если транспорт явно не указан, то действует следующий алгоритм:
- Если SIP URI содержит IP-адрес, то для SIP URI используется UDP, для SIPS (Secure SIP) – TCP.
- Если IP-адрес не укзаан, но укзаан порт, то для SIP URI используется UDP, для SIPS – TCP.
- Если отсутсвует IP-адрес и порт, но в DNS присутствует соответсвующая NAPTR-запись, тогда “SIP+D2U” соответствует UDP, “SIP-D2T” указывает на TCP и “SIP-D2S” — на SCTP. NAPTR содержит ссылку на SRV-запись, которая будет использоваться для поиска Proxy-сервера. Если NAPTR остуствует, то должен быть выполнен запрос на поиск SRV-записи.
- Результатом SRV запроса будет имя и порт Proxy-сервера.
- Если SRV-запись отсутствует, то выполняется A или AAAA-запрос. При это для SIP URI используется UDP, для SIPS – TCP.
Для того, чтобы лучше разобраться, рассмотрим пример, когда мы хотим связаться с клиентом sip:ivan@domain.ru:
Итак, мы выяснили, параметры Proxy-сервера Ивана. Теперь предлагаю рассмотреть использование Proxy в рамках SIP-диалога.
Ремарка для тех, кто не знает, что такое NAPTR. Я узнал, что есть такой тип DNS-записи только, когда писал эту статью, так что не отчаивайтесь. Чуть подробнее про NAPTR здесь.
Взаимодействие с использованием Proxy
Для чего же нам необходим SIP Proxy? Как я уже сказал, в примере из 1-ой части статьи клиенты знали IP-адреса друг друга и могли общаться напрямую. В реальной жизни клиенты чаще всего получают адреса динамически, поэтому нет смысла «запоминать» тот или иной IP. Первое, что приходит на ум в данной ситуации – использовать A-записи DNS и определить реальный действующий адрес. Однако тут кроется следующая проблема: IP-адрес идентифицирует конкретное устройство, а не пользователя на нем. Особенностью взаимодействия SIP является то, что обмен сообщения происходит не на уровне устройство-устройство, а на пользователь-пользователь. При этом один пользователь может одновременно использовать несколько SIP-клиентов: на мобильном телефоне, на рабочем компьютере, на домашнем компьютере и на SIP-телефоне. Как же быть?
Протокол SIP предлагает следующее решение: создается SIP Proxy и каждый пользователь регистрирует свои устройства на этом Proxy (точнее пользователи регистрируются на сервере регистрации, а Proxy имеет доступ к базе регистрации, но для простоты будем считать, что это один и тот же сервер). Как это делается, я покажу ниже. Пока просто запомните, что Proxy знает, как именно найти тот или иной клиент пользователя.
Когда Петр звонит Ивану, выполняется следующая последовательность действий:
- SIP-клиента Петра определяет адрес и протокол SIP Proxy Ивана (как это делается — см. выше)
- Клиент отправляет на Proxy запрос INVITE
- Proxy-сервер смотрит, на каких устройствах зарегистрировался Иван и отправляет запрос на все эти устройства
- Иван отвечает на звонок на одном из устройств и шлет 200 OK на Proxy
- Proxy перенаправляет 200 OK Петру
- Петр получает SIP-адрес Ивана на конкретном устройстве из поля Contact вответе 200 ОК и шлет ответ напрямую, минуя Prxoy
- Все последующее общение идет также напрямую
На схеме это выглядит следующим образом:
Для тех, кто изучил первую часть статьи, все выглядит довольно знакомо; добавился только промежуточный Proxy-сервер. Соответственно и обмен сообщениями изменился незначительно.
Прежде, чем преступим к детальному рассмотрению, маленькая ремарка. В рамках SIP разделяют два типа URI. Первый из них – ползовательский URI, также известный как address of recorf (AOR). Запрос, отправленный на этот адрес предполагает поиск в базе данных Proxy и отправку запроса одному или несольким устройствам. Второй – URI устройства (а точнее – пользователя на устроястве). URI устройства обычно называется контакт и содержится, соответственно, в поле Contact SIP-сообщения. AOR содердится в полях From и To.
Начало разговора
Итак, Петр посылает INVITE для Ивана на Proxy-сервер:
Proxy-сервер перенаправляет запрос всем SIP-клиентам Ивана. Для простоты предположим, что Иван использует только одно устройство. Чтобы SIP-клиент понимал, что запрос был перенаправлен через Proxy, сервер добавляет свое заголовочное поле via:
SIP-клиент Ивана шлет ответ 180 Ringing (Иван слышит звонок). При этом он добавляет tag в поле To и указывает свой контакт в поле Contact. Кроме того, в первом поле via добавился параметр received этот параметр показывает, с какого адреса клиент Ивана получил запрос (т.е. адрес Proxy-сервера, как его видит Иван). Это бывает полезно знать для решения возникающих проблем:
Proxy, соответственно, перенаправляет запрос клиенту Петра. При этом он убирает свой via:
После отправки 180 Ringing, как только Иван снимет трубку, клиент Ивана отправляет на Prxoy ответ 200 OK:
Proxy передает этот ответ Петру, убирая при этом via:
Теперь самое интересное. Клиент Петра отправляет сообщение АСК непосредственно клиенту Ивана в обход Proxy. Причем, если бы Иван одновременно использовал несколько клиентов SIP, ответ пришел именно на тот, который нужно. Благодаря чему это возможно?
200 ОК отправляется с клиента на котором Иван снял трубку. Более того, в поле Contact ответа 200 ОК содержится URI, соответствующий пользователю Иван на конкретном устройстве. Таким образом клиент Петра отправляет АСК именно на это устройство, после чего участие Proxy больше не требуется:
Все остальные сообщения, включая медиа-траффик идут в обход Proxy.
Конец разговора
В конце разговора клиент Ивана отправляет BYE напрямую клиенту Петра:
Петр в ответ шлет подтверждение:
Здесь все, как в первой части статьи.
Итак, мы рассмотрели взаимодействие SIP-клиентов с участием Proxу-сервера. Остался один единственный вопрос: откуда Proxy узнал адреса клиентов Ивана? С помощью процедуры регистрации. Как это происходит, я расскажу ниже.
SIP-регистрация
Регистрация выглядит следующим образом:
Давайте подробнее рассмотрим каждое из сообщений. Иван отправляет на сервер запрос Register (для простоты считаем, что роль сервера регистрации установлена на proxy.domain.ru). Самое важное в этом запросе – поле Contact. Это адрес Ивана на конкретном устройстве:
В ответ сервер присылает 401 Unauthorized, то есть требование авторизации. Самое важное поле в ответе — WWW-Authenticate. Не сложно догадаться, что realm — это домен, а algorithm указывает, какой хеш-алгоритм мы будем использовать. Интерес вызывает поле nonce:
Nonce — это сокращение от «number used once». Nonce — это одноразовая случайная последовательность, которую клиент Ивана cкомбинирует со строкой пароля, после чего сгенерирует MD5-хеш от полученной строки и поместит результат в новый запрос в поле WWW-Authenticate (на самом деле все несколько сложнее, но для простоты будем считать, что все именно так). Для этого служит параметр response.
Зачем нужен nonce? Если бы клиент генерировал MD5 от пароля и не использовал nonce, то хеш каждый раз получался бы один и тот же. Злоумешленник мог бы перехватить такой хеш и использовать для авторизации. Это было бы столь же небезопасно, как передавать пароль в открытом виде.
Если использовать nonce, MD5 каждый раз берется от новой строки и получается разным. Поэтому даже перехватив хеш, злоумышленник скорее всего не сможет его использовать для авторизации.
Кстати, обратите внимание, что новый запрос на регистрацию имеет CSeq на единицу больше:
Сервер также комбинирует nonce с паролем Ивана и получает MD5-хеш. После этого он сравнивает свой хеш с хешем, полученным от Ивана. Если они совпадают, то сервер присылает 200 ОК. Обратите внимание на то, что в поле Contact добавился параметр expires. В данном случае регистрация будет храниться в базе сервера в течение 3600 секунд или одного часа:
Если Иван хочет продлить регистрацию, то он должен отправить еще один REGISTER в течение этого часа.
Что делать, если Иван использует сразу несколько устройств с поддержкой SIP? Все очень просто – необходимо отправить запрос на регистрацию с каждого из них.
После того, как в базе данного сервера регистрации появится соответствующая запись, Proxy-сервер сможет перенаправлять запросы на SIP-клиенты Ивана.
Bonus для тех, кому интересно
Вы могли заметить, что, в ответ на запрос регистрации, сервер присылает ответ, содержащий To-tag:
Понятно, что при установке диалога данный tag помогает избежать повторного получения одного и того же сообщения. Для этого существует правило: если сообщение не содержит To-tag и UAS уже получал сообщение с таким же CSeq, From-tag и Call-ID, то сообщение отбрасывается. Для чего же нужен To-tag, если мы не устанавливаем диалог с сервером регистрации. Лучший ответ, который я смог найти — в RFC 3261 написано, что ответ 200 ОК, приходящий на запрос без To-tag должен содержать To-tag. То есть, это ни для чего не нужно, но так принято.
Надеюсь, что работа протокола SIP, после прочтения статьи, стала для вас более понятной. Буду рад вашим комментариям.
Источник
