11.02.2024, aktualisiert um 06:50:47 Uhr

2802

Mikrotik - Container pi-hole im VLAN-Kontext "stand-alone" betreiben (dedizierte IP)

Hallo,

bisher nutzte ich pi-hole auf einem docker-server und damit mit dedizierter IP im Netz. Als Router kommt ein Mikrotik RB 3011 zum Einsatz, den ich jüngst von 6.x auf 7.14 gehoben habe und damit Container nutzen kann, u.a. für pi-hole. Ergänzt sei, dass mein Netz in 5 VLANs aufgeteilt ist (192.168.10.0 - 192.168.50.0)

Mit etwas Kampf (weil die Tutorials alle ohne VLANs arbeiten) war ich heute erfolgreich, pi-hole auf dem MT im Container zum laufen zu bringen. Wie in der MT-Anleitung mit einer in Bezug auf meine IP-Bereiche "wilden" IP 172.19.21.2 für VETH_pihole und /bridge/port auf die "vlan-bridge" (die aus der Anleitung von aqui). Dafür waren in der FW entsprechende input und forward regeln für port 53 nötig. So weit, so gut.

Aber: Da alle DNS-Anfragen über /ip dns set servers=172.19.21.2 kommen, gibt es in pi-hole quasi nur 1 client.

Ich sehe zwei Optionen:

Kann man die original-IP "irgendwie" an pi-hole durchreichen?
Wenn man den Container (ggf. mit einer eigenen bridge?) quasi stand-alone arbeiten lässt abseits der vlan-bride und (per NAT?) pi-hole eine dedizierte IP (z.B. 192.168.10.99) zuweisen würde, könnte man die IP als DNS-Server der clients nutzen anstatt die IP des MT. Dann sähe pi-hole auch wieder alle client-IPs. Das habe ich per DST-NAT versucht - leider erfolglos.

Ich vermute, Lösung zwei wäre's. Aber wie geht das richtig, den Container mit einer eigenen IP erreichbar zu machen?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 52726482073

Url: https://administrator.de/forum/mikrotik-container-pi-hole-im-vlan-kontext-stand-alone-betreiben-dedizierte-ip-52726482073.html

Ausgedruckt am: 21.12.2024 um 17:12 Uhr

30 Kommentare

Neuester Kommentar

Kann man die original-IP "irgendwie" an pi-hole durchreichen?

Joa, indem man es so macht wie es eigentlich vorgesehen ist, auf die Idee die IP des Phiole als DNS-Server per DHCP an die Clients zu verteilen bist du nicht gekommen? 🙃 So macht man das ja in der Regel ... Probleme wo es keine gibt 🤪

/ip dhcp-server network set [find address=192.168.10.0/24] dns-server=172.19.21.2
# usw.

Am pihole nicht vergessen die VLAN Subnetze für Anfragen freizuschalten (source: any)
Und natürlich am Mikrotik in der Firewall in der Forward-Chain die Kommunikation der Clients mit dem Pihole-Subnet zulassen, fertig ist die Soße.

/ip firewall filter add chain=forward src-address=192.168.0.0/18 dst-address=172.19.21.2 action=accept

☠️

Dank Dir, @11078840001
Natürlich habe ich das versucht, liegt ja auf der Hand ;) Aber dafür müsste 172.19.21.2 aus meinen VLANs erreichbar sein, aber nur im MT wird die IP erkannt und kann nur dort im DNS verwenden werden.

Daher war ja die Frage, wie ich die 172.19.21.2 (die ist ja auch laut Tutorials nur für interne Zwecke konzeptionel für container im MT nötig) in der FW auf eine 192.168.10.xx übersetzen kann. IP-Hole wäre dann darüber erreichbar und kann dann natürlich auch als DNS-Server im DHCP eingetragen werden.

Vielleicht denke ich zu kompliziert und versuche nachher mal Deinen forward. Wäre prima, wenn es so einfach wäre

Aber selbst wenn das geht: Wie könnte man denn einem Container mit einer "internen" IP 172.19.21.2 autark/losgelöst von der vlan-bridge betreiben nach außen eine feste IP z.B. 192.168.10.99 geben? Es wäre auch für andere Dienste spannend, die keinen Kontakt zu den VLANS haben sollen und losgelöst verfügbar sein sollen (Szenario z.B: einen simplen Web-Server, der per reverse proxy exponiert werden könnte)

Zitat von @natuerlich:

Dank Dir, @11078840001
Natürlich habe ich das versucht, liegt ja auf der Hand ;) Aber dafür müsste 172.19.21.2 aus meinen VLANs erreichbar sein, aber nur im MT wird die IP erkannt und kann nur dort im DNS verwenden werden.

Quatsch mit Soße, das ist ein Router und was machen Router ? 😉Genau, "routen" und das Netz ist ihm ja bereits bekannt.
Clients fragen das Default-GW nach dem Netz und dein Mikrotik kennt es ergo kann man es auch erreichen, sofern FW technisch nicht abgeschottet wurde.
Und wie gesagt am Pihole muss der Zugriff aus fremden Subnetzen erlaubt werden damit der Pihole die VLANs nicht blockiert!

Daher war ja die Frage, wie ich die 172.19.21.2 (die ist ja auch laut Tutorials nur für interne Zwecke konzeptionel für container im MT nötig) in der FW auf eine 192.168.10.xx übersetzen kann. IP-Hole wäre dann darüber erreichbar und kann dann natürlich auch als DNS-Server im DHCP eingetragen werden.

Nein. Das veth Subnetz ist global für den Router und die Clients sichtbar sofern der Mikrotik auch Default GW für die Clients ist, sofern du es auch in der Firewall zulässt.

Vielleicht denke ich zu kompliziert

Jepp, du hast da offensichtlich noch einen Knoten 😉.

Aber selbst wenn das geht: Wie könnte man denn einem Container mit einer "internen" IP 172.19.21.2 autark/losgelöst von der vlan-bridge betreiben nach außen eine feste IP z.B. 192.168.10.99 geben?

Das separate Subnetz schaffst du ja bereits mit dem veth.

/interface veth add address=172.19.21.2/24 gateway=172.19.21.1 name=veth_pihole

Das muss mitnichten Teil der Bridge sein damit es erreichbar ist denn es reicht ja das der Router es kennt, ergo routet er auch dorthin! Und natürlich kannst du auch am WAN Ports dorthin forwarden wie mir jeder anderen IP auf dem Mikrotik.

Ach ja noch als Ergänzung. Wenn du das veth Interface zur LAN Interface-Liste hinzufügst dann brauchst du bei der Default-Firewall-Config auch keine weitere Firewall Regel denn dann ist die Forward Chain bereits offen für die VLANs.

Und wenn man will kann man sich auch ein separates VLAN für die Container erstellen und in die Bridge mappen, dann lässt sich das auch an nachstehende Switches tagged übertragen falls man woanders noch weitere Container oder devices hat die in das VLAN rein sollen.

# container vlan interface erstellen
/interface vlan add name=container vlan-id=99
# ip dem interface zuweisen
/ip address add interface=container address=172.19.21.1/24
# veth interface für den container anlegen
/interface veth add address=172.19.21.2/24 gateway=172.19.21.1 name=veth_pihole
# den Port in die bridge auf die PVID des container vlans mappen
/interface bridge port add interface=veth_pihole bridge=bridge_local pvid=99
# und das container vlan auf die bridge taggen
/interface bridge vlan add vlan-ids=99 tagged=bridge_local

Wenns das nun war bitte Wie kann ich einen Beitrag als gelöst markieren?

Das wir sehr hilfreich und hat wunderbar funktioniert. Lieben Dank, @11078840001!

Ich war tatsächlich zu kompliziert... und wie so oft, waren es nur Kleinigkeiten, die fehlten, ich hatte es_fast_ so gemacht, Dein freundlicher Tritt in den Hintern war lehrreich.

Container geht nach Update auf 7.16.x nicht mehr. Weder pihole, noch mosquitto.

Nach dem Update starten beide Container scheinbar normal, aber irgendwie isoliert:

Das Webfrontend von pihole ist nicht mehr erreichbar, und der Container hat kein DSN Outbound.
Ich sehe Pakete in FW und DSTNAT, aber überhaupt nicht in SRCNAT.
Die Shell ist erreichbar und z.B. "pihole -d" sieht ok aus, bis auf fehlendes DNS (wie im LOG bereits beim start).

Ähnlich bei mosquitto: Läuft, aber MQTT Explorer kann nicht connecten. Alles andere funktioniert (VLAN, USB-Drive, CAPsMAN,...)

Zurück auf "stable" 7.15.3 laufen beide Container wie bisher und seit Monaten völlig problemlos

Irgendwelche Ideen, was sich in >= 7.16.x geändert haben könnte (Bridges, VLAN, DNS, Container,..), dass dieses Verhalten der Container erklären könnte?
Habe schon Stunden experimentiert und mir gehen die Ideen aus. Nach was sollte ich schauen?

Danke für jeden Hinweis, um endlich mit funktionierenden Containern auf 7.16 zu gehen - nicht zuletzt für das nette mDSN-feature...

Moin.

Container geht nach Update auf 7.16.x nicht mehr. Weder pihole, noch mosquitto.

Kann ich nicht bestätigen. Sowohl Mosquitto als auch ein pihole laufen nach Upgrade auf 7.16 vor Wochen und auf 7.16.1 einwandfrei in ihren VLANs!

Welche Hardware?
Connectivity via Container-Shell und ip a und Ping auf relevante IPs gecheckt?
Export der Mikrotik Config und Ausgabe der NIC Config im Container wären hilfreich fürs Debugging.
Ansonsten hilft bei Container-Problemen das Neuanlegen des Containers in den meisten fällen. Konfiguration hat man ja meist eh in separaten Mounts abgelegt so daß das Neuanlegen fix erledigt ist.

Gruß catrell.

Danke catrell,
ist ein MT RB3011.

Da ich man mittlerweile nicht mehr einfach zurück auf stable 7.15.3 kann, weil stable mittlerweile 7.16.x ist, scheue ich mich noch, es wieder zu versuchen, bis ich eine Idee habe, wonach ich dann schauen soll. Weil meine Familie in der Zeit mit betroffen ist.. mieser WAF und DAF (wife and daughters :D)
Werde es am WE dann wohl wieder versuchen, deine Tipps prüfen und Config exportieren. Da es bei Dir funktioniert, ist es wohl machbar und schafft Zuversicht. Bin allerdings kein Experte und kämpfe durchaus mit den Tiefen eines MT. Und beim letzten Versuch habe ich nach langen Nacht mit probieren und ohne Schlaf aufgegeben.

Container neuanlegen ist ein guter Gedanke, allerdings hat es nichts gebracht, das hatte ich bereits versucht.

hab das gleiche Problem wie natuerlich.

Der Container läuft auf einem RB5009/USB-Disk
Die Stable Version 7.16.1 ist drauf.
Hab die Config mit und ohne VLAN ausprobiert.
Die IP 172.17.0.2 für PiHole ist von allen Devices , egal wo aus dem Netzwerk pingbar, nur das WebGui läuft nicht.
NAT und Firewall-Regeln sind eingestellt, im LogFile gibt es keine Fails, alles ist successfully started....

Werde am WE mal den Container neu anlegen...
danke für den Tipp

Grüße
Marco

nur das WebGui läuft nicht.

Mal per Konsole in den Container verbinden und während des versuchten Zugriffs auf die GUI die Logs kontrollieren, checken ob der GUI Prozess überhaupt läuft und aus dem Container Testweise auch mal raus pingen

/container shell [find hostname="pihole"]

Ansonsten auch mal mit dem Sniffer des Mikrotik kontrollieren ob der Webzugriff überhaupt zum Container durchkommt, wenn ja, wird es eher ein Berechtigungsproblem im Container sein, die gibt es gerne mal nach Upgrades, und dann hilft immer das Neuerstellen des Containers.

NIC Config im Container wären hilfreich fürs Debugging.

Wie mache ich das? "ip a" ist ok, aber ist weiteres damit gemeint?

Zitat von @natuerlich:

NIC Config im Container wären hilfreich fürs Debugging.

Wie mache ich das? "ip a" ist ok, aber ist weiteres damit gemeint?

Jepp, und evt. noch ein ip route

ok, upgrade auf 7.16.1 "stable". Alles läuft, theoretisch auch die Container mosquitto und pihole (Status: "running"), aber faktisch sind sie nicht nutzbar.

Vergleich von export vorher<-> nachher zeigt fast keine Unterschiede. Auffällig ist nur der hinzugefügte "Type=A" für alle static DNS einträge. Und ein neu hinzugefügtes "/ip ipsec profile". Der Rest ist gleich. Aber dennoch funktioniert etwas nicht mehr, wie vorher.
"ip a" sieht unverändert aus

root@zeus:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 42:ba:24:ba:49:c1 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.19.21.2/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::40ba:24ff:feba:49c1/64 scope link 
       valid_lft forever preferred_lft forever

"ip route" ebenfalls

root@zeus:/# ip route
default via 172.19.21.1 dev eth0 
172.19.21.0/24 dev eth0 proto kernel scope link src 172.19.21.2

* "ping heise.de" aus der Container-Shell hat vor dem upgrade funktioniert, nicht mehr nach dem upgrade
* pihole -d sieht auch gut aus, bis auf alle externen pings, es gibt offenbar ein DNS oder routing problem für den Container. Explizit wird das Web-Frontend als "running" erwähnt.

*** [ DIAGNOSING ]: Operating system
[i] Pi-hole Docker Container: 2024.07.0
[i] Distro: Debian
[i] Version: 11
[   ] dig return code: 10
[   ] dig response: dig: couldn't get address for 'ns1.pi-hole.net': failure  
[   ] Error: dig command failed - Unable to check OS
     [...]
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[   ] mgtimesdispatch.112.2o7.net is 0.0.0.0 on lo (127.0.0.1)
[   ] mgtimesdispatch.112.2o7.net is 0.0.0.0 on eth0 (172.19.21.2)
[   ] Failed to resolve doubleclick.com via a remote, public DNS server (8.8.8.8)
    [...]
*** [ DIAGNOSING ]: Dashboard headers
[   ] Web interface X-Header: X-Pi-hole: The Pi-hole Web interface is working!

pihole -d ist auffällig unterschiedlich hier

vorher (container läuft bereits eine Weile)

*** [ DIAGNOSING ]: contents of /var/log/lighttpd

-rw-r--r-- 1 www-data www-data 69 Nov 16 14:47 /var/log/lighttpd/error-pihole.log
   -----head of error-pihole.log------
   2024-11-16 15:46:56: server.c.1513) server started (lighttpd/1.4.59)

   -----tail of error-pihole.log------
   2024-11-16 15:46:56: server.c.1513) server started (lighttpd/1.4.59)

nachher deutlich mehr meldungen, obwohl gerade erst gestartet

*** [ DIAGNOSING ]: contents of /var/log/lighttpd

-rw-r--r-- 1 www-data www-data 1.2K Nov 16 20:24 /var/log/lighttpd/error-pihole.log
   -----head of error-pihole.log------
   2024-11-16 15:46:56: server.c.1513) server started (lighttpd/1.4.59)
   2024-11-16 20:29:47: server.c.1976) server stopped by UID = 65534 PID = 0
   2024-11-16 20:31:21: server.c.1513) server started (lighttpd/1.4.59)
   2024-11-16 20:33:22: server.c.1513) server started (lighttpd/1.4.59)
   2024-11-16 20:34:30: server.c.1513) server started (lighttpd/1.4.59)
   2024-11-16 20:34:51: server.c.1513) server started (lighttpd/1.4.59)
   2024-11-16 20:35:12: server.c.1513) server started (lighttpd/1.4.59)
   2024-11-16 20:35:32: server.c.1513) server started (lighttpd/1.4.59)
[...einige mehr...]

Container wurde gelöscht und neu angelegt (habe mir ein Script für die Upgrades geschrieben, der den Container immer wegwirft)
Web_page "http://192.168.10.1:9000/admin/index.php" nicht mehr erreichbar, vor Upgrade problemlos
Interface:

add address=172.19.21.2/24 gateway=172.19.21.1 gateway6="" name=VETH_pihole

add action=masquerade chain=srcnat comment=\
    "Container pi-hole - ACCESS to WWW" src-address=172.19.21.0/24  
add action=dst-nat chain=dstnat comment=\
    "Container pihole - ACCESS via MT-IP (http for pihole Web-page)" \  
    dst-address=192.168.10.1 dst-port=9000 log-prefix="NAT piHole: " \  
    protocol=tcp to-addresses=172.19.21.2 to-ports=80

Container

add comment=pihole envlist=pihole_envs interface=VETH_pihole logging=yes \
    mounts=pihole_etc,pihole_dnsmasq root-dir=usb1/containers/pihole

Fazit Wo muss ich suchen? Container? Interfaces->VETH? Routing? DNS?
Habe bei all' dem nichts geändert, aber dennoch kann pihole nicht mehr ins WWW wie vor dem upgrade und die Web-Page ist nicht erreichbar.

ping heise.de" aus der Container-Shell hat vor dem upgrade funktioniert, nicht mehr nach dem upgrade

Was sagt denn ein Ping auf eine nackte IP wie 1.1.1.1 aus dem Container? Läuft der auch nicht? Wenn doch hat der Container selbst ein DNS Problem.
Wieso überhaupt noch ein pihole, der Mikrotik DNS hat inzwischen ein adlist feature an Bord was das gleiche resourcensparender erledigt.

leider erfolglos. Der Container hat - ausschließlich durch das Upgarde auf 7.16 - ein DNS-Problem... und habe keine Idee, wie ich das einkreisen kann.

root@zeus:/# ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9388ms

root@zeus:/# ping 172.19.21.1
PING 172.19.21.1 (172.19.21.1) 56(84) bytes of data.
^C
--- 172.19.21.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1061ms

root@zeus:/# ping 172.19.21.2
PING 172.19.21.2 (172.19.21.2) 56(84) bytes of data.
64 bytes from 172.19.21.2: icmp_seq=1 ttl=64 time=0.109 ms
64 bytes from 172.19.21.2: icmp_seq=2 ttl=64 time=0.163 ms
^C
--- 172.19.21.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1055ms
rtt min/avg/max/mdev = 0.109/0.136/0.163/0.027 ms
root@zeus:/# ping zeus       
PING zeus (172.19.21.2) 56(84) bytes of data.
64 bytes from zeus (172.19.21.2): icmp_seq=1 ttl=64 time=0.107 ms
64 bytes from zeus (172.19.21.2): icmp_seq=2 ttl=64 time=0.106 ms
^C

Wieso überhaupt noch ein pihole, der Mikrotik DNS hat inzwischen ein adlist feature an Bord was das gleiche resourcensparender erledigt.

Hattest Du nicht geschrieben, dass Du auch einen pi-Hole am laufen hast im Container ;)

Spaß beiseite. Ich mag das grundsätzliche (DNS) Problem nach dem Upgrade lösen, weil ich ein paar weitere Container habe. Ganz zentral für meine Infrastruktur ist MQTT. Danach werde ich mir die Alternative gerne anschauen. pihole hat halt den Vorteil der kuratierten und regelmäßig aktualisierten Sperrlisten.
Meine Avahi werde ich definitiv durch mDNS ersetzen - wieder ein Container weniger

Zitat von @natuerlich:

leider erfolglos. Der Container hat - ausschließlich durch das Upgarde auf 7.16 - ein DNS-Problem... und habe keine Idee, wie ich das einkreisen kann.

Das ist kein DNS Problem. Wenn noch nicht mal das Gateway auf Pings antwortet steht die grundlegende IP Kommunikation schon nicht.
Also als erstes mal die Firewall auf Durchzug stellen.

Eine cleane CHR VM mit pihole auf Router OS 7.16.1 läuft hier absolut problemlos, es muss also an deiner Konfiguration liegen die hier immer noch niemand vorliegen hat. Ein Export ist doch jetzt ehrlich gesagt nicht so schwer oder? Auf Rumgerate und Glaskugel polieren haben wir hier nämlich eher weniger Lust.

Hattest Du nicht geschrieben, dass Du auch einen pi-Hole am laufen hast im Container ;)

Virtuell im CHR Testlab immer auf Abruf und in ner Minute aufgesetzt 😉

Lieben Danke erstmal für Deine Hilfe!

Es bleibt unverständlich für mich...wie kann dass mit dem Upgrade zusammen hängen? Bis 7.15.3 hat es ja mit den selben FW settings funktioniert. Für die IP des Containers 172.19.21.0/24 mache ich gerne mal alles auf, aber verstehen tu' ich es Null, wie das mit dem Upgrade zusammen hängen kann...

Nun es können schon Fehlkonfigurationen vorhanden sein die sich halt erst jetzt bemerkbar machen. In den letzten Updates wurden da einige Bereinigungen vorgenommen die solche Fehler nun nicht mehr verzeihen .
Wie leider so oft können wir hier ohne was schwarz auf weiß von dir vorliegen zu haben nur raten, das ist mühsam und eines Admin-Forums nicht würdig 🫤.

Guts nächtle.

Was fehlt als Info? ich gebe zu, ich habe Bedenken, meine ganze Konfig zu posten - vielleicht steckt da was drin, was ich besser nicht veröffentliche... ich bin da eher konservativ. Lieber die Ausschnitte, die nötig und sinnvoll sind. Aber natürlich verstehe ich Deine Kritik. Ich habe zwar für einen nicht-Admin Einzelkämpfer eine vermutlich recht beeindruckende Infrastruktur für ein Eigenheim hier aufgebaut, aber aus Admin-sicht bin ich sicher kaum mehr als "interessierter Laie" und dankbar für den Rat von Experten. Gerne möchte ich angemessen liefern, wenn es denn "ungefährlich" ist. Was ist sinnvoll, was fehlt?

UPDATE: Du hast mich an die richtigen Stellen geschubst. Es geht. Es war eine Kombination von Adress List und Bridge Port. In der FW war nicht die Ursache, aber dennoch auch Unschärfen zu den Containern. Für pihole zu eng, für MQTT zu locker (nicht gut für Smarthome, wenn das Gastnetz da drauf kann - auch wenn MQTT via TLS/PW gesichert ein unnötiger Angriffsvektor). Daher: Richtiger Schubs.

Verstehe noch immer nicht, wie das durch das Upgrade beeinflusst war. Ich denke, es ist etwas im Bridging gewesen, da hat sich ja diverses getan. FW scheint mir kaum im Verhalten verändert mit 7.16.x. Egal. Läuft

Danke!!!

Die IP 172.17.0.2 für PiHole ist von allen Devices , egal wo aus dem Netzwerk pingbar, nur das WebGui läuft nicht.
NAT und Firewall-Regeln sind eingestellt, im LogFile gibt es keine Fails, alles ist successfully started....

Liefert in der Container Shell "pihole -d" auch eine Erfolgsmeldung?

*** [ DIAGNOSING ]: Dashboard headers
[   ] Web interface X-Header: X-Pi-hole: The Pi-hole Web interface is working!

Aus meiner Sicht sind dann drei FW Regeln für das Frontend nötig:

NAT (DSTNAT)

add action=dst-nat chain=dstnat dst-address=<IP des MT> dst-port=9000 protocol=tcp to-addresses=172.19.21.2 to-ports=80

NAT (SRCNAT)

add action=masquerade chain=srcnat src-address=172.17.0.0/24

add action=accept chain=forward dst-address=172.17.0.0/24 dst-port=80,9000 protocol=tcp src-address=<IP des MT.0>/24

Mit TORCH solltest Du zum Interface=Container (wenn Du nach der Mikrotik-Anleitung vorgegangen bist) entsprechende TCP-Sätze vom PC/Laptop zum Container (Port 80) sehen.

Liefert in der Container Shell "pihole -d" auch eine Erfolgsmeldung?

Ja.

Aus meiner Sicht sind dann drei FW Regeln für das Frontend nötig:

Diese Regeln sind komplett überflüssig wenn man nur LAN intern auf das Webinterface zugreifen möchte. Wer will das schon vom WAN aus tun??

Mit TORCH solltest Du zum Interface=Container (wenn Du nach der Mikrotik-Anleitung vorgegangen bist) entsprechende TCP-Sätze vom PC/Laptop zum Container (Port 80) sehen.

Eine Anleitung brauche ich dafür ehrlich gesagt nicht.
Zu und von Containern lässt sich ganz normal auf die 172.17.0.0/24 routen und mit der Firewall entsprechend der Traffic einschränken, wieso sollte ich da also noch mal überflussigerweise NAT ins Spiel bringen?! Überflüssiger overhead und nur vom Tutorial kopiert ohne darüber nachzudenken wozu diese dienen, denn diese sind eigentlich nur "optional" für den Zugriff vom WAN. Aber selbst da reicht eine einzige DSTNAT Regel denn ins WAN wird ja von Haus aus schon jede interne IP gesourceNATet. Dann noch simple Firewall Forward-Regeln zum Container um den Traffic zu beschränken. Ein zusätzliches Masquerade aus dem Containernetz raus ist da nur überflüssiger Overhead, und kostet den Router mehr CPU Power als eine Forward-Rule in der FW, da er jedes Paket anpacken und verändern muss.

Was lernt man daraus: Nicht alles blind aus Tutorials übernehmen sondern darüber nachdenken wozu diese genutzt werden, denn das sind nur mögliche Rezepte die aber nicht immer optimal für jeden Zweck sind.

Aber nun denn, wenn es für dich läuft, Glückwunsch, sich selbst helfen und debuggen ist imho immer noch die beste Methode wenn man mit Mikrotiks hantiert 👍

Schönen Sonntag.

Gruß catrell

Hallo catrell,
das war ein völliges Missverständnis! Meine zweite Nachricht heute Nacht war in keiner Weise für Dich, sondern Marco, der weiter oben mal gefragt hatte, warum bei ihm pihole funktioniert, aber er keinen Zugriff auf sein webFrontend bekommt. Von ihm war das Zitat, auf das ich mich bezog...

Dennoch danke für Deine Rückmeldung. Und ja, sicher ist etwas dran, dass ich mich sehr an Anleitungen halte und das nicht immer bis ins letzte klug ist. Ich bin sicher kein Profi darin, weil ich "nur soho" bin. Ich werde darüber nochmal nachdenken und vielleicht durch testen Deine Ausführungen besser verstehen und zu ähnlichen Schlüssen kommen.

Nochmal ein herzliches Danke für Deine Unterstützung!
Auch Dir einen schönen Sonntag

Meine zweite Nachricht heute Nacht war in keiner Weise für Dich, sondern Marco

Oh sorry, my fault, hatte das Zitat übersehen.

Hallo natuerlich, hallo catrell….
Mein lieber Scholli, da habt ihr ja ganz schön was rausgehauen….
Danke für deine Note

Mein WE ist aktuell voll bis an die Ohren……
Nächste Woche finde ich Zeit, Eure Posts zu lesen und zu versuchen zu verstehen…. Ähnlich wie natuerlich, schreibe ich mir auch den interessierten Laien auf die Stirn.
Mirkotik ist so „umfangreich und anders“ gegenüber AVM als Beispiel.
Der Einstieg ist dann recht holprig und nur durch Unterstützer wie Ihr es seid, möglich.

Danke an Euch !

Wenn bei mir das Pihole läuft, würde ich Euch kurz uppen….

Grüße Marco

Ansonsten hilft bei Container-Problemen das Neuanlegen des Containers in den meisten fällen. Konfiguration hat man ja meist eh in separaten Mounts abgelegt so daß das Neuanlegen fix erledigt ist.

Das hattest Du, catrell, anfangs geschrieben. Vielleicht kann ich auch eine Inspiration zurück geben. Denn ich habe mir ein Scripte dafür gemacht, die das auf Knopfdruck machen. Bei mir per scheduler 1x pro Woche, aber bei Bedarf jederzeit ausführbar. Damit hat man immer aktuelle Container und eben auch jederzeit neu angelegte.

Kern-Script

# Script for frequent container update
# 
# inspired by: https://forum.mikrotik.com/viewtopic.php?t=203375#p1048454
# changed:
# - seperated scripts into several PARAM per Container and one central CORE-logic 
# - added paramter for RegistryURL - as container may come from different source, not only docker (e.g. github)
# - added root-Dir
# - added check for "container exists?" > with this check it works even without an existing one > usefull as initial install-Script as well now  
# - added LOG
# ###########################

# global variables set in container-specific scripts

:global containerConfigRegistryURL
:global containerToUpdate
:global containerNetwatch
:global containerRootDir
:global containerVeth
:global containerImage
:global containerEnvlist
:global containerMounts
:global containerLogging
:global containerStartOnBoot
:global containerCmd

# ######

/ log info "[UPDATE SCRIPT] $containerToUpdate INTO $containerRootDir FROM $containerConfigRegistryURL | $containerImage MOUNT $containerMounts ENV $containerEnvlist VETH $containerVeth LOG $containerLogging STARTonBOOT $containerStartOnBoot | CMD: $containerCmd"  

/container/set [find where comment~$containerToUpdate] logging=yes

# set RegistryURL
/container/config/set registry-url=$containerConfigRegistryURL tmpdir=usb1/pull

# if Container exists: STOP + REMOVE | if not: Skip and go on with PULL container + START
:if ([/container/print count-only where comment~$containerToUpdate] > 0) do={

  # DISABLE NETWATCH
  /tool/netwatch/disable [find name~$containerNetwatch]

  # Stop Container 
  /container/stop [find where comment~$containerToUpdate]

  # Wait for container(s) to stop 
  :while ( [/container print count-only where comment~$containerToUpdate status=stopping] > 0) do={ :delay 1 }

  # Remove old Container(s)
  /container/remove [find where comment~$containerToUpdate]

  # short delay 
  :delay 3

}

# create new container
/container/add interface=$containerVeth remote-image=$containerImage mounts=$containerMounts envlist=$containerEnvlist start-on-boot=$containerStartOnBoot logging=yes comment=$containerToUpdate root-dir=$containerRootDir cmd=$containerCmd
:delay 1

# Wait for new container to be ready
:while ( [/container print count-only where comment~$containerToUpdate status=extracting] > 0 ) do { :delay 1 }

# Start the new container
/container/start [find where comment~$containerToUpdate]

# short delay 
:delay 5

# set LOGGING
/container/set [find where comment~$containerToUpdate] logging=$containerLogging

# ENABLE NETWATCH
/tool/netwatch/enable [find name~$containerNetwatch]

Container-spezifisch (exemplarisch pihole)

:global containerConfigRegistryURL
:set $containerConfigRegistryURL "https://registry-1.docker.io"  

:global containerToUpdate
:set $containerToUpdate "pihole"  

# For pihole we need "check pihole running" constanly! Hence, "web" should be disabled only 
:global containerNetwatch
:set $containerNetwatch "pihole Web"  

:global containerRootDir
set $containerRootDir "usb1/containers/pihole"  

:global containerVeth
:set $containerVeth "VETH_pihole"  

:global containerImage
:set $containerImage "pihole/pihole:latest"  

:global containerEnvlist
:set $containerEnvlist "pihole_envs"  

:global containerMounts
:set $containerMounts "pihole_dnsmasq,pihole_etc"  

:global containerLogging
:set $containerLogging "yes"  

:global containerStartOnBoot
:set $containerStartOnBoot "yes"  

:global containerCmd
:set $containerCmd ""  

# #######

/system script run Container_Update_CORE

Container-spezifisch (exemplarisch mosquitto)

:global containerConfigRegistryURL
:set $containerConfigRegistryURL "https://registry-1.docker.io"  

:global containerToUpdate
:set $containerToUpdate "MQTT"  

:global containerNetwatch
:set $containerNetwatch "MQTT"  

:global containerRootDir
set $containerRootDir "usb1/containers/MQTT_mosquitto"  

:global containerVeth
:set $containerVeth "VETH_MQTT_mosquitto"  

:global containerImage
:set $containerImage "library/eclipse-mosquitto:latest"  

:global containerEnvlist
:set $containerEnvlist ""  

:global containerMounts
:set $containerMounts "MQTT_mosquitto_config,SSL"  

:global containerLogging
:set $containerLogging "no"  

:global containerStartOnBoot
:set $containerStartOnBoot "yes"  

:global containerCmd
:set $containerCmd ""  

# #######

/system script run Container_Update_CORE

Dazu noch Netwatch, damit es für alle Clients weiter geht, wenn pihole mal down ist
UP

/ip dns set servers=172.19.21.2,9.9.9.9

# Set DNS-Server for all clients via DHCP-Servers (comma-seperated)
/ip dhcp-server network set [find gateway=192.168.10.1] dns-server=172.19.21.2
/ip dhcp-server network set [find gateway=192.168.20.1] dns-server=172.19.21.2
/ip dhcp-server network set [find gateway=192.168.30.1] dns-server=172.19.21.2
/ip dhcp-server network set [find gateway=192.168.80.1] dns-server=172.19.21.2
/ip dhcp-server network set [find gateway=192.168.100.1] dns-server=172.19.21.2

# remove all dynamic leases to force all clients to fetch new DNS-Setting
/ip dhcp-server lease remove [find dynamic server=dhcp-010-int]
/ip dhcp-server lease remove [find dynamic server=dhcp-020-haus]
/ip dhcp-server lease remove [find dynamic server=dhcp-030-media]
/ip dhcp-server lease remove [find dynamic server=dhcp-080-iot]
/ip dhcp-server lease remove [find dynamic server=dhcp-100-gast]

DOWN

/ip dns set servers=9.9.9.9

# Set DNS-Server for all clients via DHCP-Servers
/ip dhcp-server network set [find gateway=192.168.10.1] dns-server=192.168.10.1
/ip dhcp-server network set [find gateway=192.168.20.1] dns-server=192.168.20.1
/ip dhcp-server network set [find gateway=192.168.30.1] dns-server=192.168.30.1
/ip dhcp-server network set [find gateway=192.168.80.1] dns-server=192.168.80.1
/ip dhcp-server network set [find gateway=192.168.100.1] dns-server=192.168.100.1

# remove all dynamic leases to force all clients to fetch new DNS-Setting
/ip dhcp-server lease remove [find dynamic server=dhcp-010-int]
/ip dhcp-server lease remove [find dynamic server=dhcp-020-haus]
/ip dhcp-server lease remove [find dynamic server=dhcp-030-media]
/ip dhcp-server lease remove [find dynamic server=dhcp-080-iot]
/ip dhcp-server lease remove [find dynamic server=dhcp-100-gast]

/tool/e-mail/send to=mikrotik@<deineDomain> subject="Container pi-hole SERVICE down" body="Solution: Container to be stopped and re-started via RESTART-Script"  

Guten Morgen,

Container Shell? pihole -d ?
Ok... google sei dank.

Liefert in der Container Shell "pihole -d" auch eine Erfolgsmeldung?

nein, bei mir ist keine Erfolgsmeldung zu sehen.
Hab da eh mehrere Fehler, wenn ich mich das so angucke.

Gateway did not respond..random blocked domain...alles "noch" böhmische Dörfer für mich..
aber kein Grund zum Aufgeben.

Hier ein Auszug aus dem Log:

*** [ DIAGNOSING ]: Network interfaces and addresses
   1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defau
lt qlen 1000
       link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
       inet 127.0.0.1/8 scope host lo
          valid_lft forever preferred_lft forever
       inet6 ::1/128 scope host 
          valid_lft forever preferred_lft forever
   2: eth0@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
 group default qlen 1000
       link/ether 26:bd:13:81:e7:c2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
       inet 172.17.0.2/24 scope global eth0
          valid_lft forever preferred_lft forever
       inet6 fe80::24bd:13ff:fe81:e7c2/64 scope link 
          valid_lft forever preferred_lft forever

*** [ DIAGNOSING ]: Network routing table
   default via 172.17.0.1 dev eth0 
   172.17.0.0/24 dev eth0 proto kernel scope link src 172.17.0.2 

*** [ DIAGNOSING ]: Networking
[   ] IPv4 address(es) bound to the eth0 interface:
    172.17.0.2/24

[   ] IPv6 address(es) bound to the eth0 interface:
    fe80::24bd:13ff:fe81:e7c2/64

[i] Default IPv4 gateway(s):
     172.17.0.1
   * Pinging first gateway 172.17.0.1...
[   ] Gateway did not respond. (https://discourse.pi-hole.net/t/why-is-a-default-g
ateway-important-for-pi-hole/3546)

[i] Default IPv6 gateway(s):

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a kno
wn ad-serving domain
[   ] Failed to resolve glamourgrove.quest on lo (127.0.0.1)
[   ] Failed to resolve glamourgrove.quest on eth0 (172.17.0.2)
[   ] doubleclick.com is 142.250.185.78 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a kno
wn ad-serving domain
[   ] Failed to resolve www.pd.topprogit.xyz on lo (::1)
[   ] Failed to resolve www.pd.topprogit.xyz on eth0 (fe80::24bd:13ff:fe81:e7c2)
[   ] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860
:4860::8888)

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   Timeout: 10 seconds
   DHCP packets received on interface eth0: 0

*** [ DIAGNOSING ]: Pi-hole processes
[   ] lighttpd daemon is inactive
[   ] pihole-FTL daemon is inactive

*** [ DIAGNOSING ]: Pi-hole-FTL full status
[i] systemctl:  command not found

*** [ DIAGNOSING ]: Lighttpd configuration test
[   ] No error in lighttpd configuration

*** [ DIAGNOSING ]: Setup variables
    PIHOLE_INTERFACE=eth0
    IPV4_ADDRESS=0.0.0.0
    IPV6_ADDRESS=0:0:0:0:0:0
    PIHOLE_DNS_1=8.8.8.8
    QUERY_LOGGING=true
    INSTALL_WEB_SERVER=true
    INSTALL_WEB_INTERFACE=true
    LIGHTTPD_ENABLED=true
    PIHOLE_DNS_2=
    CACHE_SIZE=10000
    DNS_FQDN_REQUIRED=true
    DNS_BOGUS_PRIV=true
    DNSMASQ_LISTENING=local
    BLOCKING_ENABLED=true

*** [ DIAGNOSING ]: Dashboard headers
[   ] Web interface X-Header: X-Header does not match or could not be retrieved.


*** [ DIAGNOSING ]: Pi-hole FTL Query Database
-rw-rw-r-- 1 pihole pihole 0 Nov 17 20:17 /etc/pihole/pihole-FTL.db

*** [ DIAGNOSING ]: Gravity Database
-rw-rw-r-- 1 pihole pihole 9.5M Nov 17 21:15 /etc/pihole/gravity.db

*** [ DIAGNOSING ]: Info table
   property              value                                   
   --------------------  ----------------------------------------
   version               15                                      
   updated               1731876826                              
   gravity_count         165493                                  
   Last gravity run finished at: Sun Nov 17 20:53:46 UTC 2024

Warum PiHole keine IPv4 hat und wo die 8.8.8.8 her kommt ... keine Ahnung.

Sooo.. das für heute Vormittag... die Woche werde ich mich abends dran setzen...
Sobald ich was finde feedbacke ich.

Grüße
Marco

Da stimmt schon das IP Setup bzw. Firewall auf dem Mikrotik nicht wenn der Container sein Gateway überhaupt nicht erreichen kann. ICMP in der Input-Chain und freigeschaltete Forward-Chain für den Container ist für den Test also mindestens erforderlich.
Hier musst du also als erstes ansetzen. Wahrscheinlich also entweder Bridge- oder Firewall Config-Fehler. Mangels vorliegender Config auch hier leider wieder Glaskugel-Bowling ala Bonheur.
Leute ihr fragt hier doch nach Hilfe, nicht wir 🙃.

Warum PiHole keine IPv4 hat

Die hat er doch.

und wo die 8.8.8.8

Kommt entweder von deinem DNS-Setup für den Container oder dem pihole und dessen Forwardern selbst.

moin moin,
gestern Abend habe ich den Container neu aufgesetzt, die
Mounts gesetzt (usb1).
Container startet und es wurde das erste mal

*** [ DIAGNOSING ]: Dashboard headers[ ] Web interface X-Header: X-Pi-hole: The Pi-hole Web interface is working!

angezeigt.
Die Performance von dem Pihole GUI war allerdings sowas von grottenlangsam...puhh..
Ich hatte PiHole schon mal auf einem Container auf deiner DS718+ mit 16GB RAM laufen.
Das war deutlich flotter.
Gut, auf Settings für die DNS-Einstellungen bin ich nicht gekommen, das drehende Symbol im Browser-Tab war alles, was angezeigt wurde.

catrell: Was muss alles an Config gepostet werden, damit Du einen besseren Überblick bekommst?

LogFile vom Pihole und Export vom Router?

gelöst Frage Router, Routing

Mehr von natuerlich

2x Traefik kaskadiert: RevProxy im DMZ + LAN (Docker) mit subdomains im LAN?natuerlich

Docker auf tagged-Server - je Container flexibel VLAN wählennatuerlich - 7 Kommentare

VLAN-Sicherheit: tagged avahi-Server ein Risiko?natuerlich - 10 Kommentare

Heiß diskutiert