39
MikroTik RouterOS: (dämliche) Frage, wie DNS-Abfragen weitergeleitet werden, DCHP DNS-Einstellungen
Hallo,
da ich mehrere Grundkonfigurationen für RouterOS und VLANs kennengelernt habe, bin ich etwas verwirrt, wie man den DNS Server richtig einrichtet.
Obwohl die Antwort wohl offensichtlich sein wird, möchte ich meinen Gedanken aufschreiben und würde mich sehr freuen, wenn diese bestätigt, beantwortet, bzw. korrigiert werden, wo Dinge noch unklar sind
Ich habe mehrere MT Switches und einen MT Router.
Der Router ist entweder direkt mit dem Internet verbunden oder hinter dem vom ISP zur Verfügung gestellten Router, so:
Wäre toll, wenn dieses Rätsel vervollständigt werden könnte, da ich im Handbuch keine Antwort auf meine Frage finde (oder ich bin einfach zu dumm, sie zu finden).
Vielen vielen Dank
Stefan
da ich mehrere Grundkonfigurationen für RouterOS und VLANs kennengelernt habe, bin ich etwas verwirrt, wie man den DNS Server richtig einrichtet.
Obwohl die Antwort wohl offensichtlich sein wird, möchte ich meinen Gedanken aufschreiben und würde mich sehr freuen, wenn diese bestätigt, beantwortet, bzw. korrigiert werden, wo Dinge noch unklar sind
Ich habe mehrere MT Switches und einen MT Router.
Der Router ist entweder direkt mit dem Internet verbunden oder hinter dem vom ISP zur Verfügung gestellten Router, so:
- Die dynamischen Server werden vom IPS DHCP oder vom IPS-bereitgestellten Router bedient. Wenn letzteres der Fall ist, handelt es sich in der RRegel um die Gateway-Adresse des IPS-Routers.
- Wenn in /ip dhcp-server network dns-server nichts eingestellt ist, können die Einstellungen in /ip dns servers und /ip dns dynamic-server an die DHCP-Clients weitergegeben werden, aber welche Server?
- Wenn nur statisch, dann wird immer statisch weitergegeben, unabhängig von /ip dhcp-server network dns-none wie in Manual:IP/DHCP Server - MikroTik Wiki beschrieben?
- Wenn nur dynamisch, dann hängt es von /ip dhcp-server network dns-none ab?
- Wenn beides, werden entweder beide oder nur statische weitergegeben, abhängig von /ip dhcp-server network dns-none?
- Wird /ip dhcp-server network dns-server gesetzt, dann wird/werden diese Server weitergereicht
- Mir wurde eine Konfiguration gegeben, bei der /ip dhcp-server network dns-server gleich dem /ip dhcp-server network gateway ist. Was passiert hier?
- Die Einstellungen, die in /ip dns server und /ip dns dynamic-server angegeben sind, stehen zur Weitergabe an DHCP-Clients zur Verfügung. Was nun passiert hängt von der Antwort auf Punkt zwei ab.
- DNS-Anfragen von den DHCP-Clients (hinter dem DCHP-Server) werden abgewürgt, da keine Weiterleitung durch das Gateway erfolgt
- DNS-Anfragen werden nur gegen Einträge geprüft, die in Statische DNS-Einträge / /ip dns static?
Wäre toll, wenn dieses Rätsel vervollständigt werden könnte, da ich im Handbuch keine Antwort auf meine Frage finde (oder ich bin einfach zu dumm, sie zu finden).
Vielen vielen Dank
Stefan
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667360
Url: https://administrator.de/contentid/667360
Ausgedruckt am: 21.11.2024 um 17:11 Uhr
39 Kommentare
Neuester Kommentar
Moin,
Zitat von @PackElend:
Das steht doch auf der von dir verlinkten Seite genau beschrieben. Dort heißt es:- Die dynamischen Server werden vom IPS DHCP oder vom IPS-bereitgestellten Router bedient. Wenn letzteres der Fall ist, handelt es sich in der RRegel um die Gateway-Adresse des IPS-Routers.
- Wenn in /ip dhcp-server network dns-server nichts eingestellt ist, können die Einstellungen in /ip dns servers und /ip dns dynamic-server an die DHCP-Clients weitergegeben werden, aber welche Server?
- Wenn nur statisch, dann wird immer statisch weitergegeben, unabhängig von /ip dhcp-server network dns-none wie in Manual:IP/DHCP Server - MikroTik Wiki beschrieben?
- Wenn nur dynamisch, dann hängt es von /ip dhcp-server network dns-none ab?
- Wenn beides, werden entweder beide oder nur statische weitergegeben, abhängig von /ip dhcp-server network dns-none?
- Wird /ip dhcp-server network dns-server gesetzt, dann wird/werden diese Server weitergereicht
If set, then DHCP Server will not pass dynamic DNS servers configured on the router to the DHCP clients if no DNS Server in dns-server is set. By default if there are no DNS Servers configured, then the dynamic DNS Servers will be passed to DHCP clients.
Bedeutet: Wenn du statische DNS-Server konfiguriert hast, dann werden diese übergeben, ansonsten werden die dynamischen DNS-Server übergeben oder garkeine, wenn du dns-none auf yes gesetzt hast.# Mir wurde eine Konfiguration gegeben, bei der /ip dhcp-server network dns-server gleich dem /ip dhcp-server network gateway ist. Was passiert hier?
Das ist doch Blödsinn. Das bedeutet lediglich, dass auf dem Gateway auch ein DNS-Dienst laufen sollte, da die Anfragen dorthin weitergereicht werden.- Die Einstellungen, die in /ip dns server und /ip dns dynamic-server angegeben sind, stehen zur Weitergabe an DHCP-Clients zur Verfügung. Was nun passiert hängt von der Antwort auf Punkt zwei ab.
- DNS-Anfragen von den DHCP-Clients (hinter dem DCHP-Server) werden abgewürgt, da keine Weiterleitung durch das Gateway erfolgt
- DNS-Anfragen werden nur gegen Einträge geprüft, die in Statische DNS-Einträge / /ip dns static?
Vielen vielen Dank
Stefan
Gern geschehen...Stefan
Moin Moin,
und gern gelesen am Sonntagmorgen aber ich hätte dennoch zwei Fragen in retour.
Bedeutet: Wenn du statische DNS-Server konfiguriert hast, dann werden diese übergeben, ansonsten werden die dynamischen DNS-Server übergeben oder garkeine, wenn du dns-none auf yes gesetzt hast.
?
Meine Ausführung oder die Konfiguration?
merci und schönen Sonntag
p.s. ich versuche auch nebenbei das Netzwerk in GNS3 aufzubauen aber es hat doch noch einige was ist wenn bei mir und hätte gerne eine ungefähre Idee, wie das Ergebnis aussehen sollte anstatt etwas zu simulieren und das Ergebnis dann als DIE Antwort zu betrachten, obwohl diese evtl. auf eine überehenen Einstellung zurückgeht.
und gern gelesen am Sonntagmorgen aber ich hätte dennoch zwei Fragen in retour.
Bedeutet: Wenn du statische DNS-Server konfiguriert hast, dann werden diese übergeben, ansonsten werden die dynamischen DNS-Server übergeben oder garkeine, wenn du dns-none auf yes gesetzt hast.
Zitat von @BirdyB:
Bedeutet: Wenn du statische DNS-Server konfiguriert hast, dann werden diese übergeben, ansonsten werden die dynamischen DNS-Server übergeben oder garkeine, wenn du dns-none auf yes gesetzt hast.
aber was passiert, wenn beide existiert, welcher wird weitergeben, statisch oder dynamisch oder beide?Bedeutet: Wenn du statische DNS-Server konfiguriert hast, dann werden diese übergeben, ansonsten werden die dynamischen DNS-Server übergeben oder garkeine, wenn du dns-none auf yes gesetzt hast.
Zitat von @BirdyB:
Das ist doch Blödsinn. Das bedeutet lediglich, dass auf dem Gateway auch ein DNS-Dienst laufen sollte, da die Anfragen dorthin weitergereicht werden.
Was ist Blödsinn Das ist doch Blödsinn. Das bedeutet lediglich, dass auf dem Gateway auch ein DNS-Dienst laufen sollte, da die Anfragen dorthin weitergereicht werden.
?Meine Ausführung oder die Konfiguration?
merci und schönen Sonntag
p.s. ich versuche auch nebenbei das Netzwerk in GNS3 aufzubauen aber es hat doch noch einige was ist wenn bei mir und hätte gerne eine ungefähre Idee, wie das Ergebnis aussehen sollte anstatt etwas zu simulieren und das Ergebnis dann als DIE Antwort zu betrachten, obwohl diese evtl. auf eine überehenen Einstellung zurückgeht.
welcher wird weitergeben, statisch oder dynamisch oder beide?
Statisch hat in der IT immer die höchste Priorität. Gilt nicht nur bei DNS, sondern ist auch bei Routing, IP Adressierung usw. usw. der Fall.
merci, dass ging ja fix, eine Frage ist nur noch offen.
Wenn das Tempo so hoch bleibt ist bist heute Abend alles geklärt, supi
Wenn das Tempo so hoch bleibt ist bist heute Abend alles geklärt, supi
Moin,
dass die DNS-Anfragen abgewürgt werden oder nur statische DNS-Einträge aufgelöst werden ergibt doch garkeinen Sinn. Wie ich oben schon geschrieben habe, geht es in deinem Punkt 3 nur darum, dass das Gateway auch gleichzeitig DNS-Server ist, so wie es (fast) jeder Heimrouter tut.
VG
dass die DNS-Anfragen abgewürgt werden oder nur statische DNS-Einträge aufgelöst werden ergibt doch garkeinen Sinn. Wie ich oben schon geschrieben habe, geht es in deinem Punkt 3 nur darum, dass das Gateway auch gleichzeitig DNS-Server ist, so wie es (fast) jeder Heimrouter tut.
VG
Zitat von @BirdyB:
Moin,
dass die DNS-Anfragen abgewürgt werden oder nur statische DNS-Einträge aufgelöst werden ergibt doch garkeinen Sinn. Wie ich oben schon geschrieben habe, geht es in deinem Punkt 3 nur darum, dass das Gateway auch gleichzeitig DNS-Server ist, so wie es (fast) jeder Heimrouter tut.
VG
Danke für die Geduld mit mir.Moin,
dass die DNS-Anfragen abgewürgt werden oder nur statische DNS-Einträge aufgelöst werden ergibt doch garkeinen Sinn. Wie ich oben schon geschrieben habe, geht es in deinem Punkt 3 nur darum, dass das Gateway auch gleichzeitig DNS-Server ist, so wie es (fast) jeder Heimrouter tut.
VG
Ich hätte da noch eine Frage, wie kommen hier DNS Static & Cache von RouterOS ins Spiel?
Gebe immer den Gatway als DNS-Server an, folgt die Anfrage immer der default route, sprich springt von default gatway zu default gatway, bis ein DNS-Server reicht ist. Wenn davor ein Gatetway die DNS im Cache hat, wird abgebrochen und die zugehörige IP zurückgesschickt.
nun aber:
- wem stehen die Information in /ip dns server den ich RouterOS konfiguriere, zur Verfügung?
- jedem Gateway
- sitzt dieser nur auf dem WAN-Interface (da diese die Router zu weiteren DNS-Server ist)?
- jedes mal wenn die CPU mit im Spiel ist, was ja hier immer der Fall ist. In dem Fall ist aber die explizite Angabe des Gateway als DNS-Server hinfällig.
- Wenn ich nun einen DNS-Server, z. B. 1.1.1.1 angebe,
- wird dann weiterhin alle Geräte dazwischen gefragt, ob sie DNS xy kennen oder geht die Anfrage direkt an 1.1.1.1?
- es wird mitgeben, dass wenn eine DNS-Server gefragt werden soll, dies explizit an 1.1.1.1 gehen soll?
Ich denke es wird 2.2 sein aber ich finde nicht wirklich etwas dazu, geschweige denn etwas zu 1.
Was ich bisher gefunden habe:
- https://serverfault.com/questions/729025/what-are-all-the-flags-in-a-dig ...
- https://www.bind9.net/dns-header-flags
- https://www.ibm.com/docs/en/qsip/7.3.3?topic=levels-parsing-dns-query-re ...
- https://www.cloudflare.com/learning/dns/what-is-dns/
- http://www.firewall.cx/networking-topics/protocols/domain-name-system-d ...
Gebe immer den Gatway als DNS-Server an
Das muss man nicht, sinnvoller ist es den MT bzw. dessen IP anzugeben denn der arbeitet ja auch als DNS Cache. funktioniert aber nur wenn der Haken bei IP -> DNS "Allow remote requests" gesetzt ist. Erst das aktiviert den MT eigenen DNS Cache.Das funktioniert dann auf jedem IP Interface des MT.
wird dann weiterhin alle Geräte dazwischen gefragt
Nein, das wäre ja sinnfrei. Gibt es einen positiven Hit zu dem angefragten Host im lokalen Cache wird der DNS lokal beantwortet und nicht mehr weitergeleitet !es wird mitgeben, dass wenn eine DNS-Server gefragt werden soll, dies explizit an 1.1.1.1 gehen soll?
Nein !Den DNS Server den dein Endgerät anfragt ist immer der der ihm statisch oder per DHCP mitgeteilt wird. Gibst du dem Endgerät direkt die 1.1.1.1 als DNS hebelt das natürlich alle lokalen Caches aus und das Endgeräte fragt dann direkt den Server in den USA mit den entsprechenden Laufzeiten und auch dem Schnüffelprofil was diese von dir und deine Internet Gewohnheiten erstellen. Gut Quad 9 ist da etwas friedlicher als Google aber generell sollte man bei US Dienstleistern eine gewisse Skepsis und Vorsicht walten lassen.
Zitat von @aqui:
Gibst du dem Endgerät direkt die 1.1.1.1 als DNS hebelt das natürlich alle lokalen Caches aus und das Endgeräte fragt dann direkt den Server in den USA mit den entsprechenden Laufzeiten und auch dem Schnüffelprofil was diese von dir und deine Internet Gewohnheiten erstellen. Gut Quad 9 ist da etwas friedlicher als Google aber generell sollte man bei US Dienstleistern eine gewisse Skepsis und Vorsicht walten lassen.
Gibst du dem Endgerät direkt die 1.1.1.1 als DNS hebelt das natürlich alle lokalen Caches aus und das Endgeräte fragt dann direkt den Server in den USA mit den entsprechenden Laufzeiten und auch dem Schnüffelprofil was diese von dir und deine Internet Gewohnheiten erstellen. Gut Quad 9 ist da etwas friedlicher als Google aber generell sollte man bei US Dienstleistern eine gewisse Skepsis und Vorsicht walten lassen.
Wenn ich nun dem DHCP-Server eines VLAN nun 1.1.1.1 als DNS-Server gebe, geht jede DNS-Anfrage zu Quad 9 und alle Caches auf der Route dahin werden ignoriert. Dies würde auch heissen, die DNS-Static Einträge werden ignoriert. Dies alles, weil im IPv4 Header der DNS Query Message 1.1.1.1 als Ziel angeben ist.
Korrekt?
Zitat von @aqui:
Das funktioniert dann auf jedem IP Interface des MT.
Sprich alles Einträge in DNS-Static und DNS-Cache werden abgefragt, sobald eine Anfrage an einem Interface ankommt, das damit etwas anfangen kann. Bei einem einfachen Netzwerk wären dies :Gebe immer den Gatway als DNS-Server an
Das muss man nicht, sinnvoller ist es den MT bzw. dessen IP anzugeben denn der arbeitet ja auch als DNS Cache. funktioniert aber nur wenn der Haken bei IP -> DNS "Allow remote requests" gesetzt ist. Erst das aktiviert den MT eigenen DNS Cache.Das funktioniert dann auf jedem IP Interface des MT.
Das wäre dann:
- Bridge, wenn es nicht über den Switch-Chip geht
- Gateway des jeweiligen VLAN
Zitat von @PackElend:
Wenn ich nun dem DHCP-Server eines VLAN nun 1.1.1.1 als DNS-Server gebe, geht jede DNS-Anfrage zu Quad 9 und alle Caches auf der Route dahin werden ignoriert. Dies würde auch heissen, die DNS-Static Einträge werden ignoriert. Dies alles, weil im IPv4 Header der DNS Query Message 1.1.1.1 als Ziel angeben ist.
Korrekt?
Verabschiede dich doch mal von dem Thema mit der Route. Das ist ein anderes Layer. Wenn du als DNS-Server die 1.1.1.1 mitgibst, wird der Client seine DNS-Anfragen an die 1.1.1.1 senden. Wenn ich im Mailprogramm als IMAP-Server mail.gmx.net eingebe, holt das Mailprogramm die Mails ja auch von dem GMX-Server und nicht von irgendwo dazwischen.Zitat von @aqui:
Gibst du dem Endgerät direkt die 1.1.1.1 als DNS hebelt das natürlich alle lokalen Caches aus und das Endgeräte fragt dann direkt den Server in den USA mit den entsprechenden Laufzeiten und auch dem Schnüffelprofil was diese von dir und deine Internet Gewohnheiten erstellen. Gut Quad 9 ist da etwas friedlicher als Google aber generell sollte man bei US Dienstleistern eine gewisse Skepsis und Vorsicht walten lassen.
Gibst du dem Endgerät direkt die 1.1.1.1 als DNS hebelt das natürlich alle lokalen Caches aus und das Endgeräte fragt dann direkt den Server in den USA mit den entsprechenden Laufzeiten und auch dem Schnüffelprofil was diese von dir und deine Internet Gewohnheiten erstellen. Gut Quad 9 ist da etwas friedlicher als Google aber generell sollte man bei US Dienstleistern eine gewisse Skepsis und Vorsicht walten lassen.
Wenn ich nun dem DHCP-Server eines VLAN nun 1.1.1.1 als DNS-Server gebe, geht jede DNS-Anfrage zu Quad 9 und alle Caches auf der Route dahin werden ignoriert. Dies würde auch heissen, die DNS-Static Einträge werden ignoriert. Dies alles, weil im IPv4 Header der DNS Query Message 1.1.1.1 als Ziel angeben ist.
Korrekt?
Und wenn der DNS-Server den dein Client fragt die statischen Einträge nicht kennt, kann er auch nix zurückliefern. Das hat nichts mit "ignorieren" zu tun.
Zitat von @aqui:
Das funktioniert dann auf jedem IP Interface des MT.
Gebe immer den Gatway als DNS-Server an
Das muss man nicht, sinnvoller ist es den MT bzw. dessen IP anzugeben denn der arbeitet ja auch als DNS Cache. funktioniert aber nur wenn der Haken bei IP -> DNS "Allow remote requests" gesetzt ist. Erst das aktiviert den MT eigenen DNS Cache.Das funktioniert dann auf jedem IP Interface des MT.
Sprich alles Einträge in DNS-Static und DNS-Cache werden abgefragt, sobald eine Anfrage an einem Interface ankommt, das damit etwas anfangen kann. Bei einem einfachen Netzwerk wären dies :
Das wäre dann:
Das Interface kann mit den Anfragen nichts anfangen. Der Mikrotik wird dann einfach zum DNS-Server. Hat er einen statischen Eintrag zur Anfrage, liefert er diesen zurück. Wenn das nicht zutrifft, schaut er in den Cache, ob er dort einen Eintrag hat und liefert diesen zurück und wenn auch das nicht der Fall ist, fragt der Mikrotik den DNS-Server den du dort konfiguriert hast, bzw. den er per DHCP erhalten hat.Das wäre dann:
- Bridge, wenn es nicht über den Switch-Chip geht
- Gateway des jeweiligen VLAN
geht jede DNS-Anfrage zu Quad 9 und alle Caches auf der Route dahin werden ignoriert. Dies würde auch heissen, die DNS-Static Einträge werden ignoriert.
Richtig !Sprich alles Einträge in DNS-Static und DNS-Cache werden abgefragt, sobald eine Anfrage an einem Interface ankommt,
Richtig !Den Rest hat Kollege @BirdyB ja oben schon ausführlich erklärt.
JUHU
danke euch!
danke euch!
Tip:
Schmeiss mal den Wireshark auf deinem Rechner an. Dort kannst du explizit die genaue DNS Kommunikation ansehen und wie diese abläuft.
Ein Bild sagt bekanntlich mehr als 1000 Worte... 😉
Schmeiss mal den Wireshark auf deinem Rechner an. Dort kannst du explizit die genaue DNS Kommunikation ansehen und wie diese abläuft.
Ein Bild sagt bekanntlich mehr als 1000 Worte... 😉
bau mir gerade alles in GNS3 auf aber bin wahnsinnig geworden mit den VMs habe aber nun Tiny Core Linux worin mir Winbox läuft, wollte nun keine 2GB+ VM verwenden rein hiefür. Möchte das MGMT-VLAN realitätsnah testen
Wireshark über den ganzen Router soll dann auch komme, um zu sehen/lernen was wirklich passiert, wollte aber in etwa wissen, was passiert.
Wireshark über den ganzen Router soll dann auch komme, um zu sehen/lernen was wirklich passiert, wollte aber in etwa wissen, was passiert.
Zitat von @aqui:
>> Gebe immer den Gatway als DNS-Server an
Das muss man nicht, sinnvoller ist es den MT bzw. dessen IP anzugeben denn der arbeitet ja auch als DNS Cache. funktioniert aber nur wenn der Haken bei IP -> DNS "Allow remote requests" gesetzt ist. Erst das aktiviert den MT eigenen DNS Cache.
Das funktioniert dann auf jedem IP Interface des MT.
tut mir leid ich muss hier nochmals nachbohren, da ich ich gerade etwas unsicher bin, was ich nun als DNS-Sever in die DHCP-Server eintrage und mich die Aussage gerade etwas verwirrt.>> Gebe immer den Gatway als DNS-Server an
Das muss man nicht, sinnvoller ist es den MT bzw. dessen IP anzugeben denn der arbeitet ja auch als DNS Cache. funktioniert aber nur wenn der Haken bei IP -> DNS "Allow remote requests" gesetzt ist. Erst das aktiviert den MT eigenen DNS Cache.
Das funktioniert dann auf jedem IP Interface des MT.
Ich gehe davon aus, damit ist die IP des Management-VLAN-Interface gemeint aber warum nur dieses?
Der Zugriff auf die CPU passiert doch aus allen VLAN-Interfaces heraus, soweit im VLAN-Table das jewellige VLAN auch die bridge als tagged-port beinhaltet, was die m E. die Regel ist, ausser im VLAN ist alles statisch und kein routing verlangt (VLANs on Mikrotik Routers post 6.41 firmware | Andisa IT).
Hinzu kommt, dass in der Regel die gleiche IP für den Gateway eingetragen ist, wie die IP des des Interfaces. Da nun die Route für das Interface bekannt ist durch die Adressierung des Interfaces (anderen Gateways müsste ich dann als statische Routen eintragen), läuft das ganze hin und her auch sauber.
Somit geht jede Anfrage, welche die Bridge verlässt beim DNS-Server des MT vorbei, ausser es ist externe DNS-Server konfiguriert.
damit ist die IP des Management-VLAN-Interface gemeint aber warum nur dieses?
Nein ist damit nicht gemeint. Du kannst jedes IP Interface dafür nehmen. In der Regel ist es natürlich immer das IP Interfaces des MT in dem jeweiligen Client VLAN.Sobald man den Haken "Allow remote requests" setzt arbeitet der MT global als DNS Proxy bzw. Server.
Zitat von @aqui:
In der Regel ist es natürlich immer das IP Interfaces des MT in dem jeweiligen Client VLAN.
dann reden wir eigentlich vom gleichen In der Regel ist es natürlich immer das IP Interfaces des MT in dem jeweiligen Client VLAN.
DNS-Server-IP = VLAN-Interface-IP
Jepp, richtig !
Hoi,
ich muss hier nochmal zurückkommen, da ich OpenDNS Server als DNS im Router eingetragen habe und ich mir nicht sicher bin, ob das s wirklich alles so funktioniert, wie besprochen.
Wenn ich auf https://support.opendns.com/hc/en-us/articles/227986567-How-to-test-for- ... teste, ist alles in Ordnung.
Wenn ich aber Seiten öffne (DNS Chache wurde geleert), welche eigentlich gesperrt sein sollten, öffnen diese doch ganz normal.
Habe dann mal
da sind die OpenDNS-Server 208.67.222.222 und 208.67.220.220 gar nicht aufgelistet, was evtl. der Grund ist, warum die Sperre nicht so läuft, wie sie sollte.
Eine Idee was hier schiefläuft
CLIENT (im VLAN99 für Testzwecke):
DNS SERVER
ich muss hier nochmal zurückkommen, da ich OpenDNS Server als DNS im Router eingetragen habe und ich mir nicht sicher bin, ob das s wirklich alles so funktioniert, wie besprochen.
Wenn ich auf https://support.opendns.com/hc/en-us/articles/227986567-How-to-test-for- ... teste, ist alles in Ordnung.
Wenn ich aber Seiten öffne (DNS Chache wurde geleert), welche eigentlich gesperrt sein sollten, öffnen diese doch ganz normal.
Habe dann mal
dig, https://help.dyn.com/how-to-use-binds-dig-tool/ folgend, aufgespielt und bekomme ich folgendes:C:\Program Files\ISC BIND 9>dig internetende.de +trace +noall +answer
. 515702 IN NS i.root-servers.net.
. 515702 IN NS j.root-servers.net.
. 515702 IN NS k.root-servers.net.
. 515702 IN NS l.root-servers.net.
. 515702 IN NS m.root-servers.net.
. 515702 IN NS a.root-servers.net.
. 515702 IN NS b.root-servers.net.
. 515702 IN NS c.root-servers.net.
. 515702 IN NS d.root-servers.net.
. 515702 IN NS e.root-servers.net.
. 515702 IN NS f.root-servers.net.
. 515702 IN NS g.root-servers.net.
. 515702 IN NS h.root-servers.net.
;; Received 813 bytes from 10.99.99.1#53(10.99.99.1) in 28 ms
;; Received 779 bytes from 192.36.148.17#53(i.root-servers.net) in 23 ms
;; Received 616 bytes from 81.91.164.5#53(f.nic.de) in 10 ms
internetende.de. 10800 IN A 109.237.138.8
;; Received 60 bytes from 148.251.254.105#53(cns2.alfahosting.info) in 22 msC:\Program Files\ISC BIND 9>dig pornhub.com +trace +noall +answer
. 515172 IN NS f.root-servers.net.
. 515172 IN NS g.root-servers.net.
. 515172 IN NS h.root-servers.net.
. 515172 IN NS i.root-servers.net.
. 515172 IN NS j.root-servers.net.
. 515172 IN NS k.root-servers.net.
. 515172 IN NS l.root-servers.net.
. 515172 IN NS m.root-servers.net.
. 515172 IN NS a.root-servers.net.
. 515172 IN NS b.root-servers.net.
. 515172 IN NS c.root-servers.net.
. 515172 IN NS d.root-servers.net.
. 515172 IN NS e.root-servers.net.
;; Received 813 bytes from 10.99.99.1#53(10.99.99.1) in 12 ms
;; Received 1171 bytes from 199.7.83.42#53(l.root-servers.net) in 7 ms
;; Received 844 bytes from 192.43.172.30#53(i.gtld-servers.net) in 9 ms
pornhub.com. 3600 IN A 66.254.114.41
;; Received 56 bytes from 198.51.45.3#53(dns2.p03.nsone.net) in 11 msC:\Program Files\ISC BIND 9>tracert pornhub.com
Détermination de l’itinéraire vers pornhub.com [66.254.114.41]
avec un maximum de 30 sauts :
1 21 ms 7 ms 1 ms 10.99.99.1
2 1 ms 3 ms 3 ms fritzbox.kuerberg.ch [192.168.66.1]
3 26 ms 3 ms 2 ms 217.22.136.2
4 10 ms 20 ms 16 ms 212.25.27.122
5 78 ms 4 ms 2 ms grace.glb.as8758.net [212.25.28.238]
6 11 ms 3 ms 1 ms te0-3-1-3.rcr51.b021037-0.zrh02.atlas.cogentco.com [149.6.177.45]
7 3 ms 2 ms 3 ms be2395.ccr52.zrh02.atlas.cogentco.com [130.117.50.25]
8 292 ms 42 ms 82 ms be3073.ccr22.muc03.atlas.cogentco.com [130.117.0.62]
9 14 ms 21 ms 13 ms be2960.ccr42.fra03.atlas.cogentco.com [154.54.36.253]
10 43 ms 47 ms 15 ms haproxy.demarc.cogentco.com [149.29.8.2]
11 12 ms 11 ms 10 ms cust-reflected-svc11802.ip.reflected.net [66.254.122.141]
12 12 ms 18 ms 15 ms reflectededge.reflected.net [66.254.114.41]
Itinéraire déterminé.da sind die OpenDNS-Server 208.67.222.222 und 208.67.220.220 gar nicht aufgelistet, was evtl. der Grund ist, warum die Sperre nicht so läuft, wie sie sollte.
Eine Idee was hier schiefläuft
CLIENT (im VLAN99 für Testzwecke):
Adresse IPv6 locale du lien : fe80::997f:70f6:408e:ac18%18
Adresse IPv4 : 10.99.99.243
Serveurs DNS IPv4 :10.99.99.1/ip dhcp-server> print where name=VLAN_099_DHCP
Flags: D - dynamic, X - disabled, I - invalid
# NAME INTERFACE RELAY ADDRESS-POOL LEASE-TIME ADD-ARP
0 VLAN_099_DHCP VLAN_099 VLAN_099 10m
print where comment~"^BASE"
Flags: D - dynamic
# ADDRESS GATEWAY DNS-SERVER WINS-SERVER DOMAIN
0 ;;; BASE (MGMT) VLAN
10.99.99.0/24 10.99.99.1 10.99.99.1 DNS SERVER
/ip dns> print
servers: 208.67.222.222,208.67.220.220
dynamic-servers:
use-doh-server:
verify-doh-cert: no
allow-remote-requests: yes
max-udp-packet-size: 4096
query-server-timeout: 2s
query-total-timeout: 10s
max-concurrent-queries: 100
max-concurrent-tcp-sessions: 20
cache-size: 2048KiB
cache-max-ttl: 1w
cache-used: 332KiB
Ist eigentlich alles richtig.
Du kannst das ja mal querchecken indem du die OpenVPN DNS IP Adressen statisch mal temporär direkt im Client konfigurierst.
Damit erzwingst du dann ja direkt im Client die OpenDNS Adress Nutzung und spätestens dann sollte ja der DNS Filter greifen.
Natürlich nur wenn du vorher auch den lokalen DNS Cache löschst und zwar im Client und Router !
Ob es sinnvoll ist DNS Requests um die halbe Welt auf US Server mit kommerziellen Absichten zu schicken musst du dir selber beantworten. Sinniger ist hier immer der eigene DNS Filter wie PiHole oder noch besser AdGuard auf einem RasPi unter eigener Hoheit zu nutzen. Das drückt die DNS Wartezeit auf quasi Null und filtert dir außer nackigen Menschen auch noch alles an Malware, Trojaner und Werbung raus ! Alles anonym via DoT oder DoH und auch noch alles mit einer grafischen Statistik mit der du die Filterfunktion komplett überwachen kannst bis auf Client Ebene. Was will man mehr ?!
- Client hat MT IP Adresse und damit rennt der MT als DNS Proxy
- MT selber hat die OpenVPN IP
Du kannst das ja mal querchecken indem du die OpenVPN DNS IP Adressen statisch mal temporär direkt im Client konfigurierst.
Damit erzwingst du dann ja direkt im Client die OpenDNS Adress Nutzung und spätestens dann sollte ja der DNS Filter greifen.
Natürlich nur wenn du vorher auch den lokalen DNS Cache löschst und zwar im Client und Router !
Ob es sinnvoll ist DNS Requests um die halbe Welt auf US Server mit kommerziellen Absichten zu schicken musst du dir selber beantworten. Sinniger ist hier immer der eigene DNS Filter wie PiHole oder noch besser AdGuard auf einem RasPi unter eigener Hoheit zu nutzen. Das drückt die DNS Wartezeit auf quasi Null und filtert dir außer nackigen Menschen auch noch alles an Malware, Trojaner und Werbung raus ! Alles anonym via DoT oder DoH und auch noch alles mit einer grafischen Statistik mit der du die Filterfunktion komplett überwachen kannst bis auf Client Ebene. Was will man mehr ?!
1Zitat von @aqui:
Natürlich nur wenn du vorher auch den lokalen DNS Cache löschst und zwar im Client und Router !
Meinte hätte ich alles gemacht, es gibt aber auch Foreneinträge das der Prono-Filter nicht immer geht.Natürlich nur wenn du vorher auch den lokalen DNS Cache löschst und zwar im Client und Router !
Fange da nochmal von vorne mit der Testreihe an und gehe dann ins openDNS Forum für Fragen.
Zitat von @aqui:
Ob es sinnvoll ist DNS Requests um die halbe Welt auf US Server mit kommerziellen Absichten zu schicken musst du dir selber beantworten. Sinniger ist hier immer der eigene DNS Filter wie PiHole oder noch besser AdGuard auf einem RasPi unter eigener Hoheit zu nutzen.
habe ich im Hinterkopf aber erstmal das grundlegende Netzwerk zum laufen bringen, siehe MikroTik: kaskadisches Core-Netzwerk CCR-CRS-CRS mit Satelliten-Swichtes+APs - ein Versuch einer Anleitung von A-Z.Ob es sinnvoll ist DNS Requests um die halbe Welt auf US Server mit kommerziellen Absichten zu schicken musst du dir selber beantworten. Sinniger ist hier immer der eigene DNS Filter wie PiHole oder noch besser AdGuard auf einem RasPi unter eigener Hoheit zu nutzen.
Eventuell werde für die Arbeit zwei, drei Boards von https://connecttech.com/products/ oder https://up-board.org/up-squared-pro/ anschaffen und würde eines von diesen nachher als Firewall verwenden. (Könnte ich auch privat beschaffen aber dann dauert es länger, die Tests mit den Geräten für die Arbeit macht es drängender
)
Moin,
zum Thema Boards:
Schau dir mal das APU4D4 an: https://www.varia-store.com/de/produkt/103299-pc-engines-apu4d4-starter- ...
VG
zum Thema Boards:
Schau dir mal das APU4D4 an: https://www.varia-store.com/de/produkt/103299-pc-engines-apu4d4-starter- ...
VG
1Zitat von @BirdyB:
Schau dir mal das APU4D4 an: https://www.varia-store.com/de/produkt/103299-pc-engines-apu4d4-starter- ...
mach ich danke.Schau dir mal das APU4D4 an: https://www.varia-store.com/de/produkt/103299-pc-engines-apu4d4-starter- ...
Auf die von mir genannten bin ich wegen https://www.balena.io/ gelandet (deren OS wegen dem Docker&IoT-Ansatz). Ist die Frage, ob ich darauf zum Laufen bekomme aber generisches amd64 images hat es. Alternative hat es noch promox etc.
Ah, okay. Ich dachte jetzt wegen des Firewall-Themas…
ist schon richtig, erstmal muss ich meine test machen und dann werden die Geräte wohl verstauben. Daher kann ich danach durchaus für die Firewall verwenden.
Können auch unterschiedliche Geräte bestellt werden.
Können auch unterschiedliche Geräte bestellt werden.
Zitat von @aqui:
welcher wird weitergeben, statisch oder dynamisch oder beide?
Statisch hat in der IT immer die höchste Priorität. Gilt nicht nur bei DNS, sondern ist auch bei Routing, IP Adressierung usw. usw. der Fall.jetzt wird es spannend rextended sagt mir auf MikroTik Forum das Gegenteil
.
Pauschal kann man das nie sagen, denn es hängt letztlich immer vom Setup des Gerätes ab. Bei einer pfSense oder OPNsense Firewall z.B. ist das dediziert einstellbar ob man möchte das dynamisch erlernte DNS Server die statisch definierten überschreibt. Bzw. wie bei einem Gerät dieses Funktion als Default gesetzt ist.
1Zitat von @BirdyB:
Moin,
zum Thema Boards:
Schau dir mal das APU4D4 an: https://www.varia-store.com/de/produkt/103299-pc-engines-apu4d4-starter- ...
VG
Moin,
zum Thema Boards:
Schau dir mal das APU4D4 an: https://www.varia-store.com/de/produkt/103299-pc-engines-apu4d4-starter- ...
VG
mache mich gerade auf die Hardwaresuche, das APU4D4 ist aber erst 2022 wieder lieferbar, habe noch mit dem Hersteller gesprochen. Varia-Store wird nun die Lieferzeit anpassen, sie hatte auch nichts auf Lager.
https://www.pcengines.ch/newshop.php?c=48881
Versuche nun mein Glück mit boards von ODYSSEY oder ASRock Industry, mir fällt gerade nichts besseres ein als sonst PIs zu nehmen und warten bis 2022
APU1 oder APU2 können es genau so gut. Oder die Teile von IPU Systems.
Guckst du dazu auch hier
PFSense Hardware
Guckst du dazu auch hier
PFSense Hardware
1
Ja, die funktioniert genau so gut (basiert auf dem Klassiker iptables) und bietet noch einiges an Features mehr. Allerdings ist die Lernkurve zur Konfig etwas steiler.
dann versuche es gerade mal hier, habt ihr dazu eine Idee MikroTik: NAT Masquerade kann ungewollt private IP weitergeben aber warum?
Support hat bisher noch nicht geantwortet und im MT-Forum kommt man auch nicht zum Punkt
Support hat bisher noch nicht geantwortet und im MT-Forum kommt man auch nicht zum Punkt
Solange eine Session aktiv ist bleibt auch das NAT aktiv. Egal was das Ruleset sagt. Das stoppt erst wenn die Session geschlossen wurde oder man die NAT Session Table löscht oder resettet.
Ich habe von MT dazu eine Antwort erhalten, siehe MikroTik: NAT Masquerade kann ungewollt private IP weitergeben aber warum?
Das passt nicht ganz zu deiner Aussage.
Zufällig einen Vorschlag, wie ich MT-Support aus der Reserve locken kann, so dass wir ein paar mehr Details erfahren?
Das passt nicht ganz zu deiner Aussage.
Zufällig einen Vorschlag, wie ich MT-Support aus der Reserve locken kann, so dass wir ein paar mehr Details erfahren?
Das passt nicht ganz zu deiner Aussage.
Jein... Wenn es eine statische Route oder eine connected Route (lokales Interface) gibt hat die natürlich immer absoluten Vorrang VOR der Default Route egal welche Distance gesetzt ist.Entscheidend ist dafür einzig die kleinere Subnetzmaske, der sog. Longest Prefix Match
https://de.wikipedia.org/wiki/Longest_Prefix_Match
Der gilt wie bei allen anderen auch für Mikrotik !
ich denke die Länge der Subnetzmaske ist bei ISP durchaus gleich und beides wären ja statische Routen. Meiner Ansicht wäre der primary Link höchsten die Default Route.
MT sagt ja explizit, dass ein verschieben aktiver Verbindungen von einer Router auf eine andere Route stattfindet, wenn dessen Distance kürzer ist (es gibt keine weiteren Zusatzinformationen abers etc.)
Gibt es irgendetwas aus der welt von iptables etc. was dieses Vorgehen rechtfertig oder erklärt, bzw. etwas, was dagegenspricht?
MT sagt ja explizit, dass ein verschieben aktiver Verbindungen von einer Router auf eine andere Route stattfindet, wenn dessen Distance kürzer ist (es gibt keine weiteren Zusatzinformationen abers etc.)
Gibt es irgendetwas aus der welt von iptables etc. was dieses Vorgehen rechtfertig oder erklärt, bzw. etwas, was dagegenspricht?
wenn dessen Distance kürzer ist
Dann müsste die Distance aber dynamisch mitgesendet werden und in der Routing Tabelle ja auch sichtbar sein. Ist möglich bei dynamischen Routing Protokollen und (vermutlich) wenn das die dynamische Default Route per PPP ist. Bei deiner statischen z.B. bei einem Policy Routing ist diese aber immer gleich.
von diesen Details wird in https://help.mikrotik.com/docs/display/ROS/NAT#NAT-Masquerade nicht gesprochen, es klingt eher danach, als setzt sich ROS über all das vorhin erwähnte hinweg???
Gibt es irgendetwas, was Bezug darauf nimmt, das bei aktiven Sessions die Route gewechselt werden kann (ohne explizite Policies)?
Gibt es irgendetwas, was Bezug darauf nimmt, das bei aktiven Sessions die Route gewechselt werden kann (ohne explizite Policies)?
wie wäre es mit https://www.seeedstudio.com/Odyssey-Blue-J4125-128GB-p-4921.html, den finde ich ein Europa noch auf Lager und ist preislich noch gut platziert.
