Cloudflare исправила передачу контекста Workers при запросах к BYOIP

Cloudflare исправила передачу контекста Workers при запросах к BYOIP
Содержание статьи

30 октября Cloudflare сообщила об исправлении обработки подзапросов Workers к проксируемым доменам с BYOIP. Теперь такой трафик сохраняет контекст Worker и распознаётся как соединение между сервисами Cloudflare. На Mentoring.digital объясняем, почему это важно для правил защиты и журналов приложения.

Что раньше могло теряться по дороге

BYOIP позволяет организации использовать собственные IP-префиксы в инфраструктуре Cloudflare. Это возможность Enterprise. В затронутых подзапросах к таким адресам прежде могли теряться контекст Worker и признаки исходного клиента. По сообщению Cloudflare, это приводило к неожиданному поведению правил безопасности, оценке внутреннего соединения в Bot Management и ложным ответам 403.

После изменения сохраняются заголовок CF-Worker и поле cf.worker.upstream_zone. Оценка бота, признак проверенного бота и отпечатки JA3/JA4 на принимающей зоне относятся к исходному пользовательскому соединению.

Адрес клиента зависит от границы зоны

Для запроса из одной зоны Cloudflare в другую значение CF-Connecting-IP устанавливается в 2a06:98c0:3600::103. Это предусмотренное защитное поведение. Внутри одной зоны заголовок продолжает отражать клиентский IP через x-real-ip; документация отдельно отмечает, что Worker может менять x-real-ip.

Поэтому одинаковый служебный адрес в журнале межзонных запросов сам по себе не означает потерю всех признаков клиента. Также не следует переносить проверку заголовка CF-Worker напрямую в пользовательское правило WAF: оно исполняется до добавления заголовка. Для этого случая документация предлагает поле cf.worker.upstream_zone.

Что проверить в своей цепочке запросов

Начните со схемы: откуда Worker отправляет запрос, относится ли получатель к той же зоне и используется ли BYOIP. Затем сопоставьте журнал приложения с событиями защиты для одного тестового обращения. Проверьте ожидаемый статус ответа, определение исходной зоны и те признаки клиента, на которые действительно опираются ваши правила.

Если раньше для обхода ложного 403 создавали исключение, сначала выясните его назначение и проверьте сценарий на тестовой конфигурации. Сам анонс не доказывает, что каждое исключение уже можно удалить. Разобрать цепочку проксирования и условия правил поможет наставник по DevOps и сетевой инфраструктуре.

Похожие статьи по данной теме