29 октября GitHub сообщил о новых IP-диапазонах для доставки вебхуков на github.com. Адреса уже добавлены в поле hooks ответа Meta API. На Mentoring.digital разбираем, кому нужно обновить сетевые правила и как отличить успешную доставку от выполненной задачи приложения.
В статический список нужно добавить три диапазона
Если сервер принимает вебхуки только с заранее разрешённых IP-адресов, GitHub рекомендует добавить следующие CIDR-префиксы к существующему списку:
9.234.98.160/289.234.98.176/289.234.106.48/28
Эти адреса дополняют прежние диапазоны, а не заменяют их. Изменение относится ко всем тарифам github.com, включая GitHub Enterprise Cloud. Если allowlist уже автоматически обновляется по Meta API, отдельных изменений ради этих дополнений не требуется.
Разрешённый IP не заменяет проверку запроса
Актуальный список адресов доступен через GET /meta. В рекомендациях GitHub также указаны HTTPS, включённая проверка сертификата и webhook secret для проверки происхождения и целостности сообщения. Секреты и ключи нельзя помещать в адрес получателя вебхука.
Обработчик должен проверить тип события и его действие. GitHub ожидает ответ 2XX в течение 10 секунд; длительную работу можно передать в очередь. При этом подтверждение приёма и завершение фоновой обработки остаются разными состояниями. Полезно связывать их в журнале, чтобы видеть, на каком этапе остановилась интеграция.
Как проверить изменение без лишних повторов
Сначала сохраните действующие правила и определите, где именно фильтруется входящий трафик. После добавления диапазонов проверьте тестовую доставку и ожидаемое действие приложения. Если сообщение не дошло, сопоставьте время попытки с журналом сетевого фильтра и обработчика, прежде чем повторять отправку.
Для защиты от повторной обработки пригоден идентификатор X-GitHub-Delivery. При запрошенной повторной доставке GitHub сохраняет исходное значение этого заголовка. Поэтому повтор нужно рассматривать с учётом уже выполненных действий, особенно если событие запускает запись данных.
Разобрать сетевые правила, очереди и наблюдаемость интеграции можно с наставником по DevOps и автоматизации разработки. Критерий проверки лучше определить заранее: нужное событие принято и обработано один раз, а доступ к получателю не расширен сверх требуемых правил.
