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!

Хреновые провайдеры или 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 отключил. Все работает. Все счастливы.

Проброс DLNA в удаленную сеть

Предистория:

Итак, появилась необходимость дать возможность просматривать фильмы с моего сервера на телевизоре. Ну казалось бы, поднимаем DLNA, например miniDLNA и проблема решена. Так и было, пока не появилась нужда дать такую же возможность родителям, которые живут в другом месте, и ставить им там сервер или простенький nas не совсем правильный путь. Было принято решение объединить наши сети путем туннелирования траффика и дать доступ к моей фильмотеке.

Подготовка:

У родителей я уже давно поставил отличный роутер, с которым я давно работаю, и доверяю - Mikrotik 951Ui 12HnD. Кто не знаком с этим великолепным маршрутизатором, советую познакомиться. Ценовая политика позволяет подобрать решения как  для дома, так и для офиса. При этом получаем функционал, как у дорогих enterprise решений.

У меня в квартире так же стоял Mikrotik, лишь с одним отличием, у меня были все порты гигабитные. Я не долго думая поднял pptp туннель и тут началось...

Первые проблемы:

В отличии от классического способа передачи потокового аудио и видео сегмента данных DLNA несколько отличается. И это сразу стало понятно, после того как я посниффил траффик. Через PPTP некоторые запросы пробегали, некоторые нет. После того как я изучил дамп траффика, пришел к следующим выводам:

1. Со стороны сервера мы должны увеличить ttl траффика от DLNA сервера, я увеличил на 100.
2. Установить пакет multicast на микротики, и включить PIM на интерфейсы туннеля.
3. Не забываем прописать маршруты до локальных сетей за туннелями.
4. Со стороны сервера DLNA прописываем маршрут 239.255.255.250 в качестве шлюза указываем туннельный интерфейс.

Казалось бы, все предусмотрел, я на телевизоре родителей увидел свой DLNA сервер, подключился к нему, открыл фильм, и тут я успел увидеть 2 кадра и все. Он просто отключился от сервера. Я начал заново, пробежался по всей конфигурации на обоих маршрутизаторах, грешил на фаервол, на все. Потом опять взглянул на дамп траффика и увидел то самое.."don't fragment". И тут меня осенило! Размер пакета превышает MTU, который нам предоставляет PPTP, а фрагментировать нельзя! К сожалению в настройках miniDLNA сервера я не смог найти возможность ограничить длину пакета.

Победное решение:

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

Еще можно попробовать ограничить mtu на интерфейсе, к которому подключен NAS. В таком случае пакеты будут заведомо с небольшим MTU, который пролезет в любой туннель.

Дополнение:

Не стоит забывать что просмотр фильмов - это нехилая нагрузка на сеть в плане ширины канала. Когда в пределах локальной сети, не страшно, а вот между сетями, когда ширину канала контролирует провайдер...В общем всем советую включить QoS, отдать приоритет своему серверу, и любым подключениям к нему, а мы можем и подождать дополнительных 10 мс для открытия странички =)

Если кого интересуют подробности, пишите, помогу с настройкой, поделюсь конфигами.