Использование Discourse в частном VPN: что насчёт электронной почты?

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

Привет!

Я хотел бы использовать Discourse в особой конфигурации: веб-сервер будет доступен только ограниченному кругу заранее известных пользователей внутри VPN. IP-адрес сервера будет, например, 10.0.0.1, поэтому понятно, что для него невозможно иметь валидное публичное доменное имя.

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

Меня интересует, какой вариант будет лучшим:

a) Полная настройка Discourse без электронной почты. Будет ли это работать? Я предполагаю, что мне придётся следовать хотя бы некоторым неочевидным инструкциям для активации каждой учётной записи вручную, но для ограниченного числа пользователей это приемлемо. Будет ли это работать? Какие ограничения возникнут при отсутствии работы отправки почты? Конечно, я не смогу отправлять уведомления по электронной почте (для меня это небольшой недостаток) — это всё?

b) Хотя сервер использует приватный IP, у меня может быть отдельный публичный адрес, используемый только для почты. Я ожидаю, что всё будет оптимизировано (насколько это возможно) для простоты настройки: следуя инструкциям по установке, я введу адрес сервера только один раз, который, вероятно, будет использоваться как для HTTP-перенаправлений, так и для SMTP. Можно ли легко разграничить эти настройки? Можно ли легко настроить сервер с приватным IP-адресом и доменным именем, которое не совпадает с ним и используется только для почты?

Стоит отметить, что у меня пока нет опыта работы с Discourse. Я готов самостоятельно изучать информацию при возникновении конкретных проблем. Но я вижу, что здесь нужно принять фундаментальное решение, какой путь выбрать (a или b), и было бы здорово получить совет, чтобы не пойти по неверному пути изначально.

Спасибо!

2

Вам необходимо иметь доменное имя. Discourse не будет работать по IP-адресу.

Может ли сервер получать доступ в Интернет? Развёртывание Discourse без доступа к Интернету — задача нетривиальная.

Если сервер имеет доступ в Интернет, то настройка отправки писем не составит проблем.

3

Создайте его на публичном подключении, добавьте запись DNS в вашей VPN, указывающую на частный IP-адрес, а затем отключите публичный доступ.

Не используйте Lets Encrypt, так как обновления сертификатов не будут работать.

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

Электронная почта является центральным элементом для Discourse; без неё не будут работать многие функции.

4

Спасибо за попытку помочь. Похоже, мне нужно немного подробнее объяснить ситуацию.

Сначала я должен пояснить, что мне хорошо знакомо, а что нет ;). Я довольно хорошо понимаю низкоуровневую часть: IP-адреса, TCP и т. д. Но у меня нет опыта работы с тем, что делает сложное веб-приложение. Также вопрос по электронной почте: как аутентифицируется отправитель письма и как проверяется, что он не рассылает несанкционированный спам? (Я не ожидаю, что вы объясните мне всё это, мне нужно лишь прояснить свои вопросы…)

У меня нет полноценной корпоративной инфраструктуры VPN, на данный момент у меня есть только приватная подсеть VPN и правила на уровне IP.

Настройка следующая: у сервера есть общедоступный домен, но все порты закрыты, кроме точки входа в VPN. Клиенты, подключающиеся к VPN, получают адрес вида 10.0.x.x. Сервер затем доступен по адресу 10.0.0.1:80.

Мое понимание (и я, наверное, ошибаюсь здесь) таково: сервер ожидает, что к нему можно будет обратиться по его домену.

Предположим, у меня есть домен xyz.com, который разрешается в публичный IP-адрес 8.7.6.5. Клиенты используют этот домен/IP только для туннеля. Как только туннель настроен, их браузеры подключаются к 10.0.0.1.

Как я уже говорил, у меня нет опыта работы с Discourse. То, что, как я ожидаю, Discourse будет использовать свой собственный домен, — это действия перенаправления. Например, перенаправление новых клиентов, открывших 10.0.0.1, на 10.0.0.1/login.php. (Или что-то подобное, просто как пример). Если бы Discourse перенаправлял их на .xyz Domain Names | Join Generation XYZ, они бы потерялись, так как сервер недоступен извне VPN. Именно такой ожидаемой проблемой я предполагаю, что нужно настроить внутренний адрес.

Что касается почты, мне нужно связываться с внешними почтовыми серверами. Публичный интернет доступен на любом этапе! Однако я мало знаю об этой теме. Я просто предполагаю, что подключение к публичному почтовому серверу с сообщением «эй, я 10.0.0.1, отправьте мне несколько писем» не сработает, так как я использую приватный IP-адрес. Здесь я предполагаю, что мне нужен публичный адрес.

Оптимистично читая ваши ответы, я предполагаю, что настроенный домен не используется для клиентских HTTP-сессий. Если сервер доступен по приватному IP, и я подключаюсь к этому IP, все самоссылки и перенаправления будут относительными, поэтому пользователя не перенаправит на домен, на котором сервер ожидает подключения. Я могу просто настроить xyz.com как домен и при этом открывать Discourse в браузере по адресу 10.0.0.1, без перенаправления на (неработающие) адреса xyz.com.

Надеюсь, мой вопрос хоть немного понятен. Извините за путаницу!
О, и HTTPS не требуется. Я даже предпочитаю его не использовать — я внутри своего туннеля, и пользователям не нужно безопасное разделение. Я хотел бы избежать всех этих проблем с сертификатами и сопоставлением имен хостов.

5

Это зависит от почтового сервера. Предположим, вы будете использовать почтовый сервис, например MailGun, SendGrid и т. д. Обычно они аутентифицируются через API, например, URL-адрес с паролем пользователя.

При этом, если сервер может выходить во внешние сети (только фильтрация входящих), у вас не должно возникнуть проблем с подключением к почтовому сервису.

Особенно если доменное имя разрешается в правильный IP-адрес.

Вам даже не потребуется открывать порты для установки. Поскольку вы можете обращаться к домену example.com через VPN, если домен указывает на приватный IP-адрес при использовании VPN-туннеля.

Не уверен на 100%, будет ли Discourse использовать только относительные URL-адреса; скорее всего, нет. Но вы можете изменить DNS-записи домена так, чтобы у него было две записи A: первая указывает на адрес 10.0.0.1, а вторая — на публичный IP-адрес 8.7.6.5. Иногда это может быть непросто из-за разрешения адресов, кэширования и других факторов, но попробовать стоит.

6

Вы можете настроить разрешение xyz.com на 10.0.0.1.

Если сервер имеет доступ в интернет, то единственная проблема заключается в том, что вы не сможете создать HTTPS-сертификат Let’s Encrypt.

7

Вот вопрос к вам: чего достигает ваш VPN, чего не обеспечивает SSL?

Инстанс Discourse с закрытым доступом, работающий по SSL, уже обеспечивает аутентификацию и шифрование. Что же добавляет VPN?

8

У меня запущены другие службы, которые необходимо защитить. Мне также нравится идея открыть только один нетипичный порт.

Но вы правы: мне стоит пересмотреть это требование и разрешить запуск Discourse на публичном интерфейсе с SSL.

9

Спасибо всем вам. Похоже, я разобрался с моими задачами:

  • Для веб-сервера, работающего внутри VPN, сервер VPN должен также выполнять функции DNS. Внутренний DNS должен разрешать одно и то же доменное имя во внутренний IP-адрес, тогда как публично это же доменное имя разрешается во внешний IP-адрес. Мне следует перестать использовать IP-адрес сервера где бы то ни было и доверить DNS решение этой сложности. В настоящее время мой VPN работает только на уровне IP, и я даже не знал об этих деталях.
    Недостаток: я могу нарушить работу всего веб-сайта всех пользователей.
  • Я также мог бы запустить веб-сервер на публичном порту и доверить защиту протоколу SSL.
    Недостаток: я оказываюсь открытым для всех опасностей реального мира.