Usando Discourse em VPN privada: E quanto ao e-mail?

Olá!

Gostaria de usar o Discourse em uma configuração especial: o servidor web será acessível apenas para um grupo de usuários privados dentro de uma VPN. O IP do servidor será algo como 10.0.0.1, então é claro que não poderei ter um domínio público válido para isso.

Li que é altamente recomendável configurar corretamente a transmissão de e-mail. Também li que é possível, com algumas soluções alternativas, finalizar a criação da conta de administrador sem e-mail.

Estou me perguntando: qual é a melhor maneira de proceder?

a) Configurar o Discourse completamente sem e-mail. Isso funcionará? Acredito que precisarei seguir pelo menos algum procedimento manual e um pouco arriscado para ativar cada conta, mas isso é aceitável para o número limitado de usuários que espero. Isso funcionaria? Quais seriam as limitações de não ter a transmissão de e-mail funcionando? Claro, não poderei enviar notificações por e-mail (o que é uma desvantagem relativamente pequena para mim) — é só isso?

b) Embora o servidor esteja usando um IP privado, talvez eu possa ter um endereço público apenas para e-mail. Espero que tudo esteja otimizado (o melhor possível) para uma configuração fácil, de modo que, seguindo alguns tutoriais de instalação, eu informe o endereço do servidor apenas uma vez, o qual será provavelmente usado tanto para redirecionamentos HTTP quanto para SMTP. É fácil diferenciar isso? Posso configurar facilmente um servidor com IP privado e um domínio diferente, usado apenas para e-mail?

Devo dizer que ainda não tenho experiência com o Discourse. Estou preparado para pesquisar por conta própria quando enfrentar problemas reais. Mas vejo que há uma escolha fundamental a ser feita sobre qual caminho seguir (a ou b), e seria ótimo receber algum conselho para evitar seguir o caminho errado primeiro.

Obrigado!

Você precisa ter um nome de domínio. O Discourse não roda em um endereço IP.

O servidor tem acesso à internet? Construir o Discourse sem internet é… complicado.

Se o servidor tiver acesso à internet, então a capacidade de enviar e-mails não será um problema.

Crie-o em uma conexão pública, adicione uma entrada DNS na sua VPN para o IP privado e, em seguida, desative o acesso público.

Não use o Let’s Encrypt, pois as atualizações de certificado falharão.

Você não conseguirá atualizá-lo facilmente, mas se você está isolando-o, tenho certeza de que isso já era óbvio.

O e-mail é fundamental para o Discourse; sem ele, várias coisas não funcionarão.

Obrigado por tentar ajudar. Acho que preciso elaborar um pouco mais.

Primeiro, devo explicar o que conheço bem e o que não conheço ;). Entendo bastante a parte de baixo nível: endereços IP, TCP, etc. Mas não tenho experiência com as coisas que uma aplicação web complexa faz. Também sobre e-mail: como um remetente de e-mail é autenticado? Como é verificado que ele não está enviando spam não autorizado? (Não espero que vocês expliquem tudo isso para mim, apenas para esclarecer minhas perguntas…)

Não tenho uma infraestrutura completa de VPN corporativa aqui; atualmente, tenho apenas uma sub-rede VPN privada e regras no nível de IP.

A configuração é a seguinte: o servidor tem um domínio acessível publicamente, mas todas as portas estão fechadas, exceto o ponto de entrada da VPN. Os clientes que se conectam à VPN recebem um endereço 10.0.x.x. O servidor é então acessível em 10.0.0.1:80.

Minha compreensão (e acho que estou errado aqui) é que o servidor espera ser acessível em seu próprio domínio.

Digamos que eu tenha o domínio xyz.com, que resolve para o IP público 8.7.6.5. Os clientes usam esse domínio/IP apenas para o túnel. Uma vez que o túnel é configurado, seus navegadores se conectam a 10.0.0.1.

Como disse, não tenho experiência com o Discourse. O que espero que o Discourse use seu próprio domínio é para ações de redirecionamento. Por exemplo: redirecionar novos clientes que abrem 10.0.0.1 para 10.0.0.1/login.php. (Ou algo similar, apenas como exemplo). Se o Discourse os redirecionasse para .xyz Domain Names | Join Generation XYZ, eles ficariam perdidos, pois o servidor não é acessível de fora da VPN. Esse é o tipo de problema que assumo que um endereço interno deveria resolver.

No que diz respeito ao e-mail, preciso contatar servidores de e-mail externos. A internet pública está acessível em qualquer momento! Não sei muito sobre esse tópico, no entanto. Apenas espero que conectar a um servidor de e-mail público dizendo “ei, eu sou 10.0.0.1, por favor envie alguns e-mails para mim” não funcione, pois estou usando um endereço IP privado. Aqui, assumo que preciso de um endereço público.

Lendo suas respostas com otimismo, assumo que o domínio configurado não é usado para sessões HTTP dos clientes. Se o servidor é acessível por um IP privado e eu me conecto a esse IP, todos os links e redirecionamentos de auto-referência são relativos, então o usuário não é redirecionado para o domínio que o servidor espera estar conectado. Posso apenas configurar xyz.com como domínio e ainda abrir o Discourse no navegador usando 10.0.0.1, sem ser redirecionado para endereços de xyz.com (disfuncionais).

Espero que minha pergunta esteja meio clara. Desculpe por ser tão confuso!
Ah, e HTTPS não é necessário. Eu até prefiro não usá-lo — estou dentro do meu túnel e os usuários não precisam ser separados de forma segura. Gostaria de evitar todos esses problemas com certificados e nomes de host correspondentes.

Isso depende do servidor de e-mail. Vamos supor que você vá usar um serviço de e-mail como MailGun, SendGrid, etc. Eles geralmente autenticam por meio de uma API, como URL mais usuário/senha.

Lá, enquanto o servidor puder acessar IPs externos (apenas filtragem de entrada), você não deve ter problemas para se conectar ao serviço de e-mail.

Especialmente se o domínio for resolvido para o IP correto.

Você nem precisaria abrir as portas para a instalação. Porque você pode acessar o domínio exemplo.com pela VPN se tiver o domínio apontando para o IP privado ao usar o Túnel VPN.

Não tenho tanta certeza se o Discourse usará apenas URLs relativas; quase certo que não. Mas você pode alterar os registros DNS no domínio, de modo que tenha dois registros A: um (o primeiro) apontando para o endereço 10.0.0.1 e um segundo apontando para o IP público 8.7.6.5. Isso pode ser complicado às vezes ao resolver os endereços e lidar com cache, etc., mas você pode tentar.

Você pode fazer com que o xyz.com resolva para 10.0.0.1.

Se o servidor tiver acesso à internet, o único problema é que você não poderá criar um certificado HTTPS do Let’s Encrypt.

Aqui vai uma pergunta para você: o que sua VPN consegue fazer que o SSL não faria?

Uma instância do Discourse exclusiva por convite, usando SSL, já oferece autenticação e criptografia. O que uma VPN acrescenta?

Tenho outros serviços em execução que precisam ser protegidos. E gosto da ideia de ter apenas uma porta não padrão aberta.

Mas você tem um ponto: devo considerar relaxar esse requisito e permitir que o Discourse seja executado na interface pública, com SSL.

Obrigado a todos vocês. Acho que consegui organizar minhas coisas:

  • Para um servidor web rodando dentro da VPN, o servidor VPN precisa atuar também como DNS. O DNS interno deve resolver o mesmo domínio para um IP interno, que é resolvido publicamente para um IP externo. E eu deveria parar de usar o IP do servidor em qualquer lugar e deixar o DNS lidar com essa complexidade. Atualmente, minha VPN está funcionando apenas no nível de IP, e eu nem estava ciente desses detalhes.
    Desvantagem: posso bagunçar todo o www de todos os usuários.
  • Também poderia deixar o servidor web rodando em uma porta pública e deixar o SSL cuidar da proteção.
    Desvantagem: fico exposto a toda a maldade do mundo real.