Reverse Proxy Server funktioniert nicht
Hallo liebes Forum,
ich bin verzweifelt, daher wende ich mich an euch, in der Hoffnung einen Tipp zu erhalten. Ich habe einen NGINX Proxy Manager Reverse Proxy Server aufgelegt der unter der IP 192.168.1.218 arbeitet. Der Monitor ist unter dem Port 81 erreichbar.
Nun habe ich drei Webserver unter jeweils 192.168.1.90 (ws1.domain.com), 192.168.1.252 (ws2.domain.com) und 192.168.1.155 (ws3.domain.com) am laufen.
Dann habe ich noch eine UbiQuiti Unifi Dream Machine Pro die an den WAN angeschlossen ist. Ich habe eine Feste IP zugewiesen von Unitymedia/Vodafone.
Im Proxy Manager ist alles korrekt eingestellt. Die drei Poxy Hosts sind im Status grün und Access ist Public.
Beim Domainanbieter habe ich einen A Record für alle drei Subdomains (ws1, ws2 und ws3) auf die feste IP gelegt, so dass die Anfragen von Außerhalb immer auf die Feste IP sprich die UDM Pro weitergeleitet werden.
So jetzt zum Problem:
Wenn ich das Portforwarding für 80 und 443 in der DM Pro auf den NGINX Proxy Server lege und außerhalb des Netzwerkes die Domain einer der Domains bspw. ws1.domain.com aufrufe, dann erhalte ich im Edge Browser die Meldung ERR_CONNECTION_REFUSED. Im Netzwerk öffnet sich die Seite.
Setze ich das Portforwarding auf direkt einen der drei Webserver, dann öffnet sich die Seite ganz normal.
Ich habe neben dem NGINX auch schon andere Reverse Proxy Server probiert, immer das gleiche Verhalten, so dass ich davon ausgehe das es kein Problem des NGINX ist, sondern ich muss noch ein anderes Problem haben.
Ich nutze lokal keinen DNS Server, das bedeutet die UDM vergibt an die lokalen Geräte vermutlich den Standard des Internetanbieters Vodafone (Unitymedia). Liegt hier das Problem?
Wer kann mir einen Tipp geben? Wo steckt mein Fehler?
Besten Dank und viele Grüße
Manuel
ich bin verzweifelt, daher wende ich mich an euch, in der Hoffnung einen Tipp zu erhalten. Ich habe einen NGINX Proxy Manager Reverse Proxy Server aufgelegt der unter der IP 192.168.1.218 arbeitet. Der Monitor ist unter dem Port 81 erreichbar.
Nun habe ich drei Webserver unter jeweils 192.168.1.90 (ws1.domain.com), 192.168.1.252 (ws2.domain.com) und 192.168.1.155 (ws3.domain.com) am laufen.
Dann habe ich noch eine UbiQuiti Unifi Dream Machine Pro die an den WAN angeschlossen ist. Ich habe eine Feste IP zugewiesen von Unitymedia/Vodafone.
Im Proxy Manager ist alles korrekt eingestellt. Die drei Poxy Hosts sind im Status grün und Access ist Public.
Beim Domainanbieter habe ich einen A Record für alle drei Subdomains (ws1, ws2 und ws3) auf die feste IP gelegt, so dass die Anfragen von Außerhalb immer auf die Feste IP sprich die UDM Pro weitergeleitet werden.
So jetzt zum Problem:
Wenn ich das Portforwarding für 80 und 443 in der DM Pro auf den NGINX Proxy Server lege und außerhalb des Netzwerkes die Domain einer der Domains bspw. ws1.domain.com aufrufe, dann erhalte ich im Edge Browser die Meldung ERR_CONNECTION_REFUSED. Im Netzwerk öffnet sich die Seite.
Setze ich das Portforwarding auf direkt einen der drei Webserver, dann öffnet sich die Seite ganz normal.
Ich habe neben dem NGINX auch schon andere Reverse Proxy Server probiert, immer das gleiche Verhalten, so dass ich davon ausgehe das es kein Problem des NGINX ist, sondern ich muss noch ein anderes Problem haben.
Ich nutze lokal keinen DNS Server, das bedeutet die UDM vergibt an die lokalen Geräte vermutlich den Standard des Internetanbieters Vodafone (Unitymedia). Liegt hier das Problem?
Wer kann mir einen Tipp geben? Wo steckt mein Fehler?
Besten Dank und viele Grüße
Manuel
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4312833551
Url: https://administrator.de/contentid/4312833551
Ausgedruckt am: 24.11.2024 um 03:11 Uhr
14 Kommentare
Neuester Kommentar
Moin,
Zugriff von außen auch in der config erlaubt?
Siehe https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-a ...
lks
Zugriff von außen auch in der config erlaubt?
Siehe https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-a ...
lks
Moin,
Gruß,
Dani
Wenn ich das Portforwarding für 80 und 443 in der DM Pro auf den NGINX Proxy Server lege und außerhalb des Netzwerkes die Domain einer der Domains bspw. ws1.domain.com aufrufe, dann erhalte ich im Edge Browser die Meldung ERR_CONNECTION_REFUSED. Im Netzwerk öffnet sich die Seite.
wenn du das mit Port 81 machst, gleiches Verhalten oder kommst du dann auf die UI des NPM?Gruß,
Dani
Moin,
Gruß,
Dani
Wenn ich mich per Putty auf den NPN einlogge und per ping auf die Domain ws1.domain.com oder auch die anderen abgebe, dann erhalte ich korrekt die interne IP 192.168.1.90 usw aufgelöst.
Ich hatte die Vermutung, dass die WAN IP-Adresse ausgegeben wird und damit einen Loop hast.auch dir Danke für deinen Input. Setze ich das Portforwarding von port 80 auf 81 auf den NPM dann komme ich auch von Außen direkt auf den NPM ohne den Port 81 einzugeben. Das funktioniert.
Richtig, weil durch diese Konfiguration ein Port Forwarding und Mapping statt findet. Versuche mit dieser Konfiguration nochmals aus dem Internet auf http://ws2.domain.com:80 zuzugreifen. Das sollte nun gehen.Gruß,
Dani
Was Kollege @Dani sehr wahrscheinlich meint ist das es ggf. einen Konflikt auf der UBQT Gurke gibt, da die selber ja einen Webserver mit Port 80 und 443 zur Konfiguration betreibt. Sofern du den Konfig Zugriff auf dem WAN Port nicht vollständig deaktivierst kann er ja bei dem an seine Adresse eingehenden 80 und 443 Traffic nicht entscheiden ob das für ihn gemeint ist oder er es forwarden muss und rejected im Zweifel diese Ports was deine o.a. Fehlermeldung vermuten lässt. Sprich du musst dem Router beibringen das er diesen Traffic nicht als lokal verstehen muss sondern ihn zwingend auf den Proxy forwarden soll.
Deshalb der Vorschlag es auf 81 oder 8080 usw. zu legen um so einen Konflikt mit dem Router Webserver aus dem Weg zu gehen.
Noch hilfreicher wäre ein Sniffer Trace z.B. tcpdump port 80 or 443 auf dem Nginx um überhaupt erstmal zu sehen ob dort externer, vom Router geforwardeter 80 und 443 Traffic aufläuft!
Kannst du dort nichts sehen scheitert es ja schon am vor dem Proxy liegenden Port Forwarding!
So ein Sniffer Trace wäre doch sinnvollerweise der allererste Schritt das Problem einzugrenzen um klar zu sehen WO der Verursacher liegt?! 🧐
Nebenbei gesagt generell auch kein besonders gutes Design aus Sicherheitssicht über das Port Forwarding Loch in der Firewall ungeschützen Internet Traffic in das lokale Netz zu leiten. Ganz besonders mit den klassischen HTTP Ports. Normalerweise ein NoGo. Der Proxy gehört immer auf die Firewall selber wie es pfSense oder OPNsense u.a. über ihre Packages ja auch erlauben.
Zumindestens aber sollte man den Proxy in so einem Fall immer in eine isolierte DMZ stellen und die Ziel Webserver in getrennte Segmente und mit einem entsprechenden Regelwerk schützen wenn man schon eine Firewall sein eigen nennt. Nichteinmal das ist oben gemacht worden wie die IP Adressierung ja leider verrät.
Ggf. solltest du also generell nochmal dein Design überdenken sofern Sicherheit überhaupt eine Rolle spielt?!
Deshalb der Vorschlag es auf 81 oder 8080 usw. zu legen um so einen Konflikt mit dem Router Webserver aus dem Weg zu gehen.
Noch hilfreicher wäre ein Sniffer Trace z.B. tcpdump port 80 or 443 auf dem Nginx um überhaupt erstmal zu sehen ob dort externer, vom Router geforwardeter 80 und 443 Traffic aufläuft!
Kannst du dort nichts sehen scheitert es ja schon am vor dem Proxy liegenden Port Forwarding!
So ein Sniffer Trace wäre doch sinnvollerweise der allererste Schritt das Problem einzugrenzen um klar zu sehen WO der Verursacher liegt?! 🧐
Nebenbei gesagt generell auch kein besonders gutes Design aus Sicherheitssicht über das Port Forwarding Loch in der Firewall ungeschützen Internet Traffic in das lokale Netz zu leiten. Ganz besonders mit den klassischen HTTP Ports. Normalerweise ein NoGo. Der Proxy gehört immer auf die Firewall selber wie es pfSense oder OPNsense u.a. über ihre Packages ja auch erlauben.
Zumindestens aber sollte man den Proxy in so einem Fall immer in eine isolierte DMZ stellen und die Ziel Webserver in getrennte Segmente und mit einem entsprechenden Regelwerk schützen wenn man schon eine Firewall sein eigen nennt. Nichteinmal das ist oben gemacht worden wie die IP Adressierung ja leider verrät.
Ggf. solltest du also generell nochmal dein Design überdenken sofern Sicherheit überhaupt eine Rolle spielt?!
kommt dort nichts an
Was ja bestätigt das es dann zumindestens für TCP 443 einen Fehler gibt.Was steht denn im Nginx Log (/var/log/nginx/access.log bzw. auch /var/log/nginx/error.log) wenn du den "ERR_CONNECTION_REFUSED" Fehler bei TCP 80 bekommst? Wäre ja zielführend dort einmal nachzusehen als ersten Anlaufpunkt. Nginx muss ja irgendwas protokollieren im Log was er nicht mag. 🤔
Moin,
Gruß,
Dani
kommt dort nichts an
- Den der Docker Konfiguration entsprechend Einträge für Port 80/443 vorhanden (Link)? Die Ports natürlich entsprechend deiner Rahmenbedingungen anpassen.
- Siehst du Listner für Port 80 und 443 auf dem Server mit dem NPM (netstat -tulpen)?
- UFW/iptables auf dem Server im Einsatz, wo das notwendige Loch für Port 80/443 noch fehlt?
Was steht denn im Nginx Log (/var/log/nginx/access.log bzw. auch /var/log/nginx/error.log)
In dem Fall (NPM gibt es nur als Docker Container) in den entsprechenden Volume (./data).Gruß,
Dani
Moin,
Post doch exemplarisch mal ein paar Zeilen aus den Logfiles. Bitte nicht vergessen private Daten zu anonymisieren.
Gruß,
Dani
ich gebe es auf...die error logs sind leer, in den access logs kommt ein GET 301 Befehl an.
Der HTTP Status Code 301 bedeutet, dass eine Umleitung stattfindet (Quelle)Post doch exemplarisch mal ein paar Zeilen aus den Logfiles. Bitte nicht vergessen private Daten zu anonymisieren.
Gruß,
Dani