среда, 6 июня 2018 г.

MikroTik SIP Helper и зависшие регистрации

Как это обычно бывает, ты тратишь время на поиск истины в RFC, зарывшись в дампах трафика и исходников протокола, а кто-то за тебя это уже сделал. Ну что же, будет мне уроком. Все тоже самое, что тут, но на видео и с дополнительными картинками - https://www.youtube.com/watch?v=Anu6ZYg25yM

--------------------------------------------------------------------------------------------------------------------------
Пришло время расставить точки над И, и пояснить почему sip helper - это хорошо, и надо знать, когда его нужно отключать, а когда нет. А так же разобрать причины, по которым на MikroTik зависают сессии регистрации, в некоторых случаях падения канала связи.

Прежде всего давайте разберем основы SIP протокола и установки связи на примере Asterisk.
SIP - это транспортный протокол для SDP, и вот уже SDP определяет куда надо отвечать второму абоненту.

Давайте посмотрим на схему ниже:




На Asterisk NAT выключен, SIP Helper на микротике выключен. На микротике включен SRC-NAT masquerade, и DST-NAT TCP 5060, UDP 10000-20000 в сторону телефона.

SIP телефон успешно зарегистрировался на сервере, микротик создал трансляции ната, и держит соединения в connection tracking.

С номера 100 (192.168.1.100) совершают звонок на номер 200.

В SIP пакете, в поле Via будет стоять адрес 192.168.1.100 и порт 5060, а вот в IP - UDP/TCP заголовках благодаря SRC-NAT у нас будет стоять внешний IP адрес  - 1.1.1.1, и порт к примеру 5066
Согласно спецификации SIP протокола, он должен послать ответ на адрес и порт, указанные в поле Via. Получается, что телефон с номером 200 пошлет ответ на 192.168.1.100 5060, и естественно звонок не состоится.

Варианты решения данной проблемы:
1. Включаем на телефоне с номером 100 rport (RFC 3581), теперь в поле Via будет стоять метка rport, это сообщает серверу, что следует отвечать на порт из UDP/TCP заголовков, а не на значение порта поля Via. Если на телефоне включить rport нельзя, то следует на сервере Asterisk установить значение nat=force_rport. Хорошо с портом разобрались, а как быть с адресом, он ведь по прежнему будет его брать из поля Via. Для этого на Asterisk включается nat=comedia, или nat=force_rport,comedia (если на телефоне rport включить нельзя) таким образом сервер будет брать адрес из заголовков UDP/TCP. Ну и разумеется нам надо настроить DST-NAT на микротике на порты 5060 для SIP и 10000-20000 для голоса.

2. Включаем SIP Helper на микротике. Теперь когда телефон с номером 100 решит позвонить на 200, sip helper изменит ip и порт в поле Via на значения из IP - UDP/TCP заголовков. Так же он изменит значения полей SDP протокола, а именно owner, connection information на значения из IP - UDP/TCP заголовков. И по необходимости порт для принятия медиа потока, если таковой занят в таблице nat трансляций.  И все! Не надо DST-NAT, не надо трогать настройки nat в Asterisk.

Важный момент: SIP Helper работает только с SIP на порту 5060, он разумеется не сможет работать с SIP TLS, так как шифруется на оконечных устройствах. И он НИКАК не влияет на RTP!



SIP Helper + SIP Direct Media
Данная настройка позволит гонять напрямую медиа поток в следующей схеме:

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




Рассмотрим теперь проблему зависающих сессий.
Рассмотрим схему ниже:

















Теперь у нас есть туннель между нашими роутерами. Классическая схема основной офис - филиал.
Телефон 200 регистрируется на сервере 192.168.1.10
Никакого NAT, SIP-HELPER.
И тут падает интернет канал.. Первым делом естественно падает туннель. И если оно проваляется минут 5, то TCP сессия оборвется по таймауту. Телефон начнет слать пакеты на регистрацию, и они улетают по маршруту по умолчанию, который смотрит в с интерфейс провайдера. Создается запись в connection-tracking. И как только туннель поднимается обратно у вас ничего не работает, потому что соединение уже есть. Да нерабочее, но есть.

И тут несколько вариантов решения:
1. (Плохой вариант) Чистим все соединения с портом 5060 при падении туннеля.
2. (Хороший вариант) Делаем blackhole маршрут до 192.168.1.0/24 с метрикой больше, чем у оригинального маршрута до 192.168.1.0/24. Таким образом, если туннель упадет, blackhole маршрут станет приоритетным для данной подсети, соединение не поднимется, так как роутер будет дропать пакеты по этому маршруту до того, как для них создастся запись NAT трансляции в connection tracking!

вторник, 5 июня 2018 г.

RocketChat как мессенджер корпоративной сети

В связи с удорожанием доллара, экономического (очередного) кризиса в стране - все стремятся экономить. Наша организация тоже.

По сей день мы пользовались программой от Microsoft: Lync, которая ныне Skype for buisness.
И в принципе все хорошо, свой функционал она выполняет. Вот только каждая учетная запись заведенная на этом сервере - это CAL лицензия, которая стоит денег крайне не кислых, особенно, когда в организации порядка 5000 человек. Исходя из всего вышесказанного было принято решение искать замену.

Разумеется первый кандидат был jabber. Это проверенный годами вариант, стабильный, функциональный. Но, но, но. По сей день я действительно не видел ни одного клиента, который бы устроил полностью, как по внешнему виду, так и по функционалу. А перебирали мы их всем отделом. Где-то не устраивает сложность интерфейса, где-то откровенно пользователям не нравится внешний вид, понимаю, звучит немного бредово, но что поделать. Внешний вид тоже важен.

И тут я натыкаюсь на бесплатный аналог Slack - RocketChat. Поднимаю быстренько сервер, начинаю смотреть, ковырять. Есть интеграция с LDAP - супер! Прикручиваю, логинюсь и первые грабли...

Из LDAP каталога нашего домена для каждого пользователя должны существовать и быть заполненны 2 поля: sAMAccountName, email. У части пользователей email не заполнен. К счастью разработчики предусмотрели подобный сценарий, можно указать домен по умолчанию в настройках интеграции LDAP. И тогда у пользователя будет учетка вида login@домен_по_умолчанию. Я указал rocket.chat. Все, первая проблема решена. Пользователи смогли зайти.
Но тут снова проблема для имени в чате пользователя берется параметр cname из LDAP каталога. Но по какой-то причине он отображается в транслитерации на английский язык и с точками, как разделитель. То есть sizov.sergey.viktorovich вместо Сизов Сергей Викторович. Что сами понимаете не очень... Я потратил несколько дней, но нашел решение проблемы:

Заходим в администрирование:
1. Внешний вид - Пользовательский интерфейс - Использовать настоящее имя (включаем)
2. Общие настройки - UTF-8 - приводим к таком виду: [0-9a-zA-Z-_.а-яА-Я]+
3. LDAP - Sync / Import - Синхронизация пользовательских данных (включаем)

Вот эти пункты решили проблемы с отображением имени.

Обязательно отключаем возможность регистрации и восстановления пароля для пользователей. Иначе поверьте мне, они наплодят локальных учеток, а нам это не надо, так как у нас LDAP! =)

В целом чат хороший, функционал, внешний вид, все есть.
Из минусов:
1. Непривычный пользователям интерфейс (не классический стиль мессенджера, аля аська, жаббер, lync)
2. Пока что не сделали Kerberos аунтефикацию, следовательно не получится пользователей пускать прозрачно, надо вводить логин и пароль доменный. Но в Roadmap у них это есть, так что ждемс..

Хреновые провайдеры или MikroTik спасет мир

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

Чаще всего доступ дают через VPN, но не редки случаи, когда доступ предоставляется тупо через серую подсеть...То есть вам по DHCP выдают некий серый адрес, и далее вас NATят.
Про предоставление объединений я вообще молчу...Для некоторых L3VPN, VRF, или на худой конец VLAN - это что-то инопланетное.
Но в прочем статья не об этом. Не так давно столкнулся с интересной ситуацией. У меня на каждом объекте стоит микротик, который поднимает туннель до головного офиса и проблем, как правило не возникает. Не так давно с одного из объектов начали жаловаться. Мол беда беда, интернет есть, сервисы организации не работают. Начинаю смотреть, пинги бегают внутри туннеля без потерь, задержки вполне себе хорошие, порядка 80 мс. Но при попытке открыть корпоративный портал или иной сервис действительно вижу затык...Подсказал мне браузер, при открытии страницы нашего сервиса, он мгновенно прогрузил заголовки, я увидел <title> страницы. А вот содержимого нет...И тут меня озарило, конечно же MTU. Дабы не ломать туннель путем изменения MTU, я решил пойти другим путем - а именно поправить MSS налету. В современных прошивках MSS сразу выставляется под MTU интерфейса. Но мы то не пролезаем, в связи с чем я добавил новые правила:

/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn tcp-mss=1361-65535 action=change-mss new-mss=1360 disabled=no out-interface=my-tunnel-ppp

/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn tcp-mss=1361-65535 action=change-mss new-mss=1360 disabled=no in-interface=my-tunnel-ppp

Таким образом я зажимаю все данные (кроме заголовков) TCP пакетов в 1360 байт. Почему именно это значение? Опытным путем, понижал с 1390 до данного значения, пока не стабилизировалась работа. И это решило проблему. Убедившись, что странички наших сервисов и приложения стали работать корректно, я понизил MTU на туннельном интерфейсе, он переподнялся, и правила MSS отключил. Все работает. Все счастливы.