29
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:
Ich vermute, Lösung zwei wäre's. Aber wie geht das richtig, den Container mit einer eigenen IP erreichbar zu machen?
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?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 52726482073
Url: https://administrator.de/contentid/52726482073
Ausgedruckt am: 18.11.2024 um 23:11 Uhr
29 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☠️
2
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)
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.
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_piholeDas 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.
1
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.
1
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.
Wenns das nun war bitte Wie kann ich einen Beitrag als gelöst markieren?
# 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_localWenns 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.
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:
Ä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...
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.
Gruß catrell.
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 aund 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.
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
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"] 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.
* "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.
nachher deutlich mehr meldungen, obwohl gerade erst gestartet
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.
- 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* 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
*** [ 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)*** [ 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 - NAT
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/piholeFazit 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
^CWieso ü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.
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...
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.
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!!!
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....
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!- 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- FW
add action=accept chain=forward dst-address=172.17.0.0/24 dst-port=80,9000 protocol=tcp src-address=<IP des MT.0>/24Liefert 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
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
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: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_COREDazu 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]/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.
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:
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
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 2024Warum 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 🙃.
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.1
