Frage zu Zertifikaten und Zugriff von innen und außen (mit HAProxy oder Caddy)

Started by white_rabbit, December 30, 2024, 07:22:35 PM

Previous topic - Next topic
Quote from: Patrick M. Hausen on January 01, 2025, 05:33:11 PMDu benutzt intern und extern dieselbe Domain? Mach das halt nicht ;-)
Warum nicht?

Ich habe auch eine Nextcloud, die intern wie extern über dieselbe Domain erreichbar ist: cloud.meine.domain
Was soll daran falsch sein?

Mit unterschiedlichen Domains für intern und extern müsste ich in meinem Nextcloud Client am Handy jedes mal beim verlassen des Hauses das Konto wechseln. Wäre mir doch zu blöd.
Und wofür? Funktioniert doch bestens. Und das WebGUI der Firewall kann ich auch erreichen. Das läuft natürlich weder auf Port 80 noch auf 443, noch wird von diesen Ports darauf weitergeleitet.

Das meinte ich nicht. Wenn deine Domain "meine.domain" ist, dann benutz die für extern erreichbare Services und das sowohl von innen als auch von außen. Aber benutz sie nicht als Domain für DHCP und schlimmstenfalls Active Directory (falls du eine Firma bist und sowas hast).

Benutz dafür halt eine Subdomain wie "zuhause.meine.domain".

Grund: wenn man AD hat, dann

- müssen die DCs die DNS-Server für alle Clients ein
- muss "meine.domain" als A- und ggf. AAAA-Records die Adressen der DCs zurückgeben

Daher kannst du dir https://meine.domain für die extern gehostete Website schon mal abschminken und auch "cloud.meine.domain" per DynDNS geht dann nicht.

Auch ohne AD kann man sich jede Menge Komplikationen einfangen, also besser für die internen Geräte und extern unterschiedliche Domains verwenden. Dazu gibt es ja Subdomains. Meine Firma heißt punkt.de mit gleichnamiger Domain. Unser AD hört auf intern.punkt.de. Problem gelöst, alles sauber.

Grüße und frohes neues Jahr allen,
Patrick
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Patrick M. Hausen on January 01, 2025, 06:49:28 PMDas meinte ich nicht. Wenn deine Domain "meine.domain" ist, dann benutz die für extern erreichbare Services und das sowohl von innen als auch von außen. Aber benutz sie nicht als Domain für DHCP und schlimmstenfalls Active Directory (falls du eine Firma bist und sowas hast).
Alles klar.

Gutes neues Jahr auch!

Quote from: Patrick M. Hausen on January 01, 2025, 06:49:28 PMDas meinte ich nicht. Wenn deine Domain "meine.domain" ist, dann benutz die für extern erreichbare Services und das sowohl von innen als auch von außen. Aber benutz sie nicht als Domain für DHCP und schlimmstenfalls Active Directory (falls du eine Firma bist und sowas hast).
Dann bin ich beruhigt, denn das haben wir so.

Ich habe es nochmal so versucht wie Ihr es vorgeschlagen habt aber es hat leider nicht funktioniert. Die OPNSense lauscht jetzt auf Port :8443 und auch sonst sind die Optionen so gesetzt wie oben genannt. Allerdings konnte ich den (internen) Server (docker-Container) leider nicht mit gültigem LE-Cert erreichen. Es wurde immer das Cert des Containers verwendet.
Ich habe zwischendurch sogar mit einem A-Record auf die WAN-Adresse versucht um zu schauen, ob es daran liegt ... aber das hat nichts geändert.

Am Ende habe ich es dann so gemacht wie sonst: Das LE-Cert von der OPNSense auf den docker-Container kopiert und direkt dort eingebunden. Zusätzlich die Domain-Überschreibung auf der OPNSense auf die lokale IP wieder aktiviert. Immerhin läuft es jetzt; auch wenn das erneut der umständliche (und schlechtere) Weg ist. Aber wie auch immer: Besten Dank für's Mitdenken. Ich schaue mir in Kürze os-caddy an...


Quote from: Patrick M. Hausen on December 30, 2024, 11:47:20 PMHAproxy ist unübersichtlich und ein Problem des Plugins ist, dass der maßgebliche Autor von der etablierten Terminologie von HAproxy abweicht und das ganze aufbaut wie viele Loadbalancer aus der kommerziellen Ecke - F5, Cisco, Kemp, ... - das Ganze behandeln.

Ich hab mir zugegebenermaßen nicht alle Details in diesem Thread angeguckt aber als generellen Hinweis:

Ich benutze für alle Dienste, die extern und intern erreichbar sein sollen, ausschließlich die externe IP-Adresse und FQDN. Nebst Letsencrypt-Zertifikat, natürlich. Also z.B. die Nextcloud heißt dann cloud.meinedomain.de - A und AAAA sind die WAN-Adresse meiner OPNsense und dort lauscht der Caddy und proxiet die Requests zum FreeBSD-Jail mit der Nextcloud.

Weshalb sollte ich für Zugriffe von "innen" eine andere IP-Adresse benutzen? Die Verbindung kommt zum LAN rein, dann ist "WAN address" eine lokale Adresse, also geht das an den Caddy. Da wird nix "erst mal raus zum Provider und dann wieder rein" geroutet. Jede Adresse, die für die Sense auf einem lokalen Interface liegt, ist gleichwertig. Und da ich auf LAN "allow LAN net to any" habe, geht das auch einfach so durch.

Keine NAT-Refelction, nix. Funktioniert einfach.

Es wäre einen winzigen Tick "optimaler", wenn cloud.meinedomain.de intern direkt auf den Server verweisen würde. Das würde den Proxy-Overhead sparen. Aber alle Server und die Sense sind hier intern mit 1G oder 10G veerknubbelt, also was soll das?

Pluspunkt: wenn es imtern funktioniert, weißt du, dass es auch extern funktioniert - und umgekehrt.

Das ist der Riesenvorteil eines Reverse-Proxy mit SSL-Terminierung im Proxy. Funktioniert von außen wie innen absolut identisch und es braucht keine NAT-Reflection oder anderes Gedöns.

Eine Verbindung von einem Client im "LAN" mit Ziel "WAN address" geht nicht "über das Internet". Nie. Berücksichtigen! 😉

Eine ähnliche Frage beschäftigt mich auch gerade, ich habe den Hinweis aus obigen post aufgenommen und dabei ist mir folgendes aufgefallen.

Auf meiner opnsense ist der ACME-Client und der caddy proxy eingerichtet, als lokalen DNS nutze ich unbound.
Caddy verteilt das Let's Encrypt Wildcard Zertifikat an die Dienste die in meinem Netz laufen, aber aus irgendeinem Grund nicht an alle. Z.B. habe ich 2 managed switche von DLink in meinem Netzwerk die ich über switch1.meinedomain.de und switch2.meinedomain.de anspreche.
Bei switch1 kommt eine https Verbindung zustande bei switch2 nicht obwohl die Subdomain und der Handler in caddy für beide switche genau gleich eingerichtet ist (außer der Upstream IP natürlich). Die Overrides in unbound sind so gesetzt dass die Dienste nach dem Muster subdomain.meinedomain.de an die öffentliche IP der WAN Schnittstelle weitergeleitet werden.
Und genauso verhält es sich auch mit anderen Diensten, bei manchen kommt eine ttps Verbindung zustande bei manchen nicht.

Hat jemand eine Idee woran das liegen könnte?