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
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.
Würde das hier reichen?
https://github.com/opnsense/plugins/commit/8bf11f79a41aac78eace88538ffbb838d94a2095
Damit wäre folgender Usecase abgedeckt:
Load-balance all requests between 3 backends:
example.com {
reverse_proxy node1:80 node2:80 node3:80
}
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.
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
@Monviech,
einfach mal so: Vielen Dank für das Plug-in! ;)
Hey danke, bitteschön. Hoffe es geht alles noch seit dem letzten Update, gab viele Änderungen. xD
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.
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.
Quote from: guenti_r on April 19, 2024, 10:03:04 AM
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".
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.
Naja, streng genommen kann man beim OpenWAF auch fast nichts (ver-)konfigurieren.
Entsprechend der Dokumentation (https://docs.opnsense.org/vendor/deciso/opnwaf.html):
Quote
Web protection
The web protection options offer easy access to the OWASP ModSecurity ruleset (https://owasp.org/www-project-modsecurity-core-rule-set/), which offers a set of generic attack detection rules against a wide range attacks including the OWASP Top Ten (https://owasp.org/www-project-top-ten/).
werden Standard Rules gem. Step 3: A closer look at the rules folder (https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/#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:
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.confund 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 (https://wiki.mozilla.org/Security/Server_Side_TLS) 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 .
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.
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:
Quote
<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...
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.
OK, die neue Option "TLS Server Name" neben der schon gelesenen "TLS Insecure Skip Verify" Option eben nach einem Update der Test OPNsense VM gefunden (neu zumindest seit 1.5.2) ...
Und erfreulicherweise auch nicht in den Advanced Options "versteckt", so dass der unbedarfte User das dann intuitiv sogar entsprechend erfolgreich konfigurieren kann ;D 👍
Ich hab die UI etwas verbessert um die Relevanten Optionen besser hervorzuheben. Gut wenn es dir gefällt. ;D
@Reiner030 Ich hab das DEBUG log in der nächsten Version eingebaut. Danke für das Feedback.
https://github.com/opnsense/plugins/issues/3935
Eine Frage:
Habe Backends, die "nur" HTTPS verstehen und über vhosts laufen, wie ist da die korrekte Vorgehensweise?
Ich bekomme es mit den üblichen HowTos nicht hin und im Caddy-Forum wird das irgendwie anders angegangen...
Caddy wirft mir immer "remote error: tls: unrecognized name" aus.
UPDATE:
Konnte es mit manuellem editieren hinbekommen, anscheinend geht das noch nicht über die GUI.
Szenario:
Hinter dem Caddy liegt eine lokale Cloudpanel-VM mit der IP 192.168.1.205.
Wenn ich eine neue Website mit einer Beispiel-Domain anlegen will (mit self-signed Cert) dann muss man im Caddyfile folgendes abändern:
www.beispieldomain.at {
handle {
reverse_proxy https://192.168.1.205 {
transport http {
tls_server_name www.beispieldomain.at
}
}
}
Ist hier nur experimentell; über die GUI funktioniert es so (noch) nicht.
Häh was doch das geht über die GUI.
In den Docs steht das alles. Schau dir mal die Optionen bei Handler an.
https://docs.opnsense.org/manual/how-tos/caddy.html#reverse-proxy-handler
Und dazu das Beispiel hier:
https://docs.opnsense.org/manual/how-tos/caddy.html#reverse-proxy-the-opnsense-webui
Außerdem gibt es seit os-caddy-1.5.4 auch das hier für vhosts:
https://docs.opnsense.org/manual/how-tos/caddy.html#reverse-proxy-to-an-upstream-webserver-serving-vhosts
Leider nein, sobald ich nach einer internen upstream domain gehe, bekomme ich "remote error: tls: unrecognized name"
Extern geht es ohne Probleme.
Hier habe ich was gefunden und angewendet:
https://caddy.community/t/caddy-reverse-proxy-to-multiple-sites-on-port-80/17263/4
Das Beispiel geht aber ganz genau so wie auch in dem Thread beschrieben mit der GUI.
- Du kannst den Host Header verändern. Dafür gibt es das Header menü.
- Die Checkbox für TLS gibt es, diese ersetzt das https://
- "TLS Server Name" gibt es auch in der GUI, dort kann man den Namen setzen.
Wenn das nicht geht, zeige mir bitte ganz genau das Caddyfile welches nicht geht, was du mit der GUI erstellt hast. Und das Caddyfile was du manuell editiert hast.
Nur so kann ich das Verhalten nachstellen und wenn es einen Fehler gibt patchen.
Ich sagte ja schon, über die GUI funktioniert es nicht, weil im Handler eine IP anzugeben ist und keine Domain.
Habe im vorherigen Post das funktionierende Besipiel abgebildet.
Manuelles editieren des Caddy-Files geht sofort.
Man benötigt dann auch keine Header Manipulation mehr.
Szenario:
Eine öffentliche WAN-IP mit mehreren gepointeten Domainnamen (www.beispiel1.com, www.beispiel2.com etc...).
OPNSense mit Caddy grundlegend eingerichtet.
Im LAN zB. eine Cloudpanel-VM mit mehreren gehosteten Webseiten (zB: 192.168.1.100).
Im Caddy die gewünschten Domains anlegen.
Für diese Domains KEINE Handlers oder Headers einrichten.
Im Caddyfile die dazugehörigen Einträge folgend abändern:
www.beispiel1.com {
handle {
reverse_proxy 192.168.1.100:443 {
transport http {
tls_server_name www.beispiel1.com
}
}
}
abort
}
und
www.beispiel2.com {
handle {
reverse_proxy 192.168.1.100:443 {
transport http {
tls_server_name www.beispiel2.com
}
}
}
abort
}
Caddy restarten und es funktioniert.
https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#tls_server_name (https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#tls_server_name)
VORSICHT: Das hier ist experimentell anzusehen ;)
Aber man kann bei Upstream Domain doch eine IP Adresse eintragen. Und man kann TLS anhaken und bei TLS Server Name etwas eingeben. Vielleicht stehe ich hier auf dem Schlauch.
Hier z.b ein Beispiel Caddyfile was jemand mit der GUI erstellt hat. Darin sieht man genau das was du zeigst.
https://github.com/opnsense/plugins/issues/3929#issuecomment-2068171214
Hast du os-caddy-1.5.4 installiert?
EDIT: Wenn tls-server-name auftauchen muss, ohne dass gleichzeitig TLS angehakt wird, dann muss ich das in der template fixen. transport_http erscheint nur, sobald TLS angehakt wurde. Aber bei dir ist es das erste mal dass es jemand ohne tls in der direktive braucht.
Oh, Fehler gefunden!
Caddy reloaded/restarted sich nicht gerne über die GUI :-\
Man drückt reload/restart, im Glauben es wäre so...
Dann geht man davon aus, die Änderungen wären durch. Aber dem ist dann nicht so.
Manuelles restarten über die CLI und plötzlich funktioniert alles einwandfrei!
Somit bin ich also ohne es zu wissen ins offene Messer gerannt.
@Monviech, DANKE!
EDIT: Eben dein Edit übersehen. Ja, das könnte nicht schaden.
@guenti_r
Hiermit wird tls_server_name und tls unabhängig voneinander.
https://github.com/opnsense/plugins/pull/3948
Sehr cool, DANKE! ;D