5
Dataflow homserver (Nginx Proxy Manager, Docker, etc.)
Hallo Community,
ich weiß nicht so recht, ob das Thema hier am besten passt aber ich versuche es mal. Wieder mal ein Post a la: Ich sortiere mich mal.
Ausgangslage:
Bisher:
Idee:
Fragen:
1. Brosereingabe: hub.meinedomain.home
2. Internen DNS resolver fragen
3. Domain auf eine interne Docker IP auflösen (aber wie soll das gehen? Wie kommt hier der NPM ins Spiel?)
4. Damin per https anzeigen
Soweit meine Gedanken, hoffe ihr könnt mir etwas Folgen und Danke fürs Feedback.
ich weiß nicht so recht, ob das Thema hier am besten passt aber ich versuche es mal. Wieder mal ein Post a la: Ich sortiere mich mal.
Ausgangslage:
- Homeserver mit einigen Docker Containern z.B.: Portainer, Unifi Controller, später Nextcloud usw.
- Eigens generiert Zeritfikate (in meinem Fall per OPNsense)
- Homeserver inkl. der Container sollen nur intern oder später durch ein VPN Netz erreichbar sein, also nicht direkt aus dem www
- Ich möchte alle Verbindungen auch intern mittels SSL absichern (auch weil die SecurityInfo ständig nervt)
Bisher:
- root-CA, inter-CA und Zeritifkat zb für Portainer erstellt (also auf IP des Homeservers)
- KOmplette Chain für den Browser verfügbar gemacht
- Im Portainer kann ich manuel key und cer file einspielen, damit funtkioniert SSL nun. Für Unifi, Nextcloud etc. ist das irgendwie blöd/schwer wie auch immer
Idee:
- Nginx Proxy Manager per Docker ausfsetzen, als zentrale Anlaufstelle
- Zertifikat für Nextcloud hochladen, Proxy Host erstellen
- Für den Proxy Host in NPM benötige ich eine Domain. Da bei mir alles intern ist möchte ich zum Beispiel "https://hub.meinedomain.home" eintragen
- Bei IP kommt die interne Docker Container IP rein
- http und eben Port 80 (nicht genau im Kopf ob Nextcloud darauf hört)
Fragen:
- Damit "hub.meinedomain.home" intern auflöst benötige ich ja ein interes DNS. Wo mit baue ich dies auf? Kann/muss ich das mit Unbound, Bind etc. machen oder macht der der NPM selber?
- Was mir auch noch nicht ganz klar ist, ist die Kommunikation mittels NPM da mir ja die klassiche Portweiterleitung durch den Router fehlt. Ich bekomme bereits internen Traffic.
- In der Regel habe ich eine IP meines Servers, in meinem Fall lege ich Docker Container dann auf unterschiedliche Ports. Bei NPM geht das aber nicht mehr, siehe oben. Im Grunde muss der Weg doch sein:
1. Brosereingabe: hub.meinedomain.home
2. Internen DNS resolver fragen
3. Domain auf eine interne Docker IP auflösen (aber wie soll das gehen? Wie kommt hier der NPM ins Spiel?)
4. Damin per https anzeigen
Soweit meine Gedanken, hoffe ihr könnt mir etwas Folgen und Danke fürs Feedback.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 3293102072
Url: https://administrator.de/contentid/3293102072
Printed on: April 18, 2024 at 20:04 o'clock
5 Comments
Latest comment
Ich nutze PI-Hole als DNS. Zum einen als Werbeblocker - zum anderen kann man da über die Weboberfläche schnell eigene DNS-Einträge erzeugen ("A"-Einträge, die von einem Namen auf eine IPv4 verweisen).
PI-Hole lässt sich auch als DHCP-Server einsetzen.
PI-Hole lässt sich auch als DHCP-Server einsetzen.
ich bekomme es noch nicht ganz zusammen. Also die Idee einen Proxy zu nutzen, speziell den NPM.
Den NPM möchte ich ja auf meinem datahub hosten. Heißt deploy des Containers. Nun kann ich den container mittels url. hub.meinedomain.home:PORT ansprechen. Heißt alle Anfragen landen dann auf dem NPM und von dort kann ich weiterleitungen mittels proxy hosts.
Genau bei den proxy hosts hänge ich gerade. Beispiel portainer. ich möchte portainer aufrufen können per portainer.meinedomain.home. Jetzt muss ich doch meinem internen DNS (Unbound) beibringen, dass portainer.meinedomain.home eigentlich auf. Mittels host ovverrides scheint dies nicht zu funktionieren, da in diesem fall portainer ja kein echter host ist.
Ich habe im Grunde für jeden Container eine "virtuelle" url. Sproch portainer.meinedomain.home oder unifi.meinedomain.home. Beide muss ich doch auf eine IP , nämlich die des Docker hosts auflösen damit der NPM übernehmen kann oder denke ich hier falsch?
Wie kann ich hier vorgehen oder wo nach müsste ich schauen?
Den NPM möchte ich ja auf meinem datahub hosten. Heißt deploy des Containers. Nun kann ich den container mittels url. hub.meinedomain.home:PORT ansprechen. Heißt alle Anfragen landen dann auf dem NPM und von dort kann ich weiterleitungen mittels proxy hosts.
Genau bei den proxy hosts hänge ich gerade. Beispiel portainer. ich möchte portainer aufrufen können per portainer.meinedomain.home. Jetzt muss ich doch meinem internen DNS (Unbound) beibringen, dass portainer.meinedomain.home eigentlich auf. Mittels host ovverrides scheint dies nicht zu funktionieren, da in diesem fall portainer ja kein echter host ist.
Ich habe im Grunde für jeden Container eine "virtuelle" url. Sproch portainer.meinedomain.home oder unifi.meinedomain.home. Beide muss ich doch auf eine IP , nämlich die des Docker hosts auflösen damit der NPM übernehmen kann oder denke ich hier falsch?
Wie kann ich hier vorgehen oder wo nach müsste ich schauen?
Ich versteh das Problem nicht ganz.
In Docker kann man aber - am besten per docker-compose - per "extra_hosts" nebenbei so etwas wie einen Ersatz für /etc/hosts einpflegen und damit jedem Container beibringen, dass "portainer.meinedomain.home" eine bestimmte IP hat.
Außerdem gibt es noch Pseudo-Hostnamen wie "host.docker.internal". Den Namen kann man innerhalb von Containern benutzen, um auf die IP-Adresse des Hosts zuzugreifen. Das ist dann die IPv4, die von Docker für's Netzwerk vergeben wurde (fängt wahrscheinlich mit 172.x.x.x an). Siehe https://forums.docker.com/t/how-to-reach-localhost-on-host-from-docker-c ...
In Docker kann man aber - am besten per docker-compose - per "extra_hosts" nebenbei so etwas wie einen Ersatz für /etc/hosts einpflegen und damit jedem Container beibringen, dass "portainer.meinedomain.home" eine bestimmte IP hat.
Außerdem gibt es noch Pseudo-Hostnamen wie "host.docker.internal". Den Namen kann man innerhalb von Containern benutzen, um auf die IP-Adresse des Hosts zuzugreifen. Das ist dann die IPv4, die von Docker für's Netzwerk vergeben wurde (fängt wahrscheinlich mit 172.x.x.x an). Siehe https://forums.docker.com/t/how-to-reach-localhost-on-host-from-docker-c ...
Hi
mit extra_hoist schaue ich mal. Ich habe aktuell einfah nur name verwendet. Ich stellle mir aktuell eine andere Frage bzgl. des dataflows in meinem Testcase.
Zum einen habe ich in opnsense mittels host override einen A record mit nextcloud.meinedomain.home auf die docker ip 172.... erstellt.
Dananch habe ich ein Self-Signed Cert per OPNsense erstellt. mit IP: 172... uri https://nextclouad.meinedomain.home und dns: nextcloud. Richtig?
Dieses Cert habe ich in meine NPM installation als custom cert. eingespeilt. Dann einen Proxy host mit der Domain https://nextclouad.meinedomain.home dem Zertifikat, und weiterleitung auf http, die 172... IP und port 80 erstellt. Muss hier nicht die IP vom docker host und entsprechender Port rein?
Wenn ich jetzt aus dem NPM interface die domain aufrufe bekomme ich den Fehler: ERR_ADDRESS_UNREACHABLE
Wenn ich direkt auf die DOmain gehe gelicher fehler - macht ja sinn.
Die domain nextclouad.meinedomain.home kann ich per nslookup, oder besser nextcloud, korrekt auf die Docker IP auflösen.
Muss der nextcloud a record nicht auf die NPM IP zeigen, damit der Aufruf erst dorthingeleitet wird und von dort die Weitelreitung passieren kann?
Wie muss der worklfow und die Cert.. settings evtl. anders aussehen?
Was mir da gerade aufgefallen ist: Ich kann doch auch direkt auf meiner opnsense den nginx installieren und als proxy nehmen. Den "nginx proxy manager" (meines wisses nur als docker container verfügbar) bräcuhte ich doch dann gar nicht. Eignetlich möchte ich ja nur innerhalb meines LANs adressen statt IPs nutzen und Zertifikate vewenden, dmait die nervigen Browser dinger verschwinden. Wobei ich hier meine ich auch verstanden habe, dass die Warnung durch aus bleiben, da self-signed. Umgehe ich aktuelle indem ich root-ca, intermediate als auch das eigentlich Cert. auf meinen Geräten einspiele.
Hoffe, man kann mich einigermaßen verstehen :D
mit extra_hoist schaue ich mal. Ich habe aktuell einfah nur name verwendet. Ich stellle mir aktuell eine andere Frage bzgl. des dataflows in meinem Testcase.
Zum einen habe ich in opnsense mittels host override einen A record mit nextcloud.meinedomain.home auf die docker ip 172.... erstellt.
Dananch habe ich ein Self-Signed Cert per OPNsense erstellt. mit IP: 172... uri https://nextclouad.meinedomain.home und dns: nextcloud. Richtig?
Dieses Cert habe ich in meine NPM installation als custom cert. eingespeilt. Dann einen Proxy host mit der Domain https://nextclouad.meinedomain.home dem Zertifikat, und weiterleitung auf http, die 172... IP und port 80 erstellt. Muss hier nicht die IP vom docker host und entsprechender Port rein?
Wenn ich jetzt aus dem NPM interface die domain aufrufe bekomme ich den Fehler: ERR_ADDRESS_UNREACHABLE
Wenn ich direkt auf die DOmain gehe gelicher fehler - macht ja sinn.
Die domain nextclouad.meinedomain.home kann ich per nslookup, oder besser nextcloud, korrekt auf die Docker IP auflösen.
Muss der nextcloud a record nicht auf die NPM IP zeigen, damit der Aufruf erst dorthingeleitet wird und von dort die Weitelreitung passieren kann?
Wie muss der worklfow und die Cert.. settings evtl. anders aussehen?
Was mir da gerade aufgefallen ist: Ich kann doch auch direkt auf meiner opnsense den nginx installieren und als proxy nehmen. Den "nginx proxy manager" (meines wisses nur als docker container verfügbar) bräcuhte ich doch dann gar nicht. Eignetlich möchte ich ja nur innerhalb meines LANs adressen statt IPs nutzen und Zertifikate vewenden, dmait die nervigen Browser dinger verschwinden. Wobei ich hier meine ich auch verstanden habe, dass die Warnung durch aus bleiben, da self-signed. Umgehe ich aktuelle indem ich root-ca, intermediate als auch das eigentlich Cert. auf meinen Geräten einspiele.
Hoffe, man kann mich einigermaßen verstehen :D
Kurz abgeschlossen, wenn man es richtig konfiguriert geht auch alles mit dem NPM. Einrichtung war soweit richtig nach der Beschreibung oben, die Firewall (OPNsense und des Ubuntu Servers) sollte man aber beachten
