12
W-LAN Clients in eigenes Netzwerk zwingen
IP Adressen werden knapp...
Hallo zusammen,
wiedermal hoffe ich darauf, hier jemanden mit mehr Fachkenntnis als ich sie habe zu finden.
Zum Hintergrund: Ich habe hier ein Class-C Netz, welches aufgrund der Teilung in DMZ / Intern geteilt wurde, so dass 126 Clients IP Adressen im internen Netzwerk erhalten können.
Seit kurzem können die Clients auch per W-LAN Zugriff auf das Netzwerk nehmen, und dies hat zu einer Explosion an IP Adressen geführt, wodurch der Adresspool (1-126) permanent nahezu erschöpft ist.
Notebooks verfügen nun oft über zwei IPs, da sie LAN und W-LAN parallel nutzen. Hinzu kommen zahlreiche Mobiltelefone.
Da ich soweit ich das sehe nicht durch eine Subnetz-Änderung den Pool an IP Adressen so erweitern kann, dass z.B. statt 126 150 Adressen und der Rest für die DMZ zur Verfügung stehen (dort würden nämlich 20 reichen) suche ich nach einem anderen Weg, IP Adressen frei zu bekommen.
Nun habe ich den Gedanken, die W-LAN Clients in einem eigenen Netzwerk (irgendeinen privaten Netzwerkbereich) unterzubringen, so dass sie keine Firmen-IPs mehr belegen, trotzdem aber vollen Zugang auf die Dienste des Firmennetzwerkes haben (Exchange, Dateisystem etc.)
Die Frage ist nun, wie stelle ich das an? Netzwerktechnisch bin ich leider eine echte Niete.
Zur Umgebung:
- W-LAN Access Points: Netgear WNDAP330
- WPA2 AES mit Radius (802.1x), jeder Client verfügt also über ein manuell vergebenes Zertifikat
- Radius = IAS, Windows Server 2003std, Windows 2003 Domäne
Die Frage ist vor allem, an welcher Stelle entscheide ich über das Netzwerk. Die Access Points können scheinbar kein NAT oder sonst etwas, was sie von einem Fremden Netzwerk in das Firmennetzwerk Routen würde.
Am RADIUS finde ich ebenfalls keinen Weg, die IP Vergabe zu beeinflussen.
Bleibt nur der Weg, zwischen die Aceess Points und dem Netzwerk entsprechende Switche zu hängen, die diese Aufgabe übernehmen?
Oder ist villeicht das Konzept an sich schon falsch, und ihr habt einen viel bessere Idee, wie ich die W-LAN Clients ohne Nachteile aus den Firmen IPs herausnehmen kann, oder das IP Problem an sich lösen kann.
Wäre für Tips dankbar.
Alex aka Cardi
Hallo zusammen,
wiedermal hoffe ich darauf, hier jemanden mit mehr Fachkenntnis als ich sie habe zu finden.
Zum Hintergrund: Ich habe hier ein Class-C Netz, welches aufgrund der Teilung in DMZ / Intern geteilt wurde, so dass 126 Clients IP Adressen im internen Netzwerk erhalten können.
Seit kurzem können die Clients auch per W-LAN Zugriff auf das Netzwerk nehmen, und dies hat zu einer Explosion an IP Adressen geführt, wodurch der Adresspool (1-126) permanent nahezu erschöpft ist.
Notebooks verfügen nun oft über zwei IPs, da sie LAN und W-LAN parallel nutzen. Hinzu kommen zahlreiche Mobiltelefone.
Da ich soweit ich das sehe nicht durch eine Subnetz-Änderung den Pool an IP Adressen so erweitern kann, dass z.B. statt 126 150 Adressen und der Rest für die DMZ zur Verfügung stehen (dort würden nämlich 20 reichen) suche ich nach einem anderen Weg, IP Adressen frei zu bekommen.
Nun habe ich den Gedanken, die W-LAN Clients in einem eigenen Netzwerk (irgendeinen privaten Netzwerkbereich) unterzubringen, so dass sie keine Firmen-IPs mehr belegen, trotzdem aber vollen Zugang auf die Dienste des Firmennetzwerkes haben (Exchange, Dateisystem etc.)
Die Frage ist nun, wie stelle ich das an? Netzwerktechnisch bin ich leider eine echte Niete.
Zur Umgebung:
- W-LAN Access Points: Netgear WNDAP330
- WPA2 AES mit Radius (802.1x), jeder Client verfügt also über ein manuell vergebenes Zertifikat
- Radius = IAS, Windows Server 2003std, Windows 2003 Domäne
Die Frage ist vor allem, an welcher Stelle entscheide ich über das Netzwerk. Die Access Points können scheinbar kein NAT oder sonst etwas, was sie von einem Fremden Netzwerk in das Firmennetzwerk Routen würde.
Am RADIUS finde ich ebenfalls keinen Weg, die IP Vergabe zu beeinflussen.
Bleibt nur der Weg, zwischen die Aceess Points und dem Netzwerk entsprechende Switche zu hängen, die diese Aufgabe übernehmen?
Oder ist villeicht das Konzept an sich schon falsch, und ihr habt einen viel bessere Idee, wie ich die W-LAN Clients ohne Nachteile aus den Firmen IPs herausnehmen kann, oder das IP Problem an sich lösen kann.
Wäre für Tips dankbar.
Alex aka Cardi
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 136642
Url: https://administrator.de/contentid/136642
Ausgedruckt am: 22.11.2024 um 10:11 Uhr
12 Kommentare
Neuester Kommentar
Hey,
vergrößere dein Netz z.b auf 2* 254 hosts.
255.255.254.0
dann nutzt du das erste netz für dmz
und das 2. netz für alle anderen Clients.
Wäre eine einfache Lösung.
Nur kurze Frage nebenbei:
die Dienste exchange, fileserver, liegen die im DMZ ?
oder sind hier extra Server am laufen für externe besucher (www z.b)
greetz
vergrößere dein Netz z.b auf 2* 254 hosts.
255.255.254.0
dann nutzt du das erste netz für dmz
und das 2. netz für alle anderen Clients.
Wäre eine einfache Lösung.
Nur kurze Frage nebenbei:
die Dienste exchange, fileserver, liegen die im DMZ ?
oder sind hier extra Server am laufen für externe besucher (www z.b)
greetz
Hatte selbiges Problem.
Im ersten Schritt habe ich die WLAN Konfiguration so angepasst, dass das Wlan-Modul der Notebooks keine IP bekommt, wenn gekabelt. Dies geht über die erweiterte Konfiguration der Treibereinstellung. Das ist die coolste variante und hat mir über Monate geholfen an meinen kleineneren Standorten.
Abhängig von den eingesetzten Switchen (die meisten können das) kannst du noch ein VLan definieren. Aber Achtung. u.U. haben die Anwender @home oder anderswo ein Problem.
Ganz intelligente Lösungen gehen dann mit Anwendungen wie MacMon die einen VLan -Manager einbinden können.
Im ersten Schritt habe ich die WLAN Konfiguration so angepasst, dass das Wlan-Modul der Notebooks keine IP bekommt, wenn gekabelt. Dies geht über die erweiterte Konfiguration der Treibereinstellung. Das ist die coolste variante und hat mir über Monate geholfen an meinen kleineneren Standorten.
Abhängig von den eingesetzten Switchen (die meisten können das) kannst du noch ein VLan definieren. Aber Achtung. u.U. haben die Anwender @home oder anderswo ein Problem.
Ganz intelligente Lösungen gehen dann mit Anwendungen wie MacMon die einen VLan -Manager einbinden können.
Erstmal vielen Dank für die Schnelle Antwort.
Wäre dies denn eine Legitime Lösung? Unser jetziger IP-Bereich wurde uns von unserem Provider zugewisen, und durch deinen Vorschlag würden sich einige IP Adressen im dritten Oktett ändern, oder?
Exchange, Fileserver etc. liegen im internen Netz. In der DMZ sind nur Dienste, die halt aus dem Internet von aussen erreichbar sein sollen, und entsprechend gesichert sind bzw. keine bedenklichen Daten enthalten.
Wäre dies denn eine Legitime Lösung? Unser jetziger IP-Bereich wurde uns von unserem Provider zugewisen, und durch deinen Vorschlag würden sich einige IP Adressen im dritten Oktett ändern, oder?
Exchange, Fileserver etc. liegen im internen Netz. In der DMZ sind nur Dienste, die halt aus dem Internet von aussen erreichbar sein sollen, und entsprechend gesichert sind bzw. keine bedenklichen Daten enthalten.
Zitat von @Workholic:
Hatte selbiges Problem.
Im ersten Schritt habe ich die WLAN Konfiguration so angepasst, dass das Wlan-Modul der Notebooks keine IP bekommt, wenn gekabelt.
Dies geht über die erweiterte Konfiguration der Treibereinstellung. Das ist die coolste variante und hat mir über
Monate geholfen an meinen kleineneren Standorten.
Abhängig von den eingesetzten Switchen (die meisten können das) kannst du noch ein VLan definieren. Aber Achtung. u.U.
haben die Anwender @home oder anderswo ein Problem.
Ganz intelligente Lösungen gehen dann mit Anwendungen wie MacMon die einen VLan -Manager einbinden können.
Hatte selbiges Problem.
Im ersten Schritt habe ich die WLAN Konfiguration so angepasst, dass das Wlan-Modul der Notebooks keine IP bekommt, wenn gekabelt.
Dies geht über die erweiterte Konfiguration der Treibereinstellung. Das ist die coolste variante und hat mir über
Monate geholfen an meinen kleineneren Standorten.
Abhängig von den eingesetzten Switchen (die meisten können das) kannst du noch ein VLan definieren. Aber Achtung. u.U.
haben die Anwender @home oder anderswo ein Problem.
Ganz intelligente Lösungen gehen dann mit Anwendungen wie MacMon die einen VLan -Manager einbinden können.
Auch dir danke!
Das mit den Treibereinstellungen klingt interessant, scheint aber nur über "Turenschuh-Administration" umsetzbar, oder?
Zudem würde das leider bei den Handys nicht helfen.
V-LANs kämen da wohl eher in Frage.
Wie ich aus den Beiträgen gelesen habe, verwendest du für deine Clients Adressen aus deinem öffentlichem Netz. Das ist prinzipiell OK. Du hast ein /24 Netz vom Provider bekommen. WOW, ich muss schon bei /29 betteln. Auch OK.
Du hast das Netz bei /25 getrennt. Wo liegen denn die IP-Adressen der DMZ? Kannst du die vieleicht auf /27 eingrenzen?
Hier mal mit Privaten Adressen:
10.0.0.0/25 Client-1
10.0.0.128/27 DMZ
10.0.0.160/27 Client-2
10.0.0.192/26 Client-3
Du brauchst nur Router in den entsprechenden netzen. Den Clients ist das Egal.
DHCP-CLI-NET-1
range: 10.0.0.2-126
router: 10.0.0.1
Mask: 255.255.255.128
DHCP-CLI-NET-2
range: 10.0.0.162-190
Router: 10.0.0.161
Mask: 255.255.255.224
DHCP-CLI-NET-3
Range: 10.0.0.194-254
Router: 10.0.0.193
Mask: 255.255.255.192
Alle 3 Bereiche können im gleichem VLAN (LAN) liegen.
Du hast das Netz bei /25 getrennt. Wo liegen denn die IP-Adressen der DMZ? Kannst du die vieleicht auf /27 eingrenzen?
Hier mal mit Privaten Adressen:
10.0.0.0/25 Client-1
10.0.0.128/27 DMZ
10.0.0.160/27 Client-2
10.0.0.192/26 Client-3
Du brauchst nur Router in den entsprechenden netzen. Den Clients ist das Egal.
DHCP-CLI-NET-1
range: 10.0.0.2-126
router: 10.0.0.1
Mask: 255.255.255.128
DHCP-CLI-NET-2
range: 10.0.0.162-190
Router: 10.0.0.161
Mask: 255.255.255.224
DHCP-CLI-NET-3
Range: 10.0.0.194-254
Router: 10.0.0.193
Mask: 255.255.255.192
Alle 3 Bereiche können im gleichem VLAN (LAN) liegen.
Zitat von @datasearch:
Wie ich aus den Beiträgen gelesen habe, verwendest du für deine Clients Adressen aus deinem öffentlichem Netz. Das
ist prinzipiell OK. Du hast ein /24 Netz vom Provider bekommen. WOW, ich muss schon bei /29 betteln. Auch OK.
Du hast das Netz bei /25 getrennt. Wo liegen denn die IP-Adressen der DMZ? Kannst du die vieleicht auf /27 eingrenzen?
Hier mal mit Privaten Adressen:
10.0.0.0/25 Client-1
10.0.0.128/27 DMZ
10.0.0.160/27 Client-2
10.0.0.192/26 Client-3
Du brauchst nur Router in den entsprechenden netzen. Den Clients ist das Egal.
DHCP-CLI-NET-1
range: 10.0.0.2-126
router: 10.0.0.1
Mask: 255.255.255.128
DHCP-CLI-NET-2
range: 10.0.0.162-190
Router: 10.0.0.161
Mask: 255.255.255.224
DHCP-CLI-NET-3
Range: 10.0.0.194-254
Router: 10.0.0.193
Mask: 255.255.255.192
Alle 3 Bereiche können im gleichem VLAN (LAN) liegen.
Du hast recht, ich verwende öffentliche IPs auch für das interne Netz. Erhalten hat das Netz mein Vorgänger, villeicht war das vor 10 Jahren einfacher als heute Wie ich aus den Beiträgen gelesen habe, verwendest du für deine Clients Adressen aus deinem öffentlichem Netz. Das
ist prinzipiell OK. Du hast ein /24 Netz vom Provider bekommen. WOW, ich muss schon bei /29 betteln. Auch OK.
Du hast das Netz bei /25 getrennt. Wo liegen denn die IP-Adressen der DMZ? Kannst du die vieleicht auf /27 eingrenzen?
Hier mal mit Privaten Adressen:
10.0.0.0/25 Client-1
10.0.0.128/27 DMZ
10.0.0.160/27 Client-2
10.0.0.192/26 Client-3
Du brauchst nur Router in den entsprechenden netzen. Den Clients ist das Egal.
DHCP-CLI-NET-1
range: 10.0.0.2-126
router: 10.0.0.1
Mask: 255.255.255.128
DHCP-CLI-NET-2
range: 10.0.0.162-190
Router: 10.0.0.161
Mask: 255.255.255.224
DHCP-CLI-NET-3
Range: 10.0.0.194-254
Router: 10.0.0.193
Mask: 255.255.255.192
Alle 3 Bereiche können im gleichem VLAN (LAN) liegen.
Deine Lösung klingt sehr sehr gut! Zumal sich an den bestehenden Adressen des internen Netzes überhaupt nichts ändert (und in meinem Fall auch nicht in der DMZ), und durch die Aufsplittung der zweiten Hälfte neue hinzukommen.
Vielen Dank, das werde ich so versuchen!
Nur kurz mal nebenbei geragt:
Ich nehme an, du brauchst nur den Öffentlichen IP Bereich für die DMZ oder?
es ist doch eigentlich eine Schwachstelle, wenn jeder client öffentlich erreichbar ist, sofern er keinen Dienst im Internet zur verfügung stellt ?
welcher dann eigentlich in die dmz gehört.
wenn das so richtig ist, wäre mein Vorschlag:
Nat für die internen Clients, dann kannst du mehrere Subnetze oder Vlan einrichten, und es kann kein Client direkt gescannt / attackiert werden.
oder hab ich was überlesen?
greetz
Ich nehme an, du brauchst nur den Öffentlichen IP Bereich für die DMZ oder?
es ist doch eigentlich eine Schwachstelle, wenn jeder client öffentlich erreichbar ist, sofern er keinen Dienst im Internet zur verfügung stellt ?
welcher dann eigentlich in die dmz gehört.
wenn das so richtig ist, wäre mein Vorschlag:
Nat für die internen Clients, dann kannst du mehrere Subnetze oder Vlan einrichten, und es kann kein Client direkt gescannt / attackiert werden.
oder hab ich was überlesen?
greetz
Zitat von @Marco123:
Nur kurz mal nebenbei geragt:
Ich nehme an, du brauchst nur den Öffentlichen IP Bereich für die DMZ oder?
es ist doch eigentlich eine Schwachstelle, wenn jeder client öffentlich erreichbar ist, sofern er keinen Dienst im Internet
zur verfügung stellt ?
welcher dann eigentlich in die dmz gehört.
wenn das so richtig ist, wäre mein Vorschlag:
Nat für die internen Clients, dann kannst du mehrere Subnetze oder Vlan einrichten, und es kann kein Client direkt gescannt /
attackiert werden.
oder hab ich was überlesen?
greetz
Nur kurz mal nebenbei geragt:
Ich nehme an, du brauchst nur den Öffentlichen IP Bereich für die DMZ oder?
es ist doch eigentlich eine Schwachstelle, wenn jeder client öffentlich erreichbar ist, sofern er keinen Dienst im Internet
zur verfügung stellt ?
welcher dann eigentlich in die dmz gehört.
wenn das so richtig ist, wäre mein Vorschlag:
Nat für die internen Clients, dann kannst du mehrere Subnetze oder Vlan einrichten, und es kann kein Client direkt gescannt /
attackiert werden.
oder hab ich was überlesen?
greetz
Jap, ich habe auch schon überlegt, die öffentlichen IPs im internen Netz völlig wegzulassen, allerdings wäre dies ein deutlicher Mehraufwand (und ich habe ehrlich gesagt ein wenig Sorge wie die ganzen Dienste auf die IP-Änderungen reagieren, das würde sicher Monate dauern, bis jede Eventlog zufrieden ist
).Sicherheitstechnisch sehe ich da kein Risiko, die Clients sind ja nicht öffentlich erreichbar, auch wenn sie es technisch sein könnten. Aber zwischen Client und Internet stehen immerhin 2 Firewalls.
Vermutlich steht da sowieso noch eine Firewall die die Clients schützt. Öffentliche Adressen für Clients zu vergeben war damals üblich und ist es dank IPv6 auch wieder geworden. NAT bietet nur bedingten Schutz. Verbindungsanfragen (State NEW) von außen nach innen abzublocken ist auch ein wirksamer schutz.
Hätte ich genug IP-Adressen würde ich das warscheinlich auch so machen. Erspart viele Probleme die durch NAT erst gekommen sind.
Hätte ich genug IP-Adressen würde ich das warscheinlich auch so machen. Erspart viele Probleme die durch NAT erst gekommen sind.
Hey, kenn leider eure Infrastruktur nicht ganz (Bezug auf die -> FW)
aber es sollte eigentlich klar sein :- )
aber man weiß es nie, hab leider schon einiges vorgefunden..... deswegen lieber einmal die Frage gestellt bzw in den Raum geworfen als dies komplett immer auszuschließen und zu denken das ist schon sicher :- )
greetz
aber es sollte eigentlich klar sein :- )
aber man weiß es nie, hab leider schon einiges vorgefunden..... deswegen lieber einmal die Frage gestellt bzw in den Raum geworfen als dies komplett immer auszuschließen und zu denken das ist schon sicher :- )
greetz
Naja, und selbst wenn, in diesem Szenario ging es ihm nicht um die Sicherheit. Es kann ja sein dass er ein lokaler ISP ist. Hier ist prinzipiell jeder Client selbst für die Sicherheit verantwortlich.
ich verseth nicht wieso clints öffentliche ips brauchen reicht kein NAT
oder steig doch auf ipv6 um da kommen diese probleme nicht mehr // nur ein tipp
oder steig doch auf ipv6 um da kommen diese probleme nicht mehr // nur ein tipp
