forum.opennet.ru - "Реверсный прокси Nginx не передает звук и динамическую графику" (17)

"Реверсный прокси Nginx не передает звук и динамическую графику"

Форум Настройка Squid, Tor и прокси серверов (Другие proxy)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Реверсный прокси Nginx не передает звук и динамическую графику"	+1 +/–
Сообщение от chukcha (??), 04-Апр-20, 21:41
Здравствуйте! На ЛОРе обломились с этим вопросом, может, здесь найдутся знатоки реверсного прокси на основе Nginx. Нашлись нашлись сайты, где он оказался не в состоянии передавать звук и динамическую графику. Вот пример одного из таких удивительных сайтов: http://websdr.ewi.utwente.nl:8901/ На этом сайте практически любой современный браузер при выборе опции HTML5 прекрасно воспроизводит как движущийся водопад (waterfall), так и звук радостанции. Однако стоит пропустить этот сайт через реверсный прокси на основе Nginx c нижеизложенным фрагментом конфига, как теряется и водопад, и звук, остается только мертвая веб-страница. Воможно ли исправить этот недостаток? #--------------- server { server_name websdr.ewi.utwente.nl; listen 185.66.13.169:80; location / { proxy_pass http://websdr.ewi.utwente.nl:8901; proxy_redirect default; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; } } #--------------
Ответить \| Правка \| Cообщить модератору

Оглавление

Буферизацию отключите и протокол сделайте 1 1 , Аноним (2), 15:31 , 05-Апр-20, (2)
попробуйте выключить буфер https nginx org ru docs http ngx_http_proxy_module , name (??), 17:00 , 09-Май-20, (3)

Спасибо, уже решил этот вопрос, но возникла другая проблема - прокси показывает , Шилов (?), 18:39 , 09-Май-20, (4)

Что значит прокси показывает Сайт, которой за прокси, ничего про, собственно, , Licha Morada (ok), 05:16 , 10-Май-20, (5)

b Licha Morada b А если придется доверять , то это чем-то плохо в плане без, Шилов (?), 21:36 , 10-Май-20, (6)

Или как Представьте себе, сидите вы у себя в кабинете, открывается дверь и заход, Licha Morada (ok), 01:18 , 11-Май-20, (7)

b Licha Morada b Спасибо за столь развернутый ответ про Машу и медведей, но я , Шилов (?), 06:56 , 11-Май-20, (8)

Очень грубо говоря - скорее всего нет А точнее, нет такой вещи как безопасность, Licha Morada (ok), 20:28 , 11-Май-20, (9)

Хорошо, я согласен Как это сделать , Шилов (?), 00:43 , 12-Май-20, (10)

Вопрос не по адресу Надо править либо код движка, либо конфигурацию Возможно, с, Licha Morada (ok), 01:52 , 12-Май-20, (11)

Автор уже много лет как забросил его и на все просьбы его хоть чуток модернизиро, Шилов (?), 01:55 , 12-Май-20, (12)

Тогда погрустим , Licha Morada (ok), 18:10 , 12-Май-20, (13)

Все же мне, как дилетатнту, кажется, что тут не веб-сервер виноват, а реверсный, Шилов (?), 23:28 , 12-Май-20, (14)
Если вы перехватите трафик между сервером и прокси, то увидете что веб-сервер в , Licha Morada (ok), 00:24 , 13-Май-20, (15)
Поэтому и говорю - вопрос дилетанта Но вы так толково объяснили, особенно с гр, Шилов (?), 00:39 , 13-Май-20, (16)
Обычно сжатие непосредственно в протокол высокого уровня встраивают Возможно, он, Licha Morada (ok), 00:48 , 13-Май-20, (17)
Про опцию gzip в обычных веб-сайтах в курсе Но тут речь не о том прокси , а о, Шилов (?), 01:19 , 13-Май-20, (18)

Сообщения [Сортировка по ответам | RSS]

2. Сообщение от Аноним (2), 05-Апр-20, 15:31 +/–

Буферизацию отключите и протокол сделайте 1.1.

Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от name (??), 09-Май-20, 17:00 +/–

попробуйте выключить буфер https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pr...

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

4. Сообщение от Шилов (?), 09-Май-20, 18:39 +/–

> попробуйте выключить буфер https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pr...
Спасибо, уже решил этот вопрос, но возникла другая проблема - прокси показывает не реальный IP посетителя, заходящего на сайт, а IP самого прокси.
Добавил в конфиг еще 2 строки, и получилось нижеследующее.
Однако IP все равно от прокси. Где  же я ошибаюсь?
server {
listen 185.33.33.33:80; # IP [и порт] реверсного прокси-сервера
location / {
proxy_pass http://94.22.22.22:2222; # URL [и порт] реального веб-сервера
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection «upgrade»;
proxy_redirect default;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
set_real_ip_from 185.33.33.33;
real_ip_header X-Real-IP;
}
}

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #5

5. Сообщение от Licha Morada (ok), 10-Май-20, 05:16 +/–

> Спасибо, уже решил этот вопрос, но возникла другая проблема - прокси показывает
> не реальный IP посетителя, заходящего на сайт, а IP самого прокси.
Что значит "прокси показывает"?
Сайт, которой за прокси, ничего про, собственно, прокси знать не может. Для него прокси это клиент HTTP, генерирующий анормально высокий и разнообразный траффик с одного и того-же IP адреса.
Если сайту требуется знать IP настоящего клиента, то ему придётся кооперироваться с прокси и доверять ему, читая хедер X-Forwarded-For и/или Forwarded. Первый способ, ИМХО. более распостранён
https://en.wikipedia.org/wiki/X-Forwarded-For
> Добавил в конфиг еще 2 строки, и получилось нижеследующее.
> Однако IP все равно от прокси. Где  же я ошибаюсь?
В концепции.
Веб сервер узнаёт IP клиента из параметров TCP сессии а не из хедеров. Там всегда будет IP прокси, иначе они не смогут обмениваться пакетами.
set_real_ip_from и real_ip_header это про другое.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #6

6. Сообщение от Шилов (?), 10-Май-20, 21:36 +/–

Licha Morada
> Если сайту требуется знать IP настоящего клиента, то ему придётся
> кооперироваться с прокси и доверять ему, читая хедер X-Forwarded-For
> и/или Forwarded.
> Первый способ, ИМХО. более распостранён
> https://en.wikipedia.org/wiki/X-Forwarded-For
А если "придется...доверять", то это чем-то плохо в плане безопасности, или как?
>> Добавил в конфиг еще 2 строки, и получилось нижеследующее.
>> Однако IP все равно от прокси. Где  же я ошибаюсь?
> В концепции.
Понятно :) Ну, раз моя концепция плоха, то покажу ее в действии на реальном сервере, надеясь, что вы ее, в виде конфига, подправите.
К примеру, есть такой сайт - http://74.118.150.6:8901/
Если зайти на него, то в самом низу, где черные поля, он обязательно покажет ваш IP.
На своем прокси-сервере 185.66.13.169 смастерил такой фрагмент конфига Nginx -

server {
         listen       185.66.13.169:80;         # IP [и порт] реверсного прокси-сервера
         location / {
             proxy_pass       http://74.118.150.6:8901;   # URL [и порт] реального веб-сервера
             proxy_http_version 1.1;
             proxy_set_header Upgrade $http_upgrade;
             proxy_set_header Connection "upgrade";
             proxy_redirect   default;
             proxy_set_header Host              $http_host;
             proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
             proxy_set_header X-Forwarded-Proto $scheme;
             proxy_set_header X-Real-IP         $remote_addr;
            set_real_ip_from 185.66.13.169;
            real_ip_header X-Real-IP;
                     }
         }
Но поскольку моя концепция плоха, то при заходе на этот прокси он каждый раз показывает IP не посетителя, а IP самого прокси, т.е. 185.66.13.169.
Подскажите, плиз, как нужно подправить эту концепцию в конфиге, чтобы он показывал реальный IP посетителя? ;)
Самому с этой задачей мне не удается справиться, несмотря на вашу подсказку на вики.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #7

7. Сообщение от Licha Morada (ok), 11-Май-20, 01:18 +/–

> А если "придется...доверять", то это чем-то плохо в плане безопасности, или как?
Или как.
Представьте себе, сидите вы у себя в кабинете, открывается дверь и заходит ваша секретарша Maша, которая говорит:
- Здравствуйте. Вам звонил Матвей Иванович, просил передать что...
И тут вы её строго обрывате:
- Маша, сколько раз вам надо повторять? Я не могу принимать сообщения от других людей, когда их содержимое произносите вы! Мне надо видеть перед собой настоящий источник, иначе это плохо в плане безопасности. Если вам есть что предать мне от Матвея Изановича, то будте добры, загримируйтесь под него как следует, у уже тогда приходите. А то как я могу поверить, что это сообщение от Матвея Ивановича, когда вижу перед собой вас, Машу?

> Подскажите, плиз, как нужно подправить эту концепцию в конфиге, чтобы он показывал
> реальный IP посетителя? ;)
Боюсь что никак.
Только средствами конфига своего прокси, вы не заставите сайт http://74.118.150.6:8901/ показывать настоящий адрес клиента.
Это зависит не столько от прокси, сколько а от того, как запрограммирован сайт. Его можно было бы запрограммировать иначе, это может сделать хозяин сайта.
Вообще, оно вам зачем?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #8

8. Сообщение от Шилов (?), 11-Май-20, 06:56 +/–

Licha Morada
Спасибо за столь развернутый ответ про Машу и медведей, но я из него мало что понял :)
Мне бы попроще - пострадает ли безопасность, чья и почему.
Ну да ладно. Важнее второй вопрос.

>> Подскажите, плиз, как нужно подправить эту концепцию в конфиге, чтобы он показывал
>> реальный IP посетителя? ;)
> Боюсь что никак.
> Только средствами конфига своего прокси, вы не заставите сайт http://74.118.150.6:8901/
> показывать настоящий адрес клиента.
> Это зависит не столько от прокси, сколько а от того, как запрограммирован
> сайт. Его можно было бы запрограммировать иначе, это может сделать хозяин
> сайта.
Жаль, жаль.. Влияния на софт того веб-сайта у меня нет, так что придется смириться.

> Вообще, оно вам зачем?
Пытаюсь создать аналогичный радиосайт. Но дело в том, что разработчик  движка радиосайта прямо предупреждает, что он не гарантирует отсутствие уязвимостей, через который он может быть взломан, и рекомендует  иметь это в виду.
Вот я и пытаюсь "иметь это в виду", защитив его промежуточным реверсным прокси.
Если кому охота его ломать - на здоровье, вряд ли они найдут в Nginx серьезные уязвимости, поскольку Сысоев его активно поддерживает.
Побочный эффект такой прокси-защиты - потеря отображения реальных IP посетителей.
Ладно, а можна хотя бы вместо IP прокси, который присваивается всем посетителям, что выглядит не очень красиво, отображать какой-нибудь стринг?
Например, "Your IP hidden".
Это будет более понятно и корректно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #9

9. Сообщение от Licha Morada (ok), 11-Май-20, 20:28 +/–

> Мне бы попроще - пострадает ли безопасность, чья и почему.
Очень грубо говоря - скорее всего нет.
А точнее, нет такой вещи как "безопасность" вообще. Надо идентифицировать риски, отдавать себе отчёт от чего конкретно надо защищаться (называется "модель угрозы") и на основе этого оценивать, как повлияют на защищённость те или иные меры. Тогда можно будет сказать, пострадет ли безопасность.

>> Вообще, оно вам зачем?
> Пытаюсь создать аналогичный радиосайт. Но дело в том, что разработчик  движка
> радиосайта прямо предупреждает, что он не гарантирует отсутствие уязвимостей, через который
> он может быть взломан, и рекомендует  иметь это в виду.
Если вы у себя собираетесь движок разворачивать, то у вас есть влияние на веб сайт.
Вам придётся залезть в код, найти где и как как он определят текст, который надо показывать в качестве IP клиента, и дополнить его парсингом хедера X-Forwarded-For. Или писать "Your IP hidden".
> Вот я и пытаюсь "иметь это в виду", защитив его промежуточным реверсным
> прокси.
Сам факт наличия промежуточного прокси защиты добавляет мало. Если он просто транслирует всё как есть, то он пропустит "атаку" как любой другой запрос.
Обратным прокси можно достичь нескольких полезных вещей.
Например, терминировать TLS сессии, а именно публиковать HTTPS даже если апстрим умеет только HTTP.
Или разрешать доступ в определённому пути в URL, вместо корня сайта.
Или фильтровать клиентов по IP.
Или ограничивать интенсивность траффика от конкретных клиентов.
Иногда это даёт необходмую защиту. Иногда нет, зависит от сайта и модели угрозы.
Чтобы защитить дырявый движок обратным прокси, по меньщей мере надо конкретно знать, какие дырки закрывать и как выглядит атака на каждую из них. Неблагодарное занятие.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10

10. Сообщение от Шилов (?), 12-Май-20, 00:43 +/–

> Или писать "Your IP hidden".
Хорошо, я согласен :)  Как это сделать?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #11

11. Сообщение от Licha Morada (ok), 12-Май-20, 01:52 +/–

>> Или писать "Your IP hidden".
> Хорошо, я согласен :)  Как это сделать?
Вопрос не по адресу. Надо править либо код движка, либо конфигурацию.
Возможно, с поддержкой автора движка. Кстати, почему бы вам с нему не обратиться? Предположите что он берёт адрес клиента из переменной окружения HTTP_CLIENT_IP или HTTP_REMOTE_ADDR, а вам хочется его брать из HTTP_X_FORWARDED_FOR или HTTP_VIA. И как бы это половчей сделать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #12

12. Сообщение от Шилов (?), 12-Май-20, 01:55 +/–

> Возможно, с поддержкой автора движка. Кстати, почему бы вам с нему не
> обратиться?
Автор уже много лет как забросил его и на все просьбы его хоть чуток модернизировать отвечает отрицательно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #13

13. Сообщение от Licha Morada (ok), 12-Май-20, 18:10 +/–

Тогда погрустим.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #14

14. Сообщение от Шилов (?), 12-Май-20, 23:28 +/–

Все же мне, как дилетатнту,  кажется, что тут не веб-сервер виноват, а реверсный Nginx-прокси, который ^пока^ не  понимает и не передает реальный IP.
Ведь веб-сервер отдает реальный IP? Отдает. Причем неважно кому - реальному посетителю или прокси.
А вот реверсный прокси его "срезает".
Если бы, к примеру, создали к Nginx какой-то плагин, что ли, и тогда реальный IP отображался бы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #15

15. Сообщение от Licha Morada (ok), 13-Май-20, 00:24 +/–

Если вы перехватите трафик между сервером и прокси, то увидете что веб-сервер в теле страницы отдает тот IP адрес прокси сервера. Прокси же транслирует этот ответ без изменений.
Реальный IP никто никуда специально не передаёт, и срезать его негде.
Сервер узнаёт адрес IP из параметров сессии TCP/IP. При общении через прокси, устанавливаются две разные сессии, одна от клиента к прокси, где в качестве источника видно адрес клиента, другая от прокси к серверу, где видно источнико выступает уже адрес прокси. Конструкция так и задумана, чтобы изолировать эти сессии одну от другой на сетевом уровне.
Собствено, Nginx-прокси реальный IP клиента серверу таки передаёт, но имеет в своём распоряжении только уровень приложения, чем и пользуется, формируя информацию в виде специального хедера HTTP.

> Если бы, к примеру, создали к Nginx какой-то плагин, что ли, и
> тогда реальный IP отображался бы.
Есть такой достаточно грязный хак. Мы его иногда используем, в качестве временной меры и обвешиваем со всех сторон красными флажками. Скорее всего, он доставит больше проблем чем решит, но раз вам так приспичело...
Короче, Nginx умеет делать подстаноку текста на лету (search and replace). И если вы его должным образом сконфигурируете, то он может ответах сервера, перед тем как передать их клиенту, заменять текст "Вася Пупкин" на "Пупа Васькин", а текст "185.66.13.169" на содержимое $remote_addr. Подстановка совершенно тупая, и что то неё начнёт глючить - ХЗ. Но в теле ответа который получит клиентвместо адреса прокси окажется его собственный адрес.
Делать так: http://nginx.org/en/docs/http/ngx_http_sub_module.html
Феномен Энциклонгов обусловлен похожим решением.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #16

16. Сообщение от Шилов (?), 13-Май-20, 00:39 +/–

> Подстановка совершенно тупая, и что то неё начнёт глючить - ХЗ.
> Но в теле ответа который получит клиентвместо адреса прокси
> окажется его собственный адрес.
> Скорее всего, он доставит больше проблем чем решит,
> но раз вам так приспичело...
Поэтому и говорю - вопрос дилетанта :)
Но вы так толково объяснили, особенно с грязным хаком, что решил отказаться от этого замысла. Спасибо за разъяснение! :)
Уберу совсем окно с отображением IP, да и ладно.
Потому что на очереди другая, более актуальная проблема: сжатие трафика на лету.
Не знаю, по адресу ли обращаюсь, но на всякий случай спрошу:
- если ли готовые программные решения по сжатию двухстороннего трафика на лету?
Т.е. между 2-мя серверами.
Имеющийся трафик имеет скорость 200 Мбит/с, а мне бы очень хотелось бы его втиснуть в 100 Мбит, причем с минимальной задержкой.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #17

17. Сообщение от Licha Morada (ok), 13-Май-20, 00:48 +/–

> если ли готовые программные решения по сжатию двухстороннего трафика на лету?
Обычно сжатие непосредственно в протокол высокого уровня встраивают.
Возможно, оно уже используется.
Если это всё про тот-же самый прокси, то https://nginx.org/en/docs/http/ngx_http_gzip_module.html
Если абстрагироваться, то вам придётся строить оверлейную сеть ( https://en.wikipedia.org/wiki/Overlay_network ) с поддержкой сжатия.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #18

18. Сообщение от Шилов (?), 13-Май-20, 01:19 +/–

> Обычно сжатие непосредственно в протокол высокого уровня встраивают.
> Возможно, оно уже используется.
> Если это всё про тот-же самый прокси, то https://nginx.org/en/docs/http/ngx_http_gzip_module.html
Про опцию 'gzip' в обычных веб-сайтах в курсе.
Но тут речь не о "том прокси", а о веб-сервере WebSDR, который, в свою очередь, обменивается данными с удаленным сервером RTL-SDR.
Встроено ли сжатие или нет, неизвестно, исходного кода нет.
Но трафик жрет немеряно, так что, имхо, ничего не встроено.

> Если абстрагироваться, то вам придётся строить оверлейную сеть ( https://en.wikipedia.org/wiki/Overlay_network
> ) с поддержкой сжатия.
Посмотрел на эту чудо-сеть - и понял, что дешевле доплатить провайдеру за более широкий канал :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

2. Сообщение от Аноним (2), 05-Апр-20, 15:31	+/–
Буферизацию отключите и протокол сделайте 1.1.
Ответить \| Правка \| Наверх \| Cообщить модератору

3. Сообщение от name (??), 09-Май-20, 17:00	+/–
попробуйте выключить буфер https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pr...
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #4

4. Сообщение от Шилов (?), 09-Май-20, 18:39	+/–
> попробуйте выключить буфер https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pr... Спасибо, уже решил этот вопрос, но возникла другая проблема - прокси показывает не реальный IP посетителя, заходящего на сайт, а IP самого прокси. Добавил в конфиг еще 2 строки, и получилось нижеследующее. Однако IP все равно от прокси. Где же я ошибаюсь? server { listen 185.33.33.33:80; # IP [и порт] реверсного прокси-сервера location / { proxy_pass http://94.22.22.22:2222; # URL [и порт] реального веб-сервера proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection «upgrade»; proxy_redirect default; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; set_real_ip_from 185.33.33.33; real_ip_header X-Real-IP; } }
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3 Ответы: #5

5. Сообщение от Licha Morada (ok), 10-Май-20, 05:16	+/–
> Спасибо, уже решил этот вопрос, но возникла другая проблема - прокси показывает > не реальный IP посетителя, заходящего на сайт, а IP самого прокси. Что значит "прокси показывает"? Сайт, которой за прокси, ничего про, собственно, прокси знать не может. Для него прокси это клиент HTTP, генерирующий анормально высокий и разнообразный траффик с одного и того-же IP адреса. Если сайту требуется знать IP настоящего клиента, то ему придётся кооперироваться с прокси и доверять ему, читая хедер X-Forwarded-For и/или Forwarded. Первый способ, ИМХО. более распостранён https://en.wikipedia.org/wiki/X-Forwarded-For > Добавил в конфиг еще 2 строки, и получилось нижеследующее. > Однако IP все равно от прокси. Где же я ошибаюсь? В концепции. Веб сервер узнаёт IP клиента из параметров TCP сессии а не из хедеров. Там всегда будет IP прокси, иначе они не смогут обмениваться пакетами. set_real_ip_from и real_ip_header это про другое.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #6

6. Сообщение от Шилов (?), 10-Май-20, 21:36	+/–
Licha Morada > Если сайту требуется знать IP настоящего клиента, то ему придётся > кооперироваться с прокси и доверять ему, читая хедер X-Forwarded-For > и/или Forwarded. > Первый способ, ИМХО. более распостранён > https://en.wikipedia.org/wiki/X-Forwarded-For А если "придется...доверять", то это чем-то плохо в плане безопасности, или как? >> Добавил в конфиг еще 2 строки, и получилось нижеследующее. >> Однако IP все равно от прокси. Где же я ошибаюсь? > В концепции. Понятно :) Ну, раз моя концепция плоха, то покажу ее в действии на реальном сервере, надеясь, что вы ее, в виде конфига, подправите. К примеру, есть такой сайт - http://74.118.150.6:8901/ Если зайти на него, то в самом низу, где черные поля, он обязательно покажет ваш IP. На своем прокси-сервере 185.66.13.169 смастерил такой фрагмент конфига Nginx - server { listen 185.66.13.169:80; # IP [и порт] реверсного прокси-сервера location / { proxy_pass http://74.118.150.6:8901; # URL [и порт] реального веб-сервера proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_redirect default; proxy_set_header Host $http_host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Real-IP $remote_addr; set_real_ip_from 185.66.13.169; real_ip_header X-Real-IP; } } Но поскольку моя концепция плоха, то при заходе на этот прокси он каждый раз показывает IP не посетителя, а IP самого прокси, т.е. 185.66.13.169. Подскажите, плиз, как нужно подправить эту концепцию в конфиге, чтобы он показывал реальный IP посетителя? ;) Самому с этой задачей мне не удается справиться, несмотря на вашу подсказку на вики.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #5 Ответы: #7

7. Сообщение от Licha Morada (ok), 11-Май-20, 01:18	+/–
> А если "придется...доверять", то это чем-то плохо в плане безопасности, или как? Или как. Представьте себе, сидите вы у себя в кабинете, открывается дверь и заходит ваша секретарша Maша, которая говорит: - Здравствуйте. Вам звонил Матвей Иванович, просил передать что... И тут вы её строго обрывате: - Маша, сколько раз вам надо повторять? Я не могу принимать сообщения от других людей, когда их содержимое произносите вы! Мне надо видеть перед собой настоящий источник, иначе это плохо в плане безопасности. Если вам есть что предать мне от Матвея Изановича, то будте добры, загримируйтесь под него как следует, у уже тогда приходите. А то как я могу поверить, что это сообщение от Матвея Ивановича, когда вижу перед собой вас, Машу? > Подскажите, плиз, как нужно подправить эту концепцию в конфиге, чтобы он показывал > реальный IP посетителя? ;) Боюсь что никак. Только средствами конфига своего прокси, вы не заставите сайт http://74.118.150.6:8901/ показывать настоящий адрес клиента. Это зависит не столько от прокси, сколько а от того, как запрограммирован сайт. Его можно было бы запрограммировать иначе, это может сделать хозяин сайта. Вообще, оно вам зачем?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #8

8. Сообщение от Шилов (?), 11-Май-20, 06:56	+/–
Licha Morada Спасибо за столь развернутый ответ про Машу и медведей, но я из него мало что понял :) Мне бы попроще - пострадает ли безопасность, чья и почему. Ну да ладно. Важнее второй вопрос. >> Подскажите, плиз, как нужно подправить эту концепцию в конфиге, чтобы он показывал >> реальный IP посетителя? ;) > Боюсь что никак. > Только средствами конфига своего прокси, вы не заставите сайт http://74.118.150.6:8901/ > показывать настоящий адрес клиента. > Это зависит не столько от прокси, сколько а от того, как запрограммирован > сайт. Его можно было бы запрограммировать иначе, это может сделать хозяин > сайта. Жаль, жаль.. Влияния на софт того веб-сайта у меня нет, так что придется смириться. > Вообще, оно вам зачем? Пытаюсь создать аналогичный радиосайт. Но дело в том, что разработчик движка радиосайта прямо предупреждает, что он не гарантирует отсутствие уязвимостей, через который он может быть взломан, и рекомендует иметь это в виду. Вот я и пытаюсь "иметь это в виду", защитив его промежуточным реверсным прокси. Если кому охота его ломать - на здоровье, вряд ли они найдут в Nginx серьезные уязвимости, поскольку Сысоев его активно поддерживает. Побочный эффект такой прокси-защиты - потеря отображения реальных IP посетителей. Ладно, а можна хотя бы вместо IP прокси, который присваивается всем посетителям, что выглядит не очень красиво, отображать какой-нибудь стринг? Например, "Your IP hidden". Это будет более понятно и корректно.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #9

9. Сообщение от Licha Morada (ok), 11-Май-20, 20:28	+/–
> Мне бы попроще - пострадает ли безопасность, чья и почему. Очень грубо говоря - скорее всего нет. А точнее, нет такой вещи как "безопасность" вообще. Надо идентифицировать риски, отдавать себе отчёт от чего конкретно надо защищаться (называется "модель угрозы") и на основе этого оценивать, как повлияют на защищённость те или иные меры. Тогда можно будет сказать, пострадет ли безопасность. >> Вообще, оно вам зачем? > Пытаюсь создать аналогичный радиосайт. Но дело в том, что разработчик движка > радиосайта прямо предупреждает, что он не гарантирует отсутствие уязвимостей, через который > он может быть взломан, и рекомендует иметь это в виду. Если вы у себя собираетесь движок разворачивать, то у вас есть влияние на веб сайт. Вам придётся залезть в код, найти где и как как он определят текст, который надо показывать в качестве IP клиента, и дополнить его парсингом хедера X-Forwarded-For. Или писать "Your IP hidden". > Вот я и пытаюсь "иметь это в виду", защитив его промежуточным реверсным > прокси. Сам факт наличия промежуточного прокси защиты добавляет мало. Если он просто транслирует всё как есть, то он пропустит "атаку" как любой другой запрос. Обратным прокси можно достичь нескольких полезных вещей. Например, терминировать TLS сессии, а именно публиковать HTTPS даже если апстрим умеет только HTTP. Или разрешать доступ в определённому пути в URL, вместо корня сайта. Или фильтровать клиентов по IP. Или ограничивать интенсивность траффика от конкретных клиентов. Иногда это даёт необходмую защиту. Иногда нет, зависит от сайта и модели угрозы. Чтобы защитить дырявый движок обратным прокси, по меньщей мере надо конкретно знать, какие дырки закрывать и как выглядит атака на каждую из них. Неблагодарное занятие.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #10

10. Сообщение от Шилов (?), 12-Май-20, 00:43	+/–
> Или писать "Your IP hidden". Хорошо, я согласен :) Как это сделать?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9 Ответы: #11

11. Сообщение от Licha Morada (ok), 12-Май-20, 01:52	+/–
>> Или писать "Your IP hidden". > Хорошо, я согласен :) Как это сделать? Вопрос не по адресу. Надо править либо код движка, либо конфигурацию. Возможно, с поддержкой автора движка. Кстати, почему бы вам с нему не обратиться? Предположите что он берёт адрес клиента из переменной окружения HTTP_CLIENT_IP или HTTP_REMOTE_ADDR, а вам хочется его брать из HTTP_X_FORWARDED_FOR или HTTP_VIA. И как бы это половчей сделать.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #10 Ответы: #12

12. Сообщение от Шилов (?), 12-Май-20, 01:55	+/–
> Возможно, с поддержкой автора движка. Кстати, почему бы вам с нему не > обратиться? Автор уже много лет как забросил его и на все просьбы его хоть чуток модернизировать отвечает отрицательно.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #13

13. Сообщение от Licha Morada (ok), 12-Май-20, 18:10	+/–
Тогда погрустим.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12 Ответы: #14

14. Сообщение от Шилов (?), 12-Май-20, 23:28	+/–
Все же мне, как дилетатнту, кажется, что тут не веб-сервер виноват, а реверсный Nginx-прокси, который ^пока^ не понимает и не передает реальный IP. Ведь веб-сервер отдает реальный IP? Отдает. Причем неважно кому - реальному посетителю или прокси. А вот реверсный прокси его "срезает". Если бы, к примеру, создали к Nginx какой-то плагин, что ли, и тогда реальный IP отображался бы.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #13 Ответы: #15

15. Сообщение от Licha Morada (ok), 13-Май-20, 00:24	+/–
Если вы перехватите трафик между сервером и прокси, то увидете что веб-сервер в теле страницы отдает тот IP адрес прокси сервера. Прокси же транслирует этот ответ без изменений. Реальный IP никто никуда специально не передаёт, и срезать его негде. Сервер узнаёт адрес IP из параметров сессии TCP/IP. При общении через прокси, устанавливаются две разные сессии, одна от клиента к прокси, где в качестве источника видно адрес клиента, другая от прокси к серверу, где видно источнико выступает уже адрес прокси. Конструкция так и задумана, чтобы изолировать эти сессии одну от другой на сетевом уровне. Собствено, Nginx-прокси реальный IP клиента серверу таки передаёт, но имеет в своём распоряжении только уровень приложения, чем и пользуется, формируя информацию в виде специального хедера HTTP. > Если бы, к примеру, создали к Nginx какой-то плагин, что ли, и > тогда реальный IP отображался бы. Есть такой достаточно грязный хак. Мы его иногда используем, в качестве временной меры и обвешиваем со всех сторон красными флажками. Скорее всего, он доставит больше проблем чем решит, но раз вам так приспичело... Короче, Nginx умеет делать подстаноку текста на лету (search and replace). И если вы его должным образом сконфигурируете, то он может ответах сервера, перед тем как передать их клиенту, заменять текст "Вася Пупкин" на "Пупа Васькин", а текст "185.66.13.169" на содержимое $remote_addr. Подстановка совершенно тупая, и что то неё начнёт глючить - ХЗ. Но в теле ответа который получит клиентвместо адреса прокси окажется его собственный адрес. Делать так: http://nginx.org/en/docs/http/ngx_http_sub_module.html Феномен Энциклонгов обусловлен похожим решением.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #14 Ответы: #16

16. Сообщение от Шилов (?), 13-Май-20, 00:39	+/–
> Подстановка совершенно тупая, и что то неё начнёт глючить - ХЗ. > Но в теле ответа который получит клиентвместо адреса прокси > окажется его собственный адрес. > Скорее всего, он доставит больше проблем чем решит, > но раз вам так приспичело... Поэтому и говорю - вопрос дилетанта :) Но вы так толково объяснили, особенно с грязным хаком, что решил отказаться от этого замысла. Спасибо за разъяснение! :) Уберу совсем окно с отображением IP, да и ладно. Потому что на очереди другая, более актуальная проблема: сжатие трафика на лету. Не знаю, по адресу ли обращаюсь, но на всякий случай спрошу: - если ли готовые программные решения по сжатию двухстороннего трафика на лету? Т.е. между 2-мя серверами. Имеющийся трафик имеет скорость 200 Мбит/с, а мне бы очень хотелось бы его втиснуть в 100 Мбит, причем с минимальной задержкой.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #17

17. Сообщение от Licha Morada (ok), 13-Май-20, 00:48	+/–
> если ли готовые программные решения по сжатию двухстороннего трафика на лету? Обычно сжатие непосредственно в протокол высокого уровня встраивают. Возможно, оно уже используется. Если это всё про тот-же самый прокси, то https://nginx.org/en/docs/http/ngx_http_gzip_module.html Если абстрагироваться, то вам придётся строить оверлейную сеть ( https://en.wikipedia.org/wiki/Overlay_network ) с поддержкой сжатия.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16 Ответы: #18

18. Сообщение от Шилов (?), 13-Май-20, 01:19	+/–
> Обычно сжатие непосредственно в протокол высокого уровня встраивают. > Возможно, оно уже используется. > Если это всё про тот-же самый прокси, то https://nginx.org/en/docs/http/ngx_http_gzip_module.html Про опцию 'gzip' в обычных веб-сайтах в курсе. Но тут речь не о "том прокси", а о веб-сервере WebSDR, который, в свою очередь, обменивается данными с удаленным сервером RTL-SDR. Встроено ли сжатие или нет, неизвестно, исходного кода нет. Но трафик жрет немеряно, так что, имхо, ничего не встроено. > Если абстрагироваться, то вам придётся строить оверлейную сеть ( https://en.wikipedia.org/wiki/Overlay_network > ) с поддержкой сжатия. Посмотрел на эту чудо-сеть - и понял, что дешевле доплатить провайдеру за более широкий канал :)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17