Fehler vLAN! Devices sehen und erkennen plötzlich Ressourcen aus anderen vLANs!
Kennt jemand eine Methode oder ein Tool um festzustellen, wo das eine vLAN seinen "Fuß" irrtümlicherweise in ein anderes vLAN streckt?
Hallo zusammen,
wir haben bei uns aktuell sechs vLAN's konfiguriert. Jedes dieser vLAN's wird mit unterschiedlichen IP-Ranges betrieben. In drei vLAN's haben wir jeweils einen DHCP-Server installiert.
Bisher hat das sehr gut geklappt! Seit ein paar Wochen beziehen jedoch einige Devices (PC's, Laptop's, IP-Telefone, ...) munter IP-Adressen eines nicht für sie vorgesehenen DHCP-Servers. Dies führt insbesondere bei der sensiblen IP-Telefonie zu schweren Fehlern an den Geräten und im Netz.
Im Einsatz haben wir:
DHCP-Server => Windows Server 2003 bzw. 2008
Switches => ProCurve PoE 2610
Management Software Switches => ProCurve Manager v3
Unsere Vermutung ist dahingehend, daß durch einen unbeabsichtigten Konfigurationsfehler, auf welchem Device auch immer, die vLAN's sich plötzlich "miteinander unterhalten" können.
Deshalb hier die Frage, ob irgendjemand ein Tool oder eine Methode kennt, ein (mittelgroßes) Netzwerk nach solchen "Löchern" zu scannen ...!
Vielen Dank für Eure Hilfe!
Michael
Hallo zusammen,
wir haben bei uns aktuell sechs vLAN's konfiguriert. Jedes dieser vLAN's wird mit unterschiedlichen IP-Ranges betrieben. In drei vLAN's haben wir jeweils einen DHCP-Server installiert.
Bisher hat das sehr gut geklappt! Seit ein paar Wochen beziehen jedoch einige Devices (PC's, Laptop's, IP-Telefone, ...) munter IP-Adressen eines nicht für sie vorgesehenen DHCP-Servers. Dies führt insbesondere bei der sensiblen IP-Telefonie zu schweren Fehlern an den Geräten und im Netz.
Im Einsatz haben wir:
DHCP-Server => Windows Server 2003 bzw. 2008
Switches => ProCurve PoE 2610
Management Software Switches => ProCurve Manager v3
Unsere Vermutung ist dahingehend, daß durch einen unbeabsichtigten Konfigurationsfehler, auf welchem Device auch immer, die vLAN's sich plötzlich "miteinander unterhalten" können.
Deshalb hier die Frage, ob irgendjemand ein Tool oder eine Methode kennt, ein (mittelgroßes) Netzwerk nach solchen "Löchern" zu scannen ...!
Vielen Dank für Eure Hilfe!
Michael
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 148619
Url: https://administrator.de/forum/fehler-vlan-devices-sehen-und-erkennen-ploetzlich-ressourcen-aus-anderen-vlans-148619.html
Ausgedruckt am: 22.12.2024 um 19:12 Uhr
5 Kommentare
Neuester Kommentar
Hallo Michael,
Ein paar Fragen vorab:
Gibt es ein falsch gepatchtes Netzwerkkabel ?
Ist der DHCP Relay (und -Helper) richtig konfiguriert ?
http://h10144.www1.hp.com/network-pro-news/articles/network-rxmar08.htm
Gibt es Routen zwischen den Netzen ?
Haben die Switches den gleichen Firmwarestand ?
Ist evtl ein asymetrisches VLAN eingerichtet ?
Können die falsch konfigurierten Clients arbeiten oder haben sie nur eine Adresse ?
Zum Scannern: Angry IP-Scanner. Der scant mal eben einen IP Range und dann sieht man sofort ob Geräte zum VLAN gehören oder nicht.
Johann
Ein paar Fragen vorab:
Gibt es ein falsch gepatchtes Netzwerkkabel ?
Ist der DHCP Relay (und -Helper) richtig konfiguriert ?
http://h10144.www1.hp.com/network-pro-news/articles/network-rxmar08.htm
Gibt es Routen zwischen den Netzen ?
Haben die Switches den gleichen Firmwarestand ?
Ist evtl ein asymetrisches VLAN eingerichtet ?
Können die falsch konfigurierten Clients arbeiten oder haben sie nur eine Adresse ?
Zum Scannern: Angry IP-Scanner. Der scant mal eben einen IP Range und dann sieht man sofort ob Geräte zum VLAN gehören oder nicht.
Johann
Hallo,
kurze Frage, ist es:
1x DHCP Server (physikalisch) mit 3 Netzwerkkarten in drei Netze (physikalische Ports)
1x DHCP Server (physikalisch) mit 1 Netzwerkkarten in drei Netze (vlan tagging)
3x DHCP Server (physikalisch) mit jeweils einer Netzwerkkarte in jeweils 1 Netz (physikalischer Port)
Ist es denn immer der gleiche DHCP Server, von dem die Clients fälschlicherweise Daten bekommen?
Wieviele Switches sind im Einsatz?
Ansonsten bleiben natürlich noch die Fragen vom Vorposter offen.
Entweder es ist irgendwo Routing aktiviert, eingerichtet oder einer der DHCP Server hängt an einem Trunk Port statt Access Port.
Kommt natürlich auf die genaue Netzstruktur an.
Ich kenne mich jetzt eher mit Cisco Geräten als HP aus, aber ich denke auch HP müsste sowas wie Port Security haben, würde ich bei den Switchports für die Server konfigurieren (bestimmte Mac Adressen erlauben, sonst schaltet sich der Port ab)
Grüße
kurze Frage, ist es:
1x DHCP Server (physikalisch) mit 3 Netzwerkkarten in drei Netze (physikalische Ports)
1x DHCP Server (physikalisch) mit 1 Netzwerkkarten in drei Netze (vlan tagging)
3x DHCP Server (physikalisch) mit jeweils einer Netzwerkkarte in jeweils 1 Netz (physikalischer Port)
Ist es denn immer der gleiche DHCP Server, von dem die Clients fälschlicherweise Daten bekommen?
Wieviele Switches sind im Einsatz?
Ansonsten bleiben natürlich noch die Fragen vom Vorposter offen.
Entweder es ist irgendwo Routing aktiviert, eingerichtet oder einer der DHCP Server hängt an einem Trunk Port statt Access Port.
Kommt natürlich auf die genaue Netzstruktur an.
Ich kenne mich jetzt eher mit Cisco Geräten als HP aus, aber ich denke auch HP müsste sowas wie Port Security haben, würde ich bei den Switchports für die Server konfigurieren (bestimmte Mac Adressen erlauben, sonst schaltet sich der Port ab)
Grüße
Das Routing wird ja logischerweise irgendwo konfiguriert sein und ist ja auch vermutlich gewollt um eine Kommunikation zwischen den VLANs zu ermöglichen.
Jeder Netzwerk Admin weiss das DHCP Requests auf UDP Broadcasts beruhen und niemals ohne weiteres Routing Grenzen überschreiten können, da ein Router eben per se keine UDP Broadcasts weiterleitet.
Errreichen kann man das nur mit sog. ip helper Adressen die UDP Broadcasts aus einem IP Segment dediziert auf eine Ziel IP forwarden können wie z.B. den zentralen DHCP Server !
Folglich kann also nur ein falscher UDP Forwarder auf dem Layer 3 Routing Switch so ein Desaster auslösen, niemals aber das Routing selber...das ist also Unsinn.
Bleiben also nur 3 Gründe:
1.) Falscher UDP Forwarding Eintrag bzw. Helper Adresse
2.) Falsche Patchung (Kabel verwechselt oder Backdoor Bridge gesteckt
3.) Falsche Port Konfiguration !
Da wirst du wohl also mal deine Switches einzeln durchforsten müssen und diesen Fehler suchen müssen. Eine korrekte HP VLAN Konfig kannst du z.B. hier nachprüfen:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Jeder Netzwerk Admin weiss das DHCP Requests auf UDP Broadcasts beruhen und niemals ohne weiteres Routing Grenzen überschreiten können, da ein Router eben per se keine UDP Broadcasts weiterleitet.
Errreichen kann man das nur mit sog. ip helper Adressen die UDP Broadcasts aus einem IP Segment dediziert auf eine Ziel IP forwarden können wie z.B. den zentralen DHCP Server !
Folglich kann also nur ein falscher UDP Forwarder auf dem Layer 3 Routing Switch so ein Desaster auslösen, niemals aber das Routing selber...das ist also Unsinn.
Bleiben also nur 3 Gründe:
1.) Falscher UDP Forwarding Eintrag bzw. Helper Adresse
2.) Falsche Patchung (Kabel verwechselt oder Backdoor Bridge gesteckt
3.) Falsche Port Konfiguration !
Da wirst du wohl also mal deine Switches einzeln durchforsten müssen und diesen Fehler suchen müssen. Eine korrekte HP VLAN Konfig kannst du z.B. hier nachprüfen:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern