Vermutlich, weil die LAN-Geräte entweder IPv6 bevorzugen, oder weil derzeit DNS-Auflösung bei Dir nur IPv6 geht (und zwar über die unbotmäßig auftauchende FB).
Dann dürften wir daran auch erst einmal nichts ändern, bis klar ist, warum DNS-Anfragen nicht zu Deinem Pi-hole durchdringen.
Trag also erst einmal Deine FB als lokalen IPv4-DNS ein, stell IPv6 auf ULA-Adressen immer zuweisen um, und dann versuchen wir, die Verbindungsprobleme von Deinem PC aus zu lösen.
Ich bin bei dem Punkt "Fritzbox -> Internet -> Zugangsdaten -> DNS Server" immer noch verwirrt.
Muss ich hier eine IP eintragen? z.B. die häufig erwähnte 1.1.1.1, oder muss hier die IP vom PiHole rein?
Eigentlich hatte ich mich ja für die Variante entschieden dass die FB die DNS IP an die TEilnehmer broadcastet, ich also bei den Zugangsdaten nichts eintragen muss, richtig?
Ich nehme mal an, dass Du die IPv4-Adresse Deines Pi-holes auch von Deinem PC erreichst.
Demnach würde Port 53 irgendwo auf der Strecke zwischen PC und Pi-hole geblockt werden. Hast Du die Ports von Deinem NAS an den Container durchgeschleift?
Das sind die Upstream-DNS-Server Deiner FB, an die die FB selbst DNS-Anfragen stellt oder weiterleitet.
Die können zunächst auf ISP-Vorgabe bleiben.
Pi-hole solltest Du von Deiner FB als lokalen DNS über DHCP verteilen lassen.
EDIT: Sobald die Probleme beseitigt sind, natürlich.
C:\Users\NUC>psping 10.0.0.123:53
PsPing v2.10 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2016 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP connect to 10.0.0.123:53:
5 iterations (warmup 1) ping test:
Connecting to 10.0.0.123:53 (warmup): from 10.0.0.11:55996: 2.88ms
Connecting to 10.0.0.123:53: from 10.0.0.11:55999: 3.34ms
Connecting to 10.0.0.123:53: from 10.0.0.11:56018: 0.67ms
Connecting to 10.0.0.123:53: from 10.0.0.11:56021: 0.57ms
Connecting to 10.0.0.123:53: from 10.0.0.11:56023: 0.49ms
TCP connect statistics for 10.0.0.123:53:
Sent = 4, Received = 4, Lost = 0 (0% loss),
Minimum = 0.49ms, Maximum = 3.34ms, Average = 1.27ms
Das haben wir über den zweiten nslookup an die Pi-hole-IPv4 schon getan: Dein PC hat die DNS-Anfrage abgeschickt, aber Pi-hole hat diese nicht erhalten.
Ein funktionierender Ping hat die grundsätzliich bestehende Netzwerkverbindung bestätigt. Also blockiert irgendetwas auf der Strecke die Kommunikation für den DNS-Port.
Lade bitte mal ein Debug Token von Deinem Pi-hole hoch:
Es gibt ein paar Ungereimtheiten in Deinem Debug Log.
Zunächst einmal:
*** [ DIAGNOSING ]: Processor
[i] x86_64
Läuft Dein Synology-NAS auf Intel-Hardware?
Welches Synology-Modell verwendest Du?
Und die Netzwerkintegration war offensichtlich nicht erfolgreich:
*** [ DIAGNOSING ]: Networking
[✗] No IPv4 address(es) found on the eth0 interface.
[✗] No IPv6 address(es) found on the eth0 interface.
[i] Default IPv4 gateway: 10.0.0.1
[✗] Gateway did not respond.
[i] Default IPv6 gateway: fe80::3681:c4ff:feb7:2fed
[✗] Gateway did not respond.
Und warum steht unter Network bei manchen Clients dass sie PiHole nicht nutzen?
Ich habe die FritzBox komplett neu gestartet und alle WLAN Access Points sodass jetzt alle LAN und WLAN Clients den neuen DNS bekommen haben müssten.
Diese Punkte hängen in der Tat zusammen:
Pointer Resource Records (PTR) erlauben im DNS die reverse Zuordnung von Hostnamen zu IP-Adressen nachzuschlagen (statt wie normal IP-Adressen zu Hostnamen), wofür aus der Rückwärts-IP-Adresse ein eindeutiger synthetischer Domänenname abgeleitet wird, der für IPv4 auf in-addr.arpa und für IPv6 auf ip6.arpa endet.
Ohne diesen Reverse-Lookup findet Pi-hole keine Hostnamen zu den Client-IP-Adressen.
Normalerweise macht eine Weiterleitung dieser Anfragen für lokale private IP-Adressen keinen Sinn, da ein öffentlicher DNS-Server Dein privates Heimnetz überhaupt niemals kennen kann.
Aber Du hast folgendes eingestellt:
Damit gehen DNS-Anfragen von Pi-hole an die FritzBox - und die kennt sehr wohl die Namen Deiner lokalen Geräte.
Solange die FB also Dein Upstream-DNS für Pi-hole bleibt, kannst Du den Haken bei Never forward reverse lookups for private IP ranges herausnehmen.
Wenn Du Pi-hole auf andere Upstream-DNS-Server umstellst, kannst Du für die lokale reverse Namensauflösung Conditonal Forwarding verwenden.
Japp, hatte ich vor derm Neustart wieder angehakt.
Haken war auch schon vor dem Neustarten der ganzen Hardware raus.
In den Recent Queries tauchen manche Geräte mit ihrer IPv6 Adresse auf, und andere mit ihrer abcxyz.fritz.box, aber keines mit seinem Namen den ich in der FritzBox hinterlegt habe.
Ich habe mal
DNS - Use Conditional Forwarding = aktiviert
und als IP die IP der FB eingetragen.
Aber was muss ich als Local domain name eintragen?
Bin ich da auf dem richtigen Weg?
Manchmal tauchen Geräte Adressen (z.B. nuc.fritz.box) als Domain Namen auf.
ALso wenn die CLienten untereinander quatschen?
Nein, CF und FB als Upstream sind effektiv gleichwertig (undfritz.boxwäre der Name, den jede FB -leider unveränderlich- für die lokale Domäne vergibt).
Genaugenommen ist FB als Upstream sogar die bessere Wahl, weil auch IPv6 mit abgehandelt wird. CF in Pihole v4 behandelt derzeit nur IPv4, für IPv6 muss man bei Bedarf noch weitere manuelle Konfigurationen vornehmen.
Globale IPv6-Adressen (aus dem Adressbereich 2000::/3) bleiben allerdings problematisch.
Ein Lösungsansatz bestünde hier vielleicht darin, client-seitig die Präferenz für die Verwendung bestimmter IPv6-Präfixe anzupassen, siehe meine Anmerkung in PTR einer ULA wird an Upstream DNS weitergeleitet obwohl Conditional Forwarding aktiv - #19 by Bucking_Horn. Selbst ausprobiert habe ich letzteres jedoch noch nicht - ich habe IPv6 abgeschaltet.
Ok, Danke nochmal für deine vielen ausführlichen Antworten !
Hier habe ich nachgesehen. Den PiHole als DHCP einzurichten kommt für mich nicht infrage.
Ich bin es einfach gewohnt alle IP und Port Geschichten mit der FritzBox einzurichten und komme hier auch ganz gut zurecht. (Bis auf die DNS Geschichte halt)
Bleibt noch die Möglichkeit die hosts Datei anzupassen.
Wie ich das auf der Synology mache, muss ich noch recherchieren.
IPv6 nutze ich nicht wissentlich, werde ich aber vermutlich aktiviert lassen müssen da ich nächsten Monate einen GlasfaserAnschluss bekomme der wohl IPv6 und IPv4 nutzt.
Hier ist die Informationspolitik von Deutsche Glasfaser sehr dürftig.
Oder kann ich in einer solchen Situation IPv6 auf der Internetleitung aktiviert lassen, aber intern immer mit IPv4 arbeiten? Das wäre mein Favorit.
Google wirft hierzu ein Schlagwort NAT64 auf.
Wenn ich noch weitere Fragen habe, macht es Sinn dass wir das hier besprechen oder soll ich einen neuen Thread auf machen?
Neues Problem, neues Topic - so haben auch andere Leser was davon, wenn sie im Forum nach Lösungen für ihre Problemstellung suchen.
NAT64 ist eigentlich für den Verbindungsaufbau zu Nur-IPv4-Servern aus Nur-IPv6-Netzen gedacht und kommt vorwiegend auf ISP-Seite zum Einsatz, Nach meinem Kenntnisstand unterstützen FBen die zugehörigen RFC6052 und RFC6146 derzeit nicht.
Beim momentanen Verbereitungsstand von IPv6 verlierst Du (noch) keine Internet-Funktionalität, wenn Du auf IPv6 verzichtest (solange Du nicht igendeinen Dienst nutzt, der heute schon ausschließlich über IPv6 erreichbar ist). Es kann allerdings sein, dass bestimmte Dienste über IPv4 oder IPv6 schneller oder besser zu erreichen sind. Das hängt letztlich aber von der Entscheidung des jeweiligen Diensteanbieters ab, nicht vom Protokoll an sich.
Die Entscheidung, ob Du IPv6 einschaltest oder nicht, ist damit letztlich Deine persönliche. Es ist aber auch nur ein Haken in der FB, um das ab- und bei Bedarf wieder anzuschalten.
