"Best Practice" NGINX Reverse Proxy, HTTP to HTTPS, Dynamic DNS

[Anarchist]

Hallo Luxx,
das hier ist keine direkte Frage zu einem Problem, sondern vielmehr eine Suche nach anderen Luxxern, die folgendes schon einmal besser gemacht haben bzw. mir sagen können wie man es unkomplizierter machen könnte.

Ich stell mir die Frage, weil ich in den letzten zwei Tagen mehr oder weniger erfolgreich versucht habe privat ein paar Webseiten zu hosten. Habe ich früher schon gemacht, allerdings immer nur intern, die Seiten oft nur über IP direkt angesprochen, nur HTTP usw..

Ansprüche steigen, jetzt habe ich folgendes eingerichtet:

1. echte .de Domain geholt die per DynDNS Update zu mir nach Hause zeigt.
weil ich dazu keinen vernünftigen kostenlosen Windows Client finden konnte macht das eine Debian VM mit dem ddclient und einem kleinen Script von mir. Bisher hatte ich noch keinen IP-Wechsel aber ich gehe davon aus das funktioniert

2. Konfiguration interner DNS (dazu verwende ich Windows Server VM (DC, DNS, DHCP), DNS Zone für my-domain.de angelegt, inkl. CNAME für "www.my-domain.de"
es wird also sowohl extern als auch intern der gleiche Server über "my-domain.de" und "www.my-domain.de" erreicht.

3. Frontend-Webserver bzw. Reverse Proxy spielt eine Debian VM konfiguriert mit Nginx, LetsEncrypt Zertifikat, automatische Erneuerung des Zertifikats usw.
Der Qualys SSL Labs Test https://www.ssllabs.com/ssltest/ gibt mir eine A+
Weiterhin Nginx so konfiguriert, dass alle Anfragen über HTTP auf HTTPS umgeleitet werden und das www immer auf die non-www Adresse.
Ich lande also mit "http://www.my-domain.de", "http://mydomain.de", "https://www.my-domain.de" immer schön auf "https://my-domain.de". Funktioniert wunderbar!

4. Backend-Webserver sind bisher alles Debian, Apache2, PHP5, MySQL Server. Pro Seite bzw. Dienst ist das eine eigene Linux VM.



Nun zu meinem Anliegen..
Ich habe es geschafft das intern und extern über den ReverseProxy ein Wordpress Blog, Nextcloud Installation, TinyRSS Installation, Lychee usw. angesprochen werden können, schön mit HTTPS und gültigem Zertifikat.
also:

https://my-domain.de/blog
https://my-domain.de/tinyrss
https://my-domain.de/nextcloud
https://my-domain.de/lychee

usw.

ABER jedes Mal v.a. bei Wordpress und Nextcloud musste ich gefühlte Stunden googlen und recherchieren, probieren und wieder probieren bis es es am Laufen hatte. Oft hab ich das Gefühl jeder macht es anders, man findet zig Lösungen, manche gehen andere wieder nicht..

Dabei stoße ich meistens auf Probleme, dass durch die HTTP -> HTTPS Umleitung Webseiten ihren Dienst verweigern, z.B. meldet mir Chrome, dass ich die Seite über HTTPS aufrufe, im Hintergrund aber trotzdem unsichere HTTP Links geladen wurden. Das war bei Wordpress der Fall und ich habe die wp-config.php anpassen können, dank einem anderen Userbeitrag im Netz.

Oft gibt es auch Rewrites, Redirects, .htaccess Rewrites usw.. die es einem nicht gestatten über ein einfaches NGINX proxy_pass die Seite aufzurufen oder überhaupt einen Installer zu starten. Oft fehlen erstmal statische Elemente, CSS wird nicht geladen, kein Design usw.. mir fehlt dazu dann auch das nötige Hintergrundwissen um so etwas selbst lösen zu können und bin dann wieder auf Userbeiträge im Netz angewiesen. Gibt es die nicht läuft es oft nicht, z.B. würde ich gerne Chevereto aufsetzen, aber über den Proxy und HTTPS habe ich das bis heute nicht geschafft obwohl über HTTP alles funktioniert.


Wie macht ihr das? Gibt es vielleicht irgendwas um das zu vereinfachen bzw. um von Haus aus kompatibler zu diverser Websoftware zu sein?

 

[mensch183]

Wie wär es, das komplette Redirect-Gerassel von HTTP nach HTTPS einfach wegzulassen, wenn du sowieso nichts per HTTP anbieten willst?

 

[Fallwrrk]

Wie wär es, das komplette Redirect-Gerassel von HTTP nach HTTPS einfach wegzulassen, wenn du sowieso nichts per HTTP anbieten willst?

Weil ich nicht glaube, dass du bei jeder Domain, die du eingibst, ein "https://" vorstellst. Wenn nicht unbedingt HSTS eingerichtet ist bzw. die Domain sich auf der HSTS-Preload-Liste von Google befindet, gehen alle normalen Browser mal noch von HTTP als Protokoll aus. Wird also keine Weiterleitung eingerichtet, so landet der User entweder auf der unverschlüsselten Seite oder er bekommt erst gar keine Verbindung zum Zielserver, da nichts auf dem Port 80 lautscht.

 

[TCM]

Das Hauptproblem wird sein, dass dieser Kram fest und absolut die Links reincodiert, inkl. Protokoll, d.h. du musst überall den URL fest auf https://... setzen in der Config der Webanwendungen. Wären das alles relative Links, gäbe es gar keine Probleme. Ich hoffe mal an der Stelle nicht, dass eine Webanwendung so blöd ist und die Links danach generiert, wie sie angesprochen wird, denn wenn nginx das TLS terminiert, wird die Webanwendung ja tatsächlich über HTTP "benutzt", muss aber trotzdem HTTPS-Links generieren.

 

[Fallwrrk]

Ich hoffe mal an der Stelle nicht, dass eine Webanwendung so blöd ist...

Doch, WordPress hat ausnahmslos und durch die Bank weg absolute URLs. Wenn man eine frische WP-Installation hat, dann ist das noch recht human, da nur ein Eintrag in der Datenbank geändert werden muss und die Sache ist gegessen. Hast du allerdings schon deine 500 Beiträge, schön mit Bildern und Links versehen, dann wird's lustig.

 

[Anarchist]

Das mit dem "Mixed Content" Problem hab ich bei Chevereto jetzt doch endlich hinbekommen.

Ich lasse den Apache2 im Backend auch per HTTPS laufen, Zertifikat ist dabei völlig wurscht weil ja das vom ReserveProxy gilt.
Also einfach ein a2enmod ssl und die Default SSL Konfig auf sites-enabled gemappt und schon ist es aktiviert.

im Proxy steht dann:

location /chevereto/ {
proxy_pass https://192.168.2.16/chevereto/;
include /etc/nginx/snippets/proxy.conf;
}

und schon erledigt sich die Sache

Habe das auch für meine anderen Seiten und VMs so übernommen. Hat bei Wordpress auch alles erledigt, konnte bis auf eine Kleinigkeit die hinzugefügten Einträge in der wp-config.php entfernen.

 

[TCM]

Das ist aber Gefrickel.

 

[Anarchist]

und wieso?

 

[TCM]

Weil du so gesehen den dreifachen Aufwand an Ver-/Entschlüsselung betreibst, um ein triviales Problem zu umgehen statt zu lösen.

 

[Anarchist]

Naja bis das vielleicht mal performancetechnisch ne Rolle spielt da braucht es bestimmt etliche gleichzeitige Nutzer. Da hab ich keine Probleme mit und ist bisher eine sehr praktikable Lösung.

 

[Fallwrrk]

Gibt es eigentlich einen Grund für den nginx Reserve Proxy?

 

[TCM]

Eine IP-Adresse, mehrere Server?

 

[Anarchist]

Eine IP-Adresse, mehrere Server?

eben. Wie soll man das sonst machen mit einer dynamischen IP?
Zwar kann man auch mehrere oder tausende Seiten auf einem Server haben, das macht aber irgendwann nur noch Probleme wenn es um Abhängigkeiten in den Versionen geht.
Unterschiedliche Anforderungen an PHP Konfig usw..

Finde Nginx richtig nice dafür.

 

[Fallwrrk]

Achso, das hab ich nicht ganz mitbekommen, sorry.

 

[Florian215]

@Anarchist
Hast Du eine Anleitung die Du mit mir / uns teilen würdest ? Ich verzweifel langsam. Ich habe eine QNAP NAS TVS1282 i5 32GB und würde genau das gleiche erreichen wie du es schon eingerichtet hast. Würde mich sehr über deine Hilfe freuen.

Vielen Dank
Florian

"Ich habe es geschafft das intern und extern über den ReverseProxy ein Wordpress Blog, Nextcloud Installation, TinyRSS Installation, Lychee usw. angesprochen werden können, schön mit HTTPS und gültigem Zertifikat.
also:

https://my-domain.de/blog
https://my-domain.de/tinyrss
https://my-domain.de/nextcloud
https://my-domain.de/lychee"

 

[Shutterfly]

Was ist daran so schwer?

nginx reserve proxy installieren und für die Domain xyz.de konfigurieren, per dyndns oder api des dns-anbieters die public ip aktualisieren (gute Firewalls und gute DNS-Anbieter können das automatisch, z.B. pfsense und inwx), einen internen dns resolver betreiben (ggf. auch nur ein forwarder) und dort die public ip gegen die lokalen IP-Adressen überschreiben.

Fertig.

Das ist eigentlich nur billiges Zusammenstecken von Basis-Komponenten. Wenn du dir nun irgendwelche Begriffe nicht geläufig sind, dann empfehle ich dir diese Themen im Internet nachzulesen. Was man hier nämlich macht ist seine lokale DNS-Auflösung anzupacken sowie seine IP-Adresse in einem öffentlichen DNS zu hinterlegen, neben den ganzen offenen Ports etc.

Sicherheit ist hier ein großes Thema. Auch nginx hardening bzgl. obfuscation und sinnvoller TLS-Konfigurationen sind relevant. Das sollte man selbst wissen und sich einlesen. Damit man nicht sein Netzwerk weiter öffnet als man möchte und auch weiß, welche Risiken man eingeht.

Gerade wenn man sich das gefühlte Angriffsziel Wordpress ins Haus holt.

 

[fax668]

Wenn das auf einem NAS laufen soll, auf dem vermutlich auch alle privaten Dokumente liegen, sollte man das sowieso lieber unterlassen. Eine vom Internet erreichbare Installation gehört auf ein separat gesichertes System in einem getrennten Netzwerksegment.

 

[Shutterfly]

In der Theorie stimme ich da zu, in der Praxis finde ich es für private Haushalte entscheidend was man macht und wie man es macht.

Ich habe selbst solch ein Setup, jedoch auf keinem NAS sondern einem selbst verwalteten Home-Server. Als Port ist nur 80 und 443 offen und nur nginx hört darauf und leitet weiter. Firewall sitzt natürlich mit Snort davor.

Die entsprechenden Dienste sind soweit gekapselt, dass man selbst bei Einbruch nicht das komplette System, welches auch NAS-Charakter hat, einsehen kann. Ein Profi könnte hier sicherlich auf kurz oder lang das System irgendwie knacken, jedoch schütze ich mich mit dem Aspekt der Unwichtigkeit meiner Daten.

Mit einfachen Mitteln kommt man bei mir nicht weit, alles darüber verlangt Anstrengung. Wenn die jmd. betreibt, dann könnte er was zu holen bekommen, jedoch nichts womit er groß was anfangen kann. Zumindest nicht, wenn er Geld im Fokus hat.

Daher habe ich für mich die Abwägung bewusst getroffen. Als Privatanwender vertretbar.