DNS-Forwarder für ganz bestimmte Netzwerkadresse
Hallo zusammen, nachdem ich nun zwei LAN's erfolgreich mit OpenVPN verbunden habe möchte ich das ganzenun etwas komfortabler machen. Das VPN-Gateway, welches auch gleichzeigt das Internet-Gateway im LAN1 ist, wählt sich als VPN-CLient in LAN2 ein. Alle Hosts in LAN1 können alle Hosts in LAN2 ansprechen. Umgekehrt ist es nicht erwünscht und auch deaktiviert. Das VPN-Gateway in LAN1 ist auch der Server der in LAN1 als DHCP / DNS -Server fungiert. Die Netzwerkadresse ist 192.168.0.0/24. Die Netzwerkadresse in LAN2 ist 192.168.111.0/24. Im LAN2 steht ebenfalls ein DNS-Server und genau diesen würde ichgerne aus LAN1 benutzen. Sehe ich das richtig das ich hierzu den DNS in LAN1 als Slave von LAN2 einrichten muß? -- Sven Gehr Benderstrasse 34 77815 Bühl Fon: +49.7223.250265 -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Am Mittwoch, 14. Juni 2006 11:48 schrieb Sven Gehr:
nachdem ich nun zwei LAN's erfolgreich mit OpenVPN verbunden habe möchte ich das ganzenun etwas komfortabler machen. Das VPN-Gateway, welches auch gleichzeigt das Internet-Gateway im LAN1 ist, wählt sich als VPN-CLient in LAN2 ein. Alle Hosts in LAN1 können alle Hosts in LAN2 ansprechen. Umgekehrt ist es nicht erwünscht und auch deaktiviert.
Das VPN-Gateway in LAN1 ist auch der Server der in LAN1 als DHCP / DNS -Server fungiert. Die Netzwerkadresse ist 192.168.0.0/24. Die Netzwerkadresse in LAN2 ist 192.168.111.0/24. Im LAN2 steht ebenfalls ein DNS-Server und genau diesen würde ichgerne aus LAN1 benutzen.
Sehe ich das richtig das ich hierzu den DNS in LAN1 als Slave von LAN2 einrichten muß?
So, ich habe das einfach mal so gemacht und es funktioniert schon fast wie es soll ;-). Ich habe dem DNS-Server in LAN1 eine Neue Zone mit dem gleichen Namen wie am DNS-Server in LAN2 eingerichtet, allerdings Typ = Slave. Ich kann die Hosts im LAN2 nun aus LAN1 auch mit Ihren Hostnamen ansprechen, allerdings "nur" mit ihrem FQHN d.h. ich muss den Domainteil mit angeben. ping tux.softwareschmied funktioniert und ping tux nicht. Bekomme ich das irgendwie geregelt? -- Sven Gehr Benderstrasse 34 77815 Bühl Fon: +49.7223.250265 -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Hi Sven, Am Mittwoch, 14. Juni 2006 12:05 schrieb Sven Gehr:
Ich kann die Hosts im LAN2 nun aus LAN1 auch mit Ihren Hostnamen ansprechen, allerdings "nur" mit ihrem FQHN d.h. ich muss den Domainteil mit angeben. ping tux.softwareschmied funktioniert und ping tux nicht. Bekomme ich das irgendwie geregelt?
du kannst einen weiteren search* in der resolv.conf angeben, denn das macht nicht der DNS sondern die lokale resolver Bibliothek. *) müßte auch mit yast gehen. aus man resolv.conf search Search list for host-name lookup. The search list is normally determined from the local domain name; by default, it contains only the local domain name. This may be changed by listing the desired domain search path follow- ing the search keyword with spaces or tabs separating the names. Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found. For environments with multiple subdomains please read options ndots:n below to avoid man-in- the-middle attacks and unnecessary traffic for the root-dns- servers. Note that this process may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is avail- able for one of the domains. The search list is currently limited to six domains with a total of 256 characters. Gruß Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Am Mittwoch, 14. Juni 2006 12:19 schrieb Falk Sauer:
Am Mittwoch, 14. Juni 2006 12:05 schrieb Sven Gehr:
Hallo,
Ich kann die Hosts im LAN2 nun aus LAN1 auch mit Ihren Hostnamen ansprechen, allerdings "nur" mit ihrem FQHN d.h. ich muss den Domainteil mit angeben. ping tux.softwareschmied funktioniert und ping tux nicht. Bekomme ich das irgendwie geregelt?
du kannst einen weiteren search* in der resolv.conf angeben, denn das macht nicht der DNS sondern die lokale resolver Bibliothek.
also ein Stück weiter bin ich schon. Ich habe auf dem Server in LAN1 wie gesagt eine Zone, Typ=Slave für das entfernte LAN angelegt. Am gleichen Server habe ich in der Datei /etc/dhcpd.conf die Zeilen: option domain-name "dreampixel"; option domain-name-servers 192.168.0.5; in: option domain-name "dreampixel softwareschmied"; option domain-name-servers 192.168.0.5, 192.168.111.1; geändert. Also die Domain im entfernten LAN heist softwareschmied und die IP des dortigen DNS-Server ist die 192.168.111.1. Dies führt am Client zu folgender /etc/resolv.conf: search dreampixel softwareschmied nameserver 192.168.0.5 nameserver 192.168.111.1 und dies wiederum bewirkt das ich aus dem LAN1 den Rechner tux.softwareschmied unter dem Namen tuxanpingen kann. Soweit ist dasschon mal gut. Allerdings habe ich ja einen DDNS-Server d.h. Client meldet sich beim DHCP undder trägt die IP-Name-Kombination in den DNS ein und hier gibt es, sobald ich die Zeile: option domain-name um die Domain softwareschmied erweitere folgende Fehler im Logfile: dhcpd: Unable to add forward map from poseidon.dreampixel, softwareschmied to 192.168.0.200: timed out dhcpd: DHCPREQUEST for 192.168.0.200 from 00:11:d8:70:34:cc (poseidon) via eth0 dhcpd: DHCPACK on 192.168.0.200 to 00:11:d8:70:34:cc (poseidon) via eth0 der Hostname des Clients (poseidon) wird auch nicht mehr eingetragen. Hat jemand eine Ahnung wie ich das in den Griff bekomme? -- Sven Gehr Benderstrasse 34 77815 Bühl Fon: +49.7223.250265 -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Am Mittwoch, 14. Juni 2006 15:01 schrieb Sven Gehr:
Am Mittwoch, 14. Juni 2006 12:19 schrieb Falk Sauer:
Am Mittwoch, 14. Juni 2006 12:05 schrieb Sven Gehr:
Hallo,
Ich kann die Hosts im LAN2 nun aus LAN1 auch mit Ihren Hostnamen ansprechen, allerdings "nur" mit ihrem FQHN d.h. ich muss den Domainteil mit angeben. ping tux.softwareschmied funktioniert und ping tux nicht. Bekomme ich das irgendwie geregelt?
du kannst einen weiteren search* in der resolv.conf angeben, denn das macht nicht der DNS sondern die lokale resolver Bibliothek.
Und unter Windows kann man das sogar via dhcp zuteilen, unter linux leider immer noch nicht, oder?
also ein Stück weiter bin ich schon. Ich habe auf dem Server in LAN1 wie gesagt eine Zone, Typ=Slave für das entfernte LAN angelegt. Am gleichen Server habe ich in der Datei /etc/dhcpd.conf die Zeilen:
option domain-name "dreampixel"; option domain-name-servers 192.168.0.5;
in:
option domain-name "dreampixel softwareschmied"; option domain-name-servers 192.168.0.5, 192.168.111.1;
geändert. Also die Domain im entfernten LAN heist softwareschmied und die IP des dortigen DNS-Server ist die 192.168.111.1. Dies führt am Client zu folgender /etc/resolv.conf:
search dreampixel softwareschmied nameserver 192.168.0.5 nameserver 192.168.111.1
und dies wiederum bewirkt das ich aus dem LAN1 den Rechner tux.softwareschmied unter dem Namen tuxanpingen kann. Soweit ist dasschon mal gut. Allerdings habe ich ja einen DDNS-Server d.h. Client meldet sich beim DHCP undder trägt die IP-Name-Kombination in den DNS ein und hier gibt es, sobald ich die Zeile:
option domain-name
um die Domain softwareschmied erweitere folgende Fehler im Logfile:
dhcpd: Unable to add forward map from poseidon.dreampixel, softwareschmied to 192.168.0.200: timed out dhcpd: DHCPREQUEST for 192.168.0.200 from 00:11:d8:70:34:cc (poseidon) via eth0 dhcpd: DHCPACK on 192.168.0.200 to 00:11:d8:70:34:cc (poseidon) via eth0
der Hostname des Clients (poseidon) wird auch nicht mehr eingetragen. Hat jemand eine Ahnung wie ich das in den Griff bekomme?
-- Sven Gehr Benderstrasse 34 77815 Bühl Fon: +49.7223.250265
Vielleicht solltest du NAT erwägen - damit kannst du gerade in Kombination mit OpenVPN einiges an Funktionalität erreichen... Ich habe mal ein "virtuelles virtuelles" netz angelegt, da hat man noch mehr möglichkeiten: Jeder Host wird umgesetzt (per NAT) in eine Adresse im VPN (incl. DNS Namensauflösung), einfach per iptables. Das ergibt am ein virtuelles Netzwerk, das vom default router / Gateway/DNS verbunden wird, und in dem sogar einzelne Verbindungen/Ports etc. anders gemappt werden können. Da wir das auf shell-scripten (integriert in debian-Webmin oder susefirewall2) gemacht haben, kann das auch an ein LDAP angebunden werden... Das wurde dann unser Wartungsnetz, indem alle Linux-Maschinen unserer Kunden repräsentiert waren - aber nur mit den erlaubten Verbindungen, dafür aber mit DNS. -- Best Regards - Mit freundlichen Grüßen Markus Feilner -------------------------- Feilner IT Linux & GIS Linux Solutions, Training, Seminare und Workshops - auch Inhouse Kötztingerstr 6c 93057 Regensburg fon regensburg +49 941 8107989 mobil +49 170 3027092 www: www.feilner-it.net mail: mfeilner@feilner-it.net --------------------------------------- My new book - Out now: http://www.packtpub.com/openvpn/book OPENVPN : Building and Integrating Virtual Private Networks ======================================= -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Hi Markus, Am Mi 14.Juni 2006 16:27 schrieb Markus Feilner:
du kannst einen weiteren search* in der resolv.conf angeben, denn das macht nicht der DNS sondern die lokale resolver Bibliothek.
Und unter Windows kann man das sogar via dhcp zuteilen, unter linux leider immer noch nicht, oder?
Ehrlich gesagt ich weis es nicht, ich hab das in Verbindung mit dhcp noch nie gebraucht, wenn ich das mal brauche dann idr. nur mal auf einer Kiste und da ist es dann imho sinnvoller die resolv.conf von hand zu pflegen. Letztendlich würde der dhcp client aber auch nur die resolv.conf ändern, also solltest du mal dessen doku/code dazu befragen. Gruß Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Am Donnerstag, 15. Juni 2006 11:33 schrieb Falk Sauer:
Hi Markus,
Am Mi 14.Juni 2006 16:27 schrieb Markus Feilner:
du kannst einen weiteren search* in der resolv.conf angeben, denn das macht nicht der DNS sondern die lokale resolver Bibliothek.
Und unter Windows kann man das sogar via dhcp zuteilen, unter linux leider immer noch nicht, oder?
Ehrlich gesagt ich weis es nicht, ich hab das in Verbindung mit dhcp noch nie gebraucht, wenn ich das mal brauche dann idr. nur mal auf einer Kiste und da ist es dann imho sinnvoller die resolv.conf von hand zu pflegen. Letztendlich würde der dhcp client aber auch nur die resolv.conf ändern, also solltest du mal dessen doku/code dazu befragen.
Gruß Falk
naja, das ist schon sehr praktisch, wenn du zwei über vpn verbundene namensräume hast, deren dns nicht synchron sind. Wir hatten das problem, dass sich der Windows DNS Server (Active Directory) nicht mit mehreren Standorten so synchronisieren liess, wie wir das brauchten - daher waren zwei Namensräume notwendig. Diese als Liste über DHCP zuteilen zu können ist ein praktisches Feature, das aber leider nur die windows-notebooks nutzen konnten. ist aber auch schon ein zwei jahre her, vielleicht gehts ja mittlerweile... :-) -- Best Regards - Mit freundlichen Grüßen Markus Feilner -------------------------- Feilner IT Linux & GIS Linux Solutions, Training, Seminare und Workshops - auch Inhouse Kötztingerstr 6c 93057 Regensburg fon regensburg +49 941 8107989 mobil +49 170 3027092 www: www.feilner-it.net mail: mfeilner@feilner-it.net --------------------------------------- My new book - Out now: http://www.packtpub.com/openvpn/book OPENVPN : Building and Integrating Virtual Private Networks ======================================= -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Am Mittwoch, 14. Juni 2006 12:19 schrieb Falk Sauer:
Am Mittwoch, 14. Juni 2006 12:05 schrieb Sven Gehr:
du kannst einen weiteren search* in der resolv.conf angeben, denn das macht nicht der DNS sondern die lokale resolver Bibliothek.
Und unter Windows kann man das sogar via dhcp zuteilen, unter linux leider immer noch nicht, oder?
Doch das funktioniert. Das ist doch meiner Mail auch zu entnehmen zu was für einer resolv.conf das führt! Siehe nächster Absatz.
geändert. Also die Domain im entfernten LAN heist softwareschmied und die IP des dortigen DNS-Server ist die 192.168.111.1. Dies führt am Client zu folgender /etc/resolv.conf:
search dreampixel softwareschmied nameserver 192.168.0.5 nameserver 192.168.111.1 [...]
dhcpd: Unable to add forward map from poseidon.dreampixel, softwareschmied to 192.168.0.200: timed out dhcpd: DHCPREQUEST for 192.168.0.200 from 00:11:d8:70:34:cc (poseidon) via eth0 dhcpd: DHCPACK on 192.168.0.200 to 00:11:d8:70:34:cc (poseidon) via eth0
der Hostname des Clients (poseidon) wird auch nicht mehr eingetragen. Hat jemand eine Ahnung wie ich das in den Griff bekomme?
Vielleicht solltest du NAT erwägen - damit kannst du gerade in Kombination mit OpenVPN einiges an Funktionalität erreichen...
Ich habe mal ein "virtuelles virtuelles" netz angelegt, da hat man noch mehr möglichkeiten: [...]
Danke aber ich denke ein NAT ist nicht der für mich geeignete Lösungsanstz. Das einzige Problem das ich doch habe ist das sich der Host "poseidon" solange der die resolv.conf: search dreampixel nameserver 192.168.0.5 hat korrekt als poseidon.dreampixel in den DNS auf dem Server darwin.dreampixel eingetragen wird und sobald der die resolv.conf: search dreampixel softwareschmied nameserver 192.168.0.5 nameserver 192.168.111.1 hat das zu o.g. Fehler beim eintragen in die Zone führt. Ich denke das Problem müsste sich doch am DNS lösen lassen, oder? -- Sven Gehr Benderstrasse 34 77815 Bühl Fon: +49.7223.250265 -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Hi Sven, Am Fr 16.Juni 2006 09:58 schrieb Sven Gehr:
search dreampixel softwareschmied nameserver 192.168.0.5 nameserver 192.168.111.1
hat das zu o.g. Fehler beim eintragen in die Zone führt. Ich denke das Problem müsste sich doch am DNS lösen lassen, oder?
es gibt Dinge die ich aus Überzeugung nicht mache, dynamische DHCP Adressen automagisch in DNS eintragen gehört dazu, ich trage die zugelassenen Mac-Adressen im dhcp statisch ein und gut is, dann merke ich wenigstens wenn mir mal wieder jemand was ans netz steckt von dem ich nix weis. Aber zu deinem Problem, ich würde an deiner Stelle versuchen im jeweiligen DNS die restrictions so einzustellen das nur das jeweilige subnetz einen dns update hinbekommt, das führt zwar sicherlich auch zu Fehlermeldungen im log, ich kann mir aber nicht so recht vorstellen das die gänzlich eliminierbar sind in der konstellation. Weiters halte ich es für fraglich ob das überhaupt so funktionieren kann. Und die Verbindung der beiden DNS würde ich nicht in der resolc.conf machen sondern den jeweiligen lokalen DNS beim jew. entfernten die anfrage stellen lassen. Entweder als forwarder oder als slave zone. Hätte außerdem den Vorteil das der lokale die Antworten des entfernten cached. Gruß Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Am Freitag, 16. Juni 2006 10:41 schrieb Falk Sauer:
Hi Sven,
Am Fr 16.Juni 2006 09:58 schrieb Sven Gehr:
search dreampixel softwareschmied nameserver 192.168.0.5 nameserver 192.168.111.1
hat das zu o.g. Fehler beim eintragen in die Zone führt. Ich denke das Problem müsste sich doch am DNS lösen lassen, oder?
es gibt Dinge die ich aus Überzeugung nicht mache, dynamische DHCP Adressen automagisch in DNS eintragen gehört dazu, ich trage die zugelassenen Mac-Adressen im dhcp statisch ein und gut is, dann merke ich wenigstens wenn mir mal wieder jemand was ans netz steckt von dem ich nix weis.
Das kann ich nur bestätigen... Aber das ganze kommt meiner Meinung nach zu einem großen Teil von den Standard-Einstellungen unter Windows (ADS), und wer den Saustall (Entschuldigung!) schon mal gesehen hat, der da nach ein zwei Jahren im DNS drin hängt - na super... :-) Ich hab zusätzlich immer noch nen pool von ein paar echten dhcp-addressen, die für neulinge vergeben werden, wenn ichs brauch.
Aber zu deinem Problem, ich würde an deiner Stelle versuchen im jeweiligen DNS die restrictions so einzustellen das nur das jeweilige subnetz einen dns update hinbekommt, das führt zwar sicherlich auch zu Fehlermeldungen im log, ich kann mir aber nicht so recht vorstellen das die gänzlich eliminierbar sind in der konstellation. Weiters halte ich es für fraglich ob das überhaupt so funktionieren kann.
das denke ich auch. Schön, wenn man auch linux zwei searchlists mitgeben kann - das wusste ich noch nicht. cool, aber da verliert der client natürlich den eindeutigen namen beim DHCP - DNS Update. -> Das Problem liegt m.E. eher im Design als in einer Konfiguration.
Und die Verbindung der beiden DNS würde ich nicht in der resolc.conf machen sondern den jeweiligen lokalen DNS beim jew. entfernten die anfrage stellen lassen. Entweder als forwarder oder als slave zone. Hätte außerdem den Vorteil das der lokale die Antworten des entfernten cached.
Genau so haben wir das auch schon gemacht, das funzt sehr gut. Nochmal: Ich rate auch von jedem DHCP-DNS-update ab, das ist sehr administrationsaufwändig, wenn du immer wieder mal "Gäste" da hast. :-)
Gruß Falk
-- Best Regards - Mit freundlichen Grüßen Markus Feilner -------------------------- Feilner IT Linux & GIS Linux Solutions, Training, Seminare und Workshops - auch Inhouse Kötztingerstr 6c 93057 Regensburg fon regensburg +49 941 8107989 mobil +49 170 3027092 www: www.feilner-it.net mail: mfeilner@feilner-it.net --------------------------------------- My new book - Out now: http://www.packtpub.com/openvpn/book OPENVPN : Building and Integrating Virtual Private Networks ======================================= -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Am Freitag, 16. Juni 2006 10:41 schrieb Falk Sauer:
Am Fr 16.Juni 2006 09:58 schrieb Sven Gehr:
Hallo,
search dreampixel softwareschmied nameserver 192.168.0.5 nameserver 192.168.111.1
hat das zu o.g. Fehler beim eintragen in die Zone führt. Ich denke das Problem müsste sich doch am DNS lösen lassen, oder?
es gibt Dinge die ich aus Überzeugung nicht mache, dynamische DHCP Adressen automagisch in DNS eintragen gehört dazu, ich trage die zugelassenen Mac-Adressen im dhcp statisch ein und gut is, dann merke ich wenigstens wenn mir mal wieder jemand was ans netz steckt von dem ich nix weis.
Das ist Ansichtssache aber da wir sehr viele Geräte - Zu- und Abgänge haben ist das hier nicht praktikabel.
Aber zu deinem Problem, ich würde an deiner Stelle versuchen im jeweiligen DNS die restrictions so einzustellen das nur das jeweilige subnetz einen dns update hinbekommt,
So ganz verstehe ich nicht wie du das meinst. Es gibt den DNS-Server in LAN1 der ja auch das VPN-Gateway ist. Dieser Rechner ist auch der DNS-Server für die Domain "dreampixel". Der entsprechende Eintrag in der named.conf sieht so aus: zone "dreampixel" in { file "master/dreampixel"; type master; allow-update { key DHCP_UPDATER; }; }; Bedeutet ja das nur der, der den key "DHCP_UPDATER" hat Updates der Zonen durchführen darf. Hier ändert sich ja meiner Meinung nach nichts da es ja um die "entfernte" Zone "softwareschmied" geht. Nun habe ich an diesem DNS-Server (in LAN1) eben die Slave-Zone eingerichtet: zone "softwareschmied" in { masters { 192.168.111.1; }; file "slave/softwareschmiedXX"; type slave; }; Ich denke mal das du diese Zone mit "ich würde an deiner Stelle versuchen im jeweiligen DNS die restrictions so einzustelle ..." meinst, oder? Aber selbst wenn ich Zonen-Updates aktiviere und als ACL "any" setze ändert sich nichts an meinem Problem. Könntest du dies etwas erläutern wie du das meinst? Viele Grüße Sven -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Moin Sven, Am Montag, 19. Juni 2006 08:32 schrieb Sven Gehr:
Am Freitag, 16. Juni 2006 10:41 schrieb Falk Sauer:
Am Fr 16.Juni 2006 09:58 schrieb Sven Gehr:
search dreampixel softwareschmied nameserver 192.168.0.5 nameserver 192.168.111.1
hat das zu o.g. Fehler beim eintragen in die Zone führt. Ich denke das Problem müsste sich doch am DNS lösen lassen, oder?
es gibt Dinge die ich aus Überzeugung nicht mache, dynamische DHCP Adressen automagisch in DNS eintragen gehört dazu, ich trage die zugelassenen Mac-Adressen im dhcp statisch ein und gut is, dann merke ich wenigstens wenn mir mal wieder jemand was ans netz steckt von dem ich nix weis.
Das ist Ansichtssache aber da wir sehr viele Geräte - Zu- und Abgänge haben ist das hier nicht praktikabel.
würde das Problem aber ein für alle mal lösen.
Aber zu deinem Problem, ich würde an deiner Stelle versuchen im jeweiligen DNS die restrictions so einzustellen das nur das jeweilige subnetz einen dns update hinbekommt,
So ganz verstehe ich nicht wie du das meinst. Es gibt den DNS-Server in LAN1 der ja auch das VPN-Gateway ist. Dieser Rechner ist auch der DNS-Server für die Domain "dreampixel". Der entsprechende Eintrag in der named.conf sieht so aus:
zone "dreampixel" in { file "master/dreampixel"; type master; allow-update { key DHCP_UPDATER; }; };
wenn ich mich recht erinnere kann man hier auch noch den ip-range einschränken der darf.
Bedeutet ja das nur der, der den key "DHCP_UPDATER" hat Updates der Zonen durchführen darf. Hier ändert sich ja meiner Meinung nach nichts da es ja um die "entfernte" Zone "softwareschmied" geht.
eben und die entfernte zone sollte keinesfalls lokal updaten dürfen resp. lokal mit upgedated werden.
Nun habe ich an diesem DNS-Server (in LAN1) eben die Slave-Zone eingerichtet:
zone "softwareschmied" in { masters { 192.168.111.1; }; file "slave/softwareschmiedXX"; type slave; };
Ich denke mal das du diese Zone mit "ich würde an deiner Stelle versuchen im jeweiligen DNS die restrictions so einzustelle ..." meinst, oder? Aber selbst wenn ich Zonen-Updates aktiviere und als ACL "any" setze ändert sich nichts an meinem Problem. Könntest du dies etwas erläutern wie du das meinst?
Ich meine das du versuchen solltest nur ein update des jeweils lokalen dns zu erlauben am Besten zusätzlich über den ip-range, ich schrieb aber auch das ich denke das das so nicht geht weil der dhcp-client versucht beide zonen upzudaten da er beide zonen in der searchlist stehen hat, und auf den Versuch beide upzudaten bekommt der dhcp-client einen Fehler und bricht den update ab obwohl es mit einer zone klappen würde - so er es denn nacheinander versuchen würde. Das Problem ist das der dhcp-client offenbar die upzudatenden Zonen aus den search Einträgen ausliest, wenn du dem das abgewöhnen könntest und das irgendwie anders vorgeben könntest müßte es gehen. zb. könnte ich mir - wenn überhaupt - vorstellen das es über sowas wie den supersede eintrag in der dhclient.conf gehen könnte siehe man dhclient.conf und man dhcp-options (ziemlich am Ende) Gruß Falk -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
participants (3)
-
Falk Sauer -
Markus Feilner -
Sven Gehr