Reverse Proxy Caddy funktioniert nicht mit lokalem DNS

[cadmium2]

Hallo,
ich arbeite mich gerade in das Thema OPNsense und Caddy als Revers-Proxy ein. Folgende Schritte habe ich unternommen und komme nicht weiter.

1. Dokumentation https://docs.opnsense.org/manual/how-tos/caddy.html#caddy-troubleshooting gelesen
2. Bei Unbound DNS eine einen "Host Override" für einen lokalen DNS hinterlegt Bsp: server01.local
3. mittels nslookup wird der server01.local korrekt erkannt
4. Ein Server-Zertifikat (System -> Certificates -> Trust) erstellt
5. Port OPNsense auf 8443 geändert
6. Firewall Regel WAN/LAN, Port 80/443 gehen an "This firewall"
7. Caddy: Domain erstellt, server01.local, bei Trust das angelegte Zertifikat hinterlegt (Custom Certificate)
8. Caddy: HTTP Handler angelegt, Domain ausgewählt, Upstream IP und Port hinterlegt (Dienst ist direkt über Port ohne Reverse Proxy erreichbar), TLS Trustpool hinterlegt, TLS Server Name auf server01.local gesetzt
9. HTTP Access Log aktiviert
10. Caddy neu gestartet

Rufe ich die Seite von mehrer Clients im LAN auf, liefert Firefox nur "Fehler: Verbindung fehlgeschlagen". Im Log finde ich keine Einträge. Vielleicht ist das noch wichtig. Der Aufruf erfolgt von einem Client der sich in einem VLAN befindet. Das VLAN hat eine Firewall-Regel zu "any" - also keine Einschränkungen.

Eigenartig ist dabei, dass über WAN alles ohne Probleme funktioniert. Dort sehe ich auch den "Handle" im HTTP Access Log.

Hat jemand eine Idee was ich hier vergessen habe? Warum werden die lokalen Requests nicht an Caddy weiter gegeben? Kann es mit den Zertifikaten zusammen hängen? Trotzdem müsste ich doch da im Access Log wenigsten einen Eintrag sehen.

Vielen Dank für eure Hinweise :-)

[Patrick M. Hausen]

Grad keinen Plan bezgl. Caddy, aber du solltest niemals .local Einträge im DNS anlegen. Die Domain ist reserviert für Multicast-DNS.

[cadmium2]

Grad keinen Plan bezgl. Caddy, aber du solltest niemals .local Einträge im DNS anlegen. Die Domain ist reserviert für Multicast-DNS.

Danke für den Hinweis, dass wusste ich noch nicht. Ich verwende tatsächlich bei mir .intern und nicht .local. Das war nur dem Beispiel geschuldet. ;-)

[bananajoe78]

Hast Du im Unbound die IP auf die IP des Servers gelenkt? Oder auf die IP der opnSense?

Wenn Du das mit Caddy machen möchtest, muss der Name auf die IP der opnSense gerichtet sein.
Caddy kümmert sich dann um das Mapping zur Server-IP

[cadmium2]

Hast Du im Unbound die IP auf die IP des Servers gelenkt? Oder auf die IP der opnSense?

Wenn Du das mit Caddy machen möchtest, muss der Name auf die IP der opnSense gerichtet sein.
Caddy kümmert sich dann um das Mapping zur Server-IP

Vielen Dank. :-)  Hier bin ich schon mal einen Schritt weiter. Ich habe folgendes geändert.

1. Unbound DNS (Host Overrides), server01.internal -> IP von OPNsense hinterlegt
2. Caddy: Upstream geprüft, Dienst funktioniert direkt über IP und Port mittels HTTP
3. Caddy und Unbound neu gestartet

Jetzt bekomme ich schon mal einen Log-Eintrag bei der HTTP Access, allerdings verbindet er sich nicht zum Dienst auf den Server. Hier der Log-Auszug.

Code: [Select]

"error","ts":"2024-08-15T10:47:10Z","logger":"http.log.access.525c15bd-fea4-45b6-b019-363d217c0d32","msg":"handled request","request":{"remote_ip":"192.168.xx.xx","remote_port":"42070","client_ip":"192.168.xx.xx","proto":"HTTP/2.0","method":"GET","host":"server01.internal","uri":"/favicon.ico","headers":{"Accept-Language":["de"],"Priority":["u=6"],"Pragma":["no-cache"],"Cache-Control":["no-cache"],"User-Agent":["Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0"],"Accept":["image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Referer":["https://server01.internal/"],"Sec-Fetch-Dest":["image"],"Sec-Fetch-Mode":["no-cors"],"Sec-Fetch-Site":["same-origin"],"Te":["trailers"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"server01.internal"}},"bytes_read":0,"user_id":"","duration":0.001876465,"size":0,"status":502,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"]}}


[Patrick M. Hausen]

1. Weiß der Server auf deinem Ubuntu auch, dass er auf server01.internal reagieren soll?
2. Weshalb benutzt du nicht einfach den externen FQDN zum Zugriff auch vom LAN aus?

[cadmium2]

1. Weiß der Server auf deinem Ubuntu auch, dass er auf server01.internal reagieren soll?
2. Weshalb benutzt du nicht einfach den externen FQDN zum Zugriff auch vom LAN aus?

zu 1.) ja
zu 2.) Da ich viel über lokale DNS Einträge auf Dienste zugreife, wollte ich nicht immer bei meinem Domainprovider so viele FQDN hinterlegen. Vielleicht muss ich da auch was umdenken. ;-)


Jetzt kann ich doch Erfolg verbuchen. Ich habe bei Caddy (Domains und HTTP Handler) unter "Custom Certificate" bzw. "TLS Trust Pool" alles auf "None" gesetzt. Jetzt funktioniert es. Vermutlich war das in Konflikt mit dem Zertifikat, welches direkt für OPNsense hinterlegt ist (Web GUI)?

Kann es sein das Caddy automatisch dieses Zertifikat verwendet? Jedenfall wird es für meinen Serverdienst über HTTPS verwendet.

[Patrick M. Hausen]

Und wozu brauchst du für lokale Dienste, die keinen externen FQDN haben, einen Proxy? Ich greife auf alle, die einen FQDN haben, über den Caddy mit dem nämlichen FQDN zu, und auf die übrigen einfach direkt.

[cadmium2]

Und wozu brauchst du für lokale Dienste, die keinen externen FQDN haben, einen Proxy? Ich greife auf alle, die einen FQDN haben, über den Caddy mit dem nämlichen FQDN zu, und auf die übrigen einfach direkt.

Wahrscheinlich habe ich hier eine Wissenslücke. Mein Ziel ist es, über HTTPS auf die internen Dienste zuzugreifen. Zum Beispiel nutze ich Paperless nur intern und möchte via https auf die WebGUI zugreifen und Dokumente verwalten. Dieser Dienst läuft als Docker Container (wie andere Dienste auch) auf einem zentralen Docker Server (Runtime mit Compose). Jeden der dort verfügbaren Dienste (Container) möchte ich mit einem separaten DNS Eintrag ansprechen, damit ich den Überblick behalte und nicht jedes Mal nach Port-Mappings suchen muss, wenn sie was ändern. Dazu kommt auch, dass ich mich nicht für jeden Dienst einzeln um ein Zertifikat kümmern muss, sondern das zentral über OPNsense machen kann.

Wenn ich mich z.B. zu Paperless verbinde, möchte ich meine Zugangsdaten nicht via HTTP übertragen. Ich weiß, ich bin im LAN und die menschlichen Teilnehmer sind überschaubar, aber ich halte es trotzdem für sinnvoll.

Verstehe ich deine Aussage richtig? Du nutzt interne Dienst (via HTTP) ohne TLS? Oder wie regelst du das mit den Zertifikaten bei Diensten, die nur interne sind?

[Patrick M. Hausen]

Ich wechsle einmal im Jahr das Zertifikat für *.ettlingen.hausen.com bei den rein internen Dingen aus.

Du könntest mit Caddy folgendes tun:

1. Leg im DNS einen Wildcard A-Record auf deine externe IP-Adresse: *.meinedomain.de
2. Leg in Caddy den Service foo.meinedomain.de an mit allem drum und dran, Handler zeigt auf Docker XY.
3. Leg in Caddy eine Access-Liste an, die den Zugriff auf foo.meinedomain.de nur von LAN aus erlaubt.

Das klappt ebenfalls prima. So greife ich auf das Web-Interface der OPNsense zu, ohne immer :4443 anhängen zu müssen.