Резюме данного текста

  • Проксирование через Cloudflare скрывает реальный IP клиента на уровне L4.
  • Firewall на уровне L4 видит только IP Cloudflare, а не клиента.
  • OpenResty на L7 видит реальный IP клиента.
  • Блокировка на уровне L7 эффективнее.
  • Без проксирования можно использовать fail2ban на уровне L4.

Исходный запрос

Pasted image 20250307183811.png
Исходя из этой схемы видно, что client = 89.108.123.5
На L7 Уровень приложения (Прикладной) навешивается заголовок с адресом 89.108.123.5, а по L4 Транспортный уровень отправляется идентичный заголовок.

Обработка запроса Cloudlfare

Когда пакет попадает на Cloudflare, у него на L7 Уровень приложения (Прикладной) навешивается два заголовка:

Однако на L4 Транспортный уровень отправляется только адрес CF-сервера — 192.168.0.1.

Фильтрация трафика

Firewall находится на L4 Транспортный уровень, а nginx на L7 Уровень приложения (Прикладной).
Это значит, что в случае, например, DDoS-атаки, Firewall не будет видеть трафик с 89.108.123.5 — он будет видеть только то, что присылает ему Cloudflare (192.168.0.1).

Блокировка IP на уровне Openresty

Однако OpenResty работает на L7 Уровень приложения (Прикладной) и видит 89.108.123.5 в заголовках. Поэтому блокировка IP-адреса на уровне L7 Уровень приложения (Прикладной) сработает.

Альтернативный вариант

Если бы проксирование к домену, на который высылал запрос клиент, было отключено (DNS Only), то можно было бы использовать fail2ban, который работает на уровне L4 Транспортный уровень и блокирует IP через iptables.

Другой вариант - это заблокировать IP-адрес прямо на уровне Cloudflare, если мы используем проксиварие. Но там, насколько я помню, есть лимиты на количество IP-адресов + помимо этого, пришлось бы добавлять нежеланный нам IP-адрес для каждого домена. Заблокировать на уровне Cloudflare, в этом плане, проще.