LINUX.ORG.RU
ФорумAdmin

nginx revers proxy https


0

1

Что то не найду как проксировать внутрь сети https .

ngnix 443 -> site1 IIS 443
ngnix 443 -> site2 Apache 443

При простом конфиге:

server{
listen 443;
server_name blabla.ru;
location /{
proxy_pass https://site.dom.local;
}
}

У клиента ошибка: SSL получило запись, длина которой превышает максимально допустимую. (Код ошибки: ssl_error_rx_record_too_long).


Nginx. Reverse proxyn SSL.

кароч, по результату у меня получилось вот так:

# EXTERNAL HTTPS LISTENER ##################################################

server {
        listen            XXX.XXX.XXX.XXX:443;
        server_name       mydomain.com;

        access_log       /var/log/nginx/ssl-access.log;

        ssl                     on;
        ssl_protocols           SSLv3 TLSv1;
        ssl_certificate         /etc/nginx/ssl/cert.pem;
        ssl_certificate_key     /etc/nginx/ssl/cert.key;

        location / {
                proxy_pass            https://10.6.6.2/;
                proxy_redirect        off;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
                proxy_pass_header Set-Cookie;
        }
}

генерировать сертификат:

openssl req -new -x509 -days 2000 -nodes -out cert.pem -keyout cert.key

Acceptor ★★ ()

Общий вопрос: а действительно нужно шифровать трафик между бекендом и фронтендом?

vertexua ★★★★☆ ()

ну наверное сертификаты прописать, раз уж ты там SSL пытаешься поднять.

zgen ★★★★★ ()
Ответ на: комментарий от power

>кароч, по результату у меня получилось вот так:

да, сенкс. Заработало

Не делай так.

Что имеется ввиду?

Вот если бы еще можно было что нибудь придумать с NTLM авторизацией, а так пришлось на IIS отключить, изнутри сети народ уже бесится запросом паролей.

zooooo ()
Ответ на: комментарий от Acceptor

Что-что :)

SSL соединение должно устанавливаться между клиентами и nginx-фронтендом. Значит, SSL должен быть настроен на нем. У тебя же он и на фронтенде и на бэкенде. А это лишние телодвижения для настройки, лишний геморрой во время отладки, производительность, необходимость синхронизации настроек и сертификатов в случае чего и еще десятки факторов.

power ()
Ответ на: комментарий от power

>SSL соединение должно устанавливаться между клиентами и nginx-фронтендом. Значит, SSL должен быть настроен на нем. У тебя же он и на фронтенде и на бэкенде. А это лишние телодвижения для настройки, лишний геморрой во время отладки, производительность, необходимость синхронизации настроек и сертификатов в случае чего и еще десятки факторов.

Есть условие, что бы в локальной сети был только https, посему и SSL на бакэндах. Учитывая, что при использовании проксирования приходится включать бэйсик аутентификацию на IIS, то о простом http и речи быть не может. Понятно, когда между фронтэндом и бакэндом 100% доверенная сеть , то да - может и ненужен ssl на бакэндах.

zooooo ()
Ответ на: комментарий от zooooo

когда между фронтэндом и бакэндом 100% доверенная сеть

Я в шоке :)

power ()
Ответ на: комментарий от zooooo

учитывая что нгинкс плевал на валидность сертификата бакенда с высокой кручи - ssl на бакенде никак вас не спасет.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

как же он тогда авторизуется на бекендном сервере? как он оттуда данные забирает? интересненько было б знать. можно и ссылочку.

Acceptor ★★ ()
Ответ на: комментарий от ventilator

>учитывая что нгинкс плевал на валидность сертификата бакенда с высокой кручи - ssl на бакенде никак вас не спасет.

еще раз: внутри сети клиенты ходят напрямую на IIS по httpS, никакого http там нет. Вот и задача была прокинуть IIS https на ружу.

zooooo ()
Ответ на: комментарий от power

>Я в шоке :)

Это не ДЦ. Представь, кроме датацентров имеются множество структур, с различной организацией и деятельностью.

zooooo ()
Ответ на: комментарий от zooooo

>>учитывая что нгинкс плевал на валидность сертификата бакенда с высокой кручи - ssl на бакенде никак вас не спасет.

еще раз: внутри сети клиенты ходят напрямую на IIS по httpS, никакого http там нет. Вот и задача была прокинуть IIS https на ружу.

Еще раз: нгинкс плевать хотел на валидность сертификата бакенда (к которому ходит по https). Потому вся эта ваша секурность до одного места - ничего не мешает подменить бакенд вместе с сертификатом, раз уж у вас такая сеть небезопасная.

ventilator ★★★ ()
Ответ на: комментарий от ventilator

>Еще раз: нгинкс плевать хотел на валидность сертификата бакенда (к которому ходит по https). Потому вся эта ваша секурность до одного места - ничего не мешает подменить бакенд вместе с сертификатом, раз уж у вас такая сеть небезопасная.

Это все понятно. Но клиенту нужен https для того, что бы снифером не вытянули plain text авторизацию. Как я уже писал ngnix не работает с NTLM и на IIS пришлось его отключить. 99% клиентов - винды.

zooooo ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.