Hello! On Mon, Jun 12, 2023 at 02:31:04AM +0300, Gena Makhomed wrote:
> On 09.06.2023 9:29, Maxim Dounin wrote: > > >> (1) client ==> vps_server ==> main_server > >> > >> (2) client ==> cloudflare => vps_server ==> main_server > > > Если у вас в обоих случаях vps_server проксирует всё через stream > > с proxy_protocol, то на принимающей стороне вам в любом случае > > надо сначала достать реальный адрес клиента из proxy_protocol. > > А уже потом смотреть в заголовки (или не смотреть, если на > > vps_server пришли не с IP-адресов Cloudflare). > > > > То есть, фактически, для корректной работы такой схемы - нужен > > "real_ip_recursive on;" (http://nginx.org/r/real_ip_recursive) > > и заголовок со списком нужных адресов. > > > > Сейчас из коробки такое можно сделать дополнительным > > проксированием с установкой заголовка. Для стандартного заголовка > > X-Forwarded-For, благо Cloudflare его ставит, конфигурация будет > > выглядеть как-то так: > > > > server { > > listen 8080 proxy_protocol; > > > > set_real_ip_from <vps>; > > real_ip_header proxy_protocol; > > > > location / { > > proxy_pass http://127.0.0.1:8081; > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > } > > } > > > > server { > > listen 8081; > > > > set_real_ip_from 127.0.0.1; > > set_real_ip_from <cloudflare>; > > > > real_ip_header X-Forwarded-For; > > real_ip_recursive on; > > > > ... > > } > > Это будет работать только в том случае, если система защиты от DDoS > указывает IP адрес клиента в заголовке X-Forwarded-For. Если же какая-то > экзотическая система защиты от DDoS будет указывать реальный IP клиента > в каком-то другом заголовке, например, только в загловке X-Real-IP - > тогда этот метод работать не будет, потому что в nginx есть переменная > $proxy_add_x_forwarded_for но в nginx нет перменной $proxy_add_x_real_ip > > Что же нам делать в том случае, если какая-то система защиты от DDoS > передает реальный IP клиента в заголовке отличном от X-Forwarded-For ? Если нужно работать с нестандартными заголовками - это можно сделать с помощью модуля map, благо сейчас его возможностей с лихвой хватает для реализации логики, аналогичной работе переменной $proxy_add_x_forwarded_for. Не говоря уже о том, что, по большому счёту, в данной конкретной задаче полная логика $proxy_add_x_forwarded_for не важна, и вполне можно обойтись безусловным добавлением адреса через запятую: proxy_set_header X-Real-IP "$http_x_real_ip, $remote_addr"; В вырожденном случае пустого $http_x_real_ip будет лишняя запятая в начале, но на работоспособность это не влияет. > >> Или существует какой-то еще лучший вариант решения этой задачи? > > > > Я периодически думаю о том, чтобы научить модуль realip брать > > список IP-адресов не из заголовка, а непосредственно из > > переменной. Тогда необходимость в дополнительном проксировании в > > подобных странных конфигурациях отпадёт. > > Каким же образом тут можно будет обойтись без двойного проксирования, > если необходимо будет сначала указывать real_ip_header proxy_protocol; > чтобы узнать реальный IP сервера cloudflare, который подключился к VPS, > и при этом - несколько директив real_ip_header нельзя указывать в одном > контексте. А если указать одну директиву real_ip_header одновременно > и в контексте server и одну в контексте location, то согласно правил > наследования директив в nginx - директива real_ip_header в контексте > location будет выполняться, а директива real_ip_header в контексте > server выполняться не будет, и всегда будет просто проигнорирована. > > Максим, можете пояснить в чем тут моя ошибка и что я не так понял? Идея состоит в том, что вместо указания названия заголовка в директиве real_ip_header - указать непосредственно адреса. Тогда вместо real_ip_header proxy_protocol; можно будет написать что-то вроде: real_ip_address $proxy_protocol_addr; А для последующего рекурсивного поиска в заголовке X-Forwarded-For (если он получен с доверенного адреса), соответственно, будет достаточно написать: real_ip_address "$http_x_forwarded_for, $proxy_protocol_addr"; И, соответственно, полная конфигурация будет выглядеть как: server { listen 8080 proxy_protocol; set_real_ip_from <vps>; set_real_ip_from <cloudflare>; real_ip_address "$http_x_forwarded_for, $proxy_protocol_addr"; real_ip_recursive on; ... } То есть ровно то, что в примере выше делается с помощью дополнительного проксирования - в такой схеме будет сделано с помощью установки переменной. [...] > Максим, вопрос в том, можно ли будет в основной ветке nginx заменить > текущую версию модуля ngx_http_realip_module новой версией модуля, > в которой будет реализован вариант директивы set_real_ip_from > с одним, тремя и пятью параметрами? Я не вижу решительно никаких причин переусложнять работу модуля подобным образом. Имеющиеся задачи вполне решаются с помощью существующих возможностей модуля, что и было продемонстрировано в исходном ответе. С помощью минимальных (в первую очередь с точки зрения пользователя) доработок можно сделать так, чтобы подобные задачи решались эффективнее - однако, как уже было сказано, острой необходимости в этом пока не прослеживается. [...] -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org https://mailman.nginx.org/mailman/listinfo/nginx-ru
