Ich hasse es wirklich, hier etwas Außergewöhnliches zu tun. Ich hasse es so sehr wie jeder andere, aber es ist alles, was ich tun kann und wie jede andere selbst gehostete App, die ich habe, läuft.
Ich habe meinen Wildcard-A-Eintrag, der auf eine interne IP in meinem Netzwerk zeigt, auf der Port 80 und 443 von nginx proxy manager exportiert werden, der meine SSL-Zertifikate eingerichtet hat. Ich habe fast alles in meinem bestehenden Netzwerk mit Docker eingerichtet, daher ist nginx proxy manager sicher zu verwenden, da er nur das Docker-Netzwerk verwendet, um über HTTP zu proxyen.
Im Fall von Discourse habe ich versucht, discourse.MEINEDOMAIN.com auf die separate lokale IP-Adresse unter einem separaten A-Eintrag einzurichten und habe es zum Auflösen gebracht; jedoch funktioniert die Let’s Encrypt-Einrichtung von nginx proxy manager und die von Discourse eingerichtete nicht für interne IPs.
Also… ich möchte nur Reverse-Proxying betreiben. Ich werde alle möglichen nginx-Proxy-Konfigurationen ausprobieren, um dies zum Laufen zu bringen. Ich bin leicht besorgt über Man-in-the-Middle-Angriffe, aber ich möchte herausfinden, warum die Let’s Encrypt-Konfiguration von nginx proxy manager mit interner Konfiguration funktioniert und die von Discourse nicht.
Es muss einen Weg geben!
(PS: Ich weiß, dass ich überfordert bin. Bitte stellen Sie spezifische Fragen, und ich kann Klarheit schaffen)
Es gibt einige Themen, die sich mit dem Ausführen von Discourse hinter dem Nginx Proxy Manager befassen. Grundsätzlich konfigurieren Sie Discourse so, dass es an keine Ports gebunden wird, und fügen die erforderlichen Labels in einem labels:-Abschnitt in Ihrer app.yml hinzu.
Wenn ich den Nginx Proxy Manager wähle, was ich derzeit so eingerichtet habe (im Gegensatz zur Einrichtung von Let’s Encrypt auf der Discourse VM selbst)…
Ich müsste immer noch Port 80 auf der Discourse VM binden, da es sich in meinem Fall um eine separate Maschine handelt.
Meine aktuelle Erfahrung ist, dass ich Mixed Content-Fehler mit meiner aktuellen Konfiguration des Nginx Proxy Managers erhalte, wobei die SSL-Einrichtung dort auf die IP-Adresse der Discourse VM an Port 80 zeigt.
Ich glaube nicht, dass dies zu beseitigen ist, da die http://-Referenzen im Code hartcodiert sind… oder irre ich mich? Ist das das, was das von Ihnen erwähnte Labels-Feld ändern würde?
Ich werde die Socket.IO-Vorlage ausprobieren, die hier erwähnt wird, zusammen mit der Konfiguration für den Nginx Proxy Manager im erweiterten Tab hier.
Ich werde das versuchen, wenn die Unix-Socket-Einrichtung nicht funktioniert. Vielen Dank an @Falco und @pfaffman für die Unterstützung. Ich werde mich melden, was funktioniert.
Ich kann die Unix-Socket-Einrichtung nicht durchführen… meine Discourse VM befindet sich auf einem separaten Rechner. Zurück zum ursprünglichen Plan. Mal sehen, ob ich das force_https-Aktivieren mit einigen anderen Beiträgen im Forum herausfinden kann. Zu Ihrer Information, dieser ist der Schritt, den ich nicht ausführen kann.
Ich konnte dies, wie bereits erwähnt, in der GUI tun.
@Falco, @pfaffman, @Jagster, @merefield… dank euch allen habe ich den Reverse-Proxy erfolgreich eingerichtet und habe keine Mixed-Content-Fehler mehr.
Sobald ich auf Port 80 der Discourse-VM per Reverse-Proxy zugegriffen habe und mich registrieren konnte, ging es darum, force_https über die GUI einzustellen und das x-forwarded-proto-Flag im erweiterten Tab des Nginx Proxy Managers hinzuzufügen.