Los puertos 443/80 se muestran como cerrados después de la instalación

Hola,
Acabo de terminar mi primera instalación de Discourse en un servidor Ubuntu 22.04.4 en Proxmox VE (entorno virtual).
La instalación fue bien, sin errores, pero después de terminarla, el sitio del foro no se abre diciendo que el servicio no es accesible.

Al comprobar desde mi red, veo los puertos cerrados:

PS C:\Users\mwojt> nmap 192.168.131.211

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

Pero al ejecutar lo mismo para localhost desde dentro de la máquina Ubuntu, se muestra como abierto:

root@ubuntu-discourse:~# nmap localhost

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

Sin embargo, si ejecuto la comprobación de la dirección IP desde la misma VM de Ubuntu a la IP, veo esto:

root@ubuntu-discourse:~# nmap 192.168.131.211

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

Por lo tanto, los puertos aparecen como filtrados.
Los puertos se abrieron en el 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)

Y el reenvío de puertos de Docker parece estar configurado correctamente:

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

¿Qué estoy haciendo mal? ¿Dónde está el problema?

Pasé otros 90 minutos instalando Discourse. Esta vez en una máquina física separada para descartar el entorno virtual y obtuve un problema idéntico, a pesar de que seguí cuidadosamente las instrucciones de GitHub.

¿Es simplemente imposible hacer que esto funcione?

¿Podría ser el problema de tu lado? Veo resultados muy similares a los tuyos, con mi instancia de Discourse funcionando correctamente.

¿Puedes acceder a tu instancia usando un proxy, como Browserling?

Editar: espera, tu dirección 192.168.131.211 es una dirección local, no se esperaría que fuera accesible desde el exterior.

Editar: ¿qué ves en tu host de Discourse cuando intentas netstat -rn?

Aquí está mi netstat:

root@ubuntu-forum:/var/discourse# netstat -rn
Tabla de enrutamiento IP del kernel
Destino         Puerta de enlace  Genmask         Indicadores   MSS Ventana  irtt Interfaz
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

Aparte de Discourse en Ubuntu, instalé Talkyard en Debian (Talkyard es un motor de foros un poco similar a Discourse), también en Docker, y funciona a la perfección. Así que creo que intentaré instalar Discourse en Debian también.

Netstat -rn en mi Debian se ve así:

root@debian-12:~# netstat -rn
Tabla de enrutamiento IP del kernel
Destino         Puerta de enlace  Genmask         Indicadores   MSS Ventana  irtt Interfaz
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

No estoy seguro de si esto es útil.

Creo que es cierto que Discourse solo funciona cuando se accede a través de un dominio, así que ¿tienes una configuración por la cual puedes acceder a tu sitio usando un navegador y un dominio? Si estás completamente en tu propia LAN, quizás puedas hacerlo con un archivo de hosts, pero no estoy seguro. Creo que tanto el servidor como el cliente (y quizás también el docker) deben poder realizar una búsqueda de nombres.

Tengo mi servidor DNS local que está resolviendo el nombre de mi red a ese host, por lo que funciona igual que desde el mundo exterior.

Acabo de instalar Discourse con éxito en una VM de DigitalOcean. Lo usaré como referencia para mi configuración local. Una cosa que noté de inmediato es el archivo hosts en la VM; tiene la siguiente entrada:

Espero que sea esto. Te avisaré.

No, fallo… Estoy completamente derrotado después de 3 días de lucha y estoy cansado… :slightly_frowning_face:
Empiezo a pensar que no es posible instalar Discourse en tu máquina local, no alojada por un proveedor :frowning:

Mira este video que grabé mientras lo instalaba y por favor dime qué estoy haciendo mal.

Podría valer la pena intentar
lsof -i
en el servidor

Parece bastante probable que Discourse se esté ejecutando, pero algo en la situación de la red lo hace inalcanzable.

OK, encontré la causa raíz… Revisé los registros de Docker y resultó que el servidor nginx no se inicia en absoluto, ya que no puede obtener el certificado Let’s Encrypt (ver los registros adjuntos)
docker_logs_not_working.txt (10.0 KB)

Ahora necesito averiguar cómo solucionar eso. De hecho, ni siquiera necesito SSL, ya que estoy usando un proxy inverso con sus propios certificados SSL. Por lo tanto, puede comunicarse fácilmente con Discourse a través del puerto 80. No estoy seguro de si el servidor Discourse lo aceptará.

Si buscas, encontrarás que es la razón más común por la que fallan las configuraciones locales con entornos cerrados, también conocidos como intranets. Discourse necesita SSL.

Mi DNS está alojado en Cloudflare, por lo que puedo obtener fácilmente mis certificados LetsEncrypt, ya que puedo proporcionar la clave API para ello. ¿Puedo configurar ACME en Discourse para que mi aprovisionamiento de certificados funcione sin problemas? No pude encontrarlo en el manual, pero tal vez no estoy buscando bien.

Después de una larga lucha, finalmente logré solucionarlo.

Esto es lo que hay que hacer:
Desde la sesión SSH, ejecute el siguiente comando para encontrar los IDs o nombres de los contenedores:

docker ps

Utilice el siguiente comando para acceder al shell del contenedor de docker:

docker exec -it [container_id or name] bash

Exporte la clave API de Cloudflare y el correo electrónico como variables de entorno. Esto permite que el script ‘acme.sh’ se autentique con la API de Cloudflare para crear y eliminar registros DNS necesarios para el desafío DNS. Utilicé mi dirección de correo electrónico real y la Clave API Global de su cuenta de Cloudflare.

export CF_Key="your_cloudflare_global_api_key"
export CF_Email="your_cloudflare_email_address"

Cambie el directorio a:

cd /shared/letsencrypt

Ejecute acme.sh con el comando --issue, especificando que desea utilizar el modo dns_cf (DNS Cloudflare) para manejar los desafíos DNS. Reemplace yourdomain.com con el dominio para el que desea el certificado.

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

Después de la creación exitosa del certificado, el script mostrará a qué directorio se copió. En mi caso fue:

Your cert is in: /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.cer
Your cert key is in: /root/.acme.sh/sprawy.info.pl_ecc/sprawy.info.pl.key
The intermediate CA cert is in: /root/.acme.sh/sprawy.info.pl_ecc/ca.cer
And the full chain certs is there: /root/.acme.sh/sprawy.info.pl_ecc/fullchain.cer

Edite el archivo discourse.conf para actualizar la ruta al certificado:

nano /etc/nginx/conf.d/discourse.conf

Las líneas existentes ssl_certificate y ssl_certificate_key deben reemplazarse con:

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 ahora apunte a las nuevas ubicaciones de los certificados.

Ejecute esto para probar la configuración:

nginx -t

Si no hay errores, recargue el servidor web:

nginx -s reload

¡Y listo!

2 Me gusta

Excelentes noticias, bien hecho por haberlo descubierto. Vale la pena señalar que con Let’s Encrypt, si tienes una serie de solicitudes de certificado fallidas, te bloquean (durante 7 días, creo). Por lo tanto, vale la pena tener cuidado de que estas solicitudes sean correctas.

2 Me gusta