Entwickler-Netz abschotten : aber wie ohne die zu behindern?
Hallo,
ich habe einige Elektronikentwickler in meinem Netz (W2016 mit 2 ADs, auch als DNS. DHCP macht ein anderer W16).
Die testen dann auch schon mal Embedded-Linux Systeme, die z.B. zur Cloud verbinden müssen und/oder durch die Entwickler-PCs konfiguriert werden.
Also alles möglichst transparent, die suchen sich sonst den Wolf in der grauen Wolke der Linux-Systeme wenn da irgendwas nicht raus darf und nichts davon sagt....
Nun passiert aber letztens: eines der Linux-Systeme, frisch aufgesetzt, will sich als DHCP verdingen. Der Entwickler hat dem flugs in der IPv4-Config einen Maulkorb verpasst.
Leider aber nicht auf den v6 geachtet, der machte munter Werbung für sich.
Ich nutze intern kein v6, daher habe ich das normal auch nicht auf dem Schirm was sich da tut (ich lasse die W16-Server während der Config all das tun was sie meinen tun zu müssen bzgl. v6, bis dato kein Ding).
Kaum macht nun der Linux v6-DHCP, scheint mein Exchange die Idee zu haben sich dort eine neue v6 per DHCP zu besorgen...
Ihr könnt euch nicht vorstellen was ich mir den Wolf gesucht habe warum der Exchange plötzlich zickt; die Events waren voll mit Meldungen die ich noch nie gesehen bz. nicht zuordnen konnte etc.pp.
Erst als ich die Gemeinde angeschrieben habe bzgl. des Exchange-Problems, meldete sich der Entwickler kleinlaut und hat gebeichtet.
Lange Rede: wie bringt man dem Rest-Netz bei, sich nicht um solche Systeme wie temporäre Linuxe zu scheren - ohne die zu isolieren?
Danke Euch
ich habe einige Elektronikentwickler in meinem Netz (W2016 mit 2 ADs, auch als DNS. DHCP macht ein anderer W16).
Die testen dann auch schon mal Embedded-Linux Systeme, die z.B. zur Cloud verbinden müssen und/oder durch die Entwickler-PCs konfiguriert werden.
Also alles möglichst transparent, die suchen sich sonst den Wolf in der grauen Wolke der Linux-Systeme wenn da irgendwas nicht raus darf und nichts davon sagt....
Nun passiert aber letztens: eines der Linux-Systeme, frisch aufgesetzt, will sich als DHCP verdingen. Der Entwickler hat dem flugs in der IPv4-Config einen Maulkorb verpasst.
Leider aber nicht auf den v6 geachtet, der machte munter Werbung für sich.
Ich nutze intern kein v6, daher habe ich das normal auch nicht auf dem Schirm was sich da tut (ich lasse die W16-Server während der Config all das tun was sie meinen tun zu müssen bzgl. v6, bis dato kein Ding).
Kaum macht nun der Linux v6-DHCP, scheint mein Exchange die Idee zu haben sich dort eine neue v6 per DHCP zu besorgen...
Ihr könnt euch nicht vorstellen was ich mir den Wolf gesucht habe warum der Exchange plötzlich zickt; die Events waren voll mit Meldungen die ich noch nie gesehen bz. nicht zuordnen konnte etc.pp.
Erst als ich die Gemeinde angeschrieben habe bzgl. des Exchange-Problems, meldete sich der Entwickler kleinlaut und hat gebeichtet.
Lange Rede: wie bringt man dem Rest-Netz bei, sich nicht um solche Systeme wie temporäre Linuxe zu scheren - ohne die zu isolieren?
Danke Euch
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 655048
Url: https://administrator.de/forum/entwickler-netz-abschotten-aber-wie-ohne-die-zu-behindern-655048.html
Ausgedruckt am: 06.04.2025 um 16:04 Uhr
7 Kommentare
Neuester Kommentar
Moin,
gegen das DHCP-Problem hilft DHCP Snooping. Das müssen aber die Switche oder dein NAC können. (Du sagt leider nichts über dein Netzwerk)
Ansonsten musst du genau definieren, was von Dev-Netz in das "Rest-LAN" darf, dann alles in ein VLAN mit eigenem IP Subnetz packen und per ACL (oder Firewall) nur die gewünschten Pakete durchlassen.
Mutmaßung: 53, 80, 135, 137, 443, 445 je tcp/udp ist ausreichend.
lg,
Slainte
gegen das DHCP-Problem hilft DHCP Snooping. Das müssen aber die Switche oder dein NAC können. (Du sagt leider nichts über dein Netzwerk)
Ansonsten musst du genau definieren, was von Dev-Netz in das "Rest-LAN" darf, dann alles in ein VLAN mit eigenem IP Subnetz packen und per ACL (oder Firewall) nur die gewünschten Pakete durchlassen.
Mutmaßung: 53, 80, 135, 137, 443, 445 je tcp/udp ist ausreichend.
lg,
Slainte
Ihr könnt euch nicht vorstellen was ich mir den Wolf gesucht habe
Nein, können wir auch nicht, denn ein Netzwerk Admin hätte mit einem Wireshark Trace das in nicht einmal 10 Minuten entdeckt.Fazit zur Lösung:
Setze die Kollegen in ein eigenes VLAN was in 5 Minuten auf einem VLAN Switch eingerichtet ist und trenne sie mit einem einfachen 20 Euro NAT Router von deinem lokalen Netz.
Die Kollegen können in ihrem Netz dann frei schalten und walten mit welchen IP Adressen sie wollen und über die NAT Firewall alle deine lokalen Resourcen und das Internet erreichen ohbe irgendwelche Auswirkungen.
Fertig ist der Lack und du kannst dich entspannen das es in Zukunft nicht wieder zu solchen Vorkommnissen kommt ! Ohne Isolation ist das doch nicht machbar wie die Kollegen oben auch schon gesagt haben, denn diese Funktionen die zur Störung geführt haben basieren bekanntlich alle auf Layer 2. Du musst also die Layer 2 Broadcast Domains trennen und VLANs sind, wie immer, dafür deine besten Freunde. Wozu hat man Firewalls und NAT Router erfunden wenn nicht dafür...?!
Mit 20 Euro Hardware und 10 Minuten Zeitaufwand ja auch durchaus handhabbar.
Auf solch banale Lösungen kommt man in 5 Minuten doch auch selber ohne ein Administrator Forum. 😉
die müssen sowohl im eigenen Netz frei sein als auch auf die Linux-Büchsen runterkommen.
Wie bereits oben mehrfach gesagt ein kleiner 20 Euro Router zusammen mit VLANs erledigt das alles mit links:https://www.varia-store.com/de/produkt/97209-mikrotik-routerboard-rb941- ...
Eine alte FritzBox in der Bastelkiste oder jeglicher Breitband Router erledigt das auch.
Für die Grundlagen zu so einem simplen Setup einfach mal lesen, verstehen und machen:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Ist ja nun wahrlich kein Hexenwerk !