По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет, Мир! Сейчас расскажем об одном полезном методе траблшутинга и поиска проблем на роутерах MikroTik. Суть данного метода заключается в том, чтобы отлавливать (“сниффить”) пакеты, проходящие через определённые интерфейсы нашего роутера и анализировать их сразу же при помощи Wireshark.
Prerequisites
Итак, для того, чтобы воспользоваться данным методом нам понадобится:
Роутер MikroTik (в нашем случае использовался RB951Ui-2HnD с версией прошивки RouterOS 6.40.2 )
Программа Wireshark (в нашем случае версия 2.4.1)
Компьютер или сервер, находящийся в одной сети с роутером с запущенным Wireshark’ом
Настройка
Первым делом открываем Wireshark, выбираем интерфейс, на котором хотим “сниффить” (в нашем случае это Ethernet, то есть интерфейс, с помощью которого компьютер подключается к роутеру) и устанавливаем следующий фильтр - udp port 37008. Как показано на рисунке:
Понятно, что если мы запустим захват пакетов без этого фильтра, то нам просто вывалится весь трафик, который проходит через этот интерфейс, а мы этого не хотим.
Что же это за фильтр такой и что за порт - 37008? Дело в том, что MikroTik шлёт UDP дэйтаграммы, то есть весь перехваченный трафик, именно на этот порт streaming server’а, а в качестве этого стриминг сервера, как вы могли догадаться, у нас выступает наш компьютер с запущенным Wireshark’ом. Эти пакеты инкапсулируются по протоколу TZSP (TaZmen Sniffer Protocol), который используется для переноса в себе других протоколов.
Итак, запускаем перехват пакетов на определённом интерфейсе с фильтром udp port 37008 и видим, что ничего не происходит и пакетов нет.
А теперь самое интересное – подключаемся к MikroTik’у через WinBox, переходим в раздел Tools далее Packet Sniffer и видим следующее окно с настройками:
На вкладке General можем оставить всё по умолчанию, переходим на вкладку Streaming:
Ставим галочку в Streaming Enabled, в поле Server указываем IP адрес нашего компьютера, на котором запустили Wireshark и ставим галочку на Filter Stream, чтобы активировать фильтр, который будет настраиваться на следующей вкладке - Filter
На данной вкладке мы можем отфильтровать интересующий нас трафик. Например, у нас в сети есть IP-АТС Asterisk и мы хотим посмотреть, какие пакеты он получает и отправляет через роутер MikroTik. Так, например, можно отследить коммуникацию IP-АТС с сервером провайдера VoIP услуг.
Итак, выбираем интерфейсы, на которых хотим отлавливать пакеты (в нашем случае это bridge), далее отфильтруем трафик по определённому IP-адресу в поле IP Address (Наша IP-АТС), укажем протокол - 17 (udp) и порт 5060 (sip). Направление укажем любое - any и Filter Operation = or , то есть логика работы данного фильтра – “или”. Если вы хотите отлавливать пакеты только по жёстко определённому фильтру, то логику следует указать and, то есть – совпадение всех условий фильтра.
Далее нажимаем Apply и Start и видим, что сниффер перешёл в статус “running”
Отлично, теперь отправляемся в Wireshark и видим, что он нам уже наловил нужных пакетов в соответствии с правилами фильтра.
В нашем случае – это коммуникация IP-АТС Asterisk с сервером провайдера VoIP услуг, запрос на регистрацию и подтверждение с обратной стороны. Обратите внимание, что тип инкапсуляции - TZSP, однако, Wireshark смог правильно деинкапсулировать эти пакеты и отобразить нам пакеты SIP.
Работаете с IP – АТС Asterisk? Тогда этот материал для вас. Говорить будем про отправку уведомлений в VK (Вконтакте) при входящем звонке. От слов к делу.
Получаем access_token
Первым делом, перейдите Developers раздел VK. В хедере (верхнем меню навигации) нажмите Мои приложения после чего нажмите Создать приложение:
Название - дайте имя для вашего аппликейшна. Например, Asterisk;
Платформа - выбираем Standalone-приложение;
Переходим в раздел настроек созданного приложения. Копируем ID приложения, как показано на рисунке ниже:
Отлично. Теперь скопируйте ссылку ниже:
https://oauth.vk.com/authorize?client_id=1234567&scope= offline,messages&redirect_uri=https://oauth.vk.com/blank.html&display=page&v=5.37&response_type=token
Предварительно замените client_id на ваше значение, полученное ранее (ID приложения). VK API спросит разрешения на доступ к некоторым данным:
Если все ОК, то VK вернет нам токен:
Если вы столкнулись с ошибкой вида «{"error":"invalid_request","error_description":"Security Error"}», то перелогиньтесь в вашей учетной записи в VK и повторите попытку
Сохраняем значение и переходим к настройке скрипта на стороне Asterisk.
Адаптация на Asterisk
Реализацию скрипта сделаем на .php. Создайте файл asteriskvk.php и наполните его следующим содержимым:
#!/usr/bin/php -q
<?php
require('phpagi.php');
$agi = new AGI();
$message = "Сейчас поступит звонок с номера: ";
$message .= $agi->request['agi_callerid'];
$id = "ID получателя сообщения";
$token = "Токен";
function send($id , $message, $token)
{
$url = 'https://api.vk.com/method/messages.send';
$params = array(
'user_id' => $id,
'message' => $message,
'access_token' => $token,
'v' => '5.37',
);
$result = file_get_contents($url, false, stream_context_create(array(
'http' => array(
'method' => 'POST',
'header' => 'Content-type: application/x-www-form-urlencoded',
'content' => http_build_query($params)
)
)));
}
send($id, $message, $token);
Скачать скрипт
В скрипте вам необходимо поменять следующие переменные:
$id - идентификатор пользователя, которому будет отправлено сообщение. Помимо user_id, это может быть ID группового чата;
$token - API - токен, который вы получили ранее;
Сохраняйте файл и загрузите в директорию /var/lib/asterisk/agi-bin/ после чего дайте следующие команды в консоли сервера:
chmod 755 /var/lib/asterisk/agi-bin/asteriskvk.php
chown asterisk:asterisk /var/lib/asterisk/agi-bin/asteriskvk.php
dos2unix /var/lib/asterisk/agi-bin/asteriskvk.php
Лезем в диалплан и на входящем маршруте адаптируем простенькую конструкцию:
exten => _.,n,AGI(asteriskvk.php)
Звоним и проверяем:
Всем привет! Сейчас мы расскажем об основных правилах, которые следует соблюдать при удаленном подключении телефона к IP-АТС. Актуально не только для Asterisk, но и для вообще любых IP-АТС.
Основные проблемы возникают из-за 3 факторов: Недостаточная пропускная способность сети, конфигурация межсетевых экранов и функционал инспектирования SIP-трафика. Но обо всём по порядку.
Пропускная способность (Bandwidth)
Давайте посчитаем, какая нам потребуется пропускная способность для одного звонка с использованием кодека G.711. При условии, что мы передаём голос в стандартной Ethernet – сети и будет задействован стек протоколов – IP/UDP/RTP :
По умолчанию, кодек G.711 формирует два голосовых семпла общей длительностью 20 мс, размер которых = 160 байт. Скорость потока, создаваемого G.711 = 64 Кбит/c
Заголовки канального уровня (Layer 2) потребуют ещё 18 байт
Заголовки сетевого уровня (IP - Layer 3) добавят ещё 20 байт
Далее заголовки UDP – ещё 8 байт
Наконец, RTP потребует 12 байт
Таким образом, общий размер пакета, в котором будет передаваться 20 мс голоса составит: 160 + 18 + 20 + 8 + 12 = 218 байт
Количество пакетов в секунду, формируемых G.711 = скорость потока кодека / размер голосовой нагрузки (сэмплов) = 64000 бит/c / (160 байт * 8 бит на байт) = 50 пакетов в секунду
Теперь мы можем посчитать полосу пропускания, необходимую для передачи 50 пакетов, содержащих 20 мс голоса, которые будут передаваться по сети. Полоса пропускания = 218 байт * 8 бит на байт * 50 = 87200 бит/с = 87.2 Кбит/c.
Рекомендуется ещё закладывать 5% в качестве защитного интервала: 87.2 * 1.05 = 91.56 Кбит/с
Вот примерно такой должна быть полоса пропускания интернет соединения со стороны подключения удалённого телефона, и на стороне IP-АТС. Если у одной из сторон будет медленное соединение, то качество голоса будет неудовлетворительным.
Зная параметры VoIP сети и используемого кодека, Вы без проблем сможете вычислить необходимую Вам полосу пропускания. Чтобы больше узнать про кодеки, рекомендуем почитать нашу статью.
Телефонный звонок – это симметричное соединение. Поэтому необходимо иметь минимум 91.56 Кбит/с как для входящего трафика (download speed), так и для исходящего (upload speed). Если удалённый пользователь имеет 10 Мб на скорость скачивания (download), то это ещё не значит, что он имеет сколько же на upload.
Но даже если наш удалённый пользователь будет иметь 10 Мб на скачивание и 512 Кбит на загрузку, это ещё не гарантирует нормальное VoIP соединение. Потому что полоса пропускания будет делиться между всеми активностями, которые пользователь совершает в Интернете. Догадайтесь - что будет, если наш пользователь находится в телефонном звонке, а кто-то в его сети начнёт скачивать тяжёлый файл или смотреть онлайн видео? При скачивании файлов задержка или потеря пакета может быть даже не заметна. А вот VoIP трафик передаётся в реальном времени и он очень чувствителен к задержкам и потерям пакетов. Любой из этих факторов может привести к срыву звонка.
Если Вы столкнулись с такой проблемой, рекомендуем настроить Quality of Service или Traffic Shaping. Данный функционал позволяет раздать приоритеты разным видам трафика на маршрутизаторе. Более подробно о механизме QoS можно почитать в нашей статье. А здесь примеры настройки на маршрутизаторе Mikrotik.
Межсетевой экран (Firewall)
Необходимо точно понимать, что удалённый телефон – это телефон, который подключается к Вашей IP-АТС не напрямую. Он не находится в Вашей локальной сети (LAN) и, что ещё важнее, он не находится в Вашей виртуальной локальной сети (VPN). Поэтому, для его корректной работы, нужно будет открыть кое какие порты на роутере или межсетевом экране.
5060 - По стандарту именно этот UDP порт используется протоколом SIP для обмена сигнальной информацией.
10000 – 20000 - (В большей степени актуально для Asterisk). UDP порты используются протоколом RTP и RTCP для передачи исходящего и приема входящего аудио трафика. Если вы столкнулись с проблемой односторонней слышимости или полным её отсутствием (при условии наличия сигнализации SIP) – скорее всего, дело в RTP портах на одной из сторон соединения.
69 TFTP / 21 FTP - Порты для обмена файлами. В IP-АТС используются для автоматической настройки и обновления телефонных аппаратов при помощи функции auto-provision.
Отнеситесь данному пункту очень серьёзно. Нельзя просто открывать эти порты всему миру. Необходимо также настроить правила, чтобы доступ к этим портам могли получить только доверенные устройства.
Если Вы используете Asterisk/FreePBX, то рекомендуем более подробно узнать какие ещё порты может понадобиться открыть вот тут.
Функционал испектирования SIP
SIP ALG (Application Layer Gateway) – это функционал, который испектирует SIP трафик, который проходит через маршрутизатор и позволяет модифицировать его так, чтобы не нужно было делать проброс портов для SIP и RTP.
Зачастую, администраторы, которые настраивают удалённый телефон для подключения к IP-АТС, сталкиваются именно с проблемами включенного на маршрутизаторе SIP ALG. Дело в том, что SIP ALG может изменить сигнальные пакеты так, что АТС не сможет их распознать и телефон не сможет нормально зарегистрироваться. Поэтому если Вы столкнулись с проблемой подключения телефона, рекомендуем также обратить внимание на функционал SIP ALG Вашего маршрутизатора.
Многие производители включают его по умолчанию. Мы же рекомендуем либо правильно настроить его в соответствии с инструкцией от производителя, либо, если никаких других вариантов не осталось – отключить его.
Вот примеры названий данного функционала у разных производителей, но все они значат одно и то же:
SIP ALG
SIP Helper
SIP Fixup
SIP Markup
SIP Translation
Например на роутерах Mikrotik, чтобы отключить данный функционал нужно зайти в IP → Firewall → Service Ports и убедиться, что сервис SIP выключен.
Либо отключить его используя CMD Mikrotik: /ip firewall service-port disable sip
Проблемы при подключении более 1 телефонного аппарата из одной и той же удаленной точки
Представьте, что Вы пытаетесь зарегистрировать два удалённых телефона на своей IP-АТС. Пусть их внутренние номера будут 100 и 101. Когда эти телефоны будут отправлять запрос регистрации, то Ваша IP-АТС получит его от удалённого роутера, за которым находятся эти телефоны и запрос этот будет от одного и того же IP адреса. Может быть эти телефоны и зарегистрируются на АТС, но когда на один из этих номеров будет поступать вызов, то удалённый маршрутизатор не сможет разобраться на какой из телефонов его отправлять 100 или 101.
Лучшим решением данной проблемы – будет организация виртуальной локальной сети (VPN) между удалёнными точками и IP-АТС. Тогда телефоны, находящиеся в удалённых офисах смогут регистрироваться на IP-АТС как если бы они находились в одной локальной сети.