Home » Asterisk » Ошибка asterisk — Sending fake auth rejection for device

Ошибка asterisk — Sending fake auth rejection for device

На днях менял в офисе шлюз freebsd на mikrotik. Сразу скажу зачем это делал, чтобы не было вопросов. Freebsd была очень старая, обслуживать или что-то настраивать на ней было неудобно, пришло время ее заменить. Перенес все настройки, в том числе и проброс портов со старого шлюза на новый. В сети стоял астериск за nat и с одним номером возникли проблемы.

На asterisk было настроено несколько номеров одного оператора, но при этом сервера у пиров были разные. Рекомендованную конфигурацию пира для астериск оператор присылает сам. Все три пира были настроены одинаково. Но при этом после замены шлюза входящие звонки на один из номеров не проходили. После набора сразу был отбой, в логе asterisk возникала следующая ошибка:

[Dec 17 15:34:24] NOTICE[10488]: chan_sip.c:22041 handle_request_invite: Sending fake auth rejection for device "79689056609" <sip:79689056609@85.94.35.218:5060>;tag=SDih80801-as0469f3b0
79689056609Номер, с которого я звонил для теста
85.94.35.218IP сервера оператора

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

Было понятно, что проблема как-то связана с заменой шлюза, но вот как именно, совершенно не было идей. Проброс портов сделал обычным образом, как всегда это делается в mikrotik, вариантов там особо нет, на борту iptables. Сверил настройки с другими микротиками, где есть проброс портов астериска, все то же самое. Обычно проблем не возникает.

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

Начал гуглить. Такая ошибка возникает в двух случаях:

  1. Сервер каким-то образом ломают, подбирая пароли.
  2. Сетевая ошибка, связанная с nat и пробросом портов.

Понятно, что первый случай не мой. К тому же я жестко ограничил доступ к asterisk через firewall, так что вопросы безопасности меня не волнуют вообще в данном случае. В одном обсуждении я заметил, что человек, описывая свою проблему, упомянул, что у него в настройке пира указан параметр insecure=port,invite. Я проверил у себя этот параметр, там стоял только invite. Добавил к нему port и все заработало.

Посмотрел описание этих параметров:

portигнорировать номер порта, с которого пришла аутентификация
inviteне требовать начальное сообщение INVITE для аутентификации
port,inviteне требовать начальное сообщение INVITE для аутентификации и игнорировать порт, с которого пришел запрос

Откровенно говоря, я не понял, что конкретно это означает и почему мне с одним пиром это помогло решить проблему, хотя два других работают без параметра port. И почему мне пришлось поменять этот параметр в связи с заменой шлюза. Подозреваю, что этот как-то связано с настройкой сервера провайдера, так как все пиры работают с разными серверами.


Помогла статья? Есть возможность отблагодарить автора

2 комментария

  1. Здравствуйте.
    Решил поделится своей проблемой связки Mikrotik Asterisk.
    У меня несколько центральный офис и несколько удаленных площадок. В офисе, в качестве маршрутизатора, поднят Mikrotik CHR в ВМ( использовать маршрутизатор Mikrotik, при наличии Hyper-v, получается дороже и менее удобно), на площадках маршрутизаторы Mikrotik. Между офисом и площадками подняты VPN. На обоих концах прописаны прописаны маршруты, NAT не используется.
    В офисе в ВМ поднят Asterisk. В офисе и на площадках у клиентов установлены IP телефоны, шлюзы и софтфоны на ПК.
    В процессе эксплуатации вылезла следующая беда, периодически, не предсказуемо, начали отваливается клиенты, как на площадках, так и в офисе. Помогало только принудительная смена IP на оконечном оборудовании. Я так и не понял в чем проблема. Помогло Disable SIP Firewall\Service Ports во всех RouterOS. Это относится к ALG, но у меня все SIP соединения не проходят через NAT. Я так понимаю у Mikrotik криво реализован ALG SIP. Возможно Ваша проблема тоже была в этом.

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

Добавить комментарий

Ваш e-mail не будет опубликован.