Аватары, логотипы сайтов и ошибки сертификатов

[markcichy (Mark)]

Вот ссылка на один из инстансов:
https://discourse.mobiusnode.io

Он выключен. X-Forwarded-Proto указан в моём блоке сервера. Таким образом, единственный элемент (или элементы), который я не использую, судя по ссылкам, которые вы все предоставили, — это:

# базовые шаблоны, используемые; можно сократить, включив меньше функциональности в шаблоны контейнеров:
# - "templates/cron.template.yml" # cron теперь включён в базовый образ
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/sshd.template.yml"
- "templates/web.template.yml"
# - "templates/web.ssl.template.yml" # удалить - HTTPS будет обрабатываться внешним nginx
- "templates/web.ratelimited.template.yml"
- "templates/web.socketed.template.yml" # <-- Добавлено
# какие порты открывать?
# expose: закомментируйте весь раздел

[itsbhanusharma (Bhanu Sharma)]

Я загрузил сайт в трёх браузерах (Edge, Firefox и Chrome Mobile), и как аноним получил абсолютно валидный сертификат. Какие ваши шаги для воспроизведения этой проблемы?

[markcichy (Mark)]

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

[itsbhanusharma (Bhanu Sharma)]

Окей, сейчас зарегистрируюсь как вымышленный пользователь через Firefox.

[itsbhanusharma (Bhanu Sharma)]

Ваши письма никогда не доходят до моего почтового ящика. Я пробовал(а) отправить их повторно, но безрезультатно. Вы просто вручную активируете аккаунты?

[markcichy (Mark)]

Нет. Скорее всего, они попали в папку «Нежелательные» или «Спам». Жалоб от пользователей по этому поводу нет.

[itsbhanusharma (Bhanu Sharma)]

Ад не обрушился здесь. Одна из возможных проблем заключается в том, что в ваших письмах всё ещё содержатся ссылки с http://. Однако я был корректно перенаправлен на сайт по протоколу https для активации моей учётной записи, и я не вижу никаких ошибок, связанных с SSL.

Так что да, я на 99% уверен, что ваш параметр force_https не включён, или что-то очень-очень не так с вашей установкой, что и вызывает это.

[markcichy (Mark)]

В моем блоке сервера настроено перенаправление, поэтому не имеет значения, какая ссылка там отображается. В любом случае оно всегда перенаправит на https.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

Неважно, какая ссылка там отображается.

Вы ошибаетесь. Если включено принудительное использование HTTPS, Discourse должен отправлять все ссылки через HTTPS. Каждая ссылка, связанная с форумом, должна загружаться по HTTPS. Если вы продолжаете делать странные вещи и не следуете рекомендованному способу, вы остаетесь наедине с собой. Мы не можем помочь дальше стандартных процедур, которые работают.

[markcichy (Mark)]

Для меня это не совсем логично. Если мы разберём это с точки зрения логики, то я по сути делаю ровно то, для чего предназначено force-https, но в блоке сервера.

[markcichy (Mark)]

Кроме того, при включении force-https мой сайт перестает работать, и пользователи не могут пройти аутентификацию.

[itsbhanusharma (Bhanu Sharma)]

force_https — это не просто переписывание. Внутри он делает гораздо больше. Если вы хотите, чтобы ваши проблемы были решены, решение уже предложено. Если вы отвергаете это решение, не стесняйтесь взять дело в свои руки и исследовать новые пути.

@markcichy

Кроме того, когда я включаю force-https, мой сайт перестаёт работать. И пользователи не могут пройти аутентификацию.

Это связано с вашим ненадёжным обратным прокси. Вам предстоит выяснить, что не так, и сделать всё правильно. Мы не можем оказывать поддержку вашим собственным решениям.

[markcichy (Mark)]

Все представленные «решения» не подходят для моего конкретного случая использования:

• Удалённый сервер (в той же сети) — я полагаю, что все примеры предполагают, что Nginx запущен на том же сервере, что и Discourse, а я использую proxy_pass для обращения к другому внутреннему IP-адресу.

Почему я так сделал? Повышенная безопасность и распределение ресурсов. Это та же причина, по которой я разделяю сервисы двумя способами: с помощью контейнеров и виртуальных машин. Предложенная документация, кажется, ориентирована на ситуацию, когда все сервисы работают на одном сервере.

Я предполагаю, что описанные выше условия довольно распространены. Если какое-либо из них может быть использовано для поддержки условия proxy_pass, я с радостью внесу необходимые изменения в свои настройки. Мне просто кажется, что давать общее заявление «вы сами по себе» только потому, что я пытаюсь избежать ситуации «не класть все яйца в одну корзину», немного необоснованно.

[itsbhanusharma (Bhanu Sharma)]

proxy_pass 192.168.20.10:8080

в Discourse откройте 192.168.20.10:8080:80

удалите шаблон с сокетом.

включите force_https.

Готово.

[markcichy (Mark)]

Это влечёт за собой целый ряд последствий, выходящих за рамки того, что вы только что написали, и мне предстоит это изучить — мы могли бы начать с этого.

Немедленные вопросы:

1. В app.yml изменить порт по умолчанию на 8080?
2. Что насчёт SSL на порту 443? Оставить 443?
3. Убрать редирект с порта 80 в блоке сервера Nginx?
4. Имеет ли значение пункт 3, если я просто меняю proxy_pass на внутренней стороне? Наверное, нет? Я ведь просто перенаправляю на 8080?
5. Самый главный вопрос: зачем? Почему это должно что-то изменить, если перейти с порта 80 на 8080?
6. Оставить все остальные шаблоны активными? Просто закомментировать socketed?

Спасибо за вашу помощь и терпение.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

Изменить порт прослушивания по умолчанию в app.yml на 8080?

Это ваше предпочтение, я привёл это как пример. Вы также можете выбрать порт 80.

@markcichy

А что насчёт SSL на порту 443? Оставить 443?

Нет никакого смысла или выгоды в включении SSL в локальной сети.

@markcichy

Удалить перенаправление с порта 80 из блока сервера Nginx?

Это должно оставаться.

server {
    listen 80;
    server_name discourse.example.com;
    return 301 https://example.com$request_uri;
}

@markcichy

Имеет ли значение пункт №3, если я просто меняю proxy_pass на внутренней стороне? Скорее всего, нет? Я просто перенаправляю на 8080?

Именно это и происходит: вы перенаправляете все запросы, получаемые вашим прокси/ingress, на внутренний бэкенд на порту 8080 (то есть на Discourse).

@markcichy

Самый главный вопрос: зачем? Почему это должно иметь значение, изменение с порта 80 на 8080?

Ответ дан в пункте №1: это было личным предпочтением. Пользуйтесь любым портом, какой вам нравится.

@markcichy

Оставить все остальные шаблоны активными? Просто закомментировать socketed?

Вам особенно не нужно ничего, что связано с сокетами или SSL на внутреннем сервере. SSL должен корректно завершаться на обратном прокси.

Примечание: многое из этого основано на личном предпочтении при развёртывании для клиентов.

[markcichy (Mark)]

Хорошо. Спасибо за комментарии.

Вот мой блок конфигурации сервера Nginx, для справки:

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

server_name discourse.mobiusnode.io;

location / {
# http трафик
proxy_pass http://192.168.86.108;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

}

ssl on;
ssl_certificate /path/to/certificate/domain.io/fullchain.pem; # управляется Certbot
ssl_certificate_key /path/to/certificate/domain.io/privkey.pem; # управляется Certbot

ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

add_header Strict-Transport-Security "max-age=63072000;";
ssl_stapling on;
ssl_stapling_verify on;

client_max_body_size 0;

}

server {
if ($host = discourse.mobiusnode.io) {
return 301 https://$host$request_uri;
} # управляется Certbot

listen 80;
listen [::]:80;

server_name discourse.mobiusnode.io;
return 404; # управляется Certbot

}

[markcichy (Mark)]

Поведение, которое я наблюдаю, возникает при указанных выше условиях.

Начало файла app.yml выглядит следующим образом:

## это шаблон контейнера Docker Discourse «всё в одном» (standalone)
##
## После внесения изменений в этот файл ВЫ ДОЛЖНЫ выполнить пересборку
## /var/discourse/launcher rebuild app
##
## БУДЬТЕ *ОЧЕНЬ* ОСТОРОЖНЫ ПРИ РЕДАКТИРОВАНИИ!
## YAML-ФАЙЛЫ ЧРЕЗВЫЧАЙНО ЧУВСТВИТЕЛЬНЫ К ОШИБКАМ В ПРОБЕЛАХ И ВЫРАВНИВАНИИ!
## используйте http://www.yamllint.com/ для проверки файла при необходимости

templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Раскомментируйте эти две строки, если хотите добавить Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"

## какие TCP/IP-порты должен открывать этот контейнер?
## Если вы хотите, чтобы Discourse использовал тот же порт, что и другой веб-сервер, например Apache или nginx,
## см. https://meta.discourse.org/t/17247 для деталей
expose:
- "80:80" # http
- "443:443" # https

params:
db_default_text_search_config: "pg_catalog.english"

## Установите db_shared_buffers на максимум 25% от общего объема памяти.
## значение будет установлено автоматически при загрузке на основе обнаруженного объема ОЗУ, либо вы можете переопределить его
db_shared_buffers: "1024MB"

## может улучшить производительность сортировки, но увеличивает потребление памяти на подключение
#db_work_mem: "40MB"

## Какую ревизию Git должен использовать этот контейнер? (по умолчанию: tests-passed)
#version: tests-passed

[RGJ (Richard - Communiteq)]

Вы подключаетесь к порту 80 на втором nginx, поэтому он считает, что вы используете http, а не https.

Попробуйте найти X-Forwarded-Proto во внутреннем nginx и изменить proxy_set_header X-Forwarded-Proto $thescheme; на proxy_set_header X-Forwarded-Proto https;

или перенаправьте ваш трафик на https: proxy_pass https://192.168.86.108

[itsbhanusharma (Bhanu Sharma)]

@markcichy

- "80:80" # http
- "443:443" # https

Эту часть нужно изменить