Ports 443/80 werden nach der Installation als geschlossen angezeigt

Hallo,
Ich habe gerade meine erste Discourse-Installation auf einem Ubuntu 22.04.4-Server auf Proxmox VE (virtuelle Umgebung) abgeschlossen.
Die Installation verlief problemlos, aber nach Abschluss lässt sich die Forum-Website nicht öffnen, da der Dienst nicht erreichbar ist.

Wenn ich von meinem Netzwerk aus prüfe, sehe ich die Ports als geschlossen:

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

Wenn ich jedoch denselben Test für localhost von innerhalb der Ubuntu-Maschine aus durchführe, werden die Ports als offen angezeigt:

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

Wenn ich jedoch die IP-Adresse von derselben Ubuntu-VM aus prüfe, sehe ich Folgendes:

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

Die Ports werden also als gefiltert angezeigt.
Die Ports wurden in der Firewall geöffnet:

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)

Und die Docker-Portweiterleitung scheint korrekt eingestellt zu sein:

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

Was mache ich falsch? Wo liegt das Problem?

Ich habe gerade weitere 90 Minuten mit der Installation von Discourse verbracht. Diesmal auf einem separaten physischen Rechner, um die virtuelle Umgebung auszuschließen, und ich hatte ein identisches Problem, obwohl ich die Anweisungen von GitHub sorgfältig befolgt habe.

Ist es einfach unmöglich, das zum Laufen zu bringen??

Könnte das Problem bei Ihnen liegen? Ich sehe sehr ähnliche Ergebnisse wie Sie, mit meiner korrekt funktionierenden Discourse-Instanz.

Können Sie Ihre Instanz über einen Proxy wie Browserling erreichen?

Bearbeiten: Moment, Ihre Adresse 192.168.131.211 ist eine lokale Adresse, man würde nicht erwarten, dass sie von außen erreichbar ist.

Bearbeiten: Was sehen Sie auf Ihrem Discourse-Host, wenn Sie netstat -rn versuchen?

Hier ist mein 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

Neben Discourse unter Ubuntu habe ich Talkyard auf Debian installiert (Talkyard ist eine Forum-Engine, die Discourse ein wenig ähnelt), ebenfalls auf Docker, und es funktioniert einwandfrei. Ich denke also, ich werde versuchen, Discourse auch unter Debian zu installieren.

Netstat -rn unter meinem Debian sieht so aus:

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

Ich bin mir nicht sicher, ob das hilfreich ist.

Ich glaube, es stimmt, dass Discourse nur funktioniert, wenn es über eine Domain aufgerufen wird. Haben Sie also eine Einrichtung, über die Sie auf Ihre Website über einen Browser und eine Domain zugreifen können? Wenn Sie sich ausschließlich in Ihrem eigenen LAN befinden, können Sie dies vielleicht mit einer Hosts-Datei tun, aber ich bin mir nicht sicher. Ich denke, sowohl der Server als auch der Client (und vielleicht auch der Docker) müssen in der Lage sein, eine Namensauflösung durchzuführen.

Ich habe meinen lokalen DNS-Server, der meinen Netzwerknamen auf diesen Host auflöst, sodass er genauso funktioniert wie aus der Außenwelt.\n\nIch habe gerade erfolgreich Discourse auf einer DigitalOcean VM installiert. Ich werde sie als Referenz für meine lokale Konfiguration verwenden. Eine Sache, die mir sofort aufgefallen ist, ist die Hosts-Datei auf der VM – sie hat folgenden Eintrag:\n

\n\nHoffentlich ist das alles. Ich werde Sie auf dem Laufenden halten.

Nein, ein Fehlschlag… Ich bin nach 3 Tagen Kampf völlig besiegt und müde… :slightly_frowning_face:
Ich fange an zu denken, dass es nicht möglich ist, Discourse auf Ihrem lokalen Rechner zu installieren, nicht von einem Anbieter gehostet :frowning:

Schauen Sie sich dieses Video an, das ich während der Installation aufgenommen habe, und lassen Sie mich bitte wissen – was mache ich falsch.

Könnte es wert sein, Folgendes zu versuchen:
lsof -i
auf dem Server

Es scheint ziemlich wahrscheinlich, dass Discourse läuft, aber etwas an der Netzwerksituation macht es unerreichbar.

OK, ich habe die Grundursache gefunden… Ich habe die Docker-Logs überprüft und es stellte sich heraus, dass der Nginx-Server überhaupt nicht startet, da er kein Let’s Encrypt-Zertifikat erhalten kann (siehe angehängte Logs)
docker_logs_not_working.txt (10,0 KB)

Jetzt muss ich herausfinden, wie ich das beheben kann. Tatsächlich brauche ich nicht einmal SSL, da ich einen Reverse-Proxy mit eigenen SSL-Zertifikaten verwende. Er kann also problemlos über Port 80 mit Discourse kommunizieren. Ich bin mir nicht sicher, ob der Discourse-Server das mag.

Wenn Sie suchen, werden Sie feststellen, dass dies der häufigste Grund ist, warum lokale Setups mit geschlossenen Umgebungen, auch Intranets genannt, fehlschlagen. Discourse benötigt SSL.

Meine DNS wird von Cloudflare gehostet, daher kann ich meine LetsEncrypt-Zertifikate problemlos erhalten, da ich den API-Schlüssel dafür bereitstellen kann. Kann ich ACME in Discourse konfigurieren, damit meine Zertifikatbereitstellung reibungslos funktioniert? Ich konnte im Handbuch nichts finden, aber vielleicht suche ich nicht richtig.

Nach langem Kampf habe ich es endlich geschafft, es zu reparieren.

Hier ist, was zu tun ist:
Führen Sie von der SSH-Sitzung aus den folgenden Befehl aus, um die Container-IDs oder -Namen zu finden:

docker ps

Verwenden Sie den folgenden Befehl, um auf die Shell des Docker-Containers zuzugreifen
docker exec -it [container_id or name] bash

Exportieren Sie den Cloudflare API-Schlüssel und die E-Mail-Adresse als Umgebungsvariablen. Dies ist erforderlich, damit das Skript ‘acme.sh’ mit der Cloudflare-API authentifiziert werden kann, um DNS-Einträge zu erstellen und zu entfernen, die für die DNS-Herausforderung erforderlich sind. Ich habe meine tatsächliche E-Mail-Adresse und meinen globalen API-Schlüssel aus Ihrem Cloudflare-Konto verwendet.

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

Wechseln Sie in das folgende Verzeichnis:

cd /shared/letsencrypt

Führen Sie acme.sh mit dem Befehl --issue aus und geben Sie an, dass Sie den Modus dns_cf (DNS Cloudflare) für die Bearbeitung von DNS-Herausforderungen verwenden möchten. Ersetzen Sie yourdomain.com durch die Domain, für die Sie das Zertifikat wünschen.

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

Nach erfolgreicher Zertifikatserstellung zeigt das Skript an, in welches Verzeichnis es kopiert wurde. In meinem Fall war es:

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

Bearbeiten Sie die Datei discourse.conf, um den Pfad zum Zertifikat zu aktualisieren:

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

Die vorhandenen Zeilen ssl_certificate und ssl_certificate_key sollten ersetzt werden durch:

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;

damit sie nun auf die neuen Zertifikatspfade zeigen.

Führen Sie dies aus, um die Konfiguration zu testen:

nginx -t

Wenn keine Fehler auftreten – laden Sie den Webserver neu:

nginx -s reload

Und – voilà!

2 „Gefällt mir“

Ausgezeichnete Neuigkeiten, gut gemacht, dass Sie es herausgefunden haben. Es ist meiner Meinung nach erwähnenswert, dass Sie sich bei LetsEncrypt, wenn Sie eine Reihe von fehlgeschlagenen Zertifikatsanfragen haben, aussperren (ich glaube für 7 Tage). Daher ist es ratsam, vorsichtig zu sein, um diese Anfragen korrekt zu stellen.

2 „Gefällt mir“