ich betreibe einen Pi-Hole mit Unbound auf Ubuntu 18.04.4 LTS. Alles funktioniert soweit ganz gut, bis auf eine Sache.
Grundsätzlich erstmal:
Man hat ja in der FritzBox zwei Möglichkeiten den DNS-Server zu ändern:
Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> IPv4-Adressen und IPv6-Adressen
Gilt für alle Geräte im Heimnetz. Egal ob LAN oder WLAN.
Internet -> Zugangsdaten -> DNS-Server
Gilt auch zusätzlich für Geräte im Gastnetz. Egal ob LAN sowie WLAN.
Hier gleich die Frage ob es die Einstellung vom Heimnetz überflüssig macht? Sprich, wann muss ich bei beiden Punkten die IP des Pi-Holes setzen?
Ich möchte das der Pi-Hole die Clients einzeln auflöst bzw. anzeigt. Daher muss ich unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen -> IPv4-Adressen und IPv6-Adressen jeweils die IP des Pi-Holes eingeben. Das funktioniert auch wunderbar, bis auf eine Sache!
Ich betreibe unter subdomain.domain.de ein eigene Nextcloud Server. Diese Subdomain zeigt per CNAME Eintrag beim Hoster auf subdomain.dynv6.net, damit der DNS-Eintrag auch eine wechselnde IP mitbekommt. Der Dyn-DNS Dienst ist in der FritzBox eingetragen und funktioniert ohne Probleme.
Aktuell ist es so das ich subdomain.dynv6.net in der FritzBox unter den Ausnahmen für DNS-Rebind-Schutz eingetragen habe. Tue ich das nicht, fallen alle Browser in Panik und Nextcloud ist nicht erreichbar, weil als DNS-Name subdomain.dynv6.net im Zertifikat und NICHT subdomain.domain.de angezeigt wird. Ich habe schon alle möglichen Einträge in den Ausnahmen vom Rebind Schutz eingetragen, inklusive Neustart der FritzBox. Leider ohne Erfolg.
subdomain.domain.de = öffentliche Domain von Nextcloud subdomain.dynv6.net = DynDNS Adresse für den CNAME Eintrag beim Hoster
(das sind natürlich nur Beispiele!)
Frage: Warum kommt die FritzBox nicht klar damit? Welchen Eintrag muss man in den Ausnahmen für DNS-Rebind-Schutz eintragen? Entweder ist dies ein Bug bei AVM, oder ich verstehe hier etwas nicht.
Nein, nicht in Deinem Fall - es sei denn, Du möchtest doch noch auf individuelle Zuordnung Deiner DNS-Clients verzichten. (klicken für Details)
Der Einsatz von Pi-hole als Upstream-DNS Deines Routers ist eine valide Konfiguration, d.h. Dein Netz wird ordnungsgemäß gefiltert.
Allerdings ist es dann Dein Router, der die Anfragen an Pi-hole stellt. Eine indivduelle Zuordnung ist dann nicht mehr möglich. Auch Conditional Forwarding bringt in diesem Fall nichts, da die DNS-Anfragen tatsächlich nur von der Router-IP kommen.
Es ist also richtig, dass Du Pi-hole via DHCP an Deine Clients im Heimnetz verteilst, wodurch diese nicht mehr Deinen Router, sondern direkt Pi-hole für DNS befragen.
Deine FB erlaubt nun neben dem Heimnetz auch den Betrieb eines Gastnetzes (fest eingestellt auf 192.168.179.0/24). Dieses ist strikt von Deinem FB-Heimnetz (normalerweise 192.168.178.0/24) getrennt, d.h. die Clients dort benutzen nach wie vor und unveränderbar die FB (unter 192.178.179.1) als DNS-Server.
Die einzige Möglichkeit, das Gastnetz ebenfalls zu filtern, ist also die Angabe von Pi-hole als Upstream-DNS der FB. Eine individuelle Zuordnung von Anfragen zu Clients im Gastnetz ist damit wiederum nicht möglich.
Steht dieser in Deinem Heimnetz, oder betreibst Du den in außerhalb auf einem Cloudserver?
Es ist mir nicht klar, ob und mit welchen Parametern die Definition von Rebindschutz-Ausnahmen bei Dir zum Erfolg führt oder nicht.
Der Rebindschutz der FB ist dazu da, eine DNS-Antwort eines öffentlichen Upstream-Servers Deiner FB zu unterdrücken, wenn diese Antwort eine IP-Adresse in Deinem lokalen Netzwerk enthält - ein öffentlicher DNS-Server kann niemals Wissen über private IP-Adressen in Heimnetzen haben.
In diesem Falle würde also eine Verbindung zum Zielserver überhaupt nicht erst aufgebaut werden. Es könnte in einem solchen Fall also gar nicht zu Zertifikatsfehlern kommen.
An der Aushandlung von HTTPS-Zertifikaten ist DNS ebenfalls nicht beteiligt; die Namensauflösung für den Zielserver erfolgt bereits zuvor.
Eventuell fehlt Dir nur ein entsprechender Host-Record für subdomain.domain.de in Pi-hole, natürlich vorausgesetzt, dass Du ein passendes gültiges Zertifikat für den HTTPS-Zugriff besitzt.
Es funktioniert überhaupt nicht, weil ich nicht wirklich weiß was die FritzBox hier von mir möchte. Ich kann im Rebind Schutz eintragen was ich möchte, bisher hatte ich keinen Erfolg.
pihole
pihole.fritz.box
subdomain.domain.de
subdomain.dynv6.net
?
Hier ließt man auch von IP-Adressen, die man hier rein schreiben soll, was aus meiner Sicht nicht richtig ist.
Die Frage ist warum mir die FritzBox ihr eigenes Zertifikat ausliefert, obwohl auf meiner subdomain.domain.de das eigene Zertifikat läuft was auch natürlich das passende Common-Name hat.
Das Problem tritt ja auch nur innerhalb des eigenes Heimetzes auf. Sobald ich z.B. ins Gastnetz gehe, ist das Problem weg.
Was der Rebindschutz macht, habe ich bereits erklärt, und auch, dass dieser an Deinem Fehlerbild eines fehlenden HTTPS-Zertifikats nicht beteiligt ist.
Die FB sollte hier überhaupt nicht beteiligt sein.
Funktioniert denn der Zugriff von einem externen Client?
Die HTTPS-Verschlüsselung wird zwischen dem Client (nach Deiner Beschreibung also einem Rechner in Deinem lokalen Netz) und Deinem Nextcloud-Server ausgehandelt.
Da Pi-hole nur an dem vorgeschalteten DNS, nicht aber an diesem Vorgang selbst beteiligt ist, würde es Sinn machen, für diese Frage auch weitere Quellen hinzuzuziehen, z.B. die Dokumentation oder Support-Foren Deines Zertifikateanbieters.
Das Zertifikat ist doch hier nicht das Problem. Es funktioniert ja, wie schon erwähnt alles, außer wenn man im Heimnetz ist und auf die URL subdomain.domain.de zugreifen möchte. Geht man z.B. ins Gastnetz geht es, und über das Internet sowieso.
Was der Rebind Schutz macht - oder machen soll - weiß ich ja selbst, und dieser kommt hier auch zum tragen.
Wenn Sie die DNS-Auflösung für Domain-Namen, die auf private IP-Adressen im FRITZ!Box-Heimnetz verweisen, ermöglichen möchten, dann können Sie Ausnahmen eintragen. Damit werden DNS-Anfragen für Domain-Namen, die in der Liste der Ausnahmen enthalten sind, auch dann beantwortet, wenn die DNS-Antwort auf eine IP-Adresse im FRITZ!Box-Heimnetz verweist.
Meine Frage lautet also weiterhin was hier eingetragen werden soll. Alles was ich bisher probiert habe, hat nicht funktioniert. Aus meiner Sicht muss da eigentlich nur die URL vom DYN-DNS rein. Ob der CNAME Eintrag mit rein muss, da bin ich mir nicht sicher. Es funktioniert aber nicht, wenn auch beide Einträge oder jeweils nur einer drin ist. Auch den internen DNS-Namen des Servers habe ich versucht ...
Ist denn niemand hier unterwegs der eine Subdomain über einen Dyn-DNS Eintrag per CNAME Eintrag beim Hoster ins eigene Heimnetz leitet?
traceroute oder ping auf subdomain.domain.de löst genau so auf wie es sein soll. IPv4 wie IPv6. Hier sehe ich keine Fehler.
Auch ein dig subdomain.doman.de@127.0.0.1 -p 5335 löst den DNS Namen so auf wie es eben sein soll. Hier sehe ich auch keine Probleme.
Entweder es ist ein Bug in der FritzBox, oder ich peile nicht welchen DNS Namen ich da eintragen soll, oder es hat etwas mit einem fehlenden Eintrag im Pi-Hole unter "Local DNS Records" zu tun.
Tut mir leid, ich hatte Dich so verstanden, dass es beim Zugriff auf Deinen Nextcloudserver im Heimnetz vom Heimnetz zu einem Problem mit dem Zertifikat kommt.
?
Wie ich bereits schrieb kommt es zum Fehler wenn ich im eigenen Heimnetz bin. Und nur dann!
Wenn ich subdomain . domain . de aufrufe bekomme ich im Browser einen Fehler weil dort plötzlich die subdomain . dynv6 . net im Zertifikat aufgelöst werden möchte. Das muss ja von der FritzBox kommen, weil das Nextcloud Zertifikat auf dem Server ja nur auf subdomain . domain . de match, was ja gewollt ist.
Der Nextcloud Server ist ja wie folgt zu erreichen:
192.168.1.xx = interne IP
nextcloud.fritz.box = interner DNS Name
subdomain . domain . de = öffentlicher DNS Name
Das Zertifikat match nur auf subdomain . domain . de. Die anderen beiden Aufrufe liefern einen Fehler beim Namen im Zertifikat - was ja auch richtig ist!. Man kann halt mit "Risiko, akzeptieren .." im Browser die Seite dennoch zumindest laden.
Was aber nicht geht ist der Aufruf auf subdomain . domain . de - Your connection is not secure HTTP Strict Transport Security (HSTS). Die Nextcloud App auf dem iPhone und die Desktop App für Windows verweigern ebenfalls den Dienst mit Fehlern, weil eben die Subdomain nicht aufgerufen werden kann. Dies ist aber NUR im eigenen Heimnetz der Fall. Wechsle ich z.B. ins Gastnetz, funktioniert es, was mir sagt, das es ein FritzBox Problem sein muss.
Jetzt verstanden? Es ist nicht schlimm wenn du keine Lösung hast, alles gut. Ich gehe von einem Bug in der FritzBox aus.
(Texte werden wie eingefügt angezeigt, wenn Du sie markierst und über die Menüoption </>Preformatted text formatierst. Das ist praktisch für Bildschirmausgaben von Kommandos und Logs oder auch, um Auto-Links für (nicht existente) Beispieldomänen zu unterbinden.)
Dann hab ich Dich doch richtig verstanden.
Ich versuche mal, meine Antwort etwas anders zu erläutern:
Bei Deinem Fehlerbild mit einem Zertifikatsfehler ist der Rebindschutz der FB nicht beteiligt. Wäre er es, würde es statt eines Zertifikatsfehlers einen DNS-Fehler geben (wie z.B. err_name_not_resolved), weil die FB die DNS-Antwort unterdrückt.
Darüber hinaus verteilst Du im Heimnetz Pi-hole per DHCP als DNS-Server an die Clients. Da Deine Clients im Heimnetz also ihre DNS-Anfragen überhaupt nicht an die FB schicken, kann der FB-Rebindschutz hier schon prinzipiell überhaupt nicht zuschlagen.
Da Du die FB so aber auch aus der DNS-Verarbeitung für Dein Heimnetz entfernt und durch Pi-hole ersetzt hast, würde ich wie erwähnt die Definition eines lokalen DNS-Records für subdomain.domain.de versuchen, der auf die private Adresse 192.168.1.x zeigt.
Dabei solltest Du anschliessend überprüfen, ob der Zugriff aus dem Gastnetz damit weiterhin klappt (denn dort stellt die FB ja DNS-Anfragen an ihren Upstream (also Pi-hole) und kann somit potentiell DNS-Antworten unterdrücken).
Habe ich in der Zwischenzeit ebenfalls schon probiert. Genau das gleiche Fehlerbild. Auch mit den beiden Domains.
Es gibt ja zwei Domains: subdomain.domain.de = öffentliche Domain von Nextcloud subdomain.dynv6.net = DynDNS Adresse für den CNAME Eintrag beim Hoster der wiederum auf subdomain.domain.de zeigt.
Auch wenn ich beide im Pi-Hole unter Local DNS Records auf die interne IP zeigen lasse, bringt das nichts.
Beides wäre interessant, und zusätzlich wäre ein nslookup auf die öffentliche Domäne hilfreich, auch falls auf Deinem Client wget nicht verfügbar ist.
Gibt es denn mit der jetzigen Einstellung, Pi-hole nur als Upstream-DNS der FB zu verwenden, auch noch Probleme?
Abgesehen davon, dass die Zuordnung individueller Clients im Query Log und client-basiertes Filtern dann natürlich nicht möglich sind.
root@pihole:~# wget https://subdomain.domain.de --spider
Spider mode enabled. Check if remote file exists.
--2020-06-29 13:44:31-- https://subdomain.domain.de/
Resolving subdomain.domain.de (subdomain.domain.de)... 2a02:810d:8000:a:f1ad:xxxxxxxxxxxxx, 192.168.xx.xx
Connecting to subdomain.domain.de (subdomain.domain.de)|2a02:810d:8000:a:f1ad:xxxxxxxxxxxxx|:443... connected.
ERROR: cannot verify subdomain.domain.de's certificate, issued by ‘CN=subdomain.dynv6.net’:
Self-signed certificate encountered.
ERROR: no certificate subject alternative name matches
requested host name ‘subdomain.domain.de’.
To connect to subdomain.domain.de insecurely, use `--no-check-certificate'.
root@pihole:~# wget https://subdomain.domain.de --spider --no-check-certificate
Spider mode enabled. Check if remote file exists.
--2020-06-29 13:44:49-- https://subdomain.domain.de/
Resolving subdomain.domain.de (subdomain.domain.de)... 2a02:810d:8000:a:f1ad:xxxxxxxxxxxxx, 192.168.xx.xx
Connecting to subdomain.domain.de (subdomain.domain.de)|2a02:810d:8000:a:f1ad:xxxxxxxxxxxxx|:443... connected.
WARNING: cannot verify subdomain.domain.de's certificate, issued by ‘CN=subdomain.dynv6.net’:
Self-signed certificate encountered.
WARNING: no certificate subject alternative name matches
requested host name ‘subdomain.domain.de’.
HTTP request sent, awaiting response... 400 Bad Request
Remote file does not exist -- broken link!!!
Ich habe im Pihole unter Local DNS Records zwei Einträge gesetzt. IPv4 und IPv6. Ein Ping eines anderen Clients löst das auch auf.
Der Fehler ist aber immer noch da.
Zu Erinnerung:
Es gibt ja zwei Domains: subdomain.domain.de = öffentliche Domain von Nextcloud subdomain.dynv6.net = DynDNS Adresse für den CNAME Eintrag beim Hoster der wiederum auf subdomain.domain.de zeigt.
Neues Fehlerbild:
Die Adresse ist nun im Heimnetz Gast nicht zu erreichen. Letztendlich also genau anders herum. Vorher war sie im Heimnetz nicht zu erreichen.
Zusätzliche Lokale DNS Records auf öffentliche Adressen setzen, ergibt ja hier keinen Sinn.
Aus meiner Sicht ist das auch der falsche Weg dem PiHole Lokale DNS Records zu geben. Aus meiner Sicht ist das weiterhin ein DNS-Rebind-Schutz Problem der FritzBox.
Es wäre immer noch interessant, ob Dein Nextcloud-Server sowohl aus Heimnetz als auch Gastnetz errreichbar war, wenn Du Pi-hole nur als Upstream Deiner FB konfigurierst (also nicht über DHCP verteilst).
Ich hätte erwartet, dass der DNS-Eintrag für die öffentliche `subdomain.domain.de` einen CNAME-Eintrag für `subdomain.dynv6.net` zurückliefert. (klicken für mehr)
Im pihole.log könnte die DNS-Auflösung dann ungefähr so aussehen:
dnsmasq[42]: query[A] subdomain.domain.de from 192.168.1.100
dnsmasq[42]: forwarded subdomain.domain.de to 8.8.8.8
dnsmasq[42]: reply subdomain.domain.de is <CNAME>
dnsmasq[42]: reply subdomain.dynv6.net is 185.49.17.48
Bei einer Namensauflösung im Heimnetz ist die Einbeziehung der DynDNS-Adresse via CNAME nicht erforderlich, da die Zieladresse ja nicht dynamisch ermittelt werden muss. (mehr)
Entsprechend kürzer würde das Log ausfallen:
dnsmasq[42]: query[A] subdomain.domain.de from 192.168.1.100
dnsmasq[42]: reply subdomain.domain.de is 192.168.1.x
Der lokale DNS-Eintrag sorgt damit dafür, dass die Daten zwischen Deinem Client und Deinem Nextcloud-Server auch direkt lokal fliessen statt einen Umweg über das öffentliche Netz (oder zumindest die FB) zu nehmen. (mehr)
Bei einem Aufruf über die öffentliche IPv4-Adresse nimmt zunächst die FB den Datenverkehr entgegen und leitet dann auf die eingerichtete Freigabe weiter. Theoretisch hätte die FB in diesem Fall alle Informationen, um den Datenverkehr durch entsprechendes Routing auch lokal zu halten, wenn der Kontakt von einem Client im lokalen Netz ausgeht. Ich bin allerdings überfragt, ob dies tatsächlich erfolgt, und inwieweit die Verwendung eines externen DynDNS-Dienst das beeinflusst.
Bei einer lokalen DNS-Antwort kommunizieren Client und Nextcloud-Server dagegen ohne Beteiligung des Routers direkt miteinander.
Sofern die FB sich als DNS-Server im Gastnetz nicht vorrangig vor Pi-hole um die Auflösung der öffentlichen subdomain.domain.de kümmert, führt die Definition eines lokalen DNS-Eintrags allerdings dazu, dass Dein Nextcloud-Server aus dem Gastnetz nicht erreichbar ist, da die FB Heimnetz und Gastnetz vollständig voneinander isoliert.
(Und damit die öffentliche IPv6 funktioniert, müsste der DynDNS-Client auch direkt auf den öffentlich zugänglichen Maschinen laufen, sofern Du nicht MyFritz verwendest).
Ja, lief. Ohne lokale DNS Einträge im PiHole. Heimnetz und auch im Gastnetz. Der Umweg über die FritzBox (oder auch ins Internet und wieder zurück), war nicht das Problem. Lief zumindest ohne Unterschied zu jetzt.
Der Schalter "Never forward reverse lookups for private IP ranges" im PiHole unter Settings / DNS / Advanced DNS settings hat es dann aber gebracht.
In der FritzBox ist im DNS-Rebind-Schutz jetzt gar nichts eingetragen. Im PiHole ist unter Local DNS Records der Nextcloud Server mit seiner internen IPv4 (192. ...) und IPv6 Adresse (fe80: ...) eingetragen.
Die Zugriffe funktionieren nun intern wie extern, sowohl im Heimnetz als auch im Gastnetz.
Ob das nun ein Bug in der FritzBox ist, oder nicht - ich bin mir nicht sicher. Jedenfalls sind alle Versuche gescheitert, Einträge im DNS-Rebind-Schutz der FritzBox zum laufen zu bekommen.
Dann mal Danke und viel Erfolg an alle die das gleiche vor haben.