Nov 21, 2021

3003

Routing für eigenen DNS zwischen mehreren Subnetzen

Hallo,
die Masse an Informationen zum Thema Routing und NAT überfordern mich gerade und ich muss mein Problem doch mal in die Community bringen.

Ich habe mehrere VLAN-Netze im Einsatz

192.168.1.0/24 (priv. Netz)
192.168.10.0/24 (Serverdienste)
192.168.20.0/24 (Gäste)

Mein Pi-hole läuft unter der IP 192.168.10.200.

Als Router nutze ich einen RB2011UiAS von Mikrotik (MT). Der Router hängt hinter einem Modem von DrayTek (MPoA) und auf dem MT ist der PPPoE-Client für den Internetzugriff erfolgreich installiert. Der DNS-Server ist in der DHCP-Konfiguration je Netzwerk hinterlegt.

Die folgenden NAT-Regeln, neben den Firewall-Regeln (Forward), sorgen dafür, dass Internet und DNS funktionieren.

  chain=srcnat action=masquerade src-address=192.168.0.0/16 out-interface=WANInternet log=no log-prefix=""   
  chain=srcnat action=masquerade protocol=tcp src-address=192.168.0.0/16 dst-address=192.168.10.200 dst-port=53 log=no log-prefix=""   
  chain=srcnat action=masquerade protocol=udp src-address=192.168.0.0/16 dst-address=192.168.10.200 dst-port=53 log=no log-prefix=""  

Hier noch ein Screenshot der aktuellen Routes- und DHCP-Einstellungen auf dem MT.

Mein Verständnisprobem:

Wenn ich die NAT-Regeln 1 + 2 deaktiviere, funtionieren die DNS-Anfragen nicht mehr. Der DNS-Request geht zwar an den Pi-hole, aber kommt nicht mehr an den Client z.B. im 192.168.1.0/24 Netz zurück. Der Zugriff über IP-Adressen funktioniert allerdings.

Frage: Ist meine Konfiguration, die ja aktuell auch funktioniert, korrekt oder kann ich statt der Regeln 1 + 2 ein sinnvolles Routing auf dem MT konfigurieren? Wenn ja, wie könnte dies für mein Szenario auf dem MT aussehen?

Mir ist nicht klar, warum dies aktuell nur mit dem "masquerade" innerhalb vom LAN funktioniert, obwohl die entsprechendem Firewall-Filter doch greifen müssten?

 9    ;;; Erlaube DNS Anfragen aus dem lokalen Adress-Bereich
      chain=forward action=accept protocol=udp src-address=192.168.0.0/16 dst-port=53 log=no log-prefix=""   
10    chain=forward action=accept protocol=tcp src-address=192.168.0.0/16 dst-port=53 log=no log-prefix=""   

Vielen Dank für's Lesen und Tipps geben.

Please also mark the comments that contributed to the solution of the article

Content-Key: 1536491972

Url: https://administrator.de/contentid/1536491972

Printed on: April 27, 2024 at 11:04 o'clock

12 Comments

Latest comment

Ergänzung:
Falls es hier einen Zusammengang zum Routing gibt, erhoffe ich mir dadurch auch, dass der Pi-hole mir unter Top Clients im Dashboard nicht nur die IP 192.168.10.1 aufführt, sondern die anfragenden Clients der verschiedenen Subnetze anzeigt.

Der DNS-Server ist in der DHCP-Konfiguration je Netzwerk hinterlegt.

Sinnvoller wäre es den PiHole zentral als Upstream DNS im MT unter IP -> DNS zu definieren und keinen DNS im DHCP des MT.
Dann arbeitet der MT als reiner DNS Proxy und reicht im Upstream alles an den PiHole weiter und der dann wiederum zu seinen Upstream DNS. So kannst du dir die Frickelei mit der Einzelangabe des DNS in jedem Netz ersparen.
Hat auch den Vorteil das du dann nur von einer einzigen IP nämlich des PiHole DNS Requests erlauben musst und erzwingst so die Nutzung des PiHole.
Tip:
AdGuard Home https://github.com/AdguardTeam/AdGuardHome oder auch https://www.heise.de/select/ct/2021/7/2101113595336903136 rennt allemal besser auf dem DNS Filter, da du hier die Upstrem DNS Server als DoH oder DoT Server definieren kannst was das Surfen noch sicherer macht.
Zudem bietet der AdGuard auch ein erheblich besseres grafisches Template und ungewollte Applikationen im Netz wie Facebook Schnüffelei usw. zu blocken.
Hat den PiHole technsich überholt...

Ich nutze Pi-hole in Verbindung mit unbound und dachte es ist sinnvoller als DoH oder DoT. Bei HTTPS oder TLS muss doch an den Endpunkten sowie wieder entschlüsselt werden, um die DNS-Namen zu erhalten. Aber trotzdem werde ich mir AdGuard anschauen. Wieder was zum Basteln.

Hast du noch Hinweise zu dem Thema Routing? Oder kann man mit meinem Infos dazu nichts anfangen? Vielleicht bringe ich auch alles durcheinander.

Ich habe eben AdGuard installiert. Klappt wunderbar in Verbindung mit unbound und die Oberfläche wirkt auch erstmal frischer, aufgeräumter und übersichtlicher. Allerdings ist auch hier das Problem, dass nicht die abfragenden Clients aufgeführt werden, sondern nur der Gateway des Netzes in dem die AdGuard-Instanz läuft.

Den DNS-Server habe ich vom MT aus den DHCP-Einstellungen aller Netz entfernt und nur noch unter IP -> DNS hinterlegt.

Und wieder sind meine Gedanken beim Routing.

Vermutlich hatte durch Cachen die Hinterlegung des DNS auf dem MT unter IP -> DNS noch keine Wirkung gezeigt. Durch Neuinstallation von Pi-hole und Neustart des Routers scheint es nun doch Auswirkung auf die clientbasierte Auswertung im Dashboard zu geben. Eigenartiger Weise funktionieren auch die DNS Abfragen ohne die o.g. NAT-Regeln 1+2. Was kann man doch für solchen Kram für Zeit verschwenden, ohne am Ende zu wissen, was wirklich des Rätsels Lösung war.

Es funktioniert erstmal, aber ich beobachte weiter. Danke dir aqui.

Bei HTTPS oder TLS muss doch an den Endpunkten sowie wieder entschlüsselt werden

Ja, aber damit hast du doch nix zu tun, das machen doch die Endgeräte automatisch z.B. wenn man den DoH Server der Telekom nutzt:
https://telekomhilft.telekom.de/t5/Offentliche-Tests-Umfragen/Telekom-hi ...
oder den DoT von Digitalcourage:
https://digitalcourage.de/support/zensurfreier-dns-server
Im Adguard Setup sieht das dann so aus:

Es funktioniert erstmal,

👍

Aber es läuft darauf hinaus, dass ich dem Dritten vertrauen muss. Verstehe ich es richtig, dass du mehr auf DoH/DoT vertraust, als den Root Namensserver des Ziels via unbound anzusprechen? Oder nutzt du beides?

In Pi-hole habe ich als Upstream DNS die 127.0.0.1#5335 gesetzt, um die Anfragen an unbound weiter zu geben. Bei unbound habe ich unter /etc/unbound/unbound.conf.d/pi-hole.conf die Einträge

server:
    # Entweder: Root-CA Zertifikatsbundle in Debian/Ubuntu
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt

und

forward-zone:
    name: "."  
    forward-addr: 185.95.218.43@853
    forward-ssl-upstream: yes

gesetzt. Dadurch nutze ich DoT. Die 185.95.218.43 ist ein Dienst der Digitalen Gesellschaft.

Es steht außer Frage, dass man mit AdGuard DoH oder DoT einfacher konfigurieren kann.

Bei AdGuard hat es mich gestört, dass man die Filterlisten oder Rewrite-Einträge nur über die GUI machen kann. Bei Pi-hole konnte ich mehrere Listen oder auch lokale DNS-Einträge schnell über die GUI oder in der custom.list hinterlegen. Ich weiß, ist nur eine einmalige Sache, aber trotzdem ....

Aber es läuft darauf hinaus, dass ich dem Dritten vertrauen muss.

Na ja, er sieht, da verschlüsselt, zumindestens keine deiner DNS Anfragen mehr im Klartext um daraus Profile zu erstellen wie es bei unverschlüsselten DNS der Fall ist.

Verstehe ich es richtig, dass du mehr auf DoH/DoT vertraust

Darum geht es ja gar nicht. Es geht darum das jeder der solche DNS Server betreibt wie z.B. Googles 8.8.8.8 deine DNS Anfragen komplett unverschlüsselt sieht. Er weiss also sofort ob du dich auf Kochrezept Seiten umsiehst, Katzenvideos oder abends dänische Western schaust um daraus ein Profil deiner Person zu erstellen was er dann weltweit vermarktet.
Genau das siehst du bei DoH oder DoT DNS Servern nicht mehr !
Die DoT bzw. DoH Implementation im PiHole ist gar nicht oder nur mit extremen Umwegen möglich die das ganze recht instabil machen.
https://www.heise.de/select/ct/2021/4/2030412421734924519
Das ist bei AdGuard definitiv besser, da es gleich fest integriert ist. Und das bequeme App Blocking von Apps im Netz.
Aber wie immer im Leben....alles Geschmackssache !

@aqui
Sorry, hätte nicht gedacht, dass du so schnell antwortest. Hatte meinen Post noch aktualisiert und wollte aufzeigen, dass DoT mit etwas mehr Aufwand in Pi-hole und unbound umgesetzt werden kann. Aber wie du schon schreibst, ist eben Geschmackssache.

In Fragen bzgl. Google und Vermarktung der Daten hast du meine volle Zustimmung. Dieser Umstand ist bestimmt auch vielen bekannt, die nicht so die Affinität zur IT haben. Um sich davor zu schützen, müsste es für diesen Personenkreis einfachere Lösung geben wie z.B. eine standardmäßige Implementierung in Fritzboxen oder sonstiger gägnger Routertechnik. Aber hier besteht vielleicht auch seitens Unternehmen nicht wirklich Interesse (Spekulation).

Dieser Umstand ist bestimmt auch vielen bekannt, die nicht so die Affinität zur IT haben.

Den meisten dieser Menschen ist das eben NICHT bekannt und das ist ja das Fatale. Gut, wenn man mal etwas nachdenken würde käme es einem komisch vor warum jemand für Millionen täglich so ein RZ Equipment betreibt und das alles umsonst. Da kann eigentlich etwas nicht stimmen...

eine standardmäßige Implementierung in Fritzboxen

Die können es ja mittlerweile...

https://www.heise.de/select/ct/2020/22/2024813000200650231
Man muss es nur noch nutzen wenn man eine FritzBox sein eigen nennt !!

Zitat von @aqui:
Na ja, er sieht, da verschlüsselt, zumindestens keine deiner DNS Anfragen mehr im Klartext um daraus Profile zu erstellen wie es bei unverschlüsselten DNS der Fall ist.
[...] Es geht darum das jeder der solche DNS Server betreibt wie z.B. Googles 8.8.8.8 deine DNS Anfragen komplett unverschlüsselt sieht.
Genau das siehst du bei DoH oder DoT DNS Servern nicht mehr !

Ähh, aqui?
Wenn ich einen DNS-Dienst betreibe, ist es doch vollkommen egal, wie mich die Anfragen erreichen. Damit ich dir den Dienst anbieten kann, muss ich ja schließlich in der Lage sein, deine Anfragen zu verstehen resp. zu entschlüsseln. Ich als Betreiber sehe also in jedem Fall was du mich fragst.
Bei DoH oder DoT ist es lediglich unmöglich, dass irgendwer anderes, der meinen Traffic mitliest, die Anfragen sehen oder verändern kann.

Klar, da hast du natürlich Recht. Am Ende der Kette ists immer wieder Klartext, das ist richtig. Das war ggf. missverständlich ausgedrückt oben, sorry.
Dagegen hilft dann nur das (hoffentlich) kommende ODoH https://www.heise.de/select/ct/2021/21/2120909362113083629

German solved Question Routers, Routing Networks