Пропуск SSL-прокси с NGINX, приводящий к плохому шлюзу через Docker

Question

Фон

Моя установка основана на следующем уроке:

Докеризация Django с Postgres, Gunicorn и NGINX

TL; DR: ( курсив: не рассматривается в учебнике; личное приключение )

• 3 Службы Docker для: nginx -> django -> postgres (стрелка, указывающая зависимость)
• Прокси-сервер Nginx передает запросы на открытый портв сервисе Django.
• HTTP (не-SSL) запросы работают
• требуют SSL-соединений путем перенаправления http -> https

---

Подробности

Я сгенерировал самозаверяющий сертификат для локального тестирования ssl-перенаправлений с NGINX, прежде чем пытаться заставить его работать на VPS в рабочей среде.Я совершенно новичок в работе с NGINX, и поэтому я не совсем уверен, что идет не так или как диагностировать проблемы.

Вот что я хочу, чтобы произошло с файлом NGINX, который я 'VE представлено ниже ... (спойлеры: это не так) :

1. Перейти к http://localhost
2. Получить перенаправление к https://localhost
3. Предупреждение от браузера о самоподписанном сертификате;принять предупреждение и продолжить
4. Сайт исправен, перенаправление SSL работает!

Но это не так.Я получаю 502 Bad Gateway, и NGINX выводит следующие журналы:

prod_1  | 192.168.144.1 - - [03/Jun/2019:00:01:44 +0000] "GET / HTTP/1.1" 502 158 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0" "-"
prod_1  | 2019/06/03 00:01:44 [error] 8#8: *1 peer closed connection in SSL handshake while SSL handshaking to upstream, client: 192.168.144.1, server: , request: "GET / HTTP/1.1", upstream: "https://192.168.144.3:8000/", host: "localhost"

Может кто-нибудь сказать мне, что происходит или как это исправить?Я чувствую, что с моим conf-файлом, возможно, не все в порядке, даже за исключением перенаправления SSL, но я не знаю, как определить какие-либо проблемы.Конфи файл ниже ...

upstream mysite {
    server web:8000;
}

# redirect http traffic to https
server {
    listen 80;
    listen [::]:80;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    location / {
        proxy_pass https://mysite;
        proxy_ssl_server_name   on;

        proxy_set_header        Host $host;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        X-Forwarded-Proto $scheme;

        proxy_redirect          off;
    }

    location /assets/ {
        alias /usr/src/site/assets/;
    }

    location /media/ {
        alias /usr/src/site/media/;
    }

    ssl_certificate         /etc/ssl/certificates/site.crt;
    ssl_certificate_key     /etc/ssl/certificates/site.key;

    ssl_session_cache           builtin:1000 shared:SSL:10m;
    ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers                 HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers   on;

}

Answer 1

На основании вашей ошибки

prod_1  | 2019/06/03 00:01:44 [error] 8#8: *1 peer closed connection in SSL handshake while SSL handshaking to upstream, client: 192.168.144.1, server: , request: "GET / HTTP/1.1", upstream: "https://192.168.144.3:8000/", host: "localhost"

Я бы сказал, что у вас есть какое-то несоответствие протокола между Nginx и Django. Вероятно, что Django ожидает небезопасную связь (http). Ваша конфигурация nginx указывает, что вы настроили его для связи с Django через https:

proxy_pass https://mysite;

Я предлагаю убедиться, что для связи между Nginx и Django используется один и тот же протокол, либо http, либо https.

Если вы хотите использовать http или https, решать только вам. Существуют две разные точки зрения на то, является ли http безопасным здесь.

Первая мысль заключается в том, что в этом сценарии http IS безопасен, поскольку связь происходит внутри одной машины.

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

Я склоняюсь к первой школе мысли. Хотя это не обязательно то, что вам подходит.