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

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

Онлайн курс Основы сетевых технологий

Теоретический курс с самыми базовыми знаниями по сетям. Курс подходит и начинающим, и людям с опытом. Практикующим системным администраторам курс поможет упорядочить знания и восполнить пробелы. А те, кто только входит в профессию, получат на курсе базовые знания и навыки, без воды и избыточной теории. После обучения вы сможете ответить на вопросы:
  • На каком уровне модели OSI могут работать коммутаторы;
  • Как лучше организовать работу сети организации с множеством отделов;
  • Для чего и как использовать технологию VLAN;
  • Для чего сервера стоит выносить в DMZ;
  • Как организовать объединение филиалов и удаленный доступ сотрудников по vpn;
  • и многое другое.
Уже знаете ответы на вопросы выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов в случайном порядке. Поэтому тест можно проходить несколько раз без потери интереса. Бесплатно и без регистрации. Все подробности на странице .

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

Автор Zerox

Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству.

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. Возможно Ваша проблема тоже была в этом.

    • Zerox

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

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

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

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.