Porte 443/80 risultano chiuse dopo l'installazione

Ciao,
Ho appena terminato la mia prima installazione di Discourse su un server Ubuntu 22.04.4 su Proxmox VE (ambiente virtuale).
L’installazione è andata bene, senza errori, ma dopo averla completata, il sito del forum non si apre dicendo che il servizio non è accessibile.

Controllando dalla mia rete vedo le porte chiuse:

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

Ma eseguendo lo stesso per localhost dall’interno della macchina Ubuntu, risulta aperto:

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

Tuttavia, se eseguo il controllo dell’indirizzo IP dalla stessa VM Ubuntu, vedo questo:

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

Quindi, le porte risultano filtrate.
Le porte sono state aperte nel 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 l’inoltro delle porte Docker sembra essere impostato correttamente:

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

Cosa sto sbagliando? Dov’è il problema?

Ho appena passato altri 90 minuti a installare Discourse. Questa volta su una macchina fisica separata per escludere l’ambiente virtuale e ho riscontrato un problema identico, anche se ho seguito attentamente le istruzioni da GitHub.

È semplicemente impossibile farlo funzionare??

Potrebbe essere un problema da parte tua? Vedo risultati molto simili ai tuoi, con la mia istanza di Discourse funzionante correttamente.

Riesci a raggiungere la tua istanza usando un proxy, come Browserling?

Modifica: aspetta, il tuo indirizzo 192.168.131.211 è un indirizzo locale, non ci si aspetterebbe che sia raggiungibile dal mondo esterno.

Modifica: cosa vedi sul tuo host Discourse quando provi netstat -rn

Ecco il mio netstat:

root@ubuntu-forum:/var/discourse# netstat -rn
Kernel IP routing table
Destination     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

Oltre a Discourse su Ubuntu, ho installato Talkyard su Debian (Talkyard è un motore di forum un po’ simile a Discourse), anch’esso su Docker, e funziona alla grande. Quindi penso che proverò a installare Discourse anche su Debian.

Netstat -rn sul mio Debian appare così:

root@debian-12:~# netstat -rn
Kernel IP routing table
Destination     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

Non sono sicuro che questo sia utile.

Penso sia vero che Discourse funzioni solo quando vi si accede tramite un dominio, quindi hai una configurazione che ti permette di accedere al tuo sito tramite browser e dominio? Se sei interamente locale alla tua LAN, puoi forse farlo con un file hosts, ma non ne sono sicuro. Penso che sia il server che il client (e forse anche il docker) debbano essere in grado di eseguire una ricerca del nome.

Ho il mio server DNS locale che risolve il nome della mia rete a quell’host, quindi funziona proprio come dal mondo esterno.

Ho appena installato con successo Discourse su una VM DigitalOcean. Lo userò come riferimento alla mia configurazione locale. Una cosa che ho notato immediatamente è il file hosts sulla VM: ha la seguente voce:

Spero sia questo. Ti farò sapere.

No, fallimento… Sono completamente sconfitto dopo 3 giorni di lotta e sono stanco… :slightly_frowning_face:
Inizio a pensare che non sia possibile installare Discourse sulla propria macchina locale, non ospitata da un provider :frowning:

Controlla questo video che ho registrato durante l’installazione e per favore fammi sapere – cosa sto facendo di sbagliato.

Potrebbe valere la pena provare
lsof -i
sul server

Sembra abbastanza probabile che Discourse sia in esecuzione ma qualcosa nella situazione di rete lo renda irraggiungibile.

OK, ho trovato la causa principale… Ho controllato i log di docker ed è emerso che il server nginx non si avvia affatto poiché non riesce a ottenere il certificato Let’s Encrypt (vedi i log allegati)
docker_logs_not_working.txt (10,0 KB)

Ora devo capire come risolvere il problema. In realtà non ho nemmeno bisogno di SSL poiché sto usando un reverse proxy con i suoi certificati SSL. Quindi può comunicare facilmente con Discourse sulla porta 80. Non sono sicuro che il server Discourse lo apprezzerà.

Se fai ricerche troverai che è il motivo più comune per cui le configurazioni locali con ambienti chiusi, alias intranet, falliscono. Discourse necessita di SSL.

Il mio DNS è ospitato da Cloudflare, quindi posso facilmente ottenere i miei certificati LetsEncrypt poiché posso fornire la chiave API per questo. Posso configurare ACME in Discourse per far funzionare senza problemi il provisioning dei miei certificati? Non sono riuscito a trovarlo nel manuale, ma forse non sto cercando bene.

Dopo una lunga lotta sono finalmente riuscito a risolverlo.

Ecco cosa bisogna fare:
Dalla sessione SSH esegui il seguente comando per trovare gli ID o i nomi dei container:

docker ps

Usa il seguente comando per accedere alla shell del container docker
docker exec -it [container_id or name] bash

Esporta la chiave API di Cloudflare e l’email come variabili d’ambiente. Questo serve a consentire allo script ‘acme.sh’ di autenticarsi con l’API di Cloudflare per creare e rimuovere record DNS necessari per la sfida DNS. Ho usato il mio indirizzo email effettivo e la Global API Key dal tuo account Cloudflare.

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

Cambia directory in:

cd /shared/letsencrypt

Esegui acme.sh con il comando --issue, specificando che vuoi usare la modalità dns_cf (DNS Cloudflare) per gestire le sfide DNS. Sostituisci yourdomain.com con il dominio per cui desideri il certificato.

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

Dopo la creazione del certificato, lo script mostrerà in quale directory è stato copiato. Nel mio caso era:

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

Modifica il file discourse.conf per aggiornare il percorso del certificato:

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

Le righe esistenti di ssl_certificate e ssl_certificate_key dovrebbero essere sostituite 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;

In modo che ora puntino alle nuove posizioni dei certificati.

Esegui questo per testare la configurazione:

nginx -t

Se non ci sono errori, ricarica il server web:

nginx -s reload

E… voilà!

2 Mi Piace

Ottime notizie, complimenti per averlo capito. Vale la pena notare, penso, che con Let’s Encrypt, se hai una serie di richieste di certificato non riuscite, vieni bloccato (per 7 giorni, credo). Quindi, vale la pena fare attenzione a fare correttamente queste richieste.

2 Mi Piace