DNS-Server aus dem internen Netz (mit weiterer Fritzbox) zuweisen

Bib

Mitglied
Mitglied seit
31 Aug 2005
Beiträge
769
Punkte für Reaktionen
0
Punkte
16
Hallo,

kann ich der Fritzbox einen DNS-Server zuweisen, der in einem eigenen Netzwerk hinter der Fritzbox steht?

Ich habe eine Master-Fritzbox 192.168.0.1

Ich habe eine Client-Fritzbox (Internet über LAN1) mit IP 192.168.100.1
DNS-Server hat 192.168.100.5


Jetzt komme ich ja von der Master-Fritzbox nicht ohne weiteres auf Adressen im lokalen Netz der Client-Fritzbox.



Was muss ich machen, damit die Master auch auf ein Gerät aus dem Netz x.100.x zugreifen kann? Statische Routen einrichten? Portweiterleitung?
 

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
11,754
Punkte für Reaktionen
242
Punkte
63
Moinsen


Portweiterleitung?
So ist es.
Wenn die Portfreigabe ein Tinyproxy ist, kommst du so auch an alle Geräte ( HTTP/HTTPS, IPv4 & IPv6 ) im *.100.*er Netz ran.
...wenn du im *.0.*er Netz die Freigabe als HTTP/HTTPS Proxy nutzt.
 

Bib

Mitglied
Mitglied seit
31 Aug 2005
Beiträge
769
Punkte für Reaktionen
0
Punkte
16
Tinyproxy?

Ich hab hier nur die beiden Fritzboxen und die Master soll eben auf den DNS im Client-Netz zugreifen können.

Ich trage also in der Client-Fritzbox ein, dass sämtliche DNS-Anfragen von ausserhalb von Port 53 kommend (kann ja dann nur vom *.0.* Netz sein...) an den Port 53 meines DNS-Servers im *.100.* Netz weitergereicht werden?

Also nix mit statischen Routen in der Master-Box?

Aber schickt die Master-FB nicht automatisch alle Anfragen auf ihr unbekannte Adressen ins Internet anstatt an die lokale IP im *.0.* Netz der Client-FB? Die Master-Fritzbox kennt doch das 100er Netz überhaupt nicht...
 

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
11,754
Punkte für Reaktionen
242
Punkte
63
Die Master-Fritzbox kennt doch das 100er Netz überhaupt nicht...
Und da das *.100.*er Netz ein eigenes Subnetz inklusive Firewall hochzieht greift keine statische Route.
Der fürs *.0.*er Netz freigegebene Proxy befragt immer den DNS des *.100.*er Netzes.
 

Bib

Mitglied
Mitglied seit
31 Aug 2005
Beiträge
769
Punkte für Reaktionen
0
Punkte
16
Was meinst du mit Proxy? Ich hab doch auf der Fritzbox keinen, oder?

Also für deine Lösung müsste ich erst einen Linux-Server aufsetzen, da drauf einen Tinyproxy installieren und das dann entsprechend konfigurieren??? So der Netzwerkfachmann bin ich nicht...
 

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
11,754
Punkte für Reaktionen
242
Punkte
63
Geht auch ohne Linux mit Windows und PuTTY...

...den du im *.100.*er laufen lässt und im *.0.*er nutzt.
 

Bib

Mitglied
Mitglied seit
31 Aug 2005
Beiträge
769
Punkte für Reaktionen
0
Punkte
16
Und so einfach nur mit den beiden Fritzboxen geht da nichts?

Das aus deinem letzten Link geht dann aber nur solange die SSH-Verbindung steht?
Das mit Windows und Putty ist ja schön und gut, wenn ich mal kurz was prüfen möchte, aber der pihole soll ja dauerhaft aus dem Netz der Fritzbox 1 erreichbar sein.

Kurze Erklärung:
Hierbei handelt es sich um zwei private Homenetzwerke...

Fritzbox 1 (Master) ist bei den Eltern mit Internetanschluss
Fritzbox 2 (Client) ist in der Wohnung des Kindes, LAN mit Internet kommt von der Fritzbox 1
im Netz der Fritzbox 2 befindet sich ein Pihole auf einem Raspberry Pi, der die Werbung rausfiltert

Jetzt wäre es schön, wenn auch die Eltern im Netz der Fritzbox 1 durch den Pihole profitieren könnten, ohne dass sich alle in einem gemeinsamen großen Netz befinden.

_________

Wenn man den Raspi jetzt einfach ins Netz der Fritzbox 1 hängen würde, dann kann man im Log doch nicht mehr sehen, von welchem Endgerät im Fritzbox-2-Netz die Anfragen kommen? Dann würde man dort nur sehen, dass es von der Fritzbox 2 kommt, oder? Das ist also auch keine Lösung.

Ich habs mit einem VPN ausprobiert, das funktioniert super... Also Fritzbox 3 verbunden per VPN mit Fritzbox 2. DHCP-Clients im FB3-Netz bekommen den Pihole im FB2-Netz als DNS zugewiesen.
Und hier bei zwei verkabelten lokalen Netzwerken ist da so ein riesen Problem mit Proxy usw?
 

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
11,754
Punkte für Reaktionen
242
Punkte
63
Nun, ich nutze auf dem Raspi einige Serverdienste, darunter eben auch tinyproxy.
Zwischenablage00.png
...der filtert mir ( über RegEx Filterlisten ) raus was ich nicht möchte.

Übrigens auch...
Zwischenablage00.png
 
Zuletzt bearbeitet:

Insti

Mitglied
Mitglied seit
19 Aug 2016
Beiträge
226
Punkte für Reaktionen
21
Punkte
18
Hallo,
Ich habe eine Master-Fritzbox 192.168.0.1

Ich habe eine Client-Fritzbox (Internet über LAN1) mit IP 192.168.100.1
Soll die Client Fritzbox im Routermodus laufen?
Eine Lösung wäre die als IP Client im sellben Netz der Master-Fritzbox einzustellen.
 

Bib

Mitglied
Mitglied seit
31 Aug 2005
Beiträge
769
Punkte für Reaktionen
0
Punkte
16
Die soll so laufen... Das FB2-Netz soll "abgesichert" getrennt vom FB1-Netz sein.
 

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
11,754
Punkte für Reaktionen
242
Punkte
63
Und das nennt sich auch: Doppel NAT
Ohne in die Trickkiste zu greifen wird das nichts.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,322
Punkte für Reaktionen
804
Punkte
113
Das FB2-Netz soll "abgesichert" getrennt vom FB1-Netz sein.
Tja, da gilt nun mal: "Ente oder weder".

Wenn die Netze getrennt sein sollen, dann geht eben kein Traffic hin und her ... genau das ist ja bei VPN-Benutzung anders, insofern widersprichen die mit dem VPN-Aufbau (und drei FRITZ!Boxen) gesammelten Erfahrungen ja offenkundig der oben zitierten Absicht.

Einen Tod muß man sterben ...
 

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
11,754
Punkte für Reaktionen
242
Punkte
63
Das FB2-Netz soll "abgesichert" getrennt vom FB1-Netz sein.
Zumal die ketzerische Frage aufkommt: Wie wird das *.0.*er Netz vom *.100.*er Netz abgesichert?
...oder: Wer schützt die Eltern vor dem Sohn?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,322
Punkte für Reaktionen
804
Punkte
113
Zumal hier der Einsatz eines zweiten "Pi-hole(R)" dann wohl die schlaueste (zumindest aber weiterhin die sicherste) Lösung wäre - das Problem, daß aus dem Netz der zweiten FRITZ!Box auf JEDES Gerät im Netz der ersten zugegriffen werden kann, wird davon aber natürlich nicht gelöst.

Will man das auch noch in den Griff bekommen, nimmt man einfach drei FRITZ!Boxen ... eine als Edge-Router und jeweils eine für die LANs. DANN kann man auch den "Pi-hole(R)" in das LAN des Edge-Routers hängen und aus beiden Netzen benutzen ... selbstverständlich dann aber wieder ohne genaue Aufschlüsselung, welcher Client im welchem LAN die DNS-Requests auf den Weg gebracht hat.

Will man alles auf einmal (getrennte Netze UND genaue Protokollierung), braucht's eben drei Router und zwei "Pi-hole(R)"-Devices - außer man baut zwischen dem RasPi mit "Pi-hole(R)" und den beiden kaskadierten FRITZ!Boxen dann wieder ein VPN auf, so daß die DNS-Requests der LAN-Clients per VPN (und damit ohne NAT) beim "Pi-hole(R)" landen.

Das erscheint mir aber für jemanden, der von sich selbst behauptet:
So der Netzwerkfachmann bin ich nicht...
, doch etwas zu ambitioniert - zumindest sollte man dann keine schnellen Ergebnisse erwarten.
 

Bib

Mitglied
Mitglied seit
31 Aug 2005
Beiträge
769
Punkte für Reaktionen
0
Punkte
16
Der Sohn muss ja auf die Eltern Geräte drauf können, um diese zu administrieren.

Wenn man das mit VLANs machen würde, hätte auch keine Vorteile? Dann sieht man auch nur das Gateway im pihole anstatt die eigenen IPs?

Also Eltern ist untagged. Kabel geht zu Sohn auf einen managed Switch und wird "ge-VLANt" und dann ohne extra Fritzbox bzw mit etwas "besserem" wie zb pfsense.

Dann hab ich 2 durch VLAN getrennte Netze...

Bringt dieser Ansatz irgendwas?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,322
Punkte für Reaktionen
804
Punkte
113
Auch dann bleibt die Option (das mit den VLANs verstehe ich gar nicht ... entweder die Netze sind (auf L2) verbunden oder nicht) zwischen "Pi-hole(R)" im ersten LAN und der kaskadierten FRITZ!Box eine VPN-Verbindung aufzumachen, so daß die LAN-Clients der kaskadierten Box über den Tunnel den RasPi als DNS-Server nutzen. Geht theoretisch auch vom ersten LAN (über Portfreigabe für VPN an den RasPi) in das kaskadierte ... nur verliert dann die kaskadierte FRITZ!Box die Option, selbst als VPN-Peer zu dienen (entweder die Pakete landen an der FRITZ!Box oder am RasPi, aber nicht an beiden).

EDIT: Setzt aber in beiden Fällen auch voraus, daß alle Clients direkt den "Pi-hole(R)" als DNS benutzen ... wenn die DNS-Requests erst bei der FRITZ!Box landen und die dann die bei ihr konfigurierten DNS-Server befragt, sieht man auch nur noch deren Adresse als "DNS-Forwarder".

VLANs (für jemanden ohne Netzwerkkenntnisse noch ambitionierter, weil noch schwerer zu verstehen für die meisten) helfen nur dann, wenn beide LANs über jeweils einen Port angeschlossen sind (die keine gemeinsamen VLAN-IDs haben) und der "Pi-hole(R)" an einem dritten (der dann beide IDs bedient und zwar zwingend als "tagged") - dann obendrein auch noch als "multi-homed server", also mit jeweils einer IP-Adresse aus jedem LAN auf demselben Interface.

Auch das ist eine kompliziertere Netzwerk-Konfiguration und anstelle eines VLAN-fähigen Switches (wenn der nicht ohnehin schon existiert, wobei mir das ganze "Wenn und Aber" so langsam etwas zuviel erscheint - es kommt in jedem Beitrag irgendein neuer Aspekt/eine andere Idee dazu ... wie wäre es mal mit einer "finalen Beschreibung", was nun zur Verfügung steht für diese "Aufgabenstellung" und was nicht) kann man dann ja auch gleich den zweiten RasPi anschaffen.
 

Theo Tintensich

Aktives Mitglied
Mitglied seit
10 Mrz 2008
Beiträge
1,589
Punkte für Reaktionen
36
Punkte
48
Wenn du hinter die eine F!B ein weiteres Netz hängen willst, kannst du das auch ohne doppeltes NAT machen.
Der zweite Router muss nur sauber routen, also kein NAT machen. Notfalls nimmt man einen 'echten' Router ohne NAT.(z.B. ein PI ;-)
Die Systeme im 'hinteren' Netz erreichst du aus dem 'vorderen' Netz, in dem du eine Route setzt, die auf den Gateway zeigt, der das 'hintere' Netz anbidet.
Notfalls als Route in der 'vorderen' F!B

Damit kann man auch den DNS-Server in dieses Netz schieben.
Für die Zugriffsregelung muss dann eine Firewall, auch auf dem 'inneren' Router, sorgen.
 
Zuletzt bearbeitet:

Bib

Mitglied
Mitglied seit
31 Aug 2005
Beiträge
769
Punkte für Reaktionen
0
Punkte
16
Ich hab jetzt einfach auf der Fritzbox-B ein Portforwarding für den Port 53 UDP auf meinen internen DNS (pihole) gemacht.
In der Fritzbox A hab ich bei DHCP die externe Adresse der Fritzbox-B, also die aus dem .0. Netz angegeben.

Und siehe da, es funktioniert ganz einfach, ohne Tinyproxy usw...

____________

@Theo Tintensich
Also wenn ich in der Fritzbox A eine statische Route auf die Fritzbox B setze, blockt dann die Fritzbox B nicht die ganzen Anfragen? Für Fritzbox B ist doch Fritzbox A das Internet und nichts lokales? Oder hast du das damit gemeint, dass ich eine Firewall "auch auf dem inneren Router" benötige?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,322
Punkte für Reaktionen
804
Punkte
113
für den Port 53 UDP
Das ist für (modernes) DNS heutzutage eigentlich zu wenig (und stand in #3 auch noch anders und damit "richtiger"). Denn da kann ganz schnell auch mal TCP verwendet werden - spätestens dann, wenn eine Antwort nicht mehr in das 512-Byte-Paket bei UDP paßt (EDNS (RFC 6891) ist ein optionales Feature).

Zwar werden die ersten Einträge dann meist trotzdem übertragen und der Rest nur "abgeschnitten", aber gerade bei DNSSEC kann auch schon mal ein einzelner Eintrag dank größerer Signaturen nicht mehr in diese 512 Byte passen - gerne auch mal wg. IPv6-Adressen, die halt doppelt soviel Platz brauchen und auch die "Texte" für irgendwelche Namen sind da gerne mal deutlich länger (auch beim Reverse DNS) als bei IPv4.

Daher sollte man heutzutage immer UDP und TCP für DNS-Server freigeben, wenn man nicht von Beginn an schon weiß, daß der Server (und/oder alle Clients) gar kein DNS over TCP unterstützt (was RFC 7766 seit drei Jahren aber fordert - siehe "Introduction" dort).

Auch die Dokumentation zum "Pi-hole(R)" bezieht sich auf die Verfügbarkeit der Portnummer für die beiden (gebräuchlichsten) IP-Protokolle TCP und UDP: https://docs.pi-hole.net/main/prerequesites/

Da hier ja jeder Client selbst seine Abfragen macht und viele bei abgeschnittenen UDP-Antworten danach auf TCP-Basis eine Wiederholung einer Abfrage starten (wenn sie nicht über EDNS-Support dann doch noch größere UDP-Pakete verkraften), kann das zu schwer zu findenden Problemen führen oder auch zu unerklärlichen Verzögerungen in der Auflösung von DNS-Namen. Das mag dann mit dem einen Client problemlos funktionieren (weil der mit EDNS umgehen kann), aber ein Client ohne EDNS-Support wartet sich dann einen Wolf (bis zum Timeout des Verbindungsversuchs), wenn die TCP-Umschaltung nicht möglich ist.

----------------------------------------------------------------------------------------------------------

BTW ... warum hast Du denn eigentlich nach #2 (erster Satz) und #3 (dritter Satz) noch so lange weiter diskutiert, anstatt das erst einmal zu machen? Dadurch entstand halt beim Leser der Eindruck, diese simple Portfreigabe wäre genau das, was Du nicht willst bzw. was Dir aus irgendeinem Grunde nicht reicht, weil da auch noch andere Zugriffe möglich sein sollen. Hättest Du das gleich vor oder direkt nach #3 einfach mal so eingestellt, wäre das hier vermutlich deutlich kürzer geworden.

----------------------------------------------------------------------------------------------------------

Generell mal zu diesen Blackhole-Servern beim DNS ... und deren (vermutlicher) Zukunft:

Spätestens dann, wenn sich DNS over HTTPS durchsetzen sollte bei den Browser-Herstellern und zur Standardeinstellung wird (Google und Mozilla arbeiten ja daran), muß man bei so einer Konstellation dann aber auch noch die einzelnen Browser so konfigurieren (können), daß diese ebenfalls den "Pi-hole(R)" als (DoH-)Server verwenden ... bisher gibt es dieses Feature aber m.W. im "Pi-hole(R)" noch nicht. Der unterstützte Proxy dient bisher nur dazu, die per DNS-Paket entgegengenommenen Anfragen beim Upstream über DoH aufzulösen, anstelle des "normalen" DNS-Protokolls.

Da aber so ein Blocker gerade für Browser ja i.d.R. verwendet werden soll, muß man am Ende die eingesetzten Programme auf den Clients dann noch genauer beobachten ... wenn diese auf DoH anstelle vom üblichen DNS setzen und dabei direkt einen Server im Internet/beim Provider befragen (z.B. die von Cloudflare), greift der schöne Ansatz in diesem Fall ins Leere ... das gilt natürlich auch für irgendwelche Apps, die ihre eigenen Abfragen über DoH abwickeln.

Es gibt ja bereits genug öffentliche DoH-Server (https://github.com/curl/curl/wiki/DNS-over-HTTPS) und auf diesem Weg kann eine App oder ein IoT-Gerät eben auch leicht verhindern, daß irgendwelche Kommunikation (z.B. mit dem Hersteller) über simple "DNS-Sperren" blockiert wird (IP-Adressen werden da ja ohnehin schon nicht mehr verwendet, weil die noch einfacher zu blockieren sind, sofern sie irgendwo fest verdrahtet sind).

Man darf sich also auch mit einem solchen Blackhole-Server für DNS-Abfragen nicht zu sicher fühlen ... seit DoH (und der Standardisierung) und der Verfügbarkeit der entsprechenden Server für öffentliche Abfragen, werden dabei eigentlich nur noch "die Dummen" blockiert (auch wenn das natürlich besser ist als nichts und gegen unerwünschte Werbung ggf. helfen mag) - Malware oder auch "geschwätzige" Geräte wird man auf diesem Weg vermutlich nicht mehr lange am Reden hindern können ... da braucht's dann doch wieder die Paket-Filterung.

Hier haben dann die Werbeblocker im Browser (z.B. uBlock Origin) doch wieder die besseren Karten, weil sie die betreffenden Links bzw. Requests schon sehen, bevor die DNS-Abfrage gestartet wird und damit davon unabhängig sind, auf welchem Wege die Auflösung erfolgt.

Am Ende wird man also vermutlich in der Zukunft bei einer Kombination aus beidem landen (Adblocker + DNS-Blackhole) ... quasi bei einer zweistufigen "Verteidigung".
 

Bib

Mitglied
Mitglied seit
31 Aug 2005
Beiträge
769
Punkte für Reaktionen
0
Punkte
16
Ich habe die Antwort in #2 nicht so verstanden, dass eine einfache Portweiterleitung reicht. Das mit dem Tinyproxy hab ich nicht ganz kapiert und deshalb die Lösung als für mich nicht machbar eingestuft - siehe meine Nachfragen diesbezüglich.
 

Zurzeit aktive Besucher

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
233,304
Beiträge
2,032,598
Mitglieder
351,856
Neuestes Mitglied
Rutras