Testnetz mit getrenntem DHCP hinter L2 Switch

[Renegade334]

Hallo,

ich versuche in einem bestehenden Netz aus AVM Geräten ein Testnetz mit eigenem DHCP aufzusetzen.
Die Verbindung der Netze soll über einen Port vom Netgear GS308T (weil vorhanden) zu einer FritzBox laufen, wobei das Testnetz einen unabhängigen DHCP Server nutzen soll und die Haupt FritzBox als Gateway zum Internet aber erreichbar sein muss.

Der restliche Traffic darf/soll auch netzübergreifend fließen.
Um es zu vereinfachen würde ich beide Netze im gleichen Subnetz hintereinander betreiben.

Meine erste Idee wäre, über "Protocol Based VLAN Group Configuration" DHCP Traffic der VLAN-ID vom Testnetz zuzuordnen. Anfragen der Clients und Antworten des Test-DHCP sollten dann das Grundnetz nicht erreichen (hoffentlich?).
Port Based VLAN dürfte mir nicht weiterhelfen, da alle Clients das Gateway im Grundnetz erreichen sollen.

Der Switch unterstützt auch DHCP Snooping, aber ich wüsste nicht, wie ich damit eine Trennung hinbekommen könnte. Ein "trusted" DHCP des Testnetz würde ja trotzdem ins Grundnetz antworten wenn Anfragen ankommen.

Am einfachsten wäre vermutlich den Uplink in ein VLAN zu stecken, das Testnetz in ein anderes und eine virtuelle pfSense zwischen beide Netze zu hängen. Dann müsste ich aber noch die Route im Grundnetz hinterlegen, falls Geräte von außen erreichbar sein sollen. Dafür könnte (und sollte) ich aber immerhin einen anderen IP Bereich fürs Testnetz nutzen. Die Lösung würde ich aber gerne vermeiden.

Wie man vielleicht merkt, habe ich mit Netzwerk normal nicht viel zu tun. Daher die Frage, ob die erste Idee funktionieren könnte, oder ob es vielleicht andere Lösungen gibt. Leider bleibt die Anforderung, dass das Grundnetz nicht geändert werden soll und auch nicht VLAN fähig ist.
Statische IPs scheiden aus, da regelmäßig VMs oder Container angelegt werden, die vom DHCP ihre Einstellungen ziehen sollen.
Außerdem will ich trotz der einschränkenden Umstände einen gewissen Mindeststandard wahren

Aktuell habe ich das Gefühl ich muss einmal darüber schlafen, denn jede neue Idee die mir kommt ist unpraktischer als die letzte.

 

[Joe Dalton]

DHCP arbeitet auf Layer 2 in einer Broadcastdomäne: zwei unterschiedliche DHCP-Server in einer Broadcastdomäne sind selten hilfreich. Mit DHCP Snooping könnte man was basteln, aber das wird wenig schön werden.

Wenn Du was trennen willst, dann pro Broadcastdomäne (VLAN) einen DHCP-Server und zwischen den Netzen ein sauberes Routing. Das können Deine AVM-/NETGEAR-Komponenten allerdings nicht, daher brauchst Du etwas in der Art einer Pfsense o.ä..

 

[0x8100]

Meine erste Idee wäre, über "Protocol Based VLAN Group Configuration" DHCP Traffic der VLAN-ID vom Testnetz zuzuordnen. Anfragen der Clients und Antworten des Test-DHCP sollten dann das Grundnetz nicht erreichen (hoffentlich?).

laut handbuch ist bei "protocol based" das protokoll im ethernet header gemeint, das hilft dir hier also nicht weiter.

funktionieren dürfte eine "extended ip acl" (handbuch seite 273) auf dem port richtung fritzbox. mit source-ip der fritzbox, protocol-type "udp" und source-port 67 mit action "deny" sollten alle dhcp-antworten von der fritzbox verworfen werden und nur der andere an dem switch angeschlossene dhcp-server zum zuge kommen.

 

[Renegade334]

Da merkt man, dass ich selten mit lowlevel Netzwerk zu tun habe. Ich hatte DHCP gedanklich auf einer Stufe mit ARP, aber das konnte ja nicht sein, da das über UDP 67/68 läuft und damit deutlich später ansetzt.
Danke für die Erinnerung.

Die ACL habe ich mir bisher nicht genau angesehen. Ich hatte nicht damit gerechnet, dass der Switch Features auf der Ebene bietet. Das wäre ja schon „Firewall light“ und würde mir absolut reichen.
Ich werde mir das definitiv näher anschauen.

Danke schonmal.

 

[Raijin]

Mit einer Fritzbox kommt man mit VLANs nicht weit. Ein L2(+) Switch mit VLAN-Unterstützung kann sich sinngemäß nur in mehrere Teilswitches splitten, nicht mehr und nicht weniger. Aus einem 24er VLAN-Switch werden dann zB 3 virtuelle 8er Switches ohne Verbindung untereinander. Diese Verbindungen müssen über einen Router mit VLAN-Unterstützung oder ausreichend physischen Schnittstellen hergestellt werden. Ersteres ist bei einer Fritznox nicht der Fall (kann nix VLAN) und letzeres ist mit 2 Schnittstellen (LAN1-3 = Hauptnetz + LAN4 = Gastnetz) bereits ausgeschöpft. Mehr als 2 VLANs, die lediglich innerhalb eines VLAN-Switches existieren, geht also nicht - zumindest nicht mit Internetverbindung, weil zusätzliche VLANs im Switch isoliert wären, da es keinen Router gäbe.


Das ist so ziemlich das einzige, was VLAN-mäßig mit einer Fritzbox möglich ist:

Fritzbox mit LAN1-3 Hauptnetz
Fritzbox mit LAN4 Gastnetz
Jeweils 1 Kabel von LAN1-3 bzw LAN4 zu einem VLAN-Switch
VLAN-Switch hat 2 VLANs, eines für das Hauptnetz und eines für das Gastnetz



Natürlich kann man im Switch ein 3. VLAN konfigurieren, aber da die Fritzbox es nicht routen kann, muss ein weiterer Router her, der zB das Hauptnetz auf der einen mit einem weiteren Netzwerk auf der anderen Seite verbindet - quasi eine Routerkaskade ohne NAT. L3-Switches können diese Rolle selbst übernehmen, aber wenn man nur L2(+) Switches hat, braucht man zB einen MikroTik hEX, einen EdgeRouter, eine HW-Firewall wie zB pfSense oder einen 08/15 Router mit OpenWRT, o.ä.

Damit könnte es so aussehen:

Fritzbox mit LAN1-3 Hauptnetz
Fritzbox mit LAN4 Gastnetz
Jeweils 1 Kabel von LAN1-3 bzw LAN4 zu einem VLAN-Switch
VLAN-Switch hat 3 VLANs, eines für das Hauptnetz und eines für das Gastnetz, eines für das Zusatznetz
MikroTik hEX mit LAN1 zu SwitchPort in Hauptnetz-VLAN
MikroTik hEX mit LAN2 zu SwitchPort im Zusatz-VLAN
MikroTik hEX ist Gateway und DHCP für Zusatznetz

 

[h00bi]

Leider bleibt die Anforderung, dass das Grundnetz nicht geändert werden soll und auch nicht VLAN fähig ist.
Statische IPs scheiden aus, da regelmäßig VMs oder Container angelegt werden, die vom DHCP ihre Einstellungen ziehen sollen.
Außerdem will ich trotz der einschränkenden Umstände einen gewissen Mindeststandard wahren

Was ist denn der Grund, dass ein neuer DHCP Server zum Sinsatz kommen soll?
Willst du nur den DHCP Bereich der Fritzbox clean halten oder willst du mit dem DHCP Server was testen?
Andernfalls könntest du auch einfach die DHCP Lease Time stark reduziereren.

 

[Raijin]

Was ist denn der Grund, dass ein neuer DHCP Server zum Sinsatz kommen soll?

Wie immer ist @h00bi on point

Bevor @Renegade334 Sinn und Zweck des ganzen sowie die Umstände warum das Hauptnetzwerk unangetastet bleiben muss nicht näher erläutert, ist es für uns ziemlich sinnfrei, noch näher darauf einzugehen. Es kommt auf die Details des Vorhabens an, da wir uns ohne diese im Kreis drehen oder die Ideen in völlig falsche Richtungen gehen. Am Ende reicht womöglich eine simple Routerkaskade mit einem 15€ Router schon aus, um das Vorhaben des TE umzusetzen, ganz ohne VLAN-Gedöns...

Neben den Infos zum eigentlichen Ziel des Ganzen, wäre auch eine Liste der zum Einsatz kommenden Hardware hilfreich. Nur mal so: Wenn zB ein PI, o.ä. mit von der Partie ist, kann man an diesem 2 VLAN-Sschnittstellen konfigurieren und an einem Trunk-Port am Switch anklemmen. Der PI fungiert dann quasi als Router und auch DHCP für das Testnetz.

 

[Renegade334]

Was ist denn der Grund, dass ein neuer DHCP Server zum Sinsatz kommen soll?
Willst du nur den DHCP Bereich der Fritzbox clean halten oder willst du mit dem DHCP Server was testen?

Beides.
Das originale Netz soll bei Tests weiter laufen wie bisher.
Im Testnetz würden verschiedene Einstellungen per DHCP verteilt. Je nachdem welche Einstellungen ich testen will laufen komplett andere VMs mit anderer Domäne, anderen DNS Einstellungen und teils vordefinierten Einstellungen die per DHCP verteilt werden, die aber nicht im normalen Netz verteilt werden sollen. Ab und zu z.B. neu aufgesetzte Test-Domänen (und damit auch deren DCs als DNS), verschiedene Suffixe, ...

Würden sich die normalen Clients die Einstellungen ziehen und ich schalte die Testserver ab wäre das halt unpraktisch.
Aktuell arbeite ich mit Krücken, dass ich z.B. auf den Testrechnern per GPO für ihre Domäne einen anderen DNS erzwinge, da ich bei AVM kein Conditional Forward oder ähnliches konfigurieren kann, was aber dank uneinheitlichen IPs der Testumgebungen auch nicht sinnvoll wäre.

Die eingesetzten Server haben aktuell alle jeweils nur 1 Lan Port, wobei ein Hyper-V Host theoretisch die virtuellen NICs taggen und so eine VLAN Brücke bauen könnte. Dann muss halt eine pfSense VM oder ähnliches dauerhaft beim Testen laufen.
Nervig wäre dann aber das doppelte NAT, falls ich Cloud Anbindungen testen muss.

Zusammenfassend laufen im Testnetz bis zu 5 physische Geräte mit maximal 10 VMs. Das schwankt aber je nach Bedarf.

Eine Routerkaskade wäre definitv möglich, aber ich würde gerne auf das Einrichten von NAT oder Routen im normalen Netz verzichten.

Von der Idee mit VLANs zu arbeiten bin ich weg, da das in meinem Fall tatsächlich nichts bringt. Die Filterung der DHCP Pakete werde ich definitiv noch genauer anschauen, da das eine einfache Lösung sein könnte.
Das ist halt ein typisches Problem von "ich will erst schauen was ich mit vorhandener Hardware machen kann, bevor ich mir etwas neues anschaffe". Wenn es absolut nicht anders geht, dann könnte ich auch andere Hardware einsetzen, aber dann würde ich eher eine virtuelle Firewall mit VLANs nutzen, bevor ich Geld ausgebe.

 

[Raijin]

Eine Routerkaskade wäre definitv möglich, aber ich würde gerne auf das Einrichten von NAT oder Routen im normalen Netz verzichten.

Einen Tod musst du aber sterben. Wenn mehrere Netzwerke bzw Subnetze miteinander verbunden werden und kommunizieren sollen, benötigt man entweder passende Routen oder NAT nebst ggfs Portweiterleitungen.

Bei einer Routerkaskade mit NAT ist die Vefbindungsrichtung von innen (im Netz des kaskadierten Routers) nach außen (ins Netz des Internetrouters) bereits durch das Standardgateway gegeben und der Weg der Antwort durch das NAT des kaskadierten Routers. Die andere Verbindungsrichtung bedarf entsprechender Portweiterleitungen im kaskadierten Router.

Ohne NAT, also mit einem weitestgehend frei konfigurierbaren Router zwischen den Netzen gilt die Innen>Außen Richtung ebenso wie oben durch das Standardgateway im Testnetz. Der Rückweg muss jedoch mit Route versehen werden, weil eben nicht geNATet wird. Diese Route ist dann auch für die umgekehrte Verbindungsrichtung verantwortlich.


Beim gerouteten Setup ohne NAT muss entweder der Internetrouter über die Möglichkeit der manuellen Eingabe von statischen Routen verfügen (am einfachsten) oder jedes Gerät im Netz des Internetrouters, welches Verbindungen ins Testnetz aufbauen oder auf entsprechende Verbindungsanfragen aus dem Testnetz antworten soll, benötigt eine eigene statische Route.
NAT ist daher nicht zwingend ein Übel, weil einige Internetrouter gar keine benutzerdefinierten statischen Routen bieten und geräteeigene Routen sind weitestgehend nur bei PCs, o.ä. möglich, nicht aber bei zahlreichen embedded devices oder dergleichen...

 

[0x8100]

wenn der switch tatsächlich die acl so umsetzt wie beschrieben, dann ist weder ein weiterer router oder separate vlans nötig.

 

[Renegade334]

Ich komme Heute nicht mehr dazu das zu testen, aber ich habe jetzt eine leicht abgewandelte Regel erstellt.

Da die Filter immer nur eingehende Pakete blockieren habe ich UDP 67-68 für alle Quell und Ziel IPs gesperrt, damit nicht Anfragen aus dem Ursprungsnetz den DHCP im Testnetz erreichen. Denn die Antwort käme sonst trotzdem an. Außerdem musste ich noch eine Permit all Rule am Anfang einfügen, da scheinbar ein implizites Deny All automatisch ergänzt wird. Hatte mich kurz auf Port 1 selbst ausgesperrt
Ich melde mich, wenn ich das testen konnte. Danke schonmal.

Falls es nicht funktionieren sollte, schaue ich mir die anderen Lösungen an. Aber aktuell wäre die ACL das einfachste.

 

[Raijin]

Ich verstehe gerade nicht so recht was das bringen soll. Sieht danach aus als wenn damit die DHCP-Messages geblockt werden sollen. Das mag funktionieren, hilft hierbei

wobei das Testnetz einen unabhängigen DHCP Server nutzen soll und die Haupt FritzBox als Gateway zum Internet aber erreichbar sein muss.

Der restliche Traffic darf/soll auch netzübergreifend fließen.

aber herzlich wenig.... Die Geräte im Testnetz hätten andere IPs aus einem anderen Subnetz und somit keine Verbindung zur Fritzbox, ins Internet und auch nicht zu anderen Geräten im Fritznetz. So wie ich das verstanden habe, sollte das aber so sein? Naja, sei's drum. Wenn das so funktioniert wie du es dir vorgestellt hast, umso besser. Ob ich skeptisch bin und es anders machen würde, spielt ja keine Rolle solange dein Ziel erreicht wird

 

[0x8100]

voraussetzung ist natürlich, dass der zweite dhcp server adressen aus dem bereich der fritzbox verteilt inkl. gateway. natürlich dürfen die ranges sich nicht überschneiden. kommt eben drauf an, was der te mit seinem testnetz machen möchte.

 

[Raijin]

Aso, jetzt wird ein Schuh draus. Ich ging von einem anderen Subnetz aus. Ok, so könnte es gehen, aber je nachdem was da nun alles so rumgetest werden soll, ist das keine zuverlässige Testumgebung. Der DHCP-Traffic wird gefiltert, aber das ist dann auch schon alles. Wenn's so reicht, kein Ding, mir wäre das zu frickelig, aber who cares

 

[Renegade334]

Ja aktuell werden nur Adressen von .51 bis .199 verteilt. 1-50 Bleiben für Infrastruktur frei und ab 200 würde ich für das neue Netz „missbrauchen“.

Natürlich ist das kein empfohlener Aufbau, aber spart mir Kopfschmerzen wenn ich z.B. testweise einen Drucker oder Telefonie einbinden will. Den sonstigen Traffic würde ich aktuell als praxisnahes Hintergrundrauschen betrachten.

Mal abwarten wie gut das funktioniert.

 

[Renegade334]

Mal als Update:
Bisher sieht es gut aus.
Port 546 und 547 mussten noch gesperrt werden wegen DHCP für IPv6.

 

[Raijin]

Um sicherzustellen, dass wirklich kein DHCP-Traffic geleaked wird, solltest du mal mit WireShark / tcpdump an einem Haupt- und einem Test-Port checken ob da wirklich nichts durchkommt. Die reine Tatsache, dass es bisher an den jeweiligen Geräten mit dem gewünschten DHCP-Server klappt, ist noch kein Nachweis, sondern kann ggfs purer Zufall sein. Wenn du aber in WireShark/tcpdump keinerlei Pakete vom jeweils anderen DHCP siehst, solltest du safe sein.

 

[Renegade334]

Hört sich sinnvoll an.
Dann kann ich auch direkt testen, was passiert, wenn ich Port 1 z.B. auf 8 Mirror. Ob die Pakete dann auch gefiltert werden oder, was ich eigentlich erwarten würde, durchgehen.

Das wird aber eher eine Aufgabe fürs Wochenende.

 

[Raijin]

Übrigens: Du wirst natürlich auch gewisse Probleme mit der Namensauflösung bekommen, wenn du zwei DHCP-Server im selben Subnetz hast. Aktuell wird ja lediglich die DHCP-Kommunikation gefiltert, aber alle Geräte landen am Ende im selben Subnetz im selben physischen Netzwerk. Im Hauptnetz gehe ich mal davon aus, dass die Fritzbox auch als DNS fungiert, sei es direkt via DHCP verteilt oder ggfs als Upstream-DNS in pihole, o.ä. Wenn du nun lokale Namen auflösen willst, wird die Fritzbox zB nach "MeinNAS" gefragt - ergänzt um die lokale Domain, meistens .fritz.box. Die Fritzbox kann aber nur die lokalen Namen ihrer Geräte zurückgeben, nicht aber jene, die vom anderen DHCP-Server abgefrühstückt wurden. Der zweite DHCP-Server bzw. der dortige potentiell vorhandene DNS kann eventuell forwarden und entsprechend auch die anderen Geräte auflösen (lassen).

Es gibt zwar durchaus noch andere Technologien zur Namensauflösung und obiges Szenario ist nicht zwingend ein Genickbruch, aber es kann eben Probleme geben, wenn du denn überhaupt mit Hostnamen arbeitest.

Mittelfristig würde ich dir daher dennoch dazu raten, nach Abschluss deiner Tests den DHCP komplett umzuziehen oder mindestens den DNS auf halbwegs vernünftige Beine zu stellen, um beispielsweise von conditional forwarding zu profitieren. Damit könnte der zentrale DNS - zB pihole - nämlich auch anhand verschiedener DNS-Suffixe an zB den DNS der Fritzbox oder den DNS des zweiten DHCP-Servers weiterzuleiten. Voraussetzung: Die Clients müssen beide DNS-Suffixe in ihrer Suffix-Suchliste haben.

 

[Renegade334]

Im Testnetz würde ich die FritzBox eh entweder als Forwarder oder Conditional Forwarder im DNS eintragen, falls ich im jeweiligen Test auf Geräte aus dem alten Netz zugreifen muss.
Die Tests sind übrigens eher für PoCs gedacht, also meist nichts dauerhaftes. Das war auch einer der Gründe, warum im Ursprungsnetz keine Änderungen vorgenommen werden sollen. Die Umgebung dahinter ändert sich öfter mal.
Wobei ich das Gefühl habe, dass der DNS der Fritzbox mehr aufnimmt als er soll. Selbst PCs mit statischer IP außerhalb der DHCP Range landen da und können per FQDN mit fritz.box angesprochen werden. Für viele dürfte das von Vorteil sein, mich stört es ein wenig.