Jump to content
Калькуляторы

Mikrotik два канала в интернет и SIP

Есть два "интернета" от разных провайдеров на микротике, за микротиком 3 SIP устройства за НАТом. Все три коннектятся к внешнему астериску.

Первый интернет "падает" Скрипты благополучно удаляют дефолтный маршрут на упавший интернет и основным становится маршрут на резервный канал. SIP устройства благополочно переавторизовываются и работают через резерв.

А вот дальше - интересно:

Восстанавливается основной интернет. Маршрут на него включается, все пакеты с момента включения как-бы должны идти через новый канал но SIP регистрация при этом падает и не восстанавливается пока руками не удалить из таблицы fierwall -> connectoins  соединения смотрящие на SIP сервер.

Это так и должно быть ? если да, то как настроить чтоб небыло таких проблем ?

SIP ALG включен, прошивка - последняя.

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

Получается что он, несмотря на смену маршрутизации, что-то все-равно пытается слать по старой памяти через резервный канал.

В принципе если объясните мне почему так происходит - думаю до решения я и сам додумаюсь.

Заранее спасибо.

Share this post


Link to post
Share on other sites

conntrack

Это понятно, что conntrack, почему он не разваливается по таймауту после того как маршрутизация поменялась ?

И что в таких случаях полагается делать ?

Share this post


Link to post
Share on other sites

Можно, конечно, тупо в переключающий скрипт прописать удаление всех коннекшеннов с этим Reply Dst. Address

Но, по моему мнению, должен быть же какой-то штатный механизм, который при правильной настройке приведет к тому, что нерабочие коннекшены протухнут и умрут.

Под нерабочими я понимаю те, через которые нет двунаправленного потока данных.

Подскажите куда смотреть

Share this post


Link to post
Share on other sites

И, у меня такое ощущение, ято такое залипание только у SIP соединений имеет место быть. А значит это как-то связано с SIP ALG ?

Share this post


Link to post
Share on other sites

Пока ищу красивое решение, прописал в скрипт:

/ip firewall connection remove [find reply-dst-address~"XXX.XXX.XXX."]

Работает. Но основного вопроса это не отменяет ;)

Share this post


Link to post
Share on other sites

grifin.ru, соединение однажды установленное будет считаться живым, пока не прилетит явный "fin" или не истечет таймаут бездействия.

Для udp-based SIP важен как раз таймаут. Поскольку в соединении пролетают пакеты qualify, registration renew - в соответствии с sip registration interval, оно постоянно обновляет счётчик-таймер таймаута и соединение поддерживается "живым". Это нормальное поведение.

Так, что Ваш путь - только принудительно сбрасывать состояния соединений при восстановлении основного провайдера.

Edited by nkusnetsov

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

А какая разница ?

На самом деле так и сделано. Прописано два дефолта в разных таблицах и в манагле маргируются роуты. Но там я еще много проблем словил:

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

Потом долго бился с глюками, пока не догадался отключить fasttrack.

При включенном fasttrack маршрутизация первого пакета в соединении шла правильно а потом (когда в  forward'е fasttrack включался, больше пакеты правилами FW не маркировались и все летело через MAIN таблицу. Много времени потерял, пока это понял.

Может, кстати, и первя проблема была из-за fasttrack ?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Зачем, я просто рублю коннекшены которые построены через отключаемое соединение.

Share this post


Link to post
Share on other sites

Зачем, я просто рублю коннекшены которые построены через отключаемое соединение.

 

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

 

Когда вы обрываете соединения на роутере, соединения на абонентских устройствах не обрываются. Именно по этой причине нужно обрывать все абонентские сессии, или делать такие действия, которые позволят оборвать соединения/физические подключения на всех абонентских устройствах, что бы они поняли что связь обрывалась.

Share this post


Link to post
Share on other sites

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

Вы предлагаете оборвать принудительно все сессии. Зачем ? Те, которые пропадут - пропадут сами. Зачем рва те, которые смогут продолжить работать ?

Тем более когда я рву НАТ коннекшены то новые установятся скорее всего, уже с другим номером исходящего порта.

Share this post


Link to post
Share on other sites

Если вы вынесете НАТ на 2 сторонних микротика, а управлять кто куда идет будете с третьего, то никаких проблем не будет.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this