Portas 443/80 aparecem como fechadas após a instalação

Olá,
Acabei de concluir minha primeira instalação do Discourse em um servidor Ubuntu 22.04.4 no Proxmox VE (ambiente virtual).
A instalação ocorreu bem, sem erros, mas depois de finalizá-la, o site do fórum não abre, dizendo que o serviço não está acessível.

Ao verificar de minha rede, vejo as portas como fechadas:

PS C:\Users\mwojt> nmap 192.168.131.211
Nmap scan report for 192.168.131.211

PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  closed http
443/tcp closed https

Mas ao executar o mesmo para localhost de dentro da máquina Ubuntu, ele mostra como aberto:

root@ubuntu-discourse:~# nmap localhost
Nmap scan report for localhost (127.0.0.1)

PORT    STATE SERVICE
22/tcp  open  ssh
80/tcp  open  http
443/tcp open  https

No entanto, se eu executar a verificação do endereço IP da mesma VM Ubuntu para o IP, vejo isto:

root@ubuntu-discourse:~# nmap 192.168.131.211
Nmap scan report for ubuntu-discourse (192.168.131.211)

PORT    STATE    SERVICE
22/tcp  open     ssh
80/tcp  filtered http
443/tcp filtered https

Portanto, as portas aparecem como filtradas.
As portas foram abertas no firewall:

root@ubuntu-discourse:~# ufw status
Status: active

To                         Action      From
--                         ------      ----
80                         ALLOW       Anywhere
443                        ALLOW       Anywhere
22                         ALLOW       Anywhere
80 (v6)                    ALLOW       Anywhere (v6)
443 (v6)                   ALLOW       Anywhere (v6)
22 (v6)                    ALLOW       Anywhere (v6)

E o encaminhamento de porta do Docker parece estar configurado corretamente:

root@ubuntu-discourse:~# docker port 6922c7802903
80/tcp -> 0.0.0.0:80
80/tcp -> [::]:80
443/tcp -> 0.0.0.0:443
443/tcp -> [::]:443

O que estou fazendo de errado? Onde está o problema?

Passei mais 90 minutos instalando o Discourse. Desta vez em uma máquina física separada para descartar o ambiente virtual e tive um problema idêntico, mesmo seguindo cuidadosamente as instruções do GitHub.

É simplesmente impossível fazer isso funcionar??

O problema pode estar do seu lado? Vejo resultados muito semelhantes aos seus, com minha instância do Discourse funcionando corretamente.

Você consegue acessar sua instância usando um proxy, como o Browserling?

Editar: espere, seu endereço 192.168.131.211 é um endereço local, não se esperaria que ele fosse alcançável pelo mundo.

Editar: o que você vê no seu host do Discourse quando tenta netstat -rn

Aqui está meu netstat:

root@ubuntu-forum:/var/discourse# netstat -rn
Tabela de roteamento IP do Kernel
Destino         Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.131.1   0.0.0.0         UG        0 0          0 enp1s0
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.130.0   0.0.0.0         255.255.254.0   U         0 0          0 enp1s0
192.168.131.1   0.0.0.0         255.255.255.255 UH        0 0          0 enp1s0
192.168.131.152 0.0.0.0         255.255.255.255 UH        0 0          0 enp1s0

Além do Discourse no Ubuntu, instalei o Talkyard no Debian (Talkyard é um mecanismo de fórum um pouco semelhante ao Discourse), também no Docker, e está funcionando perfeitamente. Então, acho que tentarei instalar o Discourse no Debian também.

O Netstat -rn no meu Debian se parece com isto:

root@debian-12:~# netstat -rn
Tabela de roteamento IP do Kernel
Destino         Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.131.1   0.0.0.0         UG        0 0          0 ens18
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
172.26.0.0      0.0.0.0         255.255.255.128 U         0 0          0 br-886bebfa13ae
192.168.130.0   0.0.0.0         255.255.254.0   U         0 0          0 ens18

Não tenho certeza se isso é útil.

Eu acho que é verdade que o Discourse só funciona quando acessado através de um domínio, então você tem uma configuração onde pode acessar seu site usando um navegador e um domínio? Se você está inteiramente local em sua própria LAN, talvez possa fazer isso com um arquivo hosts, mas não tenho certeza. Acho que tanto o servidor quanto o cliente (e talvez também o docker) precisam ser capazes de fazer uma pesquisa de nome.

Tenho meu servidor DNS local que está resolvendo o nome da minha rede para esse host, então funciona exatamente como do mundo externo.

Acabei de instalar com sucesso o Discourse em uma VM da DigitalOcean. Vou usá-lo como referência para minha configuração local. Uma coisa que notei imediatamente é o arquivo hosts na VM - ele tem a seguinte entrada:

Espero que seja isso. Avisarei.

Não, falha… Estou completamente derrotado depois de 3 dias de luta e estou cansado… :slightly_frowning_face:
Começo a pensar que não é possível instalar o Discourse na sua máquina local, não hospedada por um provedor :frowning:

Verifique este vídeo que gravei durante a instalação e, por favor, diga-me – o que estou fazendo de errado.

Pode valer a pena tentar
lsof -i
no servidor

Parece bastante provável que o Discourse esteja em execução, mas algo na situação da rede o torna inacessível.

OK, encontrei a causa raiz… Verifiquei os logs do docker e descobri que o servidor nginx não inicia de forma alguma, pois está falhando ao obter o certificado Let’s Encrypt (veja os logs anexos)
docker_logs_not_working.txt (10.0 KB)

Agora preciso descobrir como consertar isso. Na verdade, eu nem preciso de SSL, pois estou usando um proxy reverso com seus próprios certificados SSL. Assim, ele pode se comunicar facilmente com o Discourse pela porta 80. Não tenho certeza se o servidor Discourse vai gostar disso.

Se você pesquisar, encontrará que esse é o motivo mais comum pelo qual configurações locais com ambientes fechados, também conhecidos como intranets, falham. O Discourse precisa de SSL.

Meu DNS é hospedado pela Cloudflare, então posso obter facilmente meus certificados LetsEncrypt, pois posso fornecer a chave de API para isso. Posso configurar o ACME no Discourse para que meu provisionamento de certificado funcione sem problemas? Não consegui encontrar no manual, mas talvez eu não esteja procurando bem.

Após uma longa luta, finalmente consegui consertar.

Aqui está o que precisa ser feito:
Da sessão SSH, execute o seguinte comando para encontrar os IDs ou nomes dos contêineres:

docker ps

Use o seguinte comando para acessar o shell do contêiner do docker
docker exec -it [container_id or name] bash

Exporte a chave de API e o e-mail do Cloudflare como variáveis de ambiente. Isso é para permitir que o script ‘acme.sh’ se autentique com a API do Cloudflare para criar e remover registros DNS necessários para o desafio DNS. Usei meu endereço de e-mail real e a Chave de API Global da sua conta Cloudflare.

export CF_Key="sua_chave_api_global_do_cloudflare"
export CF_Email="seu_endereço_de_e-mail_do_cloudflare"

Mude o diretório para o seguinte:
cd /shared/letsencrypt

Execute acme.sh com o comando --issue, especificando que você deseja usar o modo dns_cf (DNS Cloudflare) para lidar com os desafios DNS. Substitua yourdomain.com pelo domínio para o qual você deseja o certificado.

./acme.sh --issue --dns dns_cf -d yourdomain.com -d *.yourdomain.com

Após a criação bem-sucedida do certificado, o script exibirá para qual diretório ele foi copiado. No meu caso, foi:

Seu certificado está em: /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.cer
Sua chave de certificado está em: /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.key
O certificado intermediário da CA está em: /root/.acme.sh/sprawy.info.pl_ecc/ca.cer
E os certificados de cadeia completa estão lá: /root/.acme.sh/sprawy.info.pl_ecc/fullchain.cer

Edite o arquivo discourse.conf para atualizar o caminho para o certificado:
nano /etc/nginx/conf.d/discourse.conf

As linhas existentes ssl_certificate e ssl_certificate_key devem ser substituídas por:

ssl_certificate /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.cer;
ssl_certificate_key /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.key;

Para que agora aponte para os novos locais dos certificados.

Execute isso para testar a configuração:
nginx -t

Se não houver erros, recarregue o servidor web:
nginx -s reload

E pronto!

2 curtidas

Excelente notícia, parabéns por descobrir. Vale a pena notar que com o LetsEncrypt, se você tiver uma série de solicitações de certificado malsucedidas, você será bloqueado (por 7 dias, eu acho). Portanto, vale a pena ter cuidado para fazer essas solicitações corretamente.

2 curtidas