NGINX zum ausliefern von Webseiten UND als Reverse Proxy

[Auge]

Hallo

Ich habe vor, ein paar Dienste lokal (in VMs) zu betreiben und von außen erreichbar zu machen. Da ich nicht genug feste IPs für alle Dienste habe, möchte ich die Anfragen für alle Dienste über eine externe, feste IP hereinführen und die Verteilung dieser Anfragen auf die jeweils zuständige Maschine/IP über einen Reverse Proxy erledigen. Soweit ich mir das angelesen habe, ist dieser genau für solche Aufgaben da.

Nun überlege ich, ob ich dafür einen dedizierten Webserver (NGINX oder Apache) aufsetzen soll oder ob einer der sowieso vorhandenen Webserver diese Aufgabe miterledigen kann, ohne den eigentlich auf der Maschine betriebenen Dienst zu stören. Ich habe auf einem RasPi mit NGINX einen Dienst, der bestenfalls alle paar Minuten angefragt wird und dann ein paar PHP-Skripte und Datenbankabfragen ausführt.

Kann ich auf diesem Server, der selbst eine Website ausliefert, auch noch einen Proxy betreiben, ohne dass sich die Dienste in die Quere kommen? Kann ich die lokal auf dem Server bereitgestellte Seite auch über den Proxy ausliefern? Sowohl Proxy als auch die Seite haben ja die selbe IP. Nicht, dass der Verkehr in diesem Szenarion unnötige Umwege geht.

Tschö, Auge

[dedlfix]

Tach!

Kann ich auf diesem Server, der selbst eine Website ausliefert, auch noch einen Proxy betreiben, ohne dass sich die Dienste in die Quere kommen?

Das hängt davon ab, ob diese eindeutig ansprechbar sind. Das heißt, entweder eine eigene IP+Port-Kombination haben (Aufruf z.B. über http://192.0.2.42:8023), oder die Hostname-Zeile vom HTTP-Header auswerten (Aufruf z.B. über http://irgendwas.example.com). In beiden Fällen sollten die Request auf jeweils einen VHost gehen, der dann alles weitere abhandelt.

Kann ich die lokal auf dem Server bereitgestellte Seite auch über den Proxy ausliefern? Sowohl Proxy als auch die Seite haben ja die selbe IP. Nicht, dass der Verkehr in diesem Szenarion unnötige Umwege geht.

Kommt ganz auf die Netzwerkkonfiguration an.

dedlfix.

[m.]

Mahlzeit,

da NGINX vhosts unterstützt, ist es kein Problem, weitere für deine Dienste zu konfigurieren. Jeder vhost kann dann auch per Proxy ausliefern (gehe mal davon aus es gibt ein passendes Modul für nginx

Da es absolut üblich ist, teilweise mehrere tausend vhosts auf einem Rechner laufen zu haben (wenn auch eher nicht auf nem Raspi 😉) kommen die sich auch nicht ins Gehege wenn die Config passt.

Dass es nur eine IP gibt, ist dabei eher zweitrangig, zum einen kannst du verschiedene Ports nutzen und am Router mit Portforwarding arbeiten ansonsten bekommt jeder vhost einen eigenen Namen (z.B. Host- und Domainnamen)

[Christian Kruse]

Hallo Auge,

Kann ich auf diesem Server, der selbst eine Website ausliefert, auch noch einen Proxy betreiben, ohne dass sich die Dienste in die Quere kommen?

Ja, natürlich. Ohne Probleme. Dieses Setup verwende ich seit Jahren sehr erfolgreich, unter anderem in der Firma und auf https://wwwtech.de/.

Kann ich die lokal auf dem Server bereitgestellte Seite auch über den Proxy ausliefern?

Die Unterteilung „Proxy“ und „Webserver“ ist in diesem Fall künstlich. Die NGINX-Instanz, die deine lokale Website ausliefert, macht auch das Proxying zu deinen VMs. Nur halt auf unterschiedlichen URLs – wobei die URLs sich nicht zwangsläufig im Host unterscheiden müssen, sondern sich auch im Pfad oder sogar nur im Querystring unterscheiden können. Als Schaubild:

                            -----------
                            | PHP-FPM |
                           /-----------
------------   ---------  / -------------------
| Outbound | - | NGINX | ---| statische Files |
------------   ---------  \ -------------------
                           \_______   __________
                           | VM 1 | - | Apache |
                           --------   ----------
                           | VM 2 | - | Cowboy |
                           --------   ----------
                           | VM 3 | - | NGINX  |
                           --------   ----------
                           | ...  |   | ...    |
                           --------   ----------

LG,
CK

[Auge]

Hallo

Danke euch dreien für eure Antworten. Die geben mir Mut und die Stichworte mit denen ich weiterkomme.

Tschö, Auge

[TS]

Hello,

wie CK schon schrieb, kann das ein NGINX über separate VirtHosts abwickeln. Es sollte nur jeder ViertHost unbedingt sein eigenes Log führen, damit Du das dann z. B. mit Fail2Ban beobachten lassen kannst.

Im lokalbereich vielleicht nicht so brisant, aber wenn es einen WAN-Zugriff gibt, fast unerlässlich.

Glück Auf
Tom vom Berg

[Christian Kruse]

Hallo TS,

wie CK schon schrieb, kann das ein NGINX über separate VirtHosts abwickeln.

Nochmal, falls das in meinem Post nicht genau genug rüberkam: Der Nginx kann das in jeder location-Sektion behandeln. Du kannst https://example.org/foo an einen anderen Background-Service routen als https://example.org/bar. Im gleichen server-Eintrag.

LG,
CK

[TS]

Hello,

wie CK schon schrieb, kann das ein NGINX über separate VirtHosts abwickeln.

Nochmal, falls das in meinem Post nicht genau genug rüberkam: Der Nginx kann das in jeder location-Sektion behandeln. Du kannst https://example.org/foo an einen anderen Background-Service routen als https://example.org/bar. Im gleichen server-Eintrag.

Kannst Du dem Location Entry dann auch (fürs LAN) ein eigenes Log zuordnen?

Glück Auf
Tom vom Berg

[Christian Kruse]

Hallo TS,

Kannst Du dem Location Entry dann auch (fürs LAN) ein eigenes Log zuordnen?

Ja:

Context: http, server, location, if in location, limit_except

Error log auch:

Context: main, http, mail, stream, server, location

Das hätte dir ein Blick ins Manual auch verraten.

LG,
CK

[TS]

Hello CK,

Kannst Du dem Location Entry dann auch (fürs LAN) ein eigenes Log zuordnen?

Ja:

Context: http, server, location, if in location, limit_except

Error log auch:

Context: main, http, mail, stream, server, location

Das hätte dir ein Blick ins Manual auch verraten.

Das hast Du mir jetzt erleichtert durch deinen Link. Vielen Dank.

Dann sollte @Auge mMn auch daran denken, das Feature "separate Logs" zu benutzen, um besser entscheiden zu können, wann, worauf, wer da Unerwünschtes tut. Man will i.d.R. nicht gleich alle Dienste lahmlegen, nur weil einer affektiert wurde.

Wenn ich so gerne Virt-Hosts benutze, dann kommt das daher, dass sich die übliche Config von Debian (sites-available, sites-enabled) leicht übernehmen lässt.

Glück Auf
Tom vom Berg

[Auge]

Hallo

Kannst Du dem Location Entry dann auch (fürs LAN) ein eigenes Log zuordnen?

Ja:

Context: http, server, location, if in location, limit_except

Error log auch:

Context: main, http, mail, stream, server, location

Dann sollte @Auge mMn auch daran denken, das Feature "separate Logs" zu benutzen, um besser entscheiden zu können, wann, worauf, wer da Unerwünschtes tut. Man will i.d.R. nicht gleich alle Dienste lahmlegen, nur weil einer affektiert wurde.

Ist es sinnvoll, das auf dem Proxy Server zu loggen, wenn doch (bis auf einen Dienst) alle Dienste auf anderen Maschinen/VMs laufen und selbst loggen können. Oder anders, welche Fälle sollen beziehungsweise können per Logging auf dem Proxy ermittelt/abgedeckt werden? Ein fehlendes Bild, das einen 404-er auslöst, kann ja nur auf dem „echten“ Server bemerkt und geloggt werden.

Tschö, Auge

[TS]

Hello Auge,

Kannst Du dem Location Entry dann auch (fürs LAN) ein eigenes Log zuordnen?

Ja:

Context: http, server, location, if in location, limit_except

Error log auch:

Context: main, http, mail, stream, server, location

Dann sollte @Auge mMn auch daran denken, das Feature "separate Logs" zu benutzen, um besser entscheiden zu können, wann, worauf, wer da Unerwünschtes tut. Man will i.d.R. nicht gleich alle Dienste lahmlegen, nur weil einer affektiert wurde.

Ist es sinnvoll, das auf dem Proxy Server zu loggen, wenn doch (bis auf einen Dienst) alle Dienste auf anderen Maschinen/VMs laufen und selbst loggen können. Oder anders, welche Fälle sollen beziehungsweise können per Logging auf dem Proxy ermittelt/abgedeckt werden? Ein fehlendes Bild, das einen 404-er auslöst, kann ja nur auf dem „echten“ Server bemerkt und geloggt werden.

Prinzipiell sollte man Fehlzugriffe immer so früh wie möglich unterbinden und weitere blocken.

Aber vielleicht sollte ein Reverse-Proxy nicht nur für http-Zugriffe eingerichtet werden?

Glück Auf
Tom vom Berg