Почему Asterisk отвечает 403 Forbidden на SIP-запрос

SIP 403 Forbidden означает, что сервер понял запрос, но отказал в его выполнении. По одному коду нельзя заключить, что виноват пароль: проверьте, какой именно запрос получил отказ, сопоставлен ли он с endpoint и что сообщает журнал Asterisk. Ниже — последовательность проверки для chan_sip и PJSIP.

Что именно означает 403 в SIP

Начну с важной поправки: 403 — не синоним «неверный пароль». В RFC 3261 сервер сообщает этим ответом, что понял запрос, но отказывается его выполнять. В обычном digest-обмене телефон часто сначала получает 401, затем повторяет запрос с данными авторизации. Если в ответ пришёл 403, смотрите на причину отказа в контексте конкретного запроса и конфигурации. Код сам по себе не расскажет, какую строку исправлять. Это хороший способ потратить вечер на правильный пароль не в том месте.

Зафиксируйте метод запроса (обычно REGISTER, но это может быть INVITE), адрес и порт назначения, адрес источника, Request-URI и время ответа. Уточните, кто сформировал 403: сам Asterisk, пограничный шлюз, SIP-провайдер или другое устройство на пути. Если в трассировке нет исходящего от Asterisk ответа, расследовать конфиг Asterisk пока рано. Пакетная трассировка показывает последовательность, а журнал Asterisk помогает понять решение внутри приложения. Если нужна помощь с этой проверкой на рабочей АТС, мы оказываем ИТ-аутсорсинг для компаний.

Сравнивайте соседние сообщения, а не только последнюю строку обмена. Сервер мог выдать challenge, телефон повторил REGISTER, а затем получил итоговый отказ; это уже другая картина, чем одиночный 403 на первый запрос. Проверьте, совпадают ли Call-ID и CSeq у связанных сообщений, кому адресован запрос, и какой заголовок Authorization присутствует в повторе. Секретное значение заголовка не нужно сохранять в отчёте. Для рабочей диагностики достаточно оставить факт его наличия, схему авторизации и обезличенные имена. Если в ответе есть заголовок Reason или текстовое пояснение, зафиксируйте его дословно после удаления внутренних данных: конкретная реализация может указать полезную причину, хотя стандарт определяет общий смысл кода. Такой фрагмент вместе со временем события обычно сокращает поиск сильнее, чем перечень всех настроек АТС.

Я разделяю две задачи: регистрация телефона на вашей АТС и регистрация транка вашей АТС у оператора. В первой проверяем входящий REGISTER и настройки endpoint; во второй — исходящий REGISTER, объект registration и ответ удалённого сервера. Внешне симптом похож, но поля, которые надо сверять, различаются. Сначала назовите направление, потом открывайте конфиг.

В учебном разборе для условной сети «Вертикаль-Трейд» я бы попросил администратора приложить один полный обмен SIP и соответствующую запись журнала с тем же временем. Номера, домены и адреса перед передачей нужно обезличить. По одной строке «Forbidden» нельзя честно обещать ни исправление за минуту, ни виноватый пароль.

• Определите REGISTER это или INVITE
• Найдите источник ответа 403
• Сопоставьте пакет и запись журнала

Проверьте, распознал ли Asterisk endpoint

В PJSIP входящий запрос сначала должен быть сопоставлен с настроенным endpoint. Для сопоставления могут применяться идентификаторы пользователя или IP; выбор зависит от конфигурации и порядка модулей идентификации. Если номер в From не совпал с ожидаемым именем или адрес источника не подошёл к секции identify, Asterisk может отвергнуть запрос до проверки пароля. Поэтому факт «логин и пароль правильные» ещё не означает, что нужные настройки вообще участвовали в обработке.

Посмотрите список и конфигурацию через Asterisk CLI: pjsip show endpoints и pjsip show endpoint ИМЯ. Проверьте, что endpoint загружен, имеет связанные auth и aors, а если используется IP-сопоставление — что секция имеет type=identify, правильное endpoint и ожидаемый match. Не копируйте чужую подсеть вслепую: правило должно соответствовать адресу, который видит сама АТС после маршрутизаторов и NAT. Проверяйте доступ к CLI с правами администратора и не публикуйте вывод без очистки.

У PJSIP endpoint, auth, AOR и transport — разные объекты, хотя в бытовом разговоре их сваливают в один «аккаунт». Endpoint задаёт профиль SIP-устройства, auth — данные аутентификации, AOR — адреса контактов, transport — сетевой транспорт. Имя секции auth не обязано автоматически стать логином: сверяйте именно username, auth и связи между секциями. В документации Asterisk есть пример, где отсутствие type=endpoint приводит к тому, что раздел не виден как endpoint. Подробный разбор структуры конфигурации есть в статье о настройке PJSIP в Asterisk.

Для старого chan_sip проверяйте peer через sip show peer ИМЯ и правила, назначенные этому peer или общему разделу. Команда sip show peers выводит список, а не доказывает успешную регистрацию в каждом случае. Имена и доступность CLI-команд зависят от того, загружен ли соответствующий канал-драйвер. Если консоль отвечает No such command, это повод проверить модуль, а не вводить команду десять раз с надеждой на уважение со стороны терминала.

• PJSIP: endpoint, auth, AOR, identify
• chan_sip: peer и его правила
• Сверьте реальный адрес источника

Сверьте имя пользователя и аутентификацию

Когда endpoint найден, сравните данные в конфигурации АТС с настройками телефона или транка: имя пользователя, realm, тип digest-аутентификации и пароль. Учитывайте регистр и пробелы при копировании. Для PJSIP проверьте секцию type=auth, на которую указывает auth endpoint; для chan_sip — параметры peer в конфигурации, соответствующей вашей версии и способу управления. Если используется хешированный credential, проверьте алгоритм и формат по документации установленной версии. Не переносите готовый MD5 между пользователями: расчёт связан с именем и realm.

Не пытайтесь «посмотреть текущий пароль» командой sip show peer или pjsip show endpoint: эти команды предназначены для диагностики объекта и не должны рассматриваться как хранилище открытых секретов. В PJSIP вывод endpoint показывает связи и свойства, но не обязан показывать исходный пароль. Если значение потеряно, задайте новое согласованное значение в конфигурации и на устройстве, сохраняя его в защищённом менеджере секретов. Утёкший пароль не становится безопасным оттого, что он случайно был напечатан в терминале.

После изменения перечитайте конфигурацию подходящим для используемого драйвера способом и проверьте журнал на ошибки загрузки. Для PJSIP в обычных ситуациях доступна команда pjsip reload, однако изменения транспортных секций могут требовать отдельного подхода: параметры transport не всегда перечитываются при reload, если не включён соответствующий механизм. Для chan_sip команда и область перезагрузки отличаются. Не запускайте на рабочей АТС случайные команды массовой перезагрузки, пока не проверили влияние на активные вызовы.

Здесь полезно сравнить не только пароль. На телефоне отдельно задаются адрес сервера, порт, транспорт, SIP ID и иногда имя для авторизации; они могут различаться. Для исходящей регистрации транка сопоставьте сервер, пользовательскую часть Request-URI, From и auth username с тем, что ожидает оператор. Если ошибка повторяется только у одного устройства, сравните его профиль с заведомо рабочим по полям, а не меняйте всё подряд. Если проблема относится к исходящей регистрации у оператора, дополнительно пригодится разбор про SIP-транки и IP-телефонию.

• Сверьте username и realm
• Проверьте связь endpoint → auth
• Не выводите и не пересылайте секреты

Проверьте ACL, identify и сетевой периметр

ACL может дать отказ, но правила зависят от драйвера и места, где они применены. В chan_sip используются свои параметры доступа, например permit и deny; для PJSIP IP-сопоставление обычно настраивают объектом identify с match, а ACL — отдельной конфигурацией ACL, если она нужна. Это не одна универсальная директива acl=подсеть внутри любого transport. Сверьте синтаксис с документацией конкретной ветки Asterisk и действующим конфигом, прежде чем править.

Проверьте адрес источника в SIP-пакете, видимый серверу. За NAT он может отличаться от адреса, который показывает интерфейс телефона. Затем сверьте его с match/правилами доступа и правилами сетевого экрана. Слепая команда iptables -L | grep 5060 не отвечает на вопрос, почему появился SIP 403: она может не показать правила nftables, облачный экран, другой интерфейс или правило без упоминания порта в комментарии. Используйте штатную систему управления firewall и проверяйте всю цепочку от устройства до АТС.

ACL и firewall решают разные задачи. Firewall может не пропустить пакет вообще; тогда обычно не будет SIP-ответа от Asterisk. Если сервер получил запрос и отправил 403, смотрите логи приложения, сопоставление endpoint и правила доступа. Но ответ мог сформировать и другой узел. Поэтому сначала подтвердите адрес источника и отправителя ответа, а после меняйте только то правило, которое действительно соответствует симптомам.

Если администратор меняет сеть, запишите исходные значения и сделайте изменение с планом отката. Откройте SIP только для нужных адресов и только необходимыми протоколами, если инфраструктура это позволяет; широкий доступ ко всему интернету не нужен для диагностики регистрации. Убедитесь, что после правки не расширили права другим endpoint. Защитное правило, которое блокирует собственный телефон, неприятно; правило, которое случайно пустило всех, неприятнее и дольше объясняется.

• Сверьте адрес, который видит Asterisk
• Проверьте именно драйверные правила
• Разделяйте firewall и SIP-отказ

Отделите NAT и SIP-ALG от причины 403

NAT чаще проявляется проблемами достижимости, контактного адреса или односторонним звуком. SIP-ALG может переписывать SIP-сообщения и усложнить разбор трассировки. Но из этого не следует, что любой 403 вызван NAT или ALG: если пакет дошёл до приложения, а приложение ответило отказом, сначала ищите причину в обработке самого запроса. Отсутствие звука после регистрации — отдельная задача, не объяснение отказа REGISTER.

Если есть основания подозревать ALG, временно отключайте его только по согласованному окну и фиксируйте результат сравнимой SIP-трассировкой до и после. Сам факт наличия MikroTik или другого маршрутизатора не доказывает, что он изменил пакет. В экспертной базе есть практическая рекомендация отключать SIP-ALG на MikroTik для VoIP; воспринимайте её как проверяемую гипотезу, а не как универсальный рецепт для любого устройства и любой сети.

Параметры NAT зависят от используемого драйвера и топологии. Для chan_sip могут применяться настройки внешнего адреса и локальных сетей; в PJSIP настраиваются соответствующие параметры endpoint и transport по документации. Не копируйте пример внешнего адреса из чужого конфига: укажите значение, которое действительно назначено вашей сети. Настройка directmedia влияет на то, как передаётся медиатрафик; сама по себе она не исправляет неверную аутентификацию SIP.

В условном кейсе «Вертикаль-Трейд» я бы проверял NAT только после того, как увидел расхождение между Contact/Via и фактическим адресом или подтвердил переписывание заголовков. Если таких признаков нет, не трогаю маршрутизатор ради ритуала. Даже полезный совет превращается во вредный, когда его применяют без симптома. Для общей проверки границ доступа полезно свериться с материалом о защите Asterisk от атак.

• Ищите изменения Via и Contact
• Проверяйте ALG сравнительной трассой
• Не смешивайте регистрацию и аудио

Соберите диагностику и внесите одну правку

Для PJSIP официальный troubleshooting guide предлагает на время воспроизведения повысить детализацию и включить SIP-журналирование через core set verbose 4, core set debug 4 и pjsip set logger on. Для chan_sip используется собственный отладчик sip set debug on, если модуль загружен. Включайте подробный журнал на короткий период: трассировка может содержать внутренние адреса, номера и данные вызовов. Перед отправкой снимите секреты и персональные данные, затем выключите отладку.

Путь /var/log/asterisk/full распространён, но его наличие и содержание зависят от logger.conf, пакета и установки. Проверьте активные каналы логирования в своей системе и время события с часовым поясом. Не считайте core show log универсальной командой для чтения любого файла: сначала уточните поддерживаемые команды вашей версии через CLI help. Важна не красивая строка ошибки, а связка из времени, драйвера, endpoint, исходного запроса и ответа.

При чтении дампа сопоставьте направление каждого сообщения и его пару запрос–ответ. Via помогает проследить маршрут через SIP-узлы, From и To показывают заявленные стороны диалога, Call-ID связывает сообщения одного диалога, а CSeq помогает установить порядок запросов. Contact важен для адреса, по которому устройство предлагает связаться с ним; за NAT он может отличаться от ожидаемого, но одно такое отличие не доказывает причину 403. Не редактируйте исходный захват: сохраните оригинал с ограниченным доступом и отдельно подготовьте копию для разбора. Перед передачей удалите Authorization, номера, домены и внутренние IP; при этом оставьте направление, последовательность и типы полей, иначе диагностическую ценность можно вырезать вместе с чувствительными данными.

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

Если CLI показывает endpoint как Unavailable, это не равно 403 и не является универсальным признаком неправильного пароля. Состояние зависит от контакта, qualify и роли устройства. Аналогично, pjsip show endpoints перечисляет endpoint, а не доказывает, что каждый телефон успешно зарегистрирован. Для подтверждения смотрите AOR/contact и конкретный REGISTER в трассировке. В chan_sip проверяйте peer и последний контакт в терминах своей версии.

В «Вертикаль-Трейд» план работ был бы простым: определить, кто отвечает, подтвердить выбранный endpoint, сверить auth и затем проверить ACL или сетевой путь по найденному признаку. В отчёте я оставил бы исходный и исправленный фрагмент без секретов, причину и способ отката. Это позволяет следующему администратору не начинать расследование с фразы «кажется, после перезагрузки как-то заработало».

• PJSIP: `pjsip set logger on`
• chan_sip: `sip set debug on`
• Одна гипотеза — одна правка — повтор

Частые вопросы