Обратный прокси для Discourse

Поддержка Самостоятельное хостинг
1

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

Моя wildcard A-запись указывает на внутренний IP-адрес в моей сети, где порты 80 и 443 пробрасываются через Nginx Proxy Manager, где уже настроены все SSL-сертификаты. Почти всё в моей существующей сети работает на Docker, поэтому Nginx Proxy Manager безопасен в использовании, так как он просто использует docker-сеть для проксирования по HTTP.

В случае с Discourse я пробовал настроить запись discourse.MYDOMAIN.com, указывающую на отдельный локальный IP-адрес через отдельную A-запись, и она успешно разрешается; однако конфигурация Let’s Encrypt в Nginx Proxy Manager работает, тогда как настройка в Discourse не работает для внутренних IP-адресов.

Итак… я просто хочу настроить обратное проксирование. Я собираюсь попробовать множество конфигураций Nginx, чтобы заставить это работать. Я немного обеспокоен атаками типа «человек посередине», но мне бы хотелось понять, почему конфигурация Let’s Encrypt в Nginx Proxy Manager работает с внутренней настройкой, а в Discourse — нет.

Должен же быть способ!

(П.С. Я знаю, что у меня путаются мысли. Пожалуйста, задавайте конкретные вопросы, и я смогу прояснить ситуацию).

2

Я рассматриваю вариант с проверкой dns-01, упомянутый здесь.

Как я могу это сделать, если это возможно, с моей конфигурацией Discourse?

3

Существуют некоторые темы о запуске Discourse за прокси-менеджером nginx. По сути, вы настраиваете Discourse так, чтобы он не привязывался к портам, и добавляете необходимые метки в секцию labels: в вашем файле app.yml.

4

Если я выберу путь использования Nginx Proxy Manager, как у меня сейчас настроено (в отличие от настройки Let’s Encrypt непосредственно на виртуальной машине с Discourse)…

Мне всё равно нужно будет привязаться к порту 80 на виртуальной машине с Discourse, так как в моём случае это отдельная машина.

Мой текущий опыт показывает, что я получаю ошибки смешанного контента (Mixed Content) при моей текущей конфигурации Nginx Proxy Manager с настройкой SSL там, указывающей на IP-адрес виртуальной машины с Discourse и порт 80.

Я не думаю, что это можно исправить, поскольку ссылки http:// в коде прописаны жёстко… или я ошибаюсь? Разве именно это поле меток, на которое вы ссылаетесь, должно изменить ситуацию?

5

Я попробую использовать шаблон socketd, упомянутый здесь, а также конфигурацию для Nginx Proxy Manager во вкладке «Дополнительно» здесь.

6

Существует настройка под названием force_https, которую нужно включить либо через ENV, либо через rails console.

Также не забудьте правильно установить заголовок x-forwarded-proto на вашем прокси-сервере.

7

Попробую это, если настройка Unix-сокета не сработает. Спасибо @Falco и @pfaffman за поддержку. Вернусь с информацией о том, что сработало.

8

Я не могу настроить Unix-сокет… моя виртуальная машина Discourse находится на отдельном компьютере. Возвращаюсь к первоначальному плану. Посмотрю, смогу ли я разобраться с включением force_https, изучив другие сообщения на форуме. К сведению, это — шаг, который я не могу выполнить.

9

Вам действительно нужно то, что предложил Falco.

10

в nginx proxy manager:

proxy_set_header X-Forwarded-Proto $scheme;

11

это для включения force_https?

12

DISCOURSE_FORCE_HTTPS=true Я полагаю (env)
или
DISCOURSE_FORCE_HTTPS: true в app.yml в секции ENV.

13

Как я уже упоминал ранее, я смог сделать это через графический интерфейс.

@Falco, @pfaffman, @Jagster, @merefield… спасибо всем вам, я успешно настроил обратный прокси, и у меня больше нет ошибок смешанного контента.

После того как я настроил обратный прокси на порт 80 виртуальной машины Discourse и смог зарегистрироваться и выполнить другие действия, всё свелось к включению force_https через графический интерфейс и добавлению флага x-forwarded-proto на вкладке «Дополнительно» в менеджере прокси nginx.