Необходимые сетевые доступы

Коробочный Битрикс24 развернут в сети компании, а приложение — на своем сервере, поэтому запросы между ними проходят через корпоративный фаервол. Если нужное направление закрыто, приложение не устанавливается, а события не доходят до обработчика.

Для облачного Битрикс24 настраивать доступы не нужно: облако доступно из интернета. Правила ниже применяйте, когда в закрытом периметре находится коробочный Битрикс24, сервер приложения или обе стороны сразу.

Настройка самого фаервола, NAT и прокси остается за администратором сети.

Как проходят запросыКак проходят запросы

Событие идет от коробочного Битрикс24 на сервер авторизации, затем сервер очередей отправляет POST-запрос обработчику. Поэтому на стороне коробочного Битрикс24 отдельный доступ к серверам очередей не нужен: достаточно исходящего доступа к серверу авторизации. На стороне приложения нужны входящие запросы от серверов очередей. Механизм описан в разделе События.

Обработчики исходящих вебхуков вызываются с тех же серверов очередей — отдельных направлений для них открывать не нужно.

Схема меняется, если в коробочном Битрикс24 подключен свой провайдер авторизации. Тогда сервер авторизации Битрикс24 из схемы исключается, а события уходят прямым POST-запросом с самого коробочного Битрикс24. В этом случае доступ к серверу авторизации и к серверам очередей не нужен, а на сервере приложения открывают входящие запросы от коробочного Битрикс24.

Направления в таблицах указаны с точки зрения настраиваемого сервера: исходящие — запросы, которые он отправляет сам, входящие — запросы, которые он принимает. В строках с исходящими запросами адрес — это назначение, в строках с входящими — источник. Протокол https использует порт 443, http — порт 80.

Доступ рабочих мест сотрудников к серверу приложения здесь не рассматривается — правила ниже описывают только обмен между серверами.

Доступы на стороне коробочного Битрикс24Доступы на стороне коробочного Битрикс24

Адрес сервера зависит от конкретного приложения. Для своего приложения это адрес вашего сервера. Для чужого — адрес из описания в Битрикс24 Маркетплейсе; если его там нет, запросите адрес у разработчика.

Адрес для названий событийАдрес для названий событий

Выберите домен по региону своего Битрикс24.

Доступы на стороне сервера приложенияДоступы на стороне сервера приложения

Обработчик должен принимать входящие запросы с типом данных application/x-www-form-urlencoded — в этом формате приходят данные вызова. Проверьте, что фаервол или прокси не отбрасывает такие запросы.

Открытый входящий доступ не подтверждает, что запрос пришел от Битрикс24, поэтому проверяйте в обработчике параметр application_token. Принимайте вызовы по https: по http токен и данные события идут открытым текстом. Порядок проверки описан в статье Рекомендации по безопасности в приложениях на REST API.

Как получить список IP-адресов серверов очередейКак получить список IP-адресов серверов очередей

Входящие запросы приходят от динамической группы серверов, ее также называют scale-based. Размер группы меняется под нагрузкой, поэтому набор IP-адресов непостоянный. mp_actions-* — это шаблон имени группы: конкретные адреса в нем не заданы, поэтому правила фаервола строят по списку IP-адресов.

Актуальный список возвращает запрос:

curl https://repos.1c-bitrix.ru/webhook/app.json

Ответ, количество адресов в нем меняется:

{
    "nodes": ["195.208.184.200", "89.208.230.2"]
}

Адреса из массива nodes используйте в правилах фаервола для входящих соединений в корпоративной сети или на коробочной виртуальной машине.

Новый сервер попадает в список nodes за 5-10 минут до того, как с него начнут приходить вызовы. Опрашивайте адрес раз в 5-10 минут. Отправлять запрос чаще одного раза в минуту нельзя. Обновление правил по списку nodes поставьте на расписание.

Ранее компания «1С-Битрикс» указывала конкретные IP-адреса, которые нужно было открывать для запросов. Сейчас фиксированный список IP-адресов используют только для серверов очередей и берут его из nodes. Правила для остальных направлений задают по доменным именам.

Как проверить доступКак проверить доступ

Исходящий доступ проверьте с сервера, на котором настраивали правила. Запрос должен вернуть ответ сервера, а не ошибку соединения или таймаут.

curl -I https://oauth.bitrix24.tech/

Успешный ответ начинается со строки статуса:

HTTP/2 200

Сообщения Connection timed out и Connection refused означают, что доступ закрыт.

Входящий доступ к обработчику проверьте с внешнего хоста, который не входит в сеть компании. Параметр -d отправляет запрос с типом данных application/x-www-form-urlencoded — в таком же формате приходят вызовы от серверов очередей. Обработчик должен ответить, а не оборвать соединение.

curl -d "test=1" https://example.com/handler.php

Продолжите изучениеПродолжите изучение

• Особенности REST API в коробочной версии Битрикс24
• Рекомендации по безопасности в приложениях на REST API
• Полный протокол авторизации OAuth 2.0
• События: обзор методов и событий
• Входящие и исходящие вебхуки