Das war nun auch mein letzter Ausweg raus aus der Misere. Ich bin schon beim Lesen über den verlinkten Thread gestolpert, und wollte es wenn wirklich gar nichts mehr geht auch umsetzen
..was auch der Hauptgrund für meine Frustration bei diesem Setup ist.
Nun zum Eingemachten:
Das habe ich dann gestern Nacht noch in der Tat versucht, nachdem ich dein Post noch gelesen habe.
Ich bin dabei genau wie in deinem Post hier vorgegangen:
Weitere Einstellungen die ich habe:
Der DNS Resolver im Browser (FF) ist ausgeschaltet. Ich bin über WLAN mit dem Heimnetz verbunden.
Ergebnis: Wenn ich DNSv6 und DHCP_v6 vollends ausschalte, funktioniert bei mir aber gar nichts mehr. Sprich, meine aufgerufenen Websiten werden nicht mehr aufgelöst. Mein Network Manager zeigt mir wie erwartet auch nicht mehr den primären IPv6-Namensserver des Routers an; der Eintrag verschwindet. Kurioserweise funktioniert auf dem Handy aber noch der Chat wie z.b. bei Whatsapp, Netflix auf dem TV(mit LAN Kabel verbunden) funktioniert ebenfalls, selbst nachdem ich dann den Raspi komplett stromlos gemacht habe und vom Netz genommen habe!!
Hier habe ich noch ein paar prompts:
auf dem Raspi:
$ doas ss -tulpn sport = 53
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=3601,fd=4))
udp UNCONN 0 0 *:53 *:* users:(("pihole-FTL",pid=3601,fd=6))
tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=3601,fd=5))
tcp LISTEN 0 32 [::]:53 [::]:* users:(("pihole-FTL",pid=3601,fd=7))
auf dem PC:
$ nslookup pi-hole.net
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
;; no servers could be reached
$ host pi-hole.net
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
;; no servers could be reached
$ dig pi-hole.net
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
;; communications error to 192.168.178.88#53: timed out
; <<>> DiG 9.18.24-1-Debian <<>> pi-hole.net
;; global options: +cmd
;; no servers could be reached
$ dig google.com @8.8.8.8 +short
142.250.186.78
$ nslookup api.branch.io
Server: 192.168.178.88
Address: 192.168.178.88#53
Name: api.branch.io
Address: 0.0.0.0
Name: api.branch.io
Address: ::
Gerade der letzte Befehl beweist, das er ja immer noch blockieren tut, nur fehlt mir jetzt der Zugang zum Internet...An dieser Stelle könnte ich noch versuchen entweder a. noch weiter in der FB herumspielen oder b. vielleicht mal versuchen den pihole als DHCP Server einzustellen. Ich weiss aber im Moment nicht wo ich in der FB ein Haken zuviel ist oder zu wenig habe...von daher bewege ich mich immer noch im Kreis.
.
.
.
.
Ja das war schon extrem seltsam, du meinst sicherlich das hier:
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
Scanning all your interfaces for DHCP servers
Timeout: 10 seconds
Error: Could not send DHCPDISCOVER to 255.255.255.255@eth0: Operation not permitted
Error: Could not send DHCPDISCOVER to 255.255.255.255@cw-5vh13968e5w4: Operation not permitted
Error: Could not send DHCPDISCOVER to 255.255.255.255@docker0: Operation not permitted
In dem Zusammenhang habe ich auf meinem PC ein weiteres bisher noch ungeklärtes Verhalten meines Routers beobacht, wo der Router fortlaufend ein mutlicast Signal verschickt (broadcastet). Ein Blick auf die Firewall Logs bestätigt mir, dass es nur im Heimnetz passiert. Das war nicht immer so, vielleicht ein Bug seitdem letzten FritzOS Update. Auch wenn das jetzt OT ist, vielleicht könnte es den DHCP Rundruf in den richtigen Kontext setzen? In dem Fall wäre es ja ein Router Problem und kein Docker-spezifisches Problem.
Das stimmt, es ist tatsächlich wie du beschrieben hast ein Community Package, das an und für sich sehr gut implementiert ist. Insgesamt ist ja Alpine auch ein sehr niches Projekt, weshalb ich da jetzt auch ernsthaft drüber nachdenke zurück zu einem gewöhnlichen Raspi OS zu wechseln. Die verlinkten Blogartikel zum Umgang von musl mit DNS hat mir das auch nochmal vor Augen geführt. Ich nutze natürlich kein Kubernetes und brauch es auch nicht. Es zeigt aber dass gerade in diesem Bereich des Internets und der Linux Entwicklung sehr viel Bewegung herrscht und damit gestern noch funktionierende Workarounds mit den neuesten Updates schon wieder überholt sind. Das ist sehr ernüchternd. Das Fazit aus dem Ganzen hier ist schließlich auch der dass die Kombination aus Dual Stack LITE, FritzBox, musl libraries und Docker Networking nicht sehr gut miteinander harmoniert! (und schon etliche Stunden Troubleshooting dabei drauf gegangen sind.) Deswegen tendiere ich bei der Frage...
..eher zu einem verhaltenen Nein, weil ich Docker nur in der alpinen Umgebung laufen habe und ich wenn ip4_only nicht vernünfitig zum Laufen bekomm, ein komplett neues Setup mit RaspiOS ohne Docker re-installieren werde. Wenn ich etwas mehr von Netzwerktechnik und ihre Fallstricke (v.a.m.B.a. ipv6) verstehen würde, könnte ich das sogar mal als side project angehen, aber im Moment fehlt mir die Geduld und Zeit dafür. Ich bin gerade nur darauf fokussiert eine stabile Pi-Hole Instanz aufzustellen..egal mit welchem Setup. Ich hoffe du hast dafür Verständnis.