Asterisk: внешние транки в состоянии Request Sent

Знакомая картина?

[root@pbx scripts]# asterisk -x "sip show registry"
Host                                    dnsmgr Username       Refresh State                Reg.Time
sipnet.ru:5060                          Y      XXXXXXXXXXX         102 Request Sent           Fri, 20 Mar 2020 09:19:31
87.103.236.26:5060                      N      XXXXXX             105 Request Sent           Fri, 20 Mar 2020 09:20:55
sbc.megafon.ru:5060                     Y      XXXXXXXXXXX@       165 Request Sent           Fri, 20 Mar 2020 09:20:28
login.mtt.ru:5060                       Y      XXXXXXXXXXXXXX       105 Request Sent           Fri, 20 Mar 2020 09:19:50

Однажды она меня тоже достала, и я написал скрипт.

Пытался искать готовые рецепты, большинство сводилось к такому:

ну это значит что пакеты уходят, а ответы не приходят.
варианты
1) у вас нет интеренета.
2) у вас упал провайдер
3) у вас фаервол все блочит
4) у вас нет дефаулт гейтевея в системе.
попробуйте попингать те же адреса.. дебаг включите

Попингать адреса получалось, дебаг включал и видел в нём ровно то, о чем говорится в первом предложении цитаты «пакеты уходят, а ответы не приходят». Но почему?

Пункт №1 исключался элементарно. Пункт №2 — тоже, т.к. тестовое соединение с того же IP-адреса, но другого внутреннего хоста работало. Пункт №4 это совсем «жость». А вот №3 — уже ближе. Только не блочит, а почему-то не дает обмениваться пакетами именно хосту с Asterisk'ом.
И происходит это в 99% случаях после пункта №2, когда рвется PPPoE сессия. Сессия-то потом восстанавливается, и доступ в инет из локалки тоже, а вот UDP-сессии залипают.

Вот что нам говорит Mikrotik, через который эти сессии проходят:

[admin@MikroTik] > /ip firewall connection print where dst-address~":5060" and srcnat
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
 #          PR.. SRC-ADDRESS           DST-ADDRESS           TCP-STATE   TIMEOUT     ORIG-RATE REPL-RATE ORIG-PACKETS REPL-PACKETS      ORIG-BYTES
 0  SAC  s  udp  10.X.X.X:5060     80.75.130.83:5060                 59m48s           0bps      0bps        2 172        2 191       1 358 335
 1  SAC  s  udp  10.X.X.X:5060     193.201.229.35:5060               59m47s           0bps      0bps        1 611        1 662         996 786
 2  SAC  s  udp  10.X.X.X:5060     212.53.40.40:5060                 59m44s           0bps      0bps        1 837        1 830       1 114 259
 3  SAC  s  udp  10.X.X.X:5060     87.103.236.26:5060                59m21s           0bps      0bps        2 501        2 509       1 614 239

Это состояние сессий в нормальном режиме, когда всё работает. При отсутствии регистраций, если мне не изменяет память, отсутствует флаг S — seen-reply.

Пробуем срубить залипшие сессии командой:

[admin@MikroTik] > ip firewall connection remove [find where dst-address~":5060" and srcnat]

И, о чудо, буквально через секунду транки восстанавливаются, звонки идут, жизнь расцветает яркими красками! Значит пишем скрипт!

Первое — нам надо управлять Микротом на основе информации с Asterisk. Поэтому скрипт будет запускаться в cron каждые 5 минут на хосте с Asterisk, а управлять Микротом будем по ssh с сертификатом. Вот тут прекрасно всё расписано — как создать ключ и привязать его к новому пользователю на Микроте.

Ну и сам скрипт:

#!/bin/sh

if /usr/sbin/asterisk -x "sip show registry" | grep -q "Request Sent"; then
    echo "$(date) Resetting UDP connections on Mikrotik" >> /var/log/asterisk/mikrotik
    ssh -l admin-ssh -i /XXXX/.ssh/id_dsa 10.X.X.X 'ip firewall connection remove [find where dst-address~":5060" and srcnat]'
    sleep 2
    asterisk -x "sip reload"
fi

На всякий случай через 2 секунды после сброса зависших сессий обновляем регистрации — чтобы уж точно заработало!

С 04.09.2019 скрипт отработал 273 раза, судя по логу. Можно посчитать, сколько он сэкономил мне времени, а менеджерам и их клиентом нервов.

P.S. Подобная ситуация происходит на всех роутерах, которые мне попадались в связке с Asterisk. И только Микрот позволяет решить проблему без затрагивания других сервисов. Остальные роутеры надо тупо перегружать.

Комментарии 17

    0

    У меня стойкое ощущение того, что я прочитал первый вменяемо оформленный вопрос на тостере…
    По сабжу… на микротике лучше пишите скрипт.

      0
      А почему лучше на микроте?
        0
        Проблемы микротика логичнее решать на микротике.
        Вообще перирегистрация идет каждые 120 секунд. В норме так же показывает — 59минут?
          0
          Учитывая, что в скрипте вы всё равно коннектитесь к микротику, то лучше на микротике. А учитывая, что за сеть и телефонию могут отвечать разные люди, то могут такое решение не пропустить по безопасности.
        0
        Соединения залипают и при разрыве VPN сессий.
        Так получается потому что, если нужный маршрут unreachable, маршрут идет через таблицу main
        Помогает создать второй маршрут с бОльшей метрикой в сторону филиала и type=blackhole.
        Либо netwatch и по поднятию сессии дропать sip
          0
          Так вот в том-то и цимес, что при разрыве и последующем восстановлении VPN-соединений с филиалами SIP-сессии моментально восстанавливаются (ну, как моментально — в соответствии с таймером REFRESH) и работают без дополнительного возложения рук, а те, что проходят через NAT залипают.
            0
            Была похожая ситуация.
            Когда подключены к провайдеру через впн, то обычно маскарад настроен на двух интерфейсах, впн и физическом в сторону провайдера.
            Если падает впн с провайдером, то остаётся маскарад на интерфейсе в сторону провайдера, и нат сессии зависают на этом втором интерфейсе, даже после повторного подключения впн.
            Аналогичная ситуация возникает, когда подключены два провайдера с резервированием. Один провайдер упал, потом вернулся, а нат сессии остались висеть на резервном. Причём такое бывало и на cisco.
              0
              В случае резервирования должен быть скрипт, который заставляет Asterisk перерегистрировать транки через новый IP-адрес (другого провайдера). Я экспериментировал с этим, но пока устойчивого результата добиться не удалось.
                0
                Когда подключены к провайдеру через впн, то обычно маскарад настроен на двух интерфейсах, впн и физическом в сторону провайдера.

                А зачем так? Маскарад нужен исключительно для хостов локальной сети, чтобы выходить в интернет. VPN-же соединение до провайдера поднимает роутер — не хост внутри локалки, а роутер со своего пусть серого адреса, который ему выдал провайдер, но который находится внутри сети провайдера и с которого достижим, по крайней мере, адрес VPN-шлюза.
                  0
                  Иногда нужен доступ к локальной сети провайдера, например, вход в личный кабинет.
                  Да и вообще это же настройка по умолчанию.
                  А если вдруг роутер с филиалом переедет еще куда-то (как всегда без информирования ИТ), то с высокой вероятностью он может сразу начать раздавать интернет на новом месте, или человек по телефону сможет изменить статический адрес без ковыряния в дебрях фаервола.
            0
            net.ipv4.ip_dynaddr = 1 на микротике выставить представляется возможным?
              +1
              Вот прямо так указать возможности нет. В Микроте в разделе /ip firewall nat создается правило маскарадинга через WAN интерфейс, и оно срабатывает моментально при изменении его IP-адреса после реконнекта PPPoE сессии, например.
              В моем же примере на PPPoE интерфейсе адрес автостатический, т.е. его всё же выдает провайдер при поднятии сессии, но при этом всегда один и тот же.
              0
              Тоже была похожая ситуация с залипанием udp в sip трафике, но вроде только проблема с голосом была. Мне помогло /ip firewall service-port disable sip,
                +1
                Это тоже метод, но помогает далеко не всегда.
                И менять эту опцию надо совместно с настройкой NAT в Chan SIP/PJSIP.
                  0
                  В целом это так, но модуль nf_conntrack_sip, который и выгружает как я понимаю эта команда, умудряется иногда даже без nat создавать одностороннюю слышимость, столкнулся в первый с ней как раз на линуксе на котором и стоял астериск.
                  0

                  Это тот же sip alg, его надо в 100% случаев вырубать если между клиентами и сервером нат. Присутствует в любом роутере. Создан для поправки косяков циско-решений, которые не смогли сами в sip. Астеру сильно мешает.

                  0

                  Остальные роутера тупо работают годами и ничего не требуют.
                  Одни некротики мозг парят, задолбали… за статью спасибо. Буду на нее ссылку давать когда очередной сисадмин очередного клиента будет с пафосом "у нас МИКРОТИК!!1!" говорить на просьбу перегрузить роутер, и не верить что он причина проблем.

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

                  Самое читаемое