Docker Container eigene IP im Netzwerk zuweisen und über eigenen DNS lokal über eigene Domain erreichen

[Rumpelwicht23]

Hallo! Bin neu hier, aber ich finde nicht so richtig eine Antwort auf meine Frage, oder ich bin schon mal drüber gestolpert, aber habe sie nicht verstanden.
Ich habe es mittlerweile geschafft suf meinem raspberry (ich glaube 4) über docker eine Instanz von evcc (https://docs.evcc.io/docs/installation/docker) und eine Instanz der Teddycloud (https://tonies-wiki.revvox.de/docs/tools/teddycloud/) zum laufen zu bekommen. Beide sind über die ip des raspi unter ihren jeweiligen Ports zu finden.
Jetzt möchte ich gerne einen DNS auf dem pi laufen lassen, über den die beiden Container eine eigene ip bekommen und denen eine eigene Domain zuordnen. (Für evcc Auto.laden oder so) ich brauche keine Anleitung wie ich das mache, sondern bevor ich meine Zeit in die Recherche und das ausprobieren stecke erstmal eine Aussage, ob das überhaupt möglich ist.
Die Domain Auto.laden soll erstmal nur über das heimnetz (oder über VPN) und nicht öffentlich aus dem Internet erreichbar sein. Ist das möglich?
P.S.: meine erste Idee ist das mit einem bind9

 

[blurrrr]

Also ich hab jetzt mehrfach angesetzt und wieder gelöscht... Ich fasse mich daher einfach mal kurz

Jetzt möchte ich gerne einen DNS auf dem pi laufen lassen, über den die beiden Container eine eigene ip bekommen und denen eine eigene Domain zuordnen.

Ja, das sollte funktionieren.

Frage ist eher, was Du unter "DNS" verstehst. Ein reiner Nameserver wird Dir erstmal nicht viel nutzen, wenn dieser von niemandem befragt wird. Auf der anderen Seite kann ein reiner Nameserver keine Antworten zu Zonen liefern, welcher er selbst nicht kennt. Das wäre dann der Resolver-Part. Die Resolver hangeln sich durch (je nach Config) und besorgen die Antwort, die Nameserver haben die Antworten (je nachdem, für welche Zonen sie zuständig sind).

Heisst also: Einfach nur einen Nameserver hingesetzt, bedeutet für die Clients:

1) Sie fragen weiterhin ihren üblichen DNS, der weiss aber nix vom Nameserver (conditional forwarding)
2) Sie fragen den Nameserver, der kennt aber nur seinen Kram, somit funktioniert die gesamte restliche DNS-Auflösung nicht mehr

In Kurzfassung: Entweder hast Du EIN System, was "beide" Aufgaben übernimmt (Resolver+Nameserver), oder Du hast 2 Instanzen (Resolver+Nameserver), oder Du hast einfach nur einen Resolver (der seinen Cache manipuliert) und jubelst diesem einfach Deine beiden gewünschten Einträge zu (oder mehr) und alle fragen diesen Resolver, welcher dann die entsprechenden Antworten liefert (sofern er sie denn kennt bzw. sofern sie denn im Cache hinterlegt).

Vielleicht schaust Du Dir einfach mal piHole an, das geht flott von der Hand und braucht eigentlich auch keine Extrawürstchen... Ist zwar alles etwas aufgeblasen, dafür aber auch mit Webinterface und Zeugs, hier mal eine docker-compose.yml:

version: "3"

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
    environment:
      TZ: 'Europe/Berlin'
      WEBPASSWORD: 'meinsupersicherespassword12345'
    # Volumes store your data between container upgrades
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
    restart: unless-stopped

Kannste Dir ja mal anschauen... Zum testen, musst Du auch nicht direkt alles verbiegen, sondern kannst unter Angabe eines zu befragenden Resolvers auch direkt auf Deiner lokalen Eingabeaufforderung/Shell testen, z.B. via:

nslookup <Ziel-FQDN> <Resolver>

Würde dann z.B. für Google so aussehen: nslookup test.de 8.8.8.8. Bei Dir lokal wäre es dann sowas wie nslookup host.auto.laden <IP Resolver>, oder wie auch immer Du das gestalten magst. Via VPN müsstest Du dann halt noch den entsprechenden internen Resolver an den Client zuweisen.

Mit dem bind9 geht sowas natürlich auch, ist aber schon eine "etwas" anderes Hausnummer. Gibt auch noch andere Produkte, allerdings wird meist strikt zwischen Resolver und Nameserver getrennt, was dann direkt 2 Instanzen bedingungen würde.

Wünsche vorab schon mal viel Erfolg und viel Spass beim basteln!

EDIT: Achso, für so "Kleinzeugs" kann man auch die hosts-Datei am Client manipulieren. Ist dann aber mit Mobilgeräten (Smartphones/Tablets) dann eher nicht so drin (meines Wissens nach).

 

[Rumpelwicht23]

Vielen Dank für die ausführliche Antwort. Da sind direkt einige Punkte an denen ich ansetzen kann, um tiefer in die Materie einzusteigen.
Pihole gucke ich mir mal an, und nach einem kurzen Einstieg und deiner Erklärung denke ich ein resolver reicht für meine Zwecke.
Falls es wen interessiert kann ich später ja mal berichten, was draus geworden ist.

 

[blurrrr]

Mach das, gern

Hab grade nochmal geschaut, dachte immer, dass unbound direkt dabei wäre... Falls nicht: https://docs.pi-hole.net/guides/dns/unbound/ bzw. einfach mal hier schauen https://github.com/chriscrowe/docker-pihole-unbound, da gibt es eine Variante wo alles in einem Container läuft, oder halt getrennt (2 Container).

 

[Confluencer]

Wenn deine Services über HTTP-Erreichbar sind, dann kann man das auch über einen Reverse-Proxy abbügeln, bspw. mit Traefik. Dann noch den Pihole dazu, der dann die DNS-Einträge mit allen Domains auf die IP vom Docker-Host zeigen lässt, sodass Traefik dann anhand seiner Regen den Trafik für die Domains an den entsprechenden Container weiterreicht. Man könnte sogar einfach eine Wildcard Entry auf den Docker-Host zeigen lassen, sodass man nicht für jede Subdomain DNS-Einträge basteln muss, sondern selbst bei neuen Containern nur die entsprechende Regel in Traefik anlegen muss. Das ist ziemlich charmant.

Update: ich hätte mal den ersten link auf machen sollen. Ignorier meinen Post. Traefik löst das Problem in dem Scenario nicht.

 

[Rumpelwicht23]

nachdem ich mich jetzt mit macvlan und der ganzen Netzwerkthematik von docker auseinandergesetzt habe, haben die Container schon mal ihr eigene IP. Nebenbei hab ich rausgefunden, dass bei der fritzbox netzwergeräte unter NAME.fritz.Box erreichbar sind.
Für dieses Wochenende reicht das erstmal. Aber das rabbit(pi)hole werde ich noch erforschen ;-)

Edit: Den letztendlich erhellenden Moment hat mir übrigens diese Videoreihe gebracht [moderativ entfernt], s.u.

 

[Nival]

Hey @Rumpelwicht23, YT-Links sehen wir hier nicht so gerne (Ausnahme, direkt von den Herstellern), die verschwinden dann ggf. auch wieder und ganz besonders, wenn der erhellende Moment für Dich darin zu finden war, ist das ausgesprochen ärgerlich, wenn es später nicht mehr auffindbar ist. Ich habe ihn mal aus Deinem Post rauseditiert, aber es wäre absolut prima, wenn Du kurz beschreiben würdest, was genau daran der springende Punkt für Dich war

Wenn Dich weitere Gründe interessieren, weshalb wir YT-Links nicht so arg schätzen, @LittleWing hat es vorhin in einem anderen Thread noch erläutert: https://forum.heimnetz.de/threads/z...istant-einbauen-und-auslesen.4164/#post-43572