From gmm на csdoc.com Sun Jun 4 18:40:17 2023 From: gmm на csdoc.com (Gena Makhomed) Date: Sun, 4 Jun 2023 21:40:17 +0300 Subject: =?UTF-8?B?0LzQvdC+0LbQtdGB0YLQstC10L3QvdGL0LUg0LTQuNGA0LXQutGC0Lg=?= =?UTF-8?B?0LLRiyByZWFsX2lwX2hlYWRlcg==?= Message-ID: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> Здравствуйте, All! Есть такая конфигурация: (1) client ==> vps_server ==> main_server (2) client ==> cloudflare => vps_server ==> main_server vps_server слушает на 80 и 443 портах и через модуль stream проксирует запроcы на main_server через tcp, передавая на main_server информацию о реальном IP клинта через proxy_protocol. Все SSL сертификаты и конфигурации сайтов хранятся при этом только на main_server. В первом случае для получения реального IP клиента - в блоке server надо прописать: set_real_ip_from 11.22.33.44; # IP адрес vps_server real_ip_header proxy_protocol; Во втором случае для получения реального IP клиента - в блоке server надо прописать: set_real_ip_from 173.245.48.0/20; ... set_real_ip_from 2c0f:f248::/32; real_ip_header CF-Connecting-IP; При этом - в момент включения/выключения cloudflare для какого-то виртуального хоста - необходимо править конфиги nginx и делать релоад конфигурации nginx. Можно ли без правки исходников nginx используя только функциональность nginx и модуля njs получить автоматическое определение IP адреса клиента вне зависимости от того, каким образом пришел запрос - или от клиента напрямую на IP адерс vps_server, или через cloudflare proxy? Если без правки исходников nginx такую функциональность получить нельзя - как лучше всего написать патч, который реализует логику работы множественных директив set_real_ip_from и real_ip_header, таким образом, чтобы не сломать обратную совместимость со всеми уже существующими конфигурациями nginx? Может быть - лучше всего будет сделать в nginx два варианта директивы real_ip_header - первый вариант - как сейчас, с одним параметром, и второй вариант - с тремя параметрами: real_ip_header proxy_protocol set_real_ip_from 11.22.33.44; real_ip_header CF-Connecting-IP set_real_ip_from 173.245.48.0/20; первый вариант, с одним параметром - как и раньше, может быть только один, а второй вариант - с тремя параметрами может присутствовать в конфигурации nginx больше одного раза. И если обрабатывать расширенные директивы real_ip_header в том порядке, в котором они встречаются в конфиге - то как раз и будет автоматически получена необходимая функциональность обработки множественных заголовков real_ip_header, при этом будет полностью соблюдена обратная совместимость со всеми текущими конфигурациями nginx, потому что ни у кого в конфигах сейчас нет директивы real_ip_header с тремя параметрами. Б большинтсве случаев, примерно 80-90% будет использоваться текущий синтаксис директивы real_ip_header, но при необходимости обработки нескольких директив real_ip_header - будет использоваться вариант с тремя параметрами, в оставшихся 10-20% случаев. старый синтаксис набора директив set_real_ip_from 11.11.11.11; set_real_ip_from 22.22.22.22; set_real_ip_from 33.33.33.33; real_ip_header X-Real-IP; может быть автоматически преобразован при чтении конфига во внутреннее представление аналогичное набору директив: real_ip_header X-Real-IP set_real_ip_from 11.11.11.11; real_ip_header X-Real-IP set_real_ip_from 22.22.22.22; real_ip_header X-Real-IP set_real_ip_from 33.33.33.33; - так что в nginx нужно будет реализовать только один вариант кода для обработки "расширенного" варианта конфига, с тремя директивами. Или существует какой-то еще лучший вариант решения этой задачи? -- Best regards, Gena From chipitsine на gmail.com Mon Jun 5 10:06:12 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Mon, 5 Jun 2023 12:06:12 +0200 Subject: =?UTF-8?B?UmU6INC80L3QvtC20LXRgdGC0LLQtdC90L3Ri9C1INC00LjRgNC10LrRgtC40LLRiyByZQ==?= =?UTF-8?B?YWxfaXBfaGVhZGVy?= In-Reply-To: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> References: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> Message-ID: я делал каскадные map-ы (когда переменная задается через переменную, задаваемую другим map-ом). но решение далеко от идеального 1) требуется правка конфигов и релоад 2) очень сложно прикручивается эквивалент set_real_ip_from возможно, в каком-то приближении, именно за счет маркера "запрос пришел с прокси" или "запрос пришел не с прокси" можно сделать нужный вам map вс, 4 июн. 2023 г. в 20:40, Gena Makhomed : > Здравствуйте, All! > > Есть такая конфигурация: > > (1) client ==> vps_server ==> main_server > > (2) client ==> cloudflare => vps_server ==> main_server > > vps_server слушает на 80 и 443 портах и через модуль stream проксирует > запроcы на main_server через tcp, передавая на main_server информацию > о реальном IP клинта через proxy_protocol. Все SSL сертификаты > и конфигурации сайтов хранятся при этом только на main_server. > > В первом случае для получения реального IP клиента - в блоке > server надо прописать: > > set_real_ip_from 11.22.33.44; # IP адрес vps_server > real_ip_header proxy_protocol; > > Во втором случае для получения реального IP клиента - в блоке > server надо прописать: > > set_real_ip_from 173.245.48.0/20; > ... > set_real_ip_from 2c0f:f248::/32; > real_ip_header CF-Connecting-IP; > > При этом - в момент включения/выключения cloudflare > для какого-то виртуального хоста - необходимо править > конфиги nginx и делать релоад конфигурации nginx. > > Можно ли без правки исходников nginx используя только функциональность > nginx и модуля njs получить автоматическое определение IP адреса клиента > вне зависимости от того, каким образом пришел запрос - или от клиента > напрямую на IP адерс vps_server, или через cloudflare proxy? > > Если без правки исходников nginx такую функциональность получить нельзя > - как лучше всего написать патч, который реализует логику работы > множественных директив set_real_ip_from и real_ip_header, > таким образом, чтобы не сломать обратную совместимость > со всеми уже существующими конфигурациями nginx? > > Может быть - лучше всего будет сделать в nginx > два варианта директивы real_ip_header - первый > вариант - как сейчас, с одним параметром, > и второй вариант - с тремя параметрами: > > real_ip_header proxy_protocol set_real_ip_from 11.22.33.44; > > real_ip_header CF-Connecting-IP set_real_ip_from 173.245.48.0/20; > > первый вариант, с одним параметром - как и раньше, может быть только > один, а второй вариант - с тремя параметрами может присутствовать в > конфигурации nginx больше одного раза. > > И если обрабатывать расширенные директивы real_ip_header в том порядке, > в котором они встречаются в конфиге - то как раз и будет автоматически > получена необходимая функциональность обработки множественных заголовков > real_ip_header, при этом будет полностью соблюдена > обратная совместимость со всеми текущими конфигурациями nginx, > потому что ни у кого в конфигах сейчас нет директивы > real_ip_header с тремя параметрами. > > Б большинтсве случаев, примерно 80-90% будет использоваться текущий > синтаксис директивы real_ip_header, но при необходимости обработки > нескольких директив real_ip_header - будет использоваться вариант > с тремя параметрами, в оставшихся 10-20% случаев. > > старый синтаксис набора директив > > set_real_ip_from 11.11.11.11; > set_real_ip_from 22.22.22.22; > set_real_ip_from 33.33.33.33; > real_ip_header X-Real-IP; > > может быть автоматически преобразован при чтении конфига > во внутреннее представление аналогичное набору директив: > > real_ip_header X-Real-IP set_real_ip_from 11.11.11.11; > real_ip_header X-Real-IP set_real_ip_from 22.22.22.22; > real_ip_header X-Real-IP set_real_ip_from 33.33.33.33; > > - так что в nginx нужно будет реализовать только один вариант кода > для обработки "расширенного" варианта конфига, с тремя директивами. > > Или существует какой-то еще лучший вариант решения этой задачи? > > -- > Best regards, > Gena > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Mon Jun 5 15:47:43 2023 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 5 Jun 2023 18:47:43 +0300 Subject: =?UTF-8?B?UmU6INC80L3QvtC20LXRgdGC0LLQtdC90L3Ri9C1INC00LjRgNC10Lo=?= =?UTF-8?B?0YLQuNCy0YsgcmVhbF9pcF9oZWFkZXI=?= In-Reply-To: References: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> Message-ID: <841a27d0-cdb1-50cc-7aaa-5b452facd88f@csdoc.com> On 05.06.2023 13:06, Илья Шипицин wrote: > я делал каскадные map-ы (когда переменная задается через переменную, > задаваемую другим map-ом). "Talk is cheap. Show me the code" ― Linus Torvalds. > возможно, в каком-то приближении, именно за счет маркера "запрос пришел > с прокси" или "запрос пришел не с прокси" можно сделать нужный вам map все запросы приходят на основной сервер с прокси, это же хорошо видно в той схеме, которую я подробно нарисовал в своем исходном сообщении: >> (1) client ==> vps_server ==> main_server >> >> (2) client ==> cloudflare => vps_server ==> main_server Я так понимаю, что с помощью программирования на конфигах nginx эту задачу решить не получится, поэтому и задал Максиму Дунину и другим разработчикам nginx вопрос о том, как лучше всего эту функциональность реализовать в виде патча к nginx - так как мне совсем не хочется заниматься постоянной правкой конфигов nginx, - проще будет попробовать написать такой патч, чтобы добавить в nginx нужную мне, да и не только мне, функционаальность. -- Best regards, Gena From chipitsine на gmail.com Tue Jun 6 10:54:05 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 6 Jun 2023 12:54:05 +0200 Subject: =?UTF-8?B?UmU6INC80L3QvtC20LXRgdGC0LLQtdC90L3Ri9C1INC00LjRgNC10LrRgtC40LLRiyByZQ==?= =?UTF-8?B?YWxfaXBfaGVhZGVy?= In-Reply-To: <841a27d0-cdb1-50cc-7aaa-5b452facd88f@csdoc.com> References: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> <841a27d0-cdb1-50cc-7aaa-5b452facd88f@csdoc.com> Message-ID: пн, 5 июн. 2023 г. в 17:47, Gena Makhomed : > On 05.06.2023 13:06, Илья Шипицин wrote: > > > я делал каскадные map-ы (когда переменная задается через переменную, > > задаваемую другим map-ом). > > "Talk is cheap. Show me the code" ― Linus Torvalds. > > > возможно, в каком-то приближении, именно за счет маркера "запрос пришел > > с прокси" или "запрос пришел не с прокси" можно сделать нужный вам map > > все запросы приходят на основной сервер с прокси, это же хорошо видно > в той схеме, которую я подробно нарисовал в своем исходном сообщении: > > >> (1) client ==> vps_server ==> main_server > >> > >> (2) client ==> cloudflare => vps_server ==> main_server > map $remote_addr $real_remote_addr { ip_of_vps_server $http_x_forwarded_for; ip_of_cloudflare_1 $http_cf_connecting_ip; ... ip_of_cloudflare_N $http_cf_connecting_ip; default $remote_addr; } > > Я так понимаю, что с помощью программирования на конфигах nginx > эту задачу решить не получится, поэтому и задал Максиму Дунину > и другим разработчикам nginx вопрос о том, как лучше всего > эту функциональность реализовать в виде патча к nginx - > так как мне совсем не хочется заниматься постоянной правкой > конфигов nginx, - проще будет попробовать написать такой патч, > чтобы добавить в nginx нужную мне, да и не только мне, > функционаальность. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From chipitsine на gmail.com Tue Jun 6 11:00:07 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Tue, 6 Jun 2023 13:00:07 +0200 Subject: =?UTF-8?B?UmU6INC80L3QvtC20LXRgdGC0LLQtdC90L3Ri9C1INC00LjRgNC10LrRgtC40LLRiyByZQ==?= =?UTF-8?B?YWxfaXBfaGVhZGVy?= In-Reply-To: References: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> <841a27d0-cdb1-50cc-7aaa-5b452facd88f@csdoc.com> Message-ID: прошу прощения. наверное, вот так... (на vps выставлять маркер, с клаудфлера запрос или нет $http_are_we_behind_cloudflare и по этому маркеру брать из одного или другого хедера) но в целом - это то самое "программирование на конфигах" map $http_are_we_behind_cloudflare $real_remote_addr { 'yes' $http_cf_connecting_ip; default $http_x_forwarded_for; } вт, 6 июн. 2023 г. в 12:54, Илья Шипицин : > > > пн, 5 июн. 2023 г. в 17:47, Gena Makhomed : > >> On 05.06.2023 13:06, Илья Шипицин wrote: >> >> > я делал каскадные map-ы (когда переменная задается через переменную, >> > задаваемую другим map-ом). >> >> "Talk is cheap. Show me the code" ― Linus Torvalds. >> >> > возможно, в каком-то приближении, именно за счет маркера "запрос пришел >> > с прокси" или "запрос пришел не с прокси" можно сделать нужный вам map >> >> все запросы приходят на основной сервер с прокси, это же хорошо видно >> в той схеме, которую я подробно нарисовал в своем исходном сообщении: >> >> >> (1) client ==> vps_server ==> main_server >> >> >> >> (2) client ==> cloudflare => vps_server ==> main_server >> > > map $remote_addr $real_remote_addr { > ip_of_vps_server $http_x_forwarded_for; > ip_of_cloudflare_1 $http_cf_connecting_ip; > ... > ip_of_cloudflare_N $http_cf_connecting_ip; > default $remote_addr; > } > > > >> >> Я так понимаю, что с помощью программирования на конфигах nginx >> эту задачу решить не получится, поэтому и задал Максиму Дунину >> и другим разработчикам nginx вопрос о том, как лучше всего >> эту функциональность реализовать в виде патча к nginx - >> так как мне совсем не хочется заниматься постоянной правкой >> конфигов nginx, - проще будет попробовать написать такой патч, >> чтобы добавить в nginx нужную мне, да и не только мне, >> функционаальность. >> >> -- >> Best regards, >> Gena >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru на nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx-ru >> > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Tue Jun 6 20:19:37 2023 From: gmm на csdoc.com (Gena Makhomed) Date: Tue, 6 Jun 2023 23:19:37 +0300 Subject: =?UTF-8?B?UmU6INC80L3QvtC20LXRgdGC0LLQtdC90L3Ri9C1INC00LjRgNC10Lo=?= =?UTF-8?B?0YLQuNCy0YsgcmVhbF9pcF9oZWFkZXI=?= In-Reply-To: References: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> <841a27d0-cdb1-50cc-7aaa-5b452facd88f@csdoc.com> Message-ID: <0d351d2b-945e-813b-de13-7e9c121601f4@csdoc.com> On 06.06.2023 14:00, Илья Шипицин wrote: > (на vps выставлять маркер, с клаудфлера запрос или нет > $http_are_we_behind_cloudflare и по этому маркеру брать из одного или > другого хедера) > > но в целом - это то самое "программирование на конфигах" > > map $http_are_we_behind_cloudflare $real_remote_addr { > 'yes' $http_cf_connecting_ip; > default $http_x_forwarded_for; > } Не получится на VPS выставлять маркер, потому что VPS проксирует трафик на основной сервер через tcp, а не через http/https. Примерно так: # cat /etc/nginx/nginx.conf stream { server { listen 11.11.11.11:80; proxy_protocol on; proxy_pass 22.22.22.22:57001; } server { listen 11.11.11.11:443; proxy_protocol on; proxy_pass 22.22.22.22:57002; } } самый простой вариант решения проблемы - это взять исходники модуля ngx_http_realip_module, в котором определено три директивы и две переменные, и на его основании сделать модуль ngx_http_realip_module2, с такими директивами: set_real_ip_from2 real_ip_header2 real_ip_recursive2 и такими переменными: $realip_remote_addr2 $realip_remote_port2 в таком случае на основном сервере будет такой конфиг: set_real_ip_from 11.11.11.11; real_ip_header proxy_protocol; set_real_ip_from2 ; ... set_real_ip_from2 ; real_ip_header2 CF-Connecting-IP; сначала отработают директивы set_real_ip_from и real_ip_header из модуля ngx_http_realip_module и модуль установит переменные $remote_addr $remote_port на основании данных, полученных из proxy_protocol, после чего отработает модуль ngx_http_realip_module2 и установит переменную $remote_addr на основании значения заголовка CF-Connecting-IP. - насколько я понимаю, с помощью njs написать модуль ngx_http_realip_module2 не получится, потому что переменная $remote_addr для njs находится в состоянии read only, так что модуль ngx_http_realip_module2 необходимо будет делать только используя язык программирования C. Не понятно только, можно ли будет включить этот модуль ngx_http_realip_module2 в основную ветку nginx, или надо будет писать его отдельно и вручную компилировать при выходе каждой новой версии nginx? Более двух уровней обработки real_ip_header / real_ip_header2 может понадобиться, чтобы включить одновременно возможность автоматического получения реального IP клиента от cloudflare, variti, stormwall и других сервисов защиты от DDoS. Тогда можно было бы просто прописать в конфигах nginx одновременно все допустимые варианты настройки и тогда можно было бы вообще не править конфиги, при переключении метода защиты: set_real_ip_from <настройки для proxy_protocol>; real_ip_header <настройки для proxy_protocol>; set_real_ip_from2 <настройки для cloudflare>; real_ip_header2 <настройки для cloudflare>; set_real_ip_from3 <настройки для variti>; real_ip_header3 <настройки для variti>; set_real_ip_from4 <настройки для stormwall>; real_ip_header4 <настройки для stormwall>; Но тут не понятно, на каком количестве вариантов директив надо остановиться, - 5, 10, 20 ? Выполнять же директивы просто в порядке следования в конфиге: set_real_ip_from <настройки для proxy_protocol>; real_ip_header <настройки для proxy_protocol>; set_real_ip_from <настройки для cloudflare>; real_ip_header <настройки для cloudflare>; set_real_ip_from <настройки для variti>; real_ip_header <настройки для variti>; set_real_ip_from <настройки для stormwall>; real_ip_header <настройки для stormwall>; нельзя, потому что это нарушит обратную совместимость с уже существующими конфигурациями и такой патч точно никогда не будет принят в основную ветку nginx. Вариант синтаксиса: real_ip_header <имя> set_real_ip_from <адрес>; позволяет неограниченное количество директив real_ip_header, если обрабатывать их в том порядке, как они заданы в конфиге - то получается максимально гибкая настройка конфигурации, причем, даже без необходимости добавления новых директив. Но не знаю, примут ти такой патч/модуль в основную ветку nginx ? лучших вариантов синтаксиса, кроме real_ip_header <имя> set_real_ip_from <адрес>; я пока что не смог придумать. To Maxim Dounin: Максим, можно узнать Ваше мнение по этому вопросу? -- Best regards, Gena From chipitsine на gmail.com Tue Jun 6 22:01:12 2023 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 7 Jun 2023 00:01:12 +0200 Subject: =?UTF-8?B?UmU6INC80L3QvtC20LXRgdGC0LLQtdC90L3Ri9C1INC00LjRgNC10LrRgtC40LLRiyByZQ==?= =?UTF-8?B?YWxfaXBfaGVhZGVy?= In-Reply-To: <0d351d2b-945e-813b-de13-7e9c121601f4@csdoc.com> References: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> <841a27d0-cdb1-50cc-7aaa-5b452facd88f@csdoc.com> <0d351d2b-945e-813b-de13-7e9c121601f4@csdoc.com> Message-ID: кстати, proxy protocols - шикарная штука. вт, 6 июн. 2023 г. в 22:19, Gena Makhomed : > On 06.06.2023 14:00, Илья Шипицин wrote: > > > (на vps выставлять маркер, с клаудфлера запрос или нет > > $http_are_we_behind_cloudflare и по этому маркеру брать из одного или > > другого хедера) > > > > но в целом - это то самое "программирование на конфигах" > > > > map $http_are_we_behind_cloudflare $real_remote_addr { > > 'yes' $http_cf_connecting_ip; > > default $http_x_forwarded_for; > > } > > > Не получится на VPS выставлять маркер, потому что VPS проксирует трафик > на основной сервер через tcp, а не через http/https. Примерно так: > > # cat /etc/nginx/nginx.conf > > stream { > > server { > listen 11.11.11.11:80; > proxy_protocol on; > proxy_pass 22.22.22.22:57001; > } > > server { > listen 11.11.11.11:443; > proxy_protocol on; > proxy_pass 22.22.22.22:57002; > } > } > > самый простой вариант решения проблемы - это взять исходники > модуля ngx_http_realip_module, в котором определено три директивы > и две переменные, и на его основании сделать модуль > ngx_http_realip_module2, с такими директивами: > > set_real_ip_from2 > real_ip_header2 > real_ip_recursive2 > > и такими переменными: > > $realip_remote_addr2 > $realip_remote_port2 > > в таком случае на основном сервере будет такой конфиг: > > set_real_ip_from 11.11.11.11; > real_ip_header proxy_protocol; > > set_real_ip_from2 ; > ... > set_real_ip_from2 ; > real_ip_header2 CF-Connecting-IP; > > сначала отработают директивы set_real_ip_from и real_ip_header > из модуля ngx_http_realip_module и модуль установит переменные > > $remote_addr > $remote_port > > на основании данных, полученных из proxy_protocol, > после чего отработает модуль ngx_http_realip_module2 > и установит переменную > > $remote_addr > > на основании значения заголовка CF-Connecting-IP. > > - насколько я понимаю, с помощью njs написать модуль > ngx_http_realip_module2 не получится, потому что переменная > $remote_addr для njs находится в состоянии read only, > так что модуль ngx_http_realip_module2 необходимо будет > делать только используя язык программирования C. > > Не понятно только, можно ли будет включить этот модуль > ngx_http_realip_module2 в основную ветку nginx, или надо будет > писать его отдельно и вручную компилировать при выходе каждой > новой версии nginx? > > Более двух уровней обработки real_ip_header / real_ip_header2 > может понадобиться, чтобы включить одновременно возможность > автоматического получения реального IP клиента от cloudflare, > variti, stormwall и других сервисов защиты от DDoS. Тогда можно > было бы просто прописать в конфигах nginx одновременно > все допустимые варианты настройки и тогда можно было бы > вообще не править конфиги, при переключении метода защиты: > > set_real_ip_from <настройки для proxy_protocol>; > real_ip_header <настройки для proxy_protocol>; > > set_real_ip_from2 <настройки для cloudflare>; > real_ip_header2 <настройки для cloudflare>; > > set_real_ip_from3 <настройки для variti>; > real_ip_header3 <настройки для variti>; > > set_real_ip_from4 <настройки для stormwall>; > real_ip_header4 <настройки для stormwall>; > > Но тут не понятно, на каком количестве вариантов директив > надо остановиться, - 5, 10, 20 ? > > Выполнять же директивы просто в порядке следования в конфиге: > > set_real_ip_from <настройки для proxy_protocol>; > real_ip_header <настройки для proxy_protocol>; > > set_real_ip_from <настройки для cloudflare>; > real_ip_header <настройки для cloudflare>; > > set_real_ip_from <настройки для variti>; > real_ip_header <настройки для variti>; > > set_real_ip_from <настройки для stormwall>; > real_ip_header <настройки для stormwall>; > > нельзя, потому что это нарушит обратную совместимость > с уже существующими конфигурациями и такой патч > точно никогда не будет принят в основную ветку nginx. > > Вариант синтаксиса: > > real_ip_header <имя> set_real_ip_from <адрес>; > > позволяет неограниченное количество директив real_ip_header, > если обрабатывать их в том порядке, как они заданы в конфиге > - то получается максимально гибкая настройка конфигурации, > причем, даже без необходимости добавления новых директив. > > Но не знаю, примут ти такой патч/модуль в основную ветку nginx ? > > лучших вариантов синтаксиса, кроме > > real_ip_header <имя> set_real_ip_from <адрес>; > > я пока что не смог придумать. > > To Maxim Dounin: > > Максим, можно узнать Ваше мнение по этому вопросу? > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx-ru > ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From alnkapa на gmail.com Wed Jun 7 06:43:33 2023 From: alnkapa на gmail.com (Aln Kapa) Date: Wed, 7 Jun 2023 09:43:33 +0300 Subject: http3 and multi server by host name Message-ID: Добрый день. Подскажите есть возможность настроить http3, что бы можно было использовать одинаковые порт для всех имён. К примеру сейчас конфигурации выглядит вот так. server { listen 443 ssl http2; listen 443 quic reuseport; http2_push_preload on; server_name 1; location / { # used to advertise the availability of HTTP/3 add_header Alt-Svc 'h3=":443"; ma=86400'; try_files $uri $uri/ /index.html; } } server { listen 443 ssl http2; listen 8443 quic reuseport; http2_push_preload on; server_name 2; location / { # used to advertise the availability of HTTP/3 add_header Alt-Svc 'h3=":8443"; ma=86400'; try_files $uri $uri/ /index.html; } } Как бы сделать так что бы udp порт был один? Спасибо. ----------- следующая часть ----------- Вложение в формате HTML было извлечено… URL: From arut на nginx.com Wed Jun 7 07:07:43 2023 From: arut на nginx.com (Roman Arutyunyan) Date: Wed, 7 Jun 2023 11:07:43 +0400 Subject: http3 and multi server by host name In-Reply-To: References: Message-ID: <20230607070743.pvhrrcnxuqotgwks@N00W24XTQX> Добрый день, On Wed, Jun 07, 2023 at 09:43:33AM +0300, Aln Kapa wrote: > Добрый день. Подскажите есть возможность настроить http3, что бы можно было > использовать одинаковые порт для всех имён. К примеру сейчас конфигурации > выглядит вот так. > server { > listen 443 ssl http2; > listen 443 quic reuseport; > http2_push_preload on; > server_name 1; > location / { > # used to advertise the availability of HTTP/3 > add_header Alt-Svc 'h3=":443"; ma=86400'; > try_files $uri $uri/ /index.html; > } > } > server { > listen 443 ssl http2; > listen 8443 quic reuseport; > http2_push_preload on; > server_name 2; > location / { > # used to advertise the availability of HTTP/3 > add_header Alt-Svc 'h3=":8443"; ma=86400'; > try_files $uri $uri/ /index.html; > } > } > Как бы сделать так что бы udp порт был один? > Спасибо. Все аналогично обычному tcp. Сокетная опция reuserport, как обычно, указывается только у первой директивы listen. server { listen 443 quic reuseport; ... } server { listen 443 quic; ... } -- Roman Arutyunyan From mdounin на mdounin.ru Fri Jun 9 06:29:02 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 9 Jun 2023 09:29:02 +0300 Subject: =?koi8-r?B?zc7P1sXT1NfFzs7ZxSDEydLF?= =?koi8-r?B?y9TJ19k=?= real_ip_header In-Reply-To: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> References: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> Message-ID: Hello! On Sun, Jun 04, 2023 at 09:40:17PM +0300, Gena Makhomed wrote: > Здравствуйте, All! > > Есть такая конфигурация: > > (1) client ==> vps_server ==> main_server > > (2) client ==> cloudflare => vps_server ==> main_server > > vps_server слушает на 80 и 443 портах и через модуль stream проксирует > запроcы на main_server через tcp, передавая на main_server информацию > о реальном IP клинта через proxy_protocol. Все SSL сертификаты > и конфигурации сайтов хранятся при этом только на main_server. > > В первом случае для получения реального IP клиента - в блоке > server надо прописать: > > set_real_ip_from 11.22.33.44; # IP адрес vps_server > real_ip_header proxy_protocol; > > Во втором случае для получения реального IP клиента - в блоке > server надо прописать: > > set_real_ip_from 173.245.48.0/20; > ... > set_real_ip_from 2c0f:f248::/32; > real_ip_header CF-Connecting-IP; Если у вас в обоих случаях 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 ; real_ip_header proxy_protocol; location / { proxy_pass http://127.0.0.1:8080; 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 ; real_ip_header X-Forwarded-For; real_ip_recursive on; ... } [...] > Или существует какой-то еще лучший вариант решения этой задачи? Я периодически думаю о том, чтобы научить модуль realip брать список IP-адресов не из заголовка, а непосредственно из переменной. Тогда необходимость в дополнительном проксировании в подобных странных конфигурациях отпадёт. Но в целом это выглядит как достаточно маргинальный use case, IMHO, и доступное сейчас решение с дополнительным проксированием ему плюс-минус адекватно. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Sun Jun 11 23:31:04 2023 From: gmm на csdoc.com (Gena Makhomed) Date: Mon, 12 Jun 2023 02:31:04 +0300 Subject: =?UTF-8?B?0L3QvtCy0LDRjyDQstC10YDRgdC40Y8g0LzQvtC00YPQu9GPIG5neF9o?= =?UTF-8?Q?ttp=5frealip=5fmodule?= In-Reply-To: References: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> Message-ID: <57b21bb6-bb12-95dc-e225-10017d41f722@csdoc.com> 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 ; > 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 ; > > 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 ? >> Или существует какой-то еще лучший вариант решения этой задачи? > > Я периодически думаю о том, чтобы научить модуль 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 выполняться не будет, и всегда будет просто проигнорирована. Максим, можете пояснить в чем тут моя ошибка и что я не так понял? > Но в целом это выглядит как достаточно маргинальный use case, > IMHO, и доступное сейчас решение с дополнительным проксированием > ему плюс-минус адекватно. Максим, я понимаю, что эта схема подключения основного сервера (1) client ==> vps_server ==> main_server (2) client ==> cloudflare => vps_server ==> main_server выглядит для Вас достаточно маргинальным вариантом, но у меня просто нет другого выхода, потому что был уже раньше случай, когда промежуточного tcp-прокси на vps_server не было - и когда пришла мощная DDoS-атака на уровне L3/L4 - хостер просто отключил сервер от интернета, сделав black hole routing для main_server IP. В этой же, новой схеме - промежуточных vps_server может быть несколько штук, так что если придет какая-то мощная DDoS-атака на уровне L3/L4 на vps_server - то от интернета будет отключен только этот один vps_server, и перестанет работать только часть сайтов, которые указывают на IP адрес этого vps_server. А все остальные сайты, которые указывают на другие vps_server, проксирующие запросы на main_server через tcp proxy - будут работать и дальше, кроме того main_server в такой схеме точно никогда не будет отключен от хостером интернета, потому что злоумышленники не будут знать его IP адрес, он будет более-менее надежно скрыт от всех пользователей. Способ простой - можно взять еще одну VPS за 5 USD и пустить весь исходящий трафик через нее, тогда весь исходящий трафик от main_server будет идти в интернет через эту VPS и в случае DDoS-атаки на нее - основной сервер продолжит работать как и раньше, и даже более того, изменив настройки в конфиге WireGuard на main_server можно будет пустить исходящий трафик от main_server через совсем другую VPS. В среднем самая дешевая vps_server на KVM стоит около 5 USD в месяц, dedicated bare metal main_server стоит около 200-300-400 USD в месяц, поэтому с моей точки зрения - гораздо лучше будет иметь десять промежуточных vps_server и в случае мощной L3/L4 DDoS-атаки иметь Denial of Service только на 1/10 часть сайтов, вместо того, чтобы иметь Denial of Service на все 100% сайтов, которые размещены на main_server, очень сильно рискуя при этом что хостер не выдержит и вообще отключит весь сервер main_server от интернета. А Cloudflare, Variti, StormWall и другие сервисы защиты от DDoS - это просто дополнительный уровень защиты, который позволит терминировать все L3/L4 DDoS-атаки на уровне системы защиты от DDoS, так что через vps_server на main_server придет только часть L7 атаки, с которой main_server уже сможет справить самостоятельно, например, с помощью https://github.com/makhomed/autofilter или с помощью встроенных в nginx модулей ngx_http_limit_conn_module и / или ngx_http_limit_req_module Поэтому идеальным вариантом решения для меня в такой ситуации - была бы возможность указывать в конфиге одновременно все используемые системы защиты от DDoS, чтобы сайтам можно было бы в любой момент времени прозрачно переключаться между ними, вообще не внося никаких изменений в конфигурацию nginx на хостинговом сервере main_server и на всех промежуточных tcp-прокси vps_server. Можно ли это сделать? Да, эта задача имеет 100% решение. Например, такой расширенный вариант синтаксиса: set_real_ip_from real_ip_header CF-Connecting-IP; set_real_ip_from real_ip_header CF-Connecting-IP; set_real_ip_from real_ip_header CF-Connecting-IP; set_real_ip_from real_ip_header X-Forwarded-For; set_real_ip_from real_ip_header X-Forwarded-For; set_real_ip_from real_ip_header X-Forwarded-For; set_real_ip_from real_ip_header X-Forwarded-For; set_real_ip_from real_ip_header X-Forwarded-For; set_real_ip_from real_ip_header X-Forwarded-For; То есть, сейчас модуль ngx_http_realip_module имеет три директивы: set_real_ip_from real_ip_header real_ip_recursive В текущей версии модуля - директив set_real_ip_from может быть несколько в одном контексте, но при этом - каждая из этих директив может иметь только одине параметр. Я предлагаю 100% обратно совместимый метод добавления дополнительной функциональности: добавить также варианты директив set_real_ip_from с тремя и пятью параметрами: set_real_ip_from
real_ip_header
set_real_ip_from
real_ip_header
real_ip_recursive таким образом, не добавляя новых директив в nginx можно получить новую функциональность, сохранив при этом 100% обратную совместимость. Внутри модуля - хранить адреса из первого аргумента директивы set_real_ip_from в форме аналогичной тому, как это делает модуль geo, во внутреннем представлении - "значением" будет структура, состоящая из двух полей: real_ip_header и real_ip_recursive. Если в директиве set_real_ip_from указаны все пять параметров - тогда значения полей real_ip_header и real_ip_recursive заполняются из дополнительных параметров. Если три или один - тогда отсутствующие парметры берутся из директив real_ip_header и/или real_ip_recursive. Таким образом - получается несколько вариантов записи директив модуля в конфигурационном файле nginx и при этом - всего одно внутреннее представление, с которым в рантайме работает модуль. В результате - получится максимально гибкая и максимально быстрая и максимально удобная версия модуля ngx_http_realip_module, которая позволит пользователям самостоятельно менять системы защиты от DDoS, без необходимости вносить какие-либо изменения в конфиг nginx. Это будет очень удобное свойство/качество, которое будет заметно облегчать и упрощать жизнь админам хостинговых серверов и владельцам сайтов. Максим, вопрос в том, можно ли будет в основной ветке nginx заменить текущую версию модуля ngx_http_realip_module новой версией модуля, в которой будет реализован вариант директивы set_real_ip_from с одним, тремя и пятью параметрами? Если можно - я попробую самостоятельно создать новую версию такого модуля ngx_http_realip_module, и буду присылать в список рассылки nginx-devel варианты модуля Вам на code review, ладно? Почему я об этом спрашиваю - просто хочу заранее с Вами договориться - о возможности включения новой версии модуля в основную ветку nginx. Чтобы не получилась такая ситуация, что я большое количество времени и сил потрачу зря и что результаты работы придется потом выборосить. Не знаю, сколько времени у меня займет, чтобы разобраться в том, как работает nginx и какое у него внутреннее API, но ведь если решение этой проблемы / задачи больше всех нужно именно мне, то логично будет именно мне написанием новой версии модуля ngx_http_realip_module и заниматься. -- Best regards, Gena From mdounin на mdounin.ru Mon Jun 12 01:26:57 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 12 Jun 2023 04:26:57 +0300 Subject: =?koi8-r?B?zs/XwdEg18XS08nRIM3PxNXM?= =?koi8-r?Q?=D1?= ngx_http_realip_module In-Reply-To: <57b21bb6-bb12-95dc-e225-10017d41f722@csdoc.com> References: <402740e6-4a38-d7eb-b297-dee487733b8e@csdoc.com> <57b21bb6-bb12-95dc-e225-10017d41f722@csdoc.com> Message-ID: 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 ; > > 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 ; > > > > 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 ; set_real_ip_from ; 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/ From mdounin на mdounin.ru Tue Jun 13 16:42:47 2023 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 13 Jun 2023 19:42:47 +0300 Subject: nginx-1.25.1 Message-ID: Изменения в nginx 1.25.1 13.06.2023 *) Добавление: директива http2, позволяющая включать HTTP/2 в отдельных блоках server; параметр http2 директивы listen объявлен устаревшим. *) Изменение: поддержка HTTP/2 server push упразднена. *) Изменение: устаревшая директива ssl больше не поддерживается. *) Исправление: в HTTP/3 при использовании OpenSSL. -- Maxim Dounin http://nginx.org/ From nginx-ru на ivanoff.spb.ru Tue Jun 13 19:07:38 2023 From: nginx-ru на ivanoff.spb.ru (Dmitry Ivanov) Date: Tue, 13 Jun 2023 22:07:38 +0300 Subject: nginx-1.25.1 In-Reply-To: References: Message-ID: <804784496.20230613220738@ivanoff.spb.ru> Здравствуйте, Maxim. Вы писали 13 июня 2023 г., 19:42:47: > *) Изменение: устаревшая директива ssl больше не поддерживается. Я 1000-кратно извиняюсь. И как теперь? В рассылке я не нашел, документация не изменилась... Это мне надо идти и везде это на что-то менять? -- С уважением, Dmitry nginx-ru на ivanoff.spb.ru From maxim на nginx.com Tue Jun 13 19:15:33 2023 From: maxim на nginx.com (Maxim Konovalov) Date: Tue, 13 Jun 2023 12:15:33 -0700 Subject: nginx-1.25.1 In-Reply-To: <804784496.20230613220738@ivanoff.spb.ru> References: <804784496.20230613220738@ivanoff.spb.ru> Message-ID: <15d8f9c5-92cd-2040-0ee9-53f1429b5121@nginx.com> Приветствую. On 13.06.2023 12:07, Dmitry Ivanov wrote: > Здравствуйте, Maxim. > > Вы писали 13 июня 2023 г., 19:42:47: > >> *) Изменение: устаревшая директива ssl больше не поддерживается. > > Я 1000-кратно извиняюсь. И как теперь? В рассылке я не нашел, > документация не изменилась... > > Это мне надо идти и везде это на что-то менять? > В документации достаточно подробно, https://nginx.org/r/ssl This directive was made obsolete in version 1.15.0 and was removed in version 1.25.1. The ssl parameter of the listen directive should be used instead. Другими словами, на эту директиву уже пять лет выдается предупреждение. -- Maxim Konovalov