HTTPS Internal Services only - Caddy, ha proxy, nginx, internal ca?

[guenthermitd]

Hi,

irgendwie verzweifele ich etwas und je mehr ich lese, desto verwirrter werde ich:

Was ich erreichen möchte: Alle internen Services per https erreichbar machen.

ich habe eine opnsense laufen und diverse Dienste auf Proxmox (homeassistant, mqtt broker, autodarts etc.) oder anderen ThinClients

Ich möchte nu, dass diese (nur intern) über https erreichbar sind, da diverse Dienste dies für weitere Funktionen benötigen.

Aktuell habe ich Caddy installiert und ich kann auch extern auf meine opnsen zugreifen, aber scheitere irgendwie daran, die weiteren server/services einzurichten.
Davor hatte ich ha-proxy und nginx ausprobiert - aber bis auf opnsense per https war ich weniger erfolgreich.

Auf meiner Sense läuft ubound als dns resolver und diversen blocklisten.

Was wäre aus Eurer Sicht der Best Practice Ansatz?
Macht ein reverse proxy überhaupt Sinn?

[openMe]

Da bist du mir schon um einige Services voraus, aber sonst bin ich auch seit ein paar Tagen auf diesem Weg.

Ich möchte nu, dass diese (nur intern) über https erreichbar sind

Wenn du deine Dienste nur intern aus deinem LAN erreichen willst, brauchst du eigentlich gar keine OPNsesnse - also zumindest nicht dafür.
Außer du möchtest deine Dienste intern hinter einer Firewall haben.

[meyergru]

Ein Reverse Proxy ist dafür sinnvoll, weil er die Verschlüsselung und die Abbildung von Namen auf IPs / Backends zentral übernimmt.

Es gibt zwei Überlegungen, die man dabei anstellen sollte:

1. Will man dafür eine "echte" DNS-Domain verwenden? Dann kann man die Erzeugung der Zertifikate per ACME machen, vorzugsweise mit Wildcards. Dadurch benötigt man nur ein einziges Zertifikat, unabhängig vom Namen. Die Alternative ist eine eigene CA - allerdings gehen dabei keine Wildcards, weil neuere Browser Wildcards nicht mehr für *.xyz, sondern nur noch für *.xyz.abc akzeptieren. Jeder neue Name benötigt also ein neues (oder erweitertes) Zertifikat - was man durch entsprechendes Skripting erreichen kann. Andererseits ist der Betrieb einer CA sowieso nicht jedermanns Sache.

2. Wo sitzt der Reverse Proxy? Egal, was man dafür verwendet, falls der Proxy auf der OpnSense liegt und gleichzeitig auch "extern" erreichbare Namen bedient, muss man dafür sorgen, dass die "internen" Services nicht aus Versehen exponiert werden.
Aus diesem Grund trenne ich die externen Dienste von den internen - letztere laufen über einen Traefik, der auf einem Docker-Host betrieben wird. Das ist auch deshalb praktisch, weil die meisten Services unter Docker laufen und somit nur Annotations brauchen, um mit HTTPS ausgestattet zu werden.

[guenthermitd]

Wenn du deine Dienste nur intern aus deinem LAN erreichen willst, brauchst du eigentlich gar keine OPNsesnse - also zumindest nicht dafür.
Außer du möchtest deine Dienste intern hinter einer Firewall haben.

Die OpnSense läuft ja hauptsächlich als Hardware Router - dahinter hängt nen reines daytrek dsl modem - also die sense brauch ich um ins Internet zu kommen :)

[guenthermitd]

Ein Reverse Proxy ist dafür sinnvoll, weil er die Verschlüsselung und die Abbildung von Namen auf IPs / Backends zentral übernimmt.

Es gibt zwei Überlegungen, die man dabei anstellen sollte:

1. Will man dafür eine "echte" DNS-Domain verwenden? Dann kann man die Erzeugung der Zertifikate per ACME machen, vorzugsweise mit Wildcards. Dadurch benötigt man nur ein einziges Zertifikat, unabhängig vom Namen. Die Alternative ist eine eigene CA - allerdings gehen dabei keine Wildcards, weil neuere Browser Wildcards nicht mehr für *.xyz, sondern nur noch für *.xyz.abc akzeptieren. Jeder neue Name benötigt also ein neues (oder erweitertes) Zertifikat - was man durch entsprechendes Skripting erreichen kann. Andererseits ist der Betrieb einer CA sowieso nicht jedermanns Sache.

2. Wo sitzt der Reverse Proxy? Egal, was man dafür verwendet, falls der Proxy auf der OpnSense liegt und gleichzeitig auch "extern" erreichbare Namen bedient, muss man dafür sorgen, dass die "internen" Services nicht aus Versehen exponiert werden.
Aus diesem Grund trenne ich die externen Dienste von den internen - letztere laufen über einen Traefik, der auf einem Docker-Host betrieben wird. Das ist auch deshalb praktisch, weil die meisten Services unter Docker laufen und somit nur Annotations brauchen, um mit HTTPS ausgestattet zu werden.

Danke dir für die Antwort.

Mir ist es eigentlich egal --> da jetzt nicht täglich neue Service hinzukommen oder wegfallen - daher sollte sich der Adminaufwand zwar in Grenzen halten, aber letztendlich will ich einfach das am einfachsten zu realisierende.

Ad 1 - ja da hab ich irgendwie Probleme zu der dynDNS Domäne Caddy klar zu machen, was er mit dem Input machen soll. Weiterleitung ubound auf caddy geht - aber dann löst er das nicht richtig auf.

Ad 2 - ubound und caddy laufen auf der OpnSense und die meisten anderen services auf einer Proxmox ldc . hatte es mit dem Resolver ehrlich gesagt nach einem Guide gemacht,vorwiegend wegen Adblocking - das läuft gefühlt aber seit 4Jahren+ unangetastet (bis auf updates) und natürlich nich dokumentiert.