Reverse Proxy Caddy / Loadbalancing

[hsiewert]

Hallo Zusammen,

wie bringe ich caddy bei dass er auf mehrere Webserver ein Loadbalancing machen soll.
In der GUI geht's soweit ich sehe nicht.

Aktuell setze ich HA Proxy ein, die Doku dazu ist aber aus der offiziellen opnSense Doku schon entfernt worden, so dass ich vermute, dass HA Proxy bald "Geschichte" sein wird.

VG

[Monviech (Cedrik)]

Hallo, das Load Balancing wird nicht unterstützt (in der GUI)

https://docs.opnsense.org/manual/how-tos/caddy.html#faq

Wenn du das willst, kannst du das Caddyfile manuell so gestalten wie du es willst mit den Imports.

https://docs.opnsense.org/manual/how-tos/caddy.html#using-custom-configuration-files

Es zu implementieren wäre mit dem jetzigen Design der GUI und wie die Template funktioniert recht aufwändig. Es gibt keine zusätzliche Abstraktion zwischen dem Reverse Proxy Eintrag der durch die Handler erzeugt wird, und dem Upstream Server der eingetragen wird.

https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#load-balancing

Das ganze Plugin Design ist darauf ausgelegt mit 2-3 Klicks einen Reverse Proxy zu haben.


EDIT:

Die HA-Proxy doc wurde nur entfernt weil sie zu alt war und nicht mit dem Plugin übereinstimmt. Es gab für die Dok keinen Maintainer. Wenn jemand eine neue Doc schreibt...?
https://github.com/opnsense/docs/commit/62d8fc19157b48a001dbb720587ed81c93e4143c


EDIT2:

Das normale "random" wäre recht einfach zu implementieren, aber es gibt grade bei den Passiven und aktiven Health Checks so viele Optionen, ich wüsste nicht was jemand braucht.

[Monviech (Cedrik)]

Würde das hier reichen?

https://github.com/opnsense/plugins/commit/8bf11f79a41aac78eace88538ffbb838d94a2095

Damit wäre folgender Usecase abgedeckt:

Code Select Expand


Load-balance all requests between 3 backends:

example.com {
reverse_proxy node1:80 node2:80 node3:80
}


[hsiewert]

Hallo Monviech,

ich denke es reicht ;-)  Ich werde es testen.

Wir wäre es mit einem Knopf unter Advanced, mit dem man die resultierende Config einsehen kann.
Das könnte helfen bei den Kollegen die Verwirrung klein zu halten, wenn doch mal die Config manuell aufgebohrt wurde.

[Monviech (Cedrik)]

Hab ich auch schon dran gedacht, ist aber bis auf weiteres erstmal nicht geplant.

Wenn dann würde es in der Zukunft einen Menüpunkt geben wo man die aktuelle geladene autosave.json ansehen kann. Die wird aus dem Caddyfile generiert und würde auch alle manuellen Imports enthalten.

(Die sieht man in /var/db/caddy/...)


EDIT:
Ich baue wenigstens noch "fail_duration" ein. https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#passive-health-checks

Dadurch werden Server die Probleme haben aus dem Load balancing für eine gewisse Zeit rausgenommen. Ich mache das konfigurierbar.

https://github.com/opnsense/plugins/pull/3911

[guenti_r]

@Monviech,

einfach mal so: Vielen Dank für das Plug-in!  ;)

[Monviech (Cedrik)]

Hey danke, bitteschön. Hoffe es geht alles noch seit dem letzten Update, gab viele Änderungen. xD

[guenti_r]

Ja, einwandfrei.
Ersetzt erstmal einen NPM.

Kommt das Plug-in auch mal in die Enterprise-Repo?

Habe ca. 30 OPNsense´s im Einsatz, ein Grossteil davon mit Enterprise-Lizenzen.

[Monviech (Cedrik)]

Da die Business Version ein Downstream der Features der Community Edition enthält, wird das Caddy plugin sicherlich auch bald darin auftauchen. Wahrscheinlich schon in 24.4. Welche Version das Caddy Plugin darin hat, weiß ich noch nicht, kann aber sein, dass es nicht die neueste Version ist.

[Reiner030]

Ja, einwandfrei.
Ersetzt erstmal einen NPM.

Kommt das Plug-in auch mal in die Enterprise-Repo?

Habe ca. 30 OPNsense´s im Einsatz, ein Grossteil davon mit Enterprise-Lizenzen.

Wenn Du die Business Version hast, kann ich Dir das OpenWAF Plugin empfehlen, das gut funktioniert und Loadbalancing kann und sogar noch WAF Protection bietet...

Hab vorhin gerade die Umstellung bei uns abgeschlossen; es gibt nur ein einfach lösbares Problemchen mit den Default Einstellungen, da in den Advanced Options "SSLProxyCheckPeerName On" generiert wird, wodurch der Apaache Proxy die vom Backend Server angebotenen TLS Zertifikate mit deren IPs matchen will...

https://forum.opnsense.org/index.php?topic=34923.msg196544#msg196544

EDIT: Das könnte bei meinem Versuch mit Caddy (Hatte mir manuell die 1.5.2 gesucht und per Console in die Business installiert, da die 1.5.3-er Probleme mit der GUI Einbindung bei der Installation hatte) auch das TLS Problem wie beim Apache Backend gewesen sein.
Das riesige Problem beim Caddy ist jedoch, das hier - typisch "modern" - total inhaltslose Logs produziert werden, mit denen man überhaupt nichts anfangen kann außer zu wissen "geht nicht".

[Monviech (Cedrik)]

Ich würde in der Business Version nicht manuell das Caddy plugin installieren. Es hat Abhängigkeiten die gerade nur die Community Edition bietet. Hier sollte man echt warten bis es bei den Plugins heruntergeladen werden kann.

Außerdem, OPNwaf zu verwenden empfehle ich auch, steht auch in den Docs im FAQ. Für WAF eine gute Sache. https://docs.opnsense.org/manual/how-tos/caddy.html#faq

Ich persönlich nutze aber Crowdsec was für mich einfacher durchschaubar als eine WAF ist und für mich weniger false positives produziert.

[Reiner030]

Naja, streng genommen kann man beim OpenWAF auch fast nichts (ver-)konfigurieren.

Entsprechend der Dokumentation:

Web protection

The web protection options offer easy access to the OWASP ModSecurity ruleset, which offers a set of generic attack detection rules against a wide range attacks including the OWASP Top Ten.

werden Standard Rules gem. Step 3: A closer look at the rules folder verwendet, von denen nur unter "General Settings" im Tab "Web Protection" spezielle Webservices explizit aktiviert werden können:

Code Select Expand

conf/crs/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
conf/crs/rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf
conf/crs/rules/REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf
conf/crs/rules/REQUEST-903.9004-DOKUWIKI-EXCLUSION-RULES.conf
conf/crs/rules/REQUEST-903.9005-CPANEL-EXCLUSION-RULES.conf

und der Rest wird fix verwendet.

Ansonsten kann man beim jeweiligen Virtuellem Server nur zwischen "Header Security" On/Off wählen
sowie das "TLS Security profile" zwischen "Modern", "Intermediate" und "Old" gem. Mozilla Empfehlung einstellen.

Das wäre dann vielleicht ein weiterer Feature Request, OpenWAF (bzw. das Apache2 mod_security Plugin) ähnlich wie bei AWS, GPC etc. individuell konfigurierbar zu machen.
Allerdings dürfte dass die Konfigurationsoberfläche und -funktionen deutlich komplexer machen.

Hierzu kann man sicher auch Crowdsec oder andere Services nutzen, wie vielleicht auch der ET Telemetry Open Edition; wobei diese Services, soweit ich das verstanden habe, für alle Ports/Services nutzbar sind und nicht nur für WAF und daher sicher parallel zu OpenWAF eingesetzt werden können.



Das Caddy Modul hatte ich auch nur vorab testen wollen und hoffte, dass es mit dem nächsten Business Update 24.1, dass diese Woche kommen dürfte wie in den letzten 2 Jahren, dann auch dabei ist.

Wie schon geschrieben war 1.5.3 inkompatibel, während 1.5.2 noch einwandfrei funktioniert hatte; jedoch noch Optionen wie TLS Backend Check Deaktivierung fehlten (was ich erst vorgestern durch den analysierten Apache Fehler erkennen konnte) und dadurch für meinen Test unbrauchbar war, da ich nicht der einzige Admin bin und die anderen nicht in der CLI herumhantieren wollen können müssen ...

Und letztendlich ist das OpenWAF VServer/Path Modul noch simpler inkl. Loadbalancing zu konfigurieren als Caddy.
Es geht halt nichts über "KISS" und "good old Apache"  ;D .

[Monviech (Cedrik)]

Wie gesagt, ich hab das Caddy Plugin für die Community geschrieben da dort ein einfacher Reverse Proxy gefehlt hat.

Für Firmen empfehle ich die Business Edition mit OPNWAF. Damit unterstützt man auch gleichzeitig die Entwickler der OPNsense.

Mit Apache2 macht man alles richtig.

[Reiner030]

Ja für Community dann sicher eine gute Alternative.
Hatte mir die neueste Version nur kurz in einer Test VM lokal auf Notebook angesehen ohne groß zu testen und war bei kurzer Recherche auch erstaunt, dass der schon über 8 Jahre entwickelt wird, da man von ihm kaum was gehört hat.

Wenn möglich wäre, sollte man - wie auch noch für OpenWAF fehlend - das LogLevel definieren können, da hier wirkich ohne funktionierende Glaskugel sonst kein Debugging möglich ist.
Die "HTTP Access Log" Option je Proxy Domain ist allgemein aber schon ein guter Anfang ^^

Ich konnte anhand der Logs nicht den Fehler erkennen... immerhin habe ich, wie vorab vermutet, durch Deaktivieren der TLS Funktion im Backend feststellen können, dass es irgendein Problem mit der TLS Kommunikation geben muss:

<11>1 2024-04-15T17:30:57+02:00 fw01.local.example.com caddy - - [meta sequenceId="3"] "error","ts":"2024-04-15T15:30:57Z","logger":"http.log.access.b9770f33-cc73-4431-8647-11a8b40c9409","msg":"handled request","request":{"remote_ip":"79.140.126.XX","remote_port":"6598","client_ip":"79.140.126.XX","proto":"HTTP/2.0","method":"GET","host":"uhd.example.com","uri":"/","headers":{"User-Agent":["curl/8.6.0"],"Accept":["*/*"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"uhd.example.com"}},"bytes_read":0,"user_id":"","duration":0.001070664,"size":0,"status":502,"resp_headers":{"Alt-Svc":["h3=\":443\"; ma=2592000"],"Server":["Caddy"]}}

<11>1 2024-04-15T17:49:04+02:00 fw01.local.example.com caddy - - [meta sequenceId="8"] "error","ts":"2024-04-15T15:49:04Z","logger":"http.log.access.b8bf171c-cce8-4285-b4ff-7e1c34c41bbd","msg":"handled request","request":{"remote_ip":"79.140.126.XX","remote_port":"60820","client_ip":"79.140.126.XX","proto":"HTTP/2.0","method":"GET","host":"akeneo.example.com","uri":"/","headers":{"User-Agent":["curl/8.6.0"],"Accept":["*/*"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"akeneo.example.com"}},"bytes_read":0,"user_id":"","duration":0.004570455,"size":0,"status":502,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"]}}

<14>1 2024-04-15T17:52:31+02:00 fw01.local.example.com caddy - - [meta sequenceId="1"] "info","ts":"2024-04-15T15:52:31Z","logger":"http.log.access.b9770f33-cc73-4431-8647-11a8b40c9409","msg":"handled request","request":{"remote_ip":"79.140.126.XX","remote_port":"10714","client_ip":"79.140.126.XX","proto":"HTTP/2.0","method":"GET","host":"uhd.example.com","uri":"/","headers":{"User-Agent":["curl/8.6.0"],"Accept":["*/*"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"uhd.example.com"}},"bytes_read":0,"user_id":"","duration":0.066035783,"size":5875,"status":200,"resp_headers":{"Last-Modified":["Mon, 28 Aug 2023 09:39:57 GMT"],"Vary":["Accept-Encoding"],"Server":["Caddy","Apache/2.4.38 (Debian)"],"Alt-Svc":["h3=\":443\"; ma=2592000"],"Etag":["\"16f3-603f87a3ca4bc-gzip\""],"Accept-Ranges":["bytes"],"Content-Type":["text/html"],"Date":["Mon, 15 Apr 2024 15:52:31 GMT"]}}

Ich gehe davon aus, dass Caddy das gleiche Problem wie der Apache hat, und das vom jeweiligen Backend Server korrekt angebotene TLS Zertifkat mit dem CN/SAN: "*.example.com" mit den jeweiligen aufgerufenen Backend IP Adressen 10.30.x.x anstatt des aufgerufenen SNIs vergleicht und daher zur fehlerhaften logischen Feststellung kommt, dass diese nicht matchen...

[Monviech (Cedrik)]

Für den Usecase gibt es in dem Caddy Plugin jetzt die Header Manipulationen.

https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#https
https://docs.opnsense.org/manual/how-tos/caddy.html#reverse-proxy-to-an-upstream-webserver-serving-vhosts

Als Alternative kann man auch den TLS Server Name in Handlers manipulieren, damit der SNI mit dem Zertifikat übereinstimmt. Wird hier erklärt mit einem Beispiel:

https://docs.opnsense.org/manual/how-tos/caddy.html#reverse-proxy-the-opnsense-webui

Die Logs von Caddy sind manchmal schwer zu sichten, aber man bekommt super Hilfe in der https://caddy.community falls etwas nicht richtig klappt. Die wissen auch vom Caddy Plugin in der OPNsense.