Как видно на скриншоте, мне удалось «установить» Discourse. Но, похоже, я не могу получить действительный SSL-сертификат.
К слову, я маршрутизирую это через свой Synology NAS с помощью обратного прокси, перенаправляя порт 89 на 443 с поддержкой веб-сокетов, а также порты 89 и 449 (в app.yml они сопоставлены с 80 и 443 соответственно).
Насколько я могу судить, я сделал всё необходимое для настройки.
У меня есть сертификат, указывающий на subdomain.domain.com, но он всё равно разрешается как domain.com.
Я не до конца понимаю вашу текущую ситуацию. Вы запускаете Discourse за прокси? Если да, то, вероятно, вам просто нужно открыть порт 80 и позволить вашему прокси-серверу обрабатывать HTTPS/SSL.
Это означает, что вы разворачиваете Discourse в частном облаке или локально? Если ответ «да», то одна из распространённых проблем — попытка доступа к сайту из локальной сети (LAN) против внешней сети (WAN). Если это ваша проблема и доступ к сайту из другой сети работает нормально (например, попробуйте открыть сайт через мобильную сеть), то ознакомьтесь с этим материалом: ref.
Как это настроено: самим Discourse? Если нет, то, вероятно, вам достаточно открыть только порт 80.
Приношу извинения за отсутствие необходимых уточнений.
Я использую обратный прокси для маршрутизации IP-адреса 192.168.1.XXX на поддомен, например discourse.mydomain.com, так что если коротко — да, это локальная установка.
В настоящее время доступ к ней невозможен ни из локальной сети, ни из внешней (через мобильную сеть).
После выполнения команды sudo netstat -tlnp | grep LISTEN я вижу, что порты 89 и 449 находятся в состоянии LISTEN, однако переход по локальному IP-адресу, например 192.168.1.XXX:449 (или 89), не работает.
И, конечно, обратный прокси (с Synology NAS) не помогает, поэтому настроенный мной поддомен остаётся недоступным.
Для полноты уточнения: машина, на которой я пытаюсь разместить Discourse, — это виртуальная машина (ВМ), размещённая на сервере с XCPNG. Операционная система ВМ — последняя версия Ubuntu Server (CLIN).
Хм, если я правильно понимаю, 192.168.1.XXX — это ваш частный IP-адрес в локальной сети (LAN), и у вас, вероятно, есть публичный IP-адрес, который предоставляет ваш провайдер (ISP). Чтобы прояснить ситуацию: в вашей DNS-записи должен быть указан ваш публичный IP-адрес, который указывает на ваш поддомен, а не ваш частный IP-адрес (в LAN). Во-вторых, ваш роутер, возможно, потребуется настроить для перенаправления входящего трафика на ваш частный IP-адрес 192.168.1.XXX. И ваш провайдер должен разрешать входящий трафик.
В качестве альтернативы вы можете просто туннелировать локальный трафик на удалённый сервер, чтобы не возиться с настройками роутера и не беспокоиться о том, разрешает ли ваш провайдер входящий трафик.
Итак, какой у вас случай: туннелирование трафика или разрешение входящего трафика через NAT или DMZ?
Мне не удалось дойти до этого этапа. Я столкнулся с целым рядом других ошибок, которые помешали мне выполнить корректную установку, поэтому я не смог активировать «force_https».
Мне придётся выбрать другой путь. Извините за беспокойство.
