bind: vlan

[sergej2018]

Guten Morgen,

habe hier einen Testaufbau mit mehreren VLANs an einem kleinen Switch. Dazu ein Server und ein Client. Auf dem Server läuft DNS (bind) und Samba für's einfache Testen.
Meine Frage: Wie sorge ich dafür, dass die Clients den Server immer unter seiner jeweiligen VLAN-IP erreichen? Wie konfiguriere ich den DNS also so, dass er - je nach VLAN - verschiedene IPs für den Server rausgibt?

Beispiel:
Server: vlan1 -> 192.168.1.1
vlan2 -> 192.168.2.1
...

[bluestar]

Hast du auf deinem Server auch für jedes VLAN ein eigenes Netzwerkinterface konfiguriert?

[DynaBlaster]

Bind müsste für jedes VLAN-Interface eine eigene Zone konfiguriert bekommen. Für jeden IP-Bereich würde ich auch jeweils eine Forward-Lookup und eine entsprechende Reverse-Lookup-Zone definieren. Dann muss sichergestellt sein, das Bind auch auf allen VLAN-Interfaces horcht und Anfragen aus den VLAN-Netzen beantwortet.

Für Samba gilt das gleiche, der muss Anfragen auch auf allen VLAN-Interfaces beantworten. wobei ich mir bei Samba vorstellen kann, das es da zu Problemen kommen kann, weil das SMB-Protokoll viel mit Broadcasts arbeitet. Von daher würde ich für Tests des DNS-Setups erstmal mit Boardmitteln wie ping, dig und Co. testen.

Dann ggf. erstmal einen weniger komplexen Netzwerkdienst auf dem Server nehmen. Da vermutlich SSH eh läuft, würd ich da die Verbindungen testen. Oder halt nen Webserver mit Minimal-Konfiguration

[BenutzerGa4gooPh]

Wie sorge ich dafür, dass die Clients den Server immer unter seiner jeweiligen VLAN-IP erreichen?

Tagging nach 802.1q zwischen Switch und "Router"/Debian (VLAN-Trunk):
https://wiki.archlinux.org/index.php/VLAN (wohl aktuellstes Wiki)
https://wiki.ubuntu.com/vlan
https://wiki.debian.org/NetworkConfigur ... C_Lenny.29
http://www.microhowto.info/howto/config ... ebian.html
Gegenseite Switch: [1]

Wie konfiguriere ich den DNS also so, dass er - je nach VLAN - verschiedene IPs für den Server rausgibt?

Gar nicht. Macht ein DHCP-Server. Und dessen Adressvergabe (unterschiedliche Subnets) an DHCP-Clients ist auch der erste/einfachste Test fuer richtig (oder falsch) konfigurierte VLANs: Subnets von mehreren oder umgesteckten DHCP-Clients an Access-Switch-Ports (untagged VLANs) unterschiedlich - wie vorgesehen?

bind9 ist hier wohl die Kanone fuer den Spatz und lt. Paketbeschreibung bind9 auch nix mit DHCP.
dnsmasq fuer DNS-Forwarding und DHCP: https://wiki.ubuntuusers.de/Dnsmasq/
Falls du bind9 aus irgendwelchen Gruenden doch benoetigst, kannst du isc-dhcp-server als reinen DHCP-Server nutzen: https://wiki.ubuntuusers.de/ISC-DHCPD/

Persoenlicher Rat: Testaufbauten auf das Wesentliche beschraenken, um weitere Fehlerquellen/Einfluesse auszuschliessen. Und natuerlich vom Einfachen zum Komplexen.

[1] Switch-Konfiguration, VLAN-Grundlagen, weiterfuehrende Links: https://www.administrator.de/wissen/vla ... 10259.html

[sergej2018]

Oh, das ist viel Material von euch, habt vielen Dank
Werde ich kommende Woche mal in Ruhe durcharbeiten und dann schauen, wie ich es genau machen will.
Bind9 wird in dem "echten" Netz eingesetzt, in dem der Spaß mal laufen soll, daher testete ich bisher mit diesem

Oh und ja: Auf dem Test-Server habe ich alle VLANs auch entsprechend eingerichtet, der Server hat also eine IP in jedem VLAN.

[r4pt0r]

Meine Frage: Wie sorge ich dafür, dass die Clients den Server immer unter seiner jeweiligen VLAN-IP erreichen? Wie konfiguriere ich den DNS also so, dass er - je nach VLAN - verschiedene IPs für den Server rausgibt?

Views ist das Stichwort wonach du suchst, und das beherrscht dnsmasq nicht - BIND9 ist also schon richtig.

Für jeden view werden dann eigene dbs für forward&reverse-zone angelegt und entsprechend z.B. subnetzbasiert gefiltert. Je nach Größe der Zone(n) kann es sinnvoll sein die Zonen per CNAME-dbs zu mappen und Subdomains zu nutzen wie z.b. lan.domain.lan, dmz.domain.lan, dev,domain.lan usw...
Die "domain.lan" zone ist dann in jedem view eine CNAME-db auf die jeweilige "sub.domain.lan"-Einträge. Dadurch kann z.b. aus jedem beliebigen subnet "server1.domain.lan" ggf mit unterschiedlicher IP aufgelöst werden oder wenn man explizit einen dienst über eine andere zone (=subnet) erreichen will, kann z.b. "server1.dmz.domain.lan" verwendet werden.
Ein solches Setup sollte nur noch automatisiert (gescriptet bzw in kombination mit configmanagement) betrieben werden; auf keinen Fall mehr manuell in den dbs rumschreiben. Ein zentraler master-NS der ausschließlich die slave-NS bedient, die dann von den clients abgefragt werden ist ebenfalls ratsam um einen sauberen "single point of truth" zu haben.

Der DHCP wird sowieso für jedes interface/subnet einzeln konfiguriert und liefert auch nur an den konfigurierten interfaces leases. Es ist NICHT Aufgabe des DHCP zu "verhindern" dass clients in andere VLANs kommen; das muss bereits am switch erfolgen, weshalb man für ('untrusted') clients ausschließlich access-ports einrichtet oder ggf zumindest beschränkt in welche VLANs ein trunk-port zugang hat. Je nach Umgebung sollte man speziell wenn clients (warum auch immer..) an trunk-ports hängen über port-security nachdenken und z.b. den port deaktivieren wenn die MAC-adresse sich ändert oder tags für nicht freigegebene VLANs gesetzt werden.

Das alles setzt auch ein SAUBER konfiguriertes routing voraus - wenn irgend ein gateway unkontrolliert zwischen VLANs routet und am besten auch noch broadcasts forwarded bricht schnell chaos aus. Nur in wirklich speziellen Anwendungsfällen kann am switch geroutet werden, ansonsten grundsätzlich nur an dem/den zentralen netzwerk-gateways/firewalls.


Leidiges Thema SMB:
Da Windows clients nur über Umwege überhaupt VLAN-fähig werden, hängt man diese sowieso ausschließlich an access ports - daher sind diese Kisten sowieso automatisch im richtigen VLAN. Den SMB-server bindet man dann einfach an das entsprechende interface/IP im selben subnet.
Windows müllt seine broadcastdomain konstant mit spam zu, daher ist es ohnehin _sehr_ sinnvoll, diese clients + zugehörige serverdienste in ein eigenes, stark isoliertes VLAN+subnet zu packen; dann kann man auf den übrigen VLANs auch normal arbeiten und monitoring/debugging betreiben.

[BenutzerGa4gooPh]

Views ist das Stichwort wonach du suchst, und das beherrscht dnsmasq nicht - BIND9 ist also schon richtig.

Also wenn ich mit aufgrund deines Beitrages den Thread nochmal durchlese,

Server: vlan1 -> 192.168.1.1
vlan2 -> 192.168.2.1

dann soll ein physischer Server (Samba+DNS) mit 1 Netzwerkkarte und 1 VLAN-Trunk zugleich in 2 verschiedenen VLANs mit 2 verschiedenen IPs "haengen".
Da muss doch ein fuer die lokale Domain sergej.test autoritativer DNS-Server einfach nur 2 A-Records enthalten.
samba1.sergej.test 192. 168.1.1
samba2.sergej.test 192.168..2.1
Okay, kann dnsmasq als Forwarder sicher nicht.
(Erreichbarkeit des richtigen und "falschen" Sambas einschl. DNS-Servers ist natuerlich zu routen bzw. zu "regeln". Jedenfalls kommt mir der Testaufbau "unpraktisch" vor: DNS auf Samba mit 2 IPs/VLANs!? Viel Spass beim Routen und "Regeln".)

[r4pt0r]

Also wenn ich mit aufgrund deines Beitrages den Thread nochmal durchlese,

Server: vlan1 -> 192.168.1.1
vlan2 -> 192.168.2.1

dann soll ein physischer Server mit 1 Netzwerkkarte und 1 VLAN-Trunk zugleich in 2 verschiedenen VLANs mit 2 verschiedenen IPs "haengen".
Da muss doch ein fuer die lokale Domain autoritativer DNS einfach nur 2 A-Records enthalten.
samba1.test 192. 168.1.1
samba2.test 192.168..2.1
Okay, kann dnsmasq als Forwarder sicher nicht.
(Erreichbarkeit des "falschen" Sambas ist natuerlich zu "regeln".)

Natürlich kann auch alles in die selbe Zone geworfen werden und der "selbe" Dienst in verschiedenen subnetzen bekommt mehrere A-Records. Das wird dann mit manchen Diensten, die auf einen FQDN angewiesen sind (z.b. mail) sehr schnell sehr häßlich, da der selbe dienst über mehrere FQDNs angesprochen wird.

Zudem können dann z.B. Clients einen Namen auflösen, aber den Server/dienst nicht erreichen, weil dieser in einem anderen Subnet steht und die Clients (berechtigterweise) keinen Zugang dazu haben - Clients haben z.B. nichts auf dem Backupserver oder dem master-nameserver zu suchen, somit hat es sie auch nicht zu interessieren welche IP backup.domain.com oder ns0.domain.com haben.
Ziel von views ist es daher 1. nur das "sichtbar" zu machen, was in diesem Subnetz auch sichtbar sein soll und 2. je nach subnet ggf eine andere IP aufzulösen. Letzteres ist lokal schon oft von Vorteil (einfachere Firewallregelsätze!!!), wenn Subnetze einer domain aber auch über verschiedene Standorte verteilt sind ist es essentiell, dass z.B. "nis.domain.com" auf den lokalen NIS-server zeigt und nicht auf den entfernten mit hoher Latenz, wahrscheinlich geringer Bandbreite und ggf sogar anderen Usern. Anstatt an 50, 200 oder noch mehr Clients dann sicher zu stellen dass "nis1/2/3..." korrekt eingetragen wurde, verwaltet man das ganze zentral am Nameserver in den views der jeweiligen subnetze.


Soweit ich verstanden habe, handelt es sich beim Beispiel um eine Testinstallation - das tatsächliche deployment wird also vermutlich umfangreicher ausfallen? Wenn es sich wirklich nur um einen einzelnen Server oder sogar einzelnen Dienst handelt, ist der Aufwand eines split-view DNS natürlich nicht gerechtfertigt. Da kann man auch "Bastellösungen" verwenden (verschiedene A-Records in der selben Zone).

[BenutzerGa4gooPh]

Ziel von views ist es daher 1. nur das "sichtbar" zu machen, was in diesem Subnetz auch sichtbar sein soll und 2. je nach subnet ggf eine andere IP aufzulösen.

Schaue ich mir an. Danke auch fuer die Erlaeuterung der Nachteile der "Billigloesung".

@TO:
Ueberblick: https://docstore.mik.ua/orelly/networki ... h10_06.htm
ausfuehrlich: https://kb.isc.org/article/AA-00851/0/U ... ample.html

[BenutzerGa4gooPh]

... split-view DNS ...

Gutes Stichwort! Da ich als Privatnutzer nur eine Cisco-Router-FW-DNS-Wollmilchsau habe, kann ich das wohl auch machen. Bisher habe ich für Laptop (und gebridgte VMs darauf) mit Ethernet und WLAN verschiedene A-Records/FQDNs/IPs je nach aktivem Netzwerkadapter benutzt. Jetzt werde ich das mal mit Cisco-Split-DNS probieren.
Entspricht doch dem, was der TO will. Sein Server = mein Lappi mit Ethernet und WLAN. Nur dass meine VLANs/Routing/Regeln schon funktionieren.

[r4pt0r]

Stimmt, Cisco DNS beherrscht ebenfalls split-view Konfigurationen. Habe ich mir aber noch nie genauer angeschaut, kann also leider nicht sagen wie umfangreich (und "gut") die Cisco-Implementierung ist. BIND ist wie üblich die Referenzimplementierung, umfasst somit den gesamten Inhalt des/der zugehörigen RFC(s).

Wichtig für die Konfiguration von BIND: es gab da einige Syntaxaktualisierungen und Erweiterungen seit der Einführung von Views (z.b."in-view" seit 9.10+), teilweise mit Regressionen. Also darauf achten für welche Version die Konfigurationsbeispiele geschrieben wurden und idealerweise die Dokumentation zur verwendeten Version benutzen. Das erspart u.U. einige graue Haare!
Um die Funktionsweise und die Eigenheiten von Views und deren Konfiguration zu verstehen sollte man auf jeden Fall mit einem einfachen Setup anfangen und ausprobieren was geht und was nicht - z.B. matcht ein Client niemals in mehreren views: der erste match gewinnt. Default-zones müssen also in jedem view vorhanden sein in dem globale Namen/IPs aufgelöst werden sollen.