Les ports 443/80 s'affichent comme fermés après l'installation

Salut,
Je viens de terminer ma première installation de Discourse sur un serveur Ubuntu 22.04.4 sur Proxmox VE (environnement virtuel).
L’installation s’est bien déroulée, sans erreurs, mais après l’avoir terminée, le site du forum ne s’ouvre pas en indiquant que le service n’est pas accessible.

En vérifiant depuis mon réseau, je vois les ports comme fermés :

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

Mais lorsque j’exécute la même commande pour localhost depuis la machine Ubuntu, elle s’affiche comme ouverte :

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

Cependant, si j’exécute la vérification de l’adresse IP depuis la même VM Ubuntu vers l’IP, je vois ceci :

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

Donc, les ports apparaissent comme filtrés.
Les ports ont été ouverts au niveau du pare-feu :

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)

Et le transfert de port Docker semble être correctement configuré :

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’est-ce que je fais de mal ? Où est le problème ?

J’ai passé encore 90 minutes à installer Discourse. Cette fois sur une machine physique séparée pour exclure l’environnement virtuel et j’ai rencontré un problème identique, même si j’ai suivi attentivement les instructions de GitHub.

Est-il simplement impossible de faire fonctionner cela ??

Le problème pourrait-il venir de votre côté ? Je vois des résultats très similaires aux vôtres, avec mon instance Discourse qui fonctionne correctement.

Pouvez-vous accéder à votre instance en utilisant un proxy, tel que Browserling ?

Modification : attendez, votre adresse 192.168.131.211 est une adresse locale, on ne s’attendrait pas à ce qu’elle soit accessible depuis l’extérieur.

Modification : que voyez-vous sur votre hôte Discourse lorsque vous essayez netstat -rn

Voici mon 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

Outre Discourse sur Ubuntu, j’ai installé Talkyard sur Debian (Talkyard est un moteur de forum un peu similaire à Discourse), également sur Docker, et cela fonctionne à merveille. Je pense donc que je vais essayer d’installer Discourse sur Debian aussi.

Netstat -rn sur ma Debian ressemble à ceci :

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

Je ne suis pas sûr que cela soit utile.

Je pense qu’il est vrai que Discourse ne fonctionne que lorsqu’il est accédé via un domaine. Avez-vous une configuration qui vous permet d’accéder à votre site en utilisant un navigateur et un domaine ? Si vous êtes entièrement local à votre propre LAN, vous pouvez peut-être le faire avec un fichier hosts, mais je ne suis pas sûr. Je pense que le serveur et le client (et peut-être aussi le docker) doivent pouvoir effectuer une recherche de nom.

J’ai mon serveur DNS local qui résout mon nom réseau vers cet hôte, donc cela fonctionne comme depuis le monde extérieur.

Je viens d’installer avec succès Discourse sur une machine virtuelle DigitalOcean. Je vais l’utiliser comme référence pour ma configuration locale. Une chose que j’ai immédiatement remarquée est le fichier hosts sur la machine virtuelle - il a l’entrée suivante :

J’espère que c’est tout. Je vous tiendrai au courant.

Non, échec… Je suis complètement vaincu après 3 jours de lutte et je suis fatigué… :slightly_frowning_face:
Je commence à penser qu’il n’est pas possible d’installer Discourse sur votre machine locale, non hébergée par un fournisseur :frowning:

Regardez cette vidéo que j’ai enregistrée pendant l’installation et dites-moi s’il vous plaît – ce que je fais de mal.

Vaut peut-être la peine d’essayer
lsof -i
sur le serveur

Il semble assez probable que Discourse fonctionne, mais quelque chose dans la situation réseau le rend inaccessible.

OK, j’ai trouvé la cause première… J’ai vérifié les logs docker et il s’est avéré que le serveur nginx ne démarre pas du tout car il n’arrive pas à obtenir le certificat Let’s Encrypt (voir les logs joints)
docker_logs_not_working.txt (10.0 KB)

Maintenant, je dois trouver comment résoudre ce problème. En fait, je n’ai même pas besoin de SSL car j’utilise un proxy inverse avec ses propres certificats SSL. Il peut donc facilement communiquer avec Discourse sur le port 80. Je ne suis pas sûr que le serveur Discourse appréciera.

Si vous effectuez des recherches, vous constaterez que c’est la raison la plus courante pour laquelle les configurations locales avec des environnements fermés, alias intranets, échouent. Discourse a besoin du SSL.

Mon DNS est hébergé par Cloudflare, je peux donc facilement obtenir mes certificats LetsEncrypt car je peux fournir la clé API pour cela. Puis-je configurer ACME dans Discourse pour que mon provisionnement de certificats fonctionne correctement ? Je n’ai pas trouvé dans le manuel, mais peut-être que je ne cherche pas bien.

Après une longue lutte, j’ai finalement réussi à résoudre le problème.

Voici ce qu’il faut faire :
Depuis la session SSH, exécutez la commande suivante pour trouver les ID ou les noms des conteneurs :

docker ps

Utilisez la commande suivante pour accéder au shell du conteneur Docker :

docker exec -it [container_id or name] bash

Exportez la clé API Cloudflare et l’e-mail en tant que variables d’environnement. Ceci est nécessaire pour permettre au script ‘acme.sh’ de s’authentifier auprès de l’API Cloudflare afin de créer et supprimer les enregistrements DNS nécessaires au défi DNS. J’ai utilisé mon adresse e-mail réelle et ma clé API globale de votre compte Cloudflare.

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

Changez de répertoire pour aller ici :

cd /shared/letsencrypt

Exécutez acme.sh avec la commande --issue, en spécifiant que vous souhaitez utiliser le mode dns_cf (DNS Cloudflare) pour gérer les défis DNS. Remplacez yourdomain.com par le domaine pour lequel vous souhaitez obtenir le certificat.

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

Après la création réussie du certificat, le script affichera le répertoire dans lequel il a été copié. Dans mon cas, c’était :

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

Modifiez le fichier discourse.conf pour mettre à jour le chemin d’accès au certificat :

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

Les lignes existantes ssl_certificate et ssl_certificate_key doivent être remplacées par :

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;

De sorte qu’elles pointent maintenant vers les nouveaux emplacements des certificats.

Exécutez ceci pour tester la configuration :

nginx -t

S’il n’y a pas d’erreurs, rechargez le serveur web :

nginx -s reload

Et voilà !

2 « J'aime »

Excellente nouvelle, félicitations pour avoir trouvé la solution. Il est intéressant de noter qu’avec Let’s Encrypt, si vous avez une série de demandes de certificats infructueuses, vous êtes bloqué (pendant 7 jours, je crois). Il est donc conseillé d’être prudent pour que ces demandes soient correctes.

2 « J'aime »