Как сеанс TCP работает в решении DSR Load Balancer (L4)?
Представим, что клиент A просматривает прямой поток (который преобразуется в набор HTTP-запросов) с включенным заголовком keep-alive .
A -r-> LB-----> R1 --|
/|\ |-----> R2 --|
| ------> R3 --|
|---R----------------|
Возможно ли, что этот DSR (прямой возврат сервера) Load Balancer (L4) предлагает метод наименьшего соединения ?
Если да, то как реалы работают с TCP Последовательность чисел? (а также для keepalive соединения) Поскольку для каждого нового клиентского соединения
Таким образом, я не могу запретить входящий IP-адрес через iptable.
Я вижу только два способа:
- Настроить nginx для использования X-Forwarded-For (или CF-Connecting-IP, дополнительно предоставляемого cloudflare) в сочетании с оценка ответа 401 плюс limit_req (возможно ли это? Как?)
- Вместо того, чтобы помещать в тюрьму обнаруженный bruteforcingIP через fail2ban, сопоставьте его с запрещенным IP-адресом (например, 140.1.1.1 или другим IP-адресом в Африке) и отклоните http-трафик через директива Deny на nginx.
Возможна ли одна из последних? Если нет, то какая альтернатива?
Поскольку сеанс TCP завершается на серверах Cloudflare, это означает, что вы не можете напрямую или легко заблокировать своих клиентов с помощью iptables, за исключением случаев, когда вы собираетесь заблокировать с помощью iptables, ищущего такие строки, как здесь: Правило Iptables для блокировки всех веб-запросов к domain.com .
Даже в этом случае некоторые запросы от клиента будут кэшироваться из cloudflare, в конце концов, это одна из причин использования CDN, поэтому вы даже не увидите приходящий запрос.
Что вы можете сделать, так это выполните сопоставление на nginx на основе содержимого X-Forwarded-For и примените к нему ограничение скорости, для получения дополнительной информации проверьте этот ответ: