Wie Sie auf dem Screenshot sehen können, habe ich es geschafft, Discourse zu „installieren“. Aber ich kann kein gültiges SSL-Zertifikat zuweisen.
Zur Information: Ich leite dies über meine Synology NAS mit einem Reverse-Proxy, der Port 89 auf 443 mit Websocket und Port 89 und 449 (gemappt auf 80 bzw. 443 in der app.yml) erhöht.
Soweit ich das beurteilen kann, habe ich alles getan, was ich tun sollte, um alles einzurichten.
Ich habe ein Zertifikat, das auf subdomain.domain.com zeigt, aber es wird immer noch auf domain.com aufgelöst.
Ich verstehe Ihre aktuelle Situation nicht ganz. Betreiben Sie Discourse hinter einem Proxy? Wenn ja, müssen Sie wahrscheinlich nur Port 80 öffnen und Ihren Proxy-Server HTTPS/SSL handhaben lassen.
Bedeutet das, dass Sie Discourse in einer privaten Cloud/On-Premise einsetzen? Wenn ja, ist ein häufiges Problem der Versuch, auf die Website über LAN oder WAN zuzugreifen. Wenn dies die Ursache ist und der Zugriff auf die Website von einem anderen Netzwerk aus in Ordnung ist d.h. versuchen Sie einfach, auf die Website über Ihr Mobilfunknetz zuzugreifen, dann überprüfen Sie dies ref.
Wie ist es eingerichtet, durch Discourse? Wenn nicht durch Discourse, dann müssen Sie wahrscheinlich nur Port 80 öffnen.
Ich verwende einen Reverse-Proxy, um die IP-Adresse 192.168.1.XXX an eine Subdomain, d. h. discourse.mydomain.com, weiterzuleiten. Kurz gesagt, ja, es ist On-Premise.
Es ist derzeit über LAN oder WAN (Mobil) nicht erreichbar.
Nachdem ich sudo netstat -tlnp | grep LISTEN ausgeführt habe, sehe ich die Ports 89 und 449 aufgelistet, aber das Aufrufen der lokalen IP, z. B. 192.168.1.XXX:449 (oder 89), funktioniert nicht.
Und natürlich hilft der Reverse-Proxy (vom Synology NAS) nicht, sodass die von mir konfigurierte Subdomain eine Sackgasse ist.
Zur vollständigen Klärung: Die Maschine, auf der ich versuche, Discourse zu hosten, ist eine VM, die auf einer Maschine mit XCPNG gehostet wird. Das VM-Betriebssystem ist das neueste Ubuntu Server (CLIN).
Hmm, wenn ich das richtig verstehe, ist 192.168.1.XXX Ihre private IP-Adresse im LAN und Sie haben wahrscheinlich eine öffentliche IP-Adresse, die Ihnen Ihr ISP gibt. Um es klar auszudrücken: In Ihrem DNS-Eintrag sollte Ihre öffentliche IP-Adresse auf Ihre Subdomain zeigen und nicht Ihre private IP-Adresse (im LAN). Zweitens muss Ihr Router möglicherweise so konfiguriert werden, dass eingehender Datenverkehr zugelassen und an Ihre private IP 192.168.1.XXX weitergeleitet wird. Und Ihr ISP sollte eingehenden Datenverkehr zulassen.
Alternativ können Sie Ihren lokalen Datenverkehr zu einem Remote-Server tunneln, damit Sie sich nicht mit Ihren Routereinstellungen herumschlagen oder darüber nachdenken müssen, ob Ihr ISP eingehenden Datenverkehr zulässt.
Was ist also Ihr Fall: Datenverkehr tunneln oder eingehenden Datenverkehr über NAT oder DMZ zulassen?
Ich bin nicht so weit gekommen. Ich bin auf eine Reihe anderer Fehler gestoßen, die mich daran gehindert haben, eine gute Installation durchzuführen, sodass ich „force_https“ nicht aktivieren konnte.
Ich muss einen anderen Weg gehen. Entschuldigen Sie die Störung.
