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

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

Углубленный онлайн-курс по MikroTik

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

На 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.218 IP сервера оператора

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

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

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

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

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

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

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

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

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

Для отладки и тестирования работы voip я рекомендую сервис Zadarma. Плюс его в том, что после регистрации вы получите настройки пира для внутренней сети оператора. И внутри этой сети вы можете бесплатно звонить. Например, я одного пира регистрирую на sip клиенте смартфона и с него звоню на второй аккаунт, пир от которого настроен в астериске. Таким образом эмулирую внешний звонок. Удобно отлаживать различные конфигурации звонков, не требуя платного подключения.

Другие материалы по asterisk:

Онлайн-курс по устройству компьютерных сетей.

На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

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. После перехода на резерв и возврата обратно на основу, не регистрировались внешние пиры. Помогал сброс соединения этих пиров на шлюзе, либо просто его перезагрузка. Подсказал такое решение саппорт одного из провайдеров, то есть проблема известная. Я сталкивался в разных местах с этой ошибкой. Может у тебя тоже самое было.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar