Hallo, mein haproxy zickt rum und ich würde den gerne noch mal neu machen. Wie kann ich haproxy komplett reseten, das auch alle Rückstände und confidateien gelöscht werden (ähnlich einem apt purge)?
Reicht es wenn ich wie folgt vorgehe?
* Löschen aller Elemente in den einzelnen haproxy-tabs
* Plugin löschen
* Reinstall der Packes haproxy28, os-haproxy und py39-haproxy-cli
Sind dann auch alle Konfigurationsrückstände entfernt? Oder muss ich da auf der Shell noch configdateien (z.B. /etc/...) entfernen?
Danke für eure Hilfe.
P.s.: Ich möchte keine Grundsatzdiskusion auslösen - aber stimmt es, das der haproxy generell ein wenig zickiger auf der Sense ist? Wäre es sinnvoll, einfach http/https auf einen Docker Host mit NPM oder so weiterzuleiten? Mir wäre es am liebsten, wenn es einfach direkt auf der Sense funktioniert - nur wenn es zu instabil ist, dann würde ich eine andere Lösung bevorzugen.
Solange du nur HTTP/HTTPS aus dem Internet per SNI auf einzelne Anwendungen verteilen möchtest, ist das Caddy-Plugin vielleicht eine einfacher zu konfigurierende Alternative. Brauchst du TCP für andere Dinge als "Web", geht nur HA-Proxy, klar.
https://github.com/Monviech/os-caddy-plugin
Demnächst dann offiziell in der OPNsense ...
Gruß
Patrick
Hallo Patrick, auch hier in dem Thread, in dem du mir hilfst erst mal ein dickes Danke :).
Habe mir mal die Github Seite durchgelesen klingt interessant - sollte funktionieren, ich nutze eigentlich nur Webanwendungen (Nextcloud, Bookstack, Cloudpanel, Leantime usw.
Denke, das sollte problemlos damit laufen.
Danke für deine Unterstützung.
Hmm, scheint nicht zu funktionieren.
Installiert ist das Plugin (vorher OPNsense aktualisiert), dann unter Services > Caddy Web Server > Generell Settings > Email Adresse eingegeben, Plugin aktivieren, Speichern klicken.
Dann unter Reverse proxy Domain und Handle anlegen - Settings zurückgehen, Modul ist wieder deaktiviert und die Emailadresse ist weg.
Neustart der Sense brachte keine Besserung, müsste auch nicht unter Dienste ein Dienst für Caddy sein? Stört es wenn der ACME Client installiert ist (für das WebUI Zertifikat der Sense)?
Danke für deine/eure Hilfe :).
Scheint ein Bug zu sein - wenn ich Emailadresse angebe und aktivieren klicke, bleibt das erhalten wenn ich unter Generell Settings die Tabs durchgehe, sobald ich aber nach Reverse Proxy gehe und wieder zurück, sind die Einstellungen weg :(.
Drückst du denn Save und dann Apply? Nur Apply saved das Form nicht.
Hier hab ich das gefixed das auch apply sichert. In version 1.5.2 die mit der opnsense kommt. In 1.5.1 musst du noch save drücken.
https://github.com/opnsense/plugins/pull/3851/commits/469421b71359e1b46efe495a6a4f7c0f5fd69ea7
Danke für deine schnelle Hilfe. Hatte ich, nach einem Neustart der Sense ist aber auch der Caddy Dienst da und ich kann speichern.
Immerhin wird mir nun schon mal eine "400 Bad Request, The plain HTTP request was sent to HTTPS port" Meldung angezeigt, wenn ich die Zielseite aufrufen.
Ich meine aber, ich habe alle Einstellungen richtig - ich möchte gerne die Seite https://wiki.leibling.de nach intern http://192.168.33.3:6875 weiterleiten.
Dazu habe ich folgende Einstellungen verwendet (siehe angehangene Bilder).
Sind die Einstellungen richtig?
Weiterhin würde ich auch gerne als CA LE verwenden, geht das?
Danke für deine / eure Unterstützung.
Wenn deine wiki ein TLS Zertifikat hat, intern, dann musst du den Handler dafür richtig einstellen, dass auch der TLS verwendet. Bei anderen Plugins kann man hier einfach einen Haken setzen der Zertifikate ignoriert. Beim Caddy Plugin /muss/ man das TLS richtig verwenden. Optionen die das umgehen sind explizit nicht vorhanden.
Hier ist die aktuelle Doku. Als beispiel versuche mal die Opnsense WebUI zu reverse proxien, das erklärt das mit dem Zertifikat.
https://github.com/Monviech/opnsense-docs/blob/master/source/manual/how-tos/caddy.rst#reverse-proxy-the-opnsense-webui
Hier noch ein Beispiel von einem User verfasst:
https://forum.opnsense.org/index.php?topic=38714.msg190745#msg190745
Du kannst nicht zwischen Lets Encrypt und ZeroSSL entscheiden, Caddy nimmt automatisch eine der Möglichkeiten für die Domain im Front End. Es steht dir natürlich frei, weiter das ACME Plugin zu verwenden, und in Caddy dann diese Zertifikate auszuwählen in der Domain, dadurch hast du dann immer nur Let's Encrypt.
Wenn dein Back End auf Let's encrypt angewiesen ist (z.b wenn Server dort ihren eigenen ACME Client haben), kannst du Caddy nicht verwenden. Es kann nicht wie HA Proxy das Lets Encrypt transparent zu deinem Back End Servern durchreichen. Es ist immer ein TLS Termination Proxy.
Edit:
Bei deiner Domain solltest du den Port leerlassen. Dadurch hört Caddy auf 80/443 und macht automatisches redirect von http zu https. (im screenshot ist es schwer zu erkennen ob es eingetragen oder der "Hint" der GUI ist.)
Noch mal vielen Dank für deine schnelle Hilfe.
Du hast recht, es ist in der Tat eine HTTPS Seite, laut Doku war die http, aber wenn ich die aufrufe, dann macht der ein redirect auf https. Dazu wird ein selfsigned Zertifikat genutzt (ist als Bild angehangen).
Muss ich das Zertifikat im Browser exportieren, in der Sense importieren und dann in den Settings vom handler TLS aktivieren, das Zertifikat auswählen und als TLS Name dann wiki.leibling.de eingeben?
P.s.: Ich habe als URL nur die Adresse eingegeben, die 443 ist die Description wiki.leibling.de.443 - meintest du das?
Danke dir.
Die ersten Seiten ohne https (intern) sind schon mal online - die, die intern https nutzen leider noch nicht. Wenn ich da das Zertifikat importieren möchte auf der Sense, dann meckert die natürlich das die kein Key hat - wenn ich nur TLS aktiviere und den namen wiki.leibling.de eingebe, dann kommt bei der Anzeige der Seite der folgende Fehler - ich vermute mal, das ich noch das Zertifikat angeben muss, nur was muss ich da angeben:
Diese Seite funktioniert nicht. wiki.leibling.de kann diese Anfrage momentan nicht verarbeiten.
HTTP ERROR 502
Bitte lies dir die Anleitungen noch mal durch die ich verlinke.
Bitte reverse proxie einmal die OPNsense GUI um die Zertifikatskonfiguration zu lernen.
Dort wird von "System - Trust - Authorities" geredet. Dort muss das selbssignierte Zertifikat importiert werden. Dort braucht man keinen privaten Schlüssel.
Wenn du Probleme hast, lies dir das LOG durch, Caddy schreibt sehr genau was das Problem ist wenn es Fehler gibt.
Danke, hatte ich - mittlerweile habe ich mit der Anleitung auch fast alle Sites am laufen (ca. 14 von 15). Ich bin sehr begeistert von dem Plugin - das ist wesentlich einfacher als der HAProxy und gefällt mir sehr gut.
Wäre es damit auch möglich z.B. die URL https://192.168.22.22/SOGo über https://webmail.leibling.de aufzurufen? Das wäre echt genial und würde auch noch ein weiteres "Problem" lösen, das ich noch auf der ToDo habe :).
So, nun muss ich mal schauen, das ich das wiki ans laufen bekomme - da gerade Anfragen aus dem Mailcow Forum kommen zu meinen Mailcow Anleitungen, welche gerade nicht über das Wiki erreicht werden können.
Danke auf jeden Fall für deine Mega Unterstützung :).
So, im Log steht nun folgendes:
"error","ts":"2024-03-16T17:02:51Z","logger":"http.log.error","msg":"tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead","request":{"remote_ip":"92.192.134.202","remote_port":"54045","client_ip":"92.192.134.202","proto":"HTTP/2.0","method":"GET","host":"wiki.leibling.de","uri":"/","headers":{"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"],"Sec-Fetch-Mode":["navigate"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Accept-Language":["de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7"],"Cache-Control":["max-age=0"],"Upgrade-Insecure-Requests":["1"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7"],"Sec-Fetch-Site":["none"],"Dnt":["1"],"Sec-Fetch-User":["?1"],"Sec-Ch-Ua":["\"Chromium\";v=\"122\", \"Not(A:Brand\";v=\"24\", \"Google Chrome\";v=\"122\""],"Sec-Ch-Ua-Platform":["\"macOS\""],"Sec-Ch-Ua-Mobile":["?0"],"Sec-Fetch-Dest":["document"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"wiki.leibling.de"}},"duration":0.002282527,"status":502,"err_id":"bgjqkx9ym","err_trace":"reverseproxy.statusError (reverseproxy.go:1267)"}
Wenn ich gar nichts angeben bei TLS Name, dann bekomme ich die folgende Meldung:
"error","ts":"2024-03-16T17:09:28Z","logger":"http.log.error","msg":"tls: failed to verify certificate: x509: cannot validate certificate for 192.168.33.3 because it doesn't contain any IP SANs","request":{"remote_ip":"92.192.134.202","remote_port":"54099","client_ip":"92.192.134.202","proto":"HTTP/2.0","method":"GET","host":"wiki.leibling.de","uri":"/","headers":{"Sec-Ch-Ua":["\"Chromium\";v=\"122\", \"Not(A:Brand\";v=\"24\", \"Google Chrome\";v=\"122\""],"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36"],"Accept":["text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7"],"Sec-Fetch-Mode":["navigate"],"Sec-Fetch-Dest":["document"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Sec-Ch-Ua-Platform":["\"macOS\""],"Dnt":["1"],"Upgrade-Insecure-Requests":["1"],"Sec-Fetch-Site":["none"],"Accept-Language":["de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7"],"Cache-Control":["max-age=0"],"Sec-Ch-Ua-Mobile":["?0"],"Sec-Fetch-User":["?1"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"wiki.leibling.de"}},"duration":0.002541955,"status":502,"err_id":"3x4y13434","err_trace":"reverseproxy.statusError (reverseproxy.go:1267)"}
Das Zertifikat hat aber wenn ich es richtig sehe keine SAN Namen - nur eim Common Namen. Kann man das irgendwie ändern? Oder was muss ich einstellen?!?
Zertifikate müssen schon seit geraumer Zeit den FQDN nicht nur im CN sondern auch als SAN vom Typ DNS Name haben. Du musst also das Zertifikat austauschen oder im Backend auf TLS verzichten, was ich bevorzugen würde.
Seit 2017 ist das so mit dem SAN: https://cabforum.org/uploads/CA-Browser-Forum-BR-1.5.4.pdf
Freut mich, dass dir das Plugin gefällt. Jetzt musst du nur noch das mit dem Zertifikat geradeziehen (also ein SAN Zertifikat mit DNS Name verwenden, kannst du z.B. in der OPNsense generieren) und dann ist alles sauber. :)
Aber ich bin mit @Patrick einer Meinung, dass intern das TLS komplett unnötig ist wenn es in einem trusted Network ist.
Edit: Und ja das mit https://192.168.22.22/SOGo sollte möglich sein. Im Handler einfach das Backend Path mit /SOgo befüllen, glaub ich.
Da gebe ich euch beiden recht - zumal mit dem Backend sowieso nur über den Reverse Proxy kommunizieren kann (ist in einem getrennten Server Subnetz).
Habe eben schnell die Docker compose angepasst und neugestartet - nun funktioniert es (ohne https intern) :).
Danke für eure Mega Unterstützung.
Quote from: Monviech on March 16, 2024, 06:24:13 PM
Edit: Und ja das mit https://192.168.22.22/SOGo sollte möglich sein. Im Handler einfach das Backend Path mit /SOgo befüllen, glaub ich.
Genau deshalb hab ich das Feature gebaut :P
Meinst du, wir sollten SOGo noch in die Beispiele in der Doku aufnehmen?
Es gibt bestimmt noch dutzende Beispiele wo man es auch brauchen könnte. Ich glaube der Hilfstext ist eindeutig (wenn er gelesen wird...)
Danke euch beiden. Ich habe einiges an Doku gelesen (natürlich vorab) - das Ding ist jedoch, wenn man "mal eben nebenebei" unter Zeitdruck was einrichtet, überliest man schnell etwas durch das querlesen - erst durch euere Hinweise bin ich dann durch das erneute lesen auf den Punkt "richtig" aufmerksam geworden.
Das mit dem Reverseproxy auf Unterverzeichnisse ist echt Mega - das fehlt einigen Reverseproxys oder auch HA Proxy als Plugin in der Sense. Meine Idee ist es, in der Mailcow das Webmailinterface was einfach in einen Unterordner geht, direkt als andere URL zur Verfügung zu stellen.
Z.B. in der Mailcow hat man z.B. die Url mail.domain.de für das Admininterface und mail.domain.de/SOGo als Webmailer - es gibt in der Anleitung die Möglichkeit mit einem weiteren Namen die URL zu erweitern, z.B. webmail.domain.de - aber dann leitet das nur weiter auf die Domain, jedoch benötigt man weiterhin die URL webmail.leibling.de/SOGo - mit dem Plugin könnte man nun jedoch bei webmail direkt in das Unterverzeichnis leiten. Gerade als Anwender würde ich doch davon ausgehen, das man öfter den Webmailer als das Admininterface benötigen würde. Somit sollte man bei webmail.domain.de das Webmailinterfache bekommen ubd bei mail oder mailadmin erst das Admininterface.
Fände ich Mega, werde ich mir anschauen und die Doku sowie mein Wiki diesbezüglich anpassen, zumindest in der Konstellation mit einer OPNsense. Dazu muss ich mir aber anschauen, wie sich das Plugin verhält - die Mailcow versucht selber immer die LE Zertifikate zu verlängern (redirect für ./well-known usw.).
Danke auf jeden Fall erst mal für eure Unterstützung und das Mega Plugin :).
Quote from: pleibling on March 16, 2024, 10:10:08 PM
Dazu muss ich mir aber anschauen, wie sich das Plugin verhält - die Mailcow versucht selber immer die LE Zertifikate zu verlängern (redirect für ./well-known usw.).
Das wird nicht funktionieren, Caddy wird "/.well-known/acme-challenge" für sich beanspruchen und /nicht/ reverse proxien. Das bedeutet, ACME Clients hinter Caddy, können nicht die HTTP-01 Challenge verwenden.
Für so Spielereien braucht man entweder DNS-01 Challenge im Backend ACME Client, oder einen L4 Proxy wie HA-Proxy. (oder man verzichtet auf TLS zwischen TLS-Termination Proxy und Backend Server, oder benutzt ein selbstsigniertes Zertifikat.)
ACME Challenge durchreichen:
https://caddy.community/t/using-certbot-behind-caddy/23295/8
Hat jemand Zeit das zu testen? Dann kann ich das als Checkbox einbauen.
Die Beispielkonfig muss nach /usr/local/etc/caddy/Caddyfile vor den ersten #Reverse Proxy Domain gesetzt werden, zusätzlich.
EDIT: Da es recht einfach ist und funktionstüchtig aussieht wird es in der neuen Plugin Version einfach mit drin sein.
https://github.com/opnsense/plugins/pull/3865/commits/7a23dfd177ceb81c6692028812a95000e8034bf1
EDIT2: Habe es mit 2 Caddys hintereinander getestet und es funktioniert. :D