HAproxy für 2 Backend Services

[jimjohn]

Anbei die Screenshots.  :) :) :)

Setze die Bedingung mal auf "Path starts with" statt matches

da sich nach dem /aaa/X ja noch Sachen ändern würde er bei "matches" nicht greifen

Funktioniert leider nicht:

503 Service Unavailable
No server is available to handle this request.

Muss ich bei dem "Public Service" die Regeln auswählen?

Ja die Regeln musst du im Frontend hinterlegen

Bringt auch nix. Selber Fehler wie vorher ...

[jimjohn]

OK, komme der Sache näher. Laut Verbose Log klappt die Weiterleitung, ABER:

https://X.X.0.2/aaa wird weiter geleitet. Der Service dahinter leitet auf /login um, daraufhin erscheint im Browser fälschlicherweise https://X.X.0.2/login.

Es müsste aber heißen: https://X.X.0.2/aaa/login.

Selber Fehler bei bbb, hier komme ich auf https://X.X.0.2/ui statt /bbb/ui.

Fehlt da noch eine weitere Regel bzw. ein spezielles Verhalten?  :)

Der Server im Backend-Pool soll natürlich von /aaa/ und /bbb/ nichts mitbekommen.  8)

Ist das das URL Rewriting, das fehlt?

Der initiale Fehler scheint gewesen zu sein, dass ich die Regeln dem Frontend-Service nicht bekannt gemacht habe.

[JeGr]

> Fehlt da noch eine weitere Regel bzw. ein spezielles Verhalten?  :)

Nein, aber deine Backends kommen mit der URL Struktur so nicht klar. Wenn dein Proxy den User auf /aaa/blubb schickt und dein Backend Service aber nicht versteht, dass er gefälligst in /aaa/ laufen soll statt unter dem Root Path / dann wird der alles immer redirecten. Das kann man umständlich im Proxy abfangen, das ist aber eigentlich Job des Backends entsprechend richtig konfiguriert zu sein.

Ist aber auch nicht der Normalfall für HAproxy als Einsatz hier mit der IP zu arbeiten. Klar kann man machen, aber einfacher wäre es schlicht mit einer eigenen (Sub)Domain pro Service und beide dann sinnvoll unter / wenn sie eh schon so installiert sind. Warum dann auch mit IPs rumbasteln, wenn man sprechende Namen nutzen kann :)

[jimjohn]

Klar kann man machen, aber einfacher wäre es schlicht mit einer eigenen (Sub)Domain pro Service und beide dann sinnvoll unter / wenn sie eh schon so installiert sind. Warum dann auch mit IPs rumbasteln, wenn man sprechende Namen nutzen kann :)

OK, nun ist es so, dass ich von außen derzeit nur an das WAN Interface der OPNsense (X.X.0.X) komme, wohingegen die Services in der "DMZ" laufen (X.X.3.X). Ich habe entsprechend eine Firewall Regel für UDP/TCP auf X.X.0.2:443 ALLOW gesetzt. So ist es ja auch fein. Innerhalb der OPNsense ist auch alles andere kein Thema. Da kann ich in Unbound einen DNS Override machen (bspw. für aaa.opnsense.lan) und den direkt auf die X.X.3.(aaa) schicken.

Aber was passiert, wenn jemand "von außen" (zwischen Router und OPNsense) auf den Service möchte? Den direkt auf die X.X.3.X zu schicken wäre irgendwie doof. Außerdem kennt er die OPNsense als DNS-Server nicht. Konkret sollen auch Teilnehmer den Service nutzen können, die sich über VPN auf den VPN-Router wählen und von diesem eine IP im Adressbereich X.X.0.X bekommen. Um die auf die X.X.3.X umzuleiten müssten die doch die OPNsense X.X.0.2 als Gateway bekommen und nicht den VPN-Router X.X.0.1, oder? Vom DNS-Server mal ganz zu schweigen ...

Außerdem nutze ich TLS über ein OPNsense Zertifikat, sodass ich in Zukunft im Zweifel auch HTTP Services nach außen über HTTPS bereit stellen kann.

Kannst du mir konkret sagen, wie ich deiner Meinung nach am besten vorgehen sollte? Danke schonmal vorab!  :)

[lfirewall1243]

Klar kann man machen, aber einfacher wäre es schlicht mit einer eigenen (Sub)Domain pro Service und beide dann sinnvoll unter / wenn sie eh schon so installiert sind. Warum dann auch mit IPs rumbasteln, wenn man sprechende Namen nutzen kann :)

OK, nun ist es so, dass ich von außen derzeit nur an das WAN Interface der OPNsense (X.X.0.X) komme, wohingegen die Services in der "DMZ" laufen (X.X.3.X). Ich habe entsprechend eine Firewall Regel für UDP/TCP auf X.X.0.2:443 ALLOW gesetzt. So ist es ja auch fein. Innerhalb der OPNsense ist auch alles andere kein Thema. Da kann ich in Unbound einen DNS Override machen (bspw. für aaa.opnsense.lan) und den direkt auf die X.X.3.(aaa) schicken.

Aber was passiert, wenn jemand "von außen" (zwischen Router und OPNsense) auf den Service möchte? Den direkt auf die X.X.3.X zu schicken wäre irgendwie doof. Außerdem kennt er die OPNsense als DNS-Server nicht.

Außerdem nutze ich TLS über ein OPNsense Zertifikat, sodass ich in Zukunft im Zweifel auch HTTP Services nach außen über HTTPS bereit stellen kann.

Kannst du mir konkret sagen, wie ich deiner Meinung nach am besten vorgehen sollte? Danke schonmal vorab!  :)

Am besten wäre 2 Subdomains anzulegen die auf deine öffentliche IP laufen

Im HAProxy verwaltest du dann alles wie z.B. automatisierte LE Zertifikate für die Backends.
Anhand der passenden ACLs teilst du die Dienste auf.


Dennoch müssen deine Dienste im Backend wie oben beschrieben auch mit den gleichen URLs arbeiten, da diese sonst falsch umgeschrieben werden

[jimjohn]

Ja, das "Problem" ist, dass ich keine öffentliche Erreichbarkeit (weder öffentliche Domain noch öffentliche IP) benötige. Die Daten sollen das lokale Netz (inkl. VPN) nicht verlassen. Es geht um private Services, die nur in meinem lokalen Netz wie auch per VPN genutzt werden sollen. Daher funktioniert auch Let's Encrypt nicht. Die self-signed Zertifikate von mir gebe ich intern halt frei, das funktioniert auch gut.

Außer die OPNsense als VPN-Router einzusetzen und den Port also sozusagen direkt auf die OPNsense weiterzuleiten fällt mir nichts ein ... bin aber derzeit eigentlich glücklich mit dem anderen VPN-Server ...

[lfirewall1243]

Ja, das "Problem" ist, dass ich keine öffentliche Erreichbarkeit (weder öffentliche Domain noch öffentliche IP benötige). Es geht um private Services, die nur in meinem lokalen Netz wie auch per VPN genutzt werden sollen. Daher funktioniert LE nicht. Die self-signed Zertifikate von mir gebe ich intern halt frei, das funktioniert.

Dann mit lokalen Namen oder eben deine Dienste umkonfigurieren dass sie mit /AAA und /BBB laufen

[jimjohn]

Ja, das "Problem" ist, dass ich keine öffentliche Erreichbarkeit (weder öffentliche Domain noch öffentliche IP benötige). Es geht um private Services, die nur in meinem lokalen Netz wie auch per VPN genutzt werden sollen. Daher funktioniert LE nicht. Die self-signed Zertifikate von mir gebe ich intern halt frei, das funktioniert.

Dann mit lokalen Namen oder eben deine Dienste umkonfigurieren dass sie mit /AAA und /BBB laufen

Was meinst du konkret mit "lokalen Namen"? DNS Overrides?