unbound docker Lösung

[Ghost108]

Guten Morgen!

aktuell habe ich auf meiner Syno pi hole als docker instanz laufen.
Habe hier öfters gelesen, das sich pi hole sehr gut mit unbound kombinieren lässt.

Nach eine Rechere, was Unbound überhaupt ist / macht, war ich Feuer und Flamme, das auch bei mir realisieren zu wollen.
Kann mir dazu jemand eine gute Anleitung empfehlen, die leicht zu verstehe ist.
Möchte mich nicht als Docker Experte bezeichnen

 

[stulpinger]

https://www.youtube.com/watch?v=sglbR68oW4c

 

[Ghost108]

bin etwas verunsichert. habe die Installtion ohne portainer vorgenommen - macvlan habe ich auch bislang nicht im EInsatz.
Ist das zwigend nowendig?

Habe einen Container vom unbound am Laufen, wie folgt:


Woher weiß ich denn, das der Container sauber läuft?
Hat Unbound ein Webinterface o.ä.?

 

[stulpinger]

Hast du das Video angesehen ?
Im pihole wird die IP-Adresse des unbound-Containers unter DNS eingetragen ...
deshalb brauchst Du schon mal macvlan, damit Du einem Container eine IP-Adresse fix zuweisen kannst,

 

[Ghost108]

sorry für den Break, habe ich habe zwischenzeitlich eine andere Lösung gefunden.
PiHole und Unbound in einem Container:
https://github.com/chriscrowe/docker-pihole-unbound/tree/main/one-container

Aber hier brauche ich ebenfalls Hilfe.
Wie soll dieser Container installiert werden?
Entweder finde ich dazu nichts oder ich verstehe es nicht :/

 

[stulpinger]

das mit dem one-container ist für einen Anfänger zu komplex, ist so, sorry

Hab mich auch gegen portainer lange gewehrt, aber ist gerade für einen Neuling empfehlenswert
und ich habe einiges unter docker am laufen ...

Außerdem, wie der Titel des Videos schon sagt, "..... die beste Methode"

 

[Ghost108]

okay, versuche dieses Video aktuel umzusetzen.
Habe auch den Portainer bereits installiert. Was ich allerdings nicht verstehe: warum muss ich ein seperates Netzwerk (macvlan) erstellen?

 

[stulpinger]

Du kannst/solltest pihole bzw. unbound eine IP-Adresse fix zuordnen, um diverse Portkonflikte (zB 53,80,443,...) zu vermeiden, weil:

Im Router (sonst hat das ganze keinen Sinn ) unter DNS gibst Du dann die IP des pihole an, im pihole die IP von unbound

Am besten fängst Du mit pihole alleine an: https://www.youtube.com/watch?v=mARLVbJcsmY
Wenn das funktioniert, dann weiter mit unbound, also eines nach dem anderen

 

[Ghost108]

nachdem ich mich nun den ganzen Tag damit beschäftig habe, habe ich nun soweit pi hole am laufen, unter eigener IP dank macvlan.
Allerdings stelle ich mir nun folgende Frage:

Bislang konnte ich via Synology Reverse Proxy pi hole via https erreichen.
WIe stelle ich das denn nun an? Pihole ist ja nicht mehr über die IP der Syno sondern über die eigene IP erreichbar.

 

[Fusion]

Das Ziel des reverse proxy ändern?

 

[Ghost108]

ja aber worauf? kann pihole lediglich via ip erreichen. der reverse proxy arbeitet nur mit dns namen

 

[Fusion]

Nein, tut er nicht. Außer du redest von einem anderen als den unter Systemsteuerung > Anwendungsportal / Anmeldeportal > reverse proxy.
Der Name und Zertifikat bleibt ja identisch, nur die Ziel IP ändert sich bzw ist nicht mehr localhost oder was du da laufen hattest.

 

[Ghost108]

sorry, habe mich davon irritieren lassen, das bei Ziel Hostname steht. Das dort auch IP geht war mir neu

 

[Ghost108]

Guten Morgen!
Was mir allerdings noch aufgefallen ist.

habe zwei Pi Hole instanzen aktuell laufen.
Meine "alte" und die neue (nach dem neuen Schema mit macvlan usw.).

Wenn ich die alte aufrufe, welche im Hostmodus läuft, ist die Webmaske sofort da.
Wenn ich die neue aufrufe, welche via macvlan und eigener IP erreichbar ist, dauert der Aufruf deutlich länger.

Normal?

 

[Fusion]

Spezifiziere 'deutlich' länger?
Auch Folgeaufrufe gleich lang?
Aufruf per IP?
Neue Browser Session bei jedem Versuch?
Mal die Browser Tools angesehen? F12 oder alt+q oder ähnlich im Firefox, Ctrl+Shift+i in Chrome. Da kann man auch diverse Ladezeiten nachsehen.

Hab leider kein so ein setup aktuell laufen und keine Performance Zahlen dazu.
Kann mir schon vorstellen, dass hier unterschiedlich viele Netzwerk-Stacks / Treiber durchlaufen werden. Aber so tief stecke ich gerade auch nicht in Docker, dass ich die das aus dem Stand erklären könnte.

Vielleicht hat @haydibe da die passende Erklärung aus seinem Erfahrungsschatz.

 

[haydibe]

Ich verwende MACVLAN (schon lange) nicht (mehr). Technisch ist es die Behandlung im Kernel verankert und sollte nicht langsamer sein, als das Natting das Docker bei Containern im Bridge-Mode mittels iptables durchführt. Das MACVLAN Netzwerk tut so, als wenn es eine Switch ist, an dem weitere Geräte mit eigenen IP's hängen. Dein LAN Router bzw. Switch sollte mitbekommen, dass die MAC-Adressen und IPs der MACVLAN Client-Interfaces über das "Switch" über die MAC-Adresse des MACVLAN Host-Interfaces zu erreichen sind.

Sicherheitsmechanismen des Linux-Kernel verhindern, dass MACVLAN Client-Interfaces (und nichts anders bekommen die Container) direkt mit dem MACVLAN Host-Interface kommunizieren können. Das ist keine Einschränkung die durch Docker eingeführt wird. Während es einen entsprechenden Hinweis damals in der Dokumentation gab, ist er mittlerweile entfernt worden - was nicht bedeutet das die Einschränkung nicht mehr gilt. Daher kommt auch der Workaround für den Host ein eigenen MACVLAN Client-Interface zu erzeugen und dem die Routen in das MACVLAN-Container-Subnetz zu spendieren. Dann klappt auch der Zugriff vom Host auf die Container-IP und der Container kann über die IP des zusätzliche MACVLAN Client-Interfaces des Hosts mit dem Host kommunizieren.

 

[Ghost108]

vielen Dank für die Erklärung Bin aber nun verwirrter als vorher
Welche Frage allerdings offen bleibt:

Warum klappt es tadellos auf meiner virtuellen DSM (ohne die Ansätze aus #16) und auf meiner Live Syno nicht?