Linuxrouter mit zwei Netzen (Clients in Netz A kommen nicht an DNS in Netz B)
Ich habe aus der Not heraus (Admin ist abgesprungen) ein ehrenamtliches Vereinsnetzwerk uebernommen in dem es ein paar Probleme gibt wo ich bevor ich groß Hand anlege ein paar Fragen habe zu dem was ich mir denke.
Ich bin in Sachen Netzwerk Neueinsteiger.
Hallo,
Folgende Situation:
1. Linuxserver/-router/-proxy/-firewall (OpenSUSE 11.2) der an der DSL Leitung haengt und fuer alle Netze und deren Clients ua. die Internetverbindung herstellt. [Funktioniert]
2. Netzwerk A = Ein Mac Server der am Linuxserver haengt und wiederrum via Switch ein Clientnetz (auch Macs, DHCP kommt vom Mac Server) unterhaelt. Auf dem Mac Server laeuft auch ein interner DNS Server, Intranet Webserver, LDAP, usw.
3. Netzwerk B = Viele Windows Clients die direkt am Linuxserver haengen (ueber einen Switch)
- Der Linuxserver selbst und 'Netzwerk A' laufen ganz gut zusammen, Internetverbindung usw. klappt.
- 'Netzwerk B' laeuft mit der Linuxkiste auch gut, die Clients kommen ins Internet, die DHCP Vergabe vom Linuxserver geht.
Jedoch funktioniert das Spiel zwischen den Netzen nicht so richtig, im speziellen faellt das beim DNS auf.
Der Linuxserver uebergibt an seine Windows Clients in 'Netz B' via DHCP den Nameserver aus 'Netz A' (Mac Server) da dieser einmal die internen DNS Zonen bereit haelt und ansonsten auch auch die externen Aufloesungen/Requests macht. Fuer die Mac Clients im 'Netz A' funktioniert das auch perfekt. Die Windowsclients aus 'Netz B' bekommen aber Timeouts bzw. fehlerhafte Antworten (siehe unten).
Die Windowsclients aus B haben entweder die Moeglichkeit den Nameservereintrag so zu lassen wie er ist, dann koennen sie die _internen_ Zonen bzw. deren Domainnamen/Subdomains erfolgreich aufloesen, aber alle externen Domains gehen nicht, oder aber sie aendern den Nameserver in den IP-Einstellungen auf die IP vom Linuxserver oder direkt einen externen DNS Server, dann koennen sie externe DNS Anfragen aufloesen aber eben nicht die internen die auf dem Mac Server liegen.
Hier eine Beispielkonfiguration eines Windows Clients ('Netz B'):
Ein nslookup auf diesem Client, gerichtet an den DNS Server in 'Netz A':
Frage:
- Warum verweist er auf die IP 192.168.3.123 die nirgends definiert ist und auch nicht existent?
Dadurch kam ich auf ein eventuelles Netmask Problem. Was mir schon von Anfang an komisch vorkam ist die Netmask von 255.255.252.0, diese wird fuer das Netz A und B verwendet, 192.168.49.x und 192.168.59.x, aber damit diese beiden sich am Ende im gleichen Netz befinden ist diese Netmask doch zu klein, oder nicht? Muesste das nicht viel mehr mindestens 255.255.240.0 sein also /20? Ein routing zwischen den beiden Netzen kann ich zumindest nicht ausmachen, hier ein paar Daten auf der Linux Kiste:
Zweiter Anhaltspunkt ist folgender, ich habe auf der Linuxkiste mal tcpdump ein bisschen mitlaufen lassen und mit Wireshark versucht auszuwerten.
Auffaellig war das wenn versucht wurde im 'Netz B' (Windows Clients) eine Webseite aufzurufen der DNS Request der jeweiligen Domain raus ging an den Mac Server (DNS) in 'Netz A' und dieser auch etwas antwortete, hier der response:
Frage:
- Auf dem Mac Server gibt es bei den DNS Settings die Einstellung => "Accept recursive queries from the following networks" <= dort steht aktuell nur "localnets" drin, wenn ich dort "192.168.0.0/16" eintrage, muesste er doch auf saemtliche Anfragen aus der Range um 192.168.0.0/16 reagieren, also auch aus 'Netz B', oder?
(Grund warum ich das Frage und nicht direkt ausprobiere ist das der Mac Server seinen 'eigenen bezahlten Admin' hat und ich keinen Zugriff, aber jener Admin felsenfest meint es liegt nicht an seinem Mac Server ... bevor ich ihn also konfrontiere will ich das abklaeren ob ich richtig liege.)
So, vielen Dank erstmal, hoffentlich kann mir einer helfen.
Ich bin in Sachen Netzwerk Neueinsteiger.
Hallo,
Folgende Situation:
1. Linuxserver/-router/-proxy/-firewall (OpenSUSE 11.2) der an der DSL Leitung haengt und fuer alle Netze und deren Clients ua. die Internetverbindung herstellt. [Funktioniert]
2. Netzwerk A = Ein Mac Server der am Linuxserver haengt und wiederrum via Switch ein Clientnetz (auch Macs, DHCP kommt vom Mac Server) unterhaelt. Auf dem Mac Server laeuft auch ein interner DNS Server, Intranet Webserver, LDAP, usw.
3. Netzwerk B = Viele Windows Clients die direkt am Linuxserver haengen (ueber einen Switch)
- Der Linuxserver selbst und 'Netzwerk A' laufen ganz gut zusammen, Internetverbindung usw. klappt.
- 'Netzwerk B' laeuft mit der Linuxkiste auch gut, die Clients kommen ins Internet, die DHCP Vergabe vom Linuxserver geht.
Jedoch funktioniert das Spiel zwischen den Netzen nicht so richtig, im speziellen faellt das beim DNS auf.
Der Linuxserver uebergibt an seine Windows Clients in 'Netz B' via DHCP den Nameserver aus 'Netz A' (Mac Server) da dieser einmal die internen DNS Zonen bereit haelt und ansonsten auch auch die externen Aufloesungen/Requests macht. Fuer die Mac Clients im 'Netz A' funktioniert das auch perfekt. Die Windowsclients aus 'Netz B' bekommen aber Timeouts bzw. fehlerhafte Antworten (siehe unten).
Die Windowsclients aus B haben entweder die Moeglichkeit den Nameservereintrag so zu lassen wie er ist, dann koennen sie die _internen_ Zonen bzw. deren Domainnamen/Subdomains erfolgreich aufloesen, aber alle externen Domains gehen nicht, oder aber sie aendern den Nameserver in den IP-Einstellungen auf die IP vom Linuxserver oder direkt einen externen DNS Server, dann koennen sie externe DNS Anfragen aufloesen aber eben nicht die internen die auf dem Mac Server liegen.
Hier eine Beispielkonfiguration eines Windows Clients ('Netz B'):
>>> Hostname. . . . . . . . . . . . . : Win_004
>>> Primäres DNS-Suffix . . . . . . . :
>>> Knotentyp . . . . . . . . . . . . : Hybrid
>>> IP-Routing aktiviert. . . . . . . : Nein
>>> WINS-Proxy aktiviert. . . . . . . : Nein
>>> DNS-Suffixsuchliste . . . . . . . : verein.lan
>>>
>>> Ethernetadapter LAN-Verbindung:
>>>
>>> Verbindungsspezifisches DNS-Suffix: verein.lan
>>> Beschreibung. . . . . . . . . . . : Realtek RTL8139/810x Family Fast Ethernet NIC
>>> Physikalische Adresse . . . . . . : 00-30-05-EB-C6-C8
>>> DHCP aktiviert. . . . . . . . . . : Ja
>>> Autokonfiguration aktiviert . . . : Ja
>>> IP-Adresse. . . . . . . . . . . . : 192.168.59.20 (Client IP)
>>> Subnetzmaske. . . . . . . . . . . : 255.255.252.0
>>> Standardgateway . . . . . . . . . : 192.168.59.254 (Linuxserver)
>>> DHCP-Server . . . . . . . . . . . : 192.168.59.254 (Linuxserver)
>>> DNS-Server. . . . . . . . . . . . : 192.168.49.1 (Mac Server in 'Netz A')
>>> Primärer WINS-Server. . . . . . . : 192.168.49.1 (Mac Server in 'Netz A')
Ein nslookup auf diesem Client, gerichtet an den DNS Server in 'Netz A':
>>> C:\>nslookup google.de 192.168.49.1
>>> DNS request timed out.
>>> timeout was 2 seconds.
>>> *** Der Servername für die Adresse 192.168.3.123 konnte nicht gefunden werden:
>>> Timed out
>>> Server: UnKnown
>>> Address: 192.168.3.123
Frage:
- Warum verweist er auf die IP 192.168.3.123 die nirgends definiert ist und auch nicht existent?
Dadurch kam ich auf ein eventuelles Netmask Problem. Was mir schon von Anfang an komisch vorkam ist die Netmask von 255.255.252.0, diese wird fuer das Netz A und B verwendet, 192.168.49.x und 192.168.59.x, aber damit diese beiden sich am Ende im gleichen Netz befinden ist diese Netmask doch zu klein, oder nicht? Muesste das nicht viel mehr mindestens 255.255.240.0 sein also /20? Ein routing zwischen den beiden Netzen kann ich zumindest nicht ausmachen, hier ein paar Daten auf der Linux Kiste:
>>> linux:~ # route -n
>>> Destination Gateway Genmask Flags Metric Ref Use Iface
>>> xxx.xxx.xxx.xxx 0.0.0.0 255.255.255.255 UH 0 0 0 dsl0
>>> 192.168.22.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
>>> 192.168.33.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
>>> 192.168.59.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
>>> 192.168.49.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
>>> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
>>> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
>>> 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 dsl0
Zweiter Anhaltspunkt ist folgender, ich habe auf der Linuxkiste mal tcpdump ein bisschen mitlaufen lassen und mit Wireshark versucht auszuwerten.
Auffaellig war das wenn versucht wurde im 'Netz B' (Windows Clients) eine Webseite aufzurufen der DNS Request der jeweiligen Domain raus ging an den Mac Server (DNS) in 'Netz A' und dieser auch etwas antwortete, hier der response:
>>> Standard query response, Refused
>>> Flags 0x8105 => .... .... 0... .... = Recursion available: Server can't do recursive queries
Frage:
- Auf dem Mac Server gibt es bei den DNS Settings die Einstellung => "Accept recursive queries from the following networks" <= dort steht aktuell nur "localnets" drin, wenn ich dort "192.168.0.0/16" eintrage, muesste er doch auf saemtliche Anfragen aus der Range um 192.168.0.0/16 reagieren, also auch aus 'Netz B', oder?
(Grund warum ich das Frage und nicht direkt ausprobiere ist das der Mac Server seinen 'eigenen bezahlten Admin' hat und ich keinen Zugriff, aber jener Admin felsenfest meint es liegt nicht an seinem Mac Server ... bevor ich ihn also konfrontiere will ich das abklaeren ob ich richtig liege.)
So, vielen Dank erstmal, hoffentlich kann mir einer helfen.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 156917
Url: https://administrator.de/forum/linuxrouter-mit-zwei-netzen-clients-in-netz-a-kommen-nicht-an-dns-in-netz-b-156917.html
Ausgedruckt am: 23.12.2024 um 07:12 Uhr
2 Kommentare
Neuester Kommentar
bevor ich ihn also konfrontiere will ich das abklaeren ob ich richtig liege.
Hört sich soweit ok an, aber warum ist der Mac Server als WINS-Server eingetragen?
Was mir schon von Anfang an komisch vorkam ist die Netmask von 255.255.252.0
Der Router benutzt die 255.255.255.0 und im Netzwerk hat sich alles nach dem Router zu richten
Hier stehen nochmal die Grundlagen dazu:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router