- Проксирование через Cloudflare скрывает реальный IP клиента на уровне L4.
- Firewall на уровне L4 видит только IP Cloudflare, а не клиента.
- OpenResty на L7 видит реальный IP клиента.
- Блокировка на уровне L7 эффективнее.
- Без проксирования можно использовать fail2ban на уровне L4.
Исходный запрос
Исходя из этой схемы видно, что client = 89.108.123.5
На L7 Уровень приложения (Прикладной) навешивается заголовок с адресом 89.108.123.5, а по L4 Транспортный уровень отправляется идентичный заголовок.
Обработка запроса Cloudlfare
Когда пакет попадает на Cloudflare, у него на L7 Уровень приложения (Прикладной) навешивается два заголовка:
- Адрес сервера CF
- Адрес клиента (89.108.123.5)
Однако на 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, в этом плане, проще.