35
Zwei VLANs und Netbios-Auflösung schlägt fehl
HI,
ich hab 2 VLANs (192.168.0.xxx und 192.168.1.xxx, fixe IPs), die sehen sich soweit korrekt, jeder kann jeden anpingen, robocopy z.B. geht auch, wenn der Host als IP angegeben ist und wenn ich einem Host eine hosts/lmhosts-Datei anlege, kann der auch die dort enthaltenen Hostnamen nutzen. Aber das Netbios geht nicht, d.h. im Windows-Netzwerk sind immer nur die Hosts des "eigenen" VLANs zu sehen.
Was tun? WINS aufsetzen? (DNS scheint mir wegen des hosts/lmhosts-Tests ja nutzlos)?
Bin etwas ratlos
Danke für jeden Tipp
jörg
ich hab 2 VLANs (192.168.0.xxx und 192.168.1.xxx, fixe IPs), die sehen sich soweit korrekt, jeder kann jeden anpingen, robocopy z.B. geht auch, wenn der Host als IP angegeben ist und wenn ich einem Host eine hosts/lmhosts-Datei anlege, kann der auch die dort enthaltenen Hostnamen nutzen. Aber das Netbios geht nicht, d.h. im Windows-Netzwerk sind immer nur die Hosts des "eigenen" VLANs zu sehen.
Was tun? WINS aufsetzen? (DNS scheint mir wegen des hosts/lmhosts-Tests ja nutzlos)?
Bin etwas ratlos
Danke für jeden Tipp
jörg
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: 288566
Url: https://administrator.de/forum/zwei-vlans-und-netbios-aufloesung-schlaegt-fehl-288566.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
35 Kommentare
Neuester Kommentar
Mit ein wenig Netzwerkwissen ist das auch erklärbar warum das so ist.....
Der Windows Naming Service basiert wenn du keinen DNS Server nutzt auf simplen Naming Broadcasts im IP Segment.
Leider lässt du uns ja im Dunkeln tappen was die Kopplung deiner beiden IP VLAN Segmente anbetrifft aber gehen wir mal davon aus das es sauber und richtig mit einem Router oder Layer 3 Routing Switch gekoppelt ist, dann weiss man als Netzwerker das Broadcasts niemals über Routing Grenzen übertragen werden im TCP/IP.
Folglich können deine Naming Services also immer nur im einzelnen IP VLAN Segment funktionieren die eine gemeinsame L2 Broadcast Domain darstellen.
Als einfache Lösung hast du 3 Optionen:
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Der Windows Naming Service basiert wenn du keinen DNS Server nutzt auf simplen Naming Broadcasts im IP Segment.
Leider lässt du uns ja im Dunkeln tappen was die Kopplung deiner beiden IP VLAN Segmente anbetrifft aber gehen wir mal davon aus das es sauber und richtig mit einem Router oder Layer 3 Routing Switch gekoppelt ist, dann weiss man als Netzwerker das Broadcasts niemals über Routing Grenzen übertragen werden im TCP/IP.
Folglich können deine Naming Services also immer nur im einzelnen IP VLAN Segment funktionieren die eine gemeinsame L2 Broadcast Domain darstellen.
Als einfache Lösung hast du 3 Optionen:
- DNS Naming Server zentral aufsetzen. In der regel macht das ein AD mit
- Hast oder willst du kein DNS dann kannst du schlicht und einfach einen UDP Forwarder auf dem Switch konfigurieren (ip helper adrress)
- Willst du auch das nicht oder kann dein Router sowas nicht, dann kannst du die relevanten Namen von Servern etc. auch statisch in die hosts oder lmhosts Datei auf den Clients eintragen.
XP-Home mit 2 Kabelgebundenen und WLAN PCs
Danke erstmal, aber so einfach ist es anscheinend eben nicht.
1. ja, ist Layer3 Routing Switch, ich hab den nicht installiert
2. wenn WNS auf Broadcasts beruht (ich hatte noch nicht viel mit MS-Netzen zu tun), hast Du recht, ist klar, dass es nicht automatisch geht
3. habe ich ja die Sache (um zu testen, ob denn ein DNS-Server helfen würde) schon mal mit hosts/lmhosts probiert - ohne Erfolg. Ein
geht dann ebenso durch, wie ein aber ich sehe die Freigaben des betreffenden Hosts dennoch nicht und ein rdesktop dahin geht z.B. auch nicht... deshalb habe ich mich ja gefragt, ob es ein WINS-Server sein muss
jörg
1. ja, ist Layer3 Routing Switch, ich hab den nicht installiert
2. wenn WNS auf Broadcasts beruht (ich hatte noch nicht viel mit MS-Netzen zu tun), hast Du recht, ist klar, dass es nicht automatisch geht
3. habe ich ja die Sache (um zu testen, ob denn ein DNS-Server helfen würde) schon mal mit hosts/lmhosts probiert - ohne Erfolg. Ein
ping hostnameping ipjörg
Hallo,
@aqui hat die Ursache Deines Problems richtig beschrieben. Das NetBEUI-Protokoll (setzt auf NetBIOS auf) stammt noch aus der Anfangszeit der Vernetzung (es bildet den Protokollstack bei MS Windows bevor TCP/IP kam) und ist, wie schon richtig beschrieben, nicht für die Nahmensauflösung über Broadcastdomänen geeignet. ( https://de.wikipedia.org/wiki/NetBIOS und https://de.wikipedia.org/wiki/NetBEUI ). Um dieses "Problem" zu lösen und den alten Protokollstack von MS noch am Leben zuerhalten, hat MS WINS "erfunden" ( https://de.wikipedia.org/wiki/Windows_Internet_Naming_Service ).
In sofern ist Deine Idee, einen WINS-Server aufzusetzen, neben den Vorschlägen von @aqui, auch eine gangbare Lösung. Ob sie in Deinem Netzwerk sinnvoll umzusetzen ist, mußt Du entscheiden. Wenn Du eh schon einen AD mit DNS und DHCP hast, kann der WINS auch noch mit machen. Gibt es das nicht, ist ein ausschließlicher WINS-Server sicher nicht die beste Lösung.
Jürgen
@aqui hat die Ursache Deines Problems richtig beschrieben. Das NetBEUI-Protokoll (setzt auf NetBIOS auf) stammt noch aus der Anfangszeit der Vernetzung (es bildet den Protokollstack bei MS Windows bevor TCP/IP kam) und ist, wie schon richtig beschrieben, nicht für die Nahmensauflösung über Broadcastdomänen geeignet. ( https://de.wikipedia.org/wiki/NetBIOS und https://de.wikipedia.org/wiki/NetBEUI ). Um dieses "Problem" zu lösen und den alten Protokollstack von MS noch am Leben zuerhalten, hat MS WINS "erfunden" ( https://de.wikipedia.org/wiki/Windows_Internet_Naming_Service ).
In sofern ist Deine Idee, einen WINS-Server aufzusetzen, neben den Vorschlägen von @aqui, auch eine gangbare Lösung. Ob sie in Deinem Netzwerk sinnvoll umzusetzen ist, mußt Du entscheiden. Wenn Du eh schon einen AD mit DNS und DHCP hast, kann der WINS auch noch mit machen. Gibt es das nicht, ist ein ausschließlicher WINS-Server sicher nicht die beste Lösung.
Jürgen
Hallo,
MS ist schon vor vielen Jahren von seinem eigenem Protokollstack NetBEUI abgerückt und voll auf TCP/IP eingeschwenkt. Einschließlich der Namensauflösung ( --> DNS). Anfangs wurde noch zuerst versucht über WINS die Namen aufzulösen und danach erst über DNS. aber auch das ist bei den aktuellen MS-Betriebssystemen Geschichte. Einige "alte" Produkte (von Drittherstellern) setzen aber immer noch auf WINS/ NetBIOS over TCP. Aus kompatibilitätsgründen schlepp MS WINS/NetBIOS noch mit. Alle modernen Produkte (spez. die von Dir genannten Dienste von MS: RemoteDesktop usw.) setzen aber auf TCP/IP mit DNS-Namensauflösung.
Wenn bei Dir die DNS-Namensauflösung nicht funktioniert, solltest Du als erstes das testen (nslookup) und die Konfiguration Deines DNS-Servers überprüfen. Ist bei den Clients und im NAS der lokale DNS-Server, der die lokale Domäne auflöst, korrekt eingetragen (ipconfig /all)? Gibt es für alle Hosts Einträge in der DNS-Datenbank?
Wer macht in Deinem Netzwerk eigentlich den DNS-Server?
Jürgen
MS ist schon vor vielen Jahren von seinem eigenem Protokollstack NetBEUI abgerückt und voll auf TCP/IP eingeschwenkt. Einschließlich der Namensauflösung ( --> DNS). Anfangs wurde noch zuerst versucht über WINS die Namen aufzulösen und danach erst über DNS. aber auch das ist bei den aktuellen MS-Betriebssystemen Geschichte. Einige "alte" Produkte (von Drittherstellern) setzen aber immer noch auf WINS/ NetBIOS over TCP. Aus kompatibilitätsgründen schlepp MS WINS/NetBIOS noch mit. Alle modernen Produkte (spez. die von Dir genannten Dienste von MS: RemoteDesktop usw.) setzen aber auf TCP/IP mit DNS-Namensauflösung.
Wenn bei Dir die DNS-Namensauflösung nicht funktioniert, solltest Du als erstes das testen (nslookup) und die Konfiguration Deines DNS-Servers überprüfen. Ist bei den Clients und im NAS der lokale DNS-Server, der die lokale Domäne auflöst, korrekt eingetragen (ipconfig /all)? Gibt es für alle Hosts Einträge in der DNS-Datenbank?
Wer macht in Deinem Netzwerk eigentlich den DNS-Server?
Jürgen
Hi,
Problem ist, es ist nicht mein Netzwerk, ... und ich sitze gerade auch nicht davor... (halt der übliche Mist, "... kannst Du mal das und das zum Laufen bringen...?")
Soweit ich sehe, gibt es keinen DNS-Server, jedenfalls nicht im 2.VLAN (....1.xxx), im ersten steht zumindest die 192.168.0.1 als solcher in den Netzwerkeinstellungen (192.168.0.1 ist eine Cisco, die das zumindest könnte). Das Doofe ist, dass es aber im Widerspruch zum von Jürgen und Aqui Gesagten trotz korrekter TCP/IP Namensauflösung mittels hosts/lmhosts eben nicht funktioniert, aber funktionieren müsste. Die betreffenden Hosts sind Win7Prof, das ist doch auch nicht sooo alt.. Als das noch ein IP-Bereich war, ging das offensichtlich problemlos, aber es wurden mehr IPs gebraucht...
Jörg
Problem ist, es ist nicht mein Netzwerk, ... und ich sitze gerade auch nicht davor... (halt der übliche Mist, "... kannst Du mal das und das zum Laufen bringen...?")
Soweit ich sehe, gibt es keinen DNS-Server, jedenfalls nicht im 2.VLAN (....1.xxx), im ersten steht zumindest die 192.168.0.1 als solcher in den Netzwerkeinstellungen (192.168.0.1 ist eine Cisco, die das zumindest könnte). Das Doofe ist, dass es aber im Widerspruch zum von Jürgen und Aqui Gesagten trotz korrekter TCP/IP Namensauflösung mittels hosts/lmhosts eben nicht funktioniert, aber funktionieren müsste. Die betreffenden Hosts sind Win7Prof, das ist doch auch nicht sooo alt.. Als das noch ein IP-Bereich war, ging das offensichtlich problemlos, aber es wurden mehr IPs gebraucht...
Jörg
Hallo,
ist der DNS-Server auch bezüglich der geänderten IP-Strucktur (2 Subnetze) angepasst worden? (Revers-Auflösung)
Aber noch mal ein Paar Grundlagen:
Man unterscheidet sich anbietende Dienste und Resourcen und nachzufragende Dienste und Resourcen. Im alten IPX/SPX-Protokoll von Novell war ersteres implementiert (Service advertising, SAP): jeder der etwas "konnte" hat regelmäßig im Netzwerk per Broadcast Kund getan, das er da war und was er für Dienste bzw. Resourcen er bereitstellte. Kam nun ein neuer Client ins Netz, brauchte er nur eine Weile am Netzwerk "lauschen" und er "wußte , was so abgeht".
Bei TCP/IP ist das anders: wenn ein Client einen Dienst oder eine Resource benötigt, muß er im Netzwerk per Broadcast nachfragen, ob "jemand" da ist, der diesen Dienst/Resource anbietet. Der Antwortet dann per Unicast auf diese Anfrage. Dh. im Endeffekt, dass der Client keinen Gesamtüberblick über das Netzwerk und die darin verfügbaren Dienste und Resourcen bekommt, sondern immer gezielt "fragen" muß. Um die Broadcast-Grenze zu Überwinden, hat MS dann WINS "erfunden".
Da dieser Mechanismus im TCP/IP-Netzwerk für das Nutzen von Diensten und Resourcen im LAN kontraproduktiv ist, hat man sich auf höheren OSI-Protokoll-Schichten entsprechende "Ankündikungs-Protokolle" ausgedacht: SLP bei Novell, UPNP und DLNA im Multimediabereich, bei Apple Bonjour und viele weitere.
Dann noch der Hinweis, dass die Namensauflösung nur bedingt etwas mit dem Finden von Diensten und Resourcen zu tun hat. Namensauflösung dient dazu, über einen "Nickname" einen Host im Netzwerk korrekt anzusprechen: http://www.xyz.lokal heißt nichts weiter als dass ich über den "Nickname" www.xyz.lokal des Gerät mit der IP aaa.bbb.ccc.ddd anspreche. Und ich frage konkret, ob dort der HTTP-Dienst verfügbar ist. Wenn ja bekomme ich eine positive Antwort (Webseite), wenn nein "Zeitüberschreitung". --> nachfrage-orientiertes TCP/IP-Protokoll.
Um allen Clients bekanntzumachen, welche Dienste und Resoucen im Netzwerk verfügbar sind, brauche ich einen "Anbieter", der regelmäßig darüber informiert und vorher diese Informationen im Netz einsammelt. ZB. SLP ( https://de.wikipedia.org/wiki/Service_Location_Protocol )
Jürgen
ist der DNS-Server auch bezüglich der geänderten IP-Strucktur (2 Subnetze) angepasst worden? (Revers-Auflösung)
Aber noch mal ein Paar Grundlagen:
Man unterscheidet sich anbietende Dienste und Resourcen und nachzufragende Dienste und Resourcen. Im alten IPX/SPX-Protokoll von Novell war ersteres implementiert (Service advertising, SAP): jeder der etwas "konnte" hat regelmäßig im Netzwerk per Broadcast Kund getan, das er da war und was er für Dienste bzw. Resourcen er bereitstellte. Kam nun ein neuer Client ins Netz, brauchte er nur eine Weile am Netzwerk "lauschen" und er "wußte , was so abgeht".
Bei TCP/IP ist das anders: wenn ein Client einen Dienst oder eine Resource benötigt, muß er im Netzwerk per Broadcast nachfragen, ob "jemand" da ist, der diesen Dienst/Resource anbietet. Der Antwortet dann per Unicast auf diese Anfrage. Dh. im Endeffekt, dass der Client keinen Gesamtüberblick über das Netzwerk und die darin verfügbaren Dienste und Resourcen bekommt, sondern immer gezielt "fragen" muß. Um die Broadcast-Grenze zu Überwinden, hat MS dann WINS "erfunden".
Da dieser Mechanismus im TCP/IP-Netzwerk für das Nutzen von Diensten und Resourcen im LAN kontraproduktiv ist, hat man sich auf höheren OSI-Protokoll-Schichten entsprechende "Ankündikungs-Protokolle" ausgedacht: SLP bei Novell, UPNP und DLNA im Multimediabereich, bei Apple Bonjour und viele weitere.
Dann noch der Hinweis, dass die Namensauflösung nur bedingt etwas mit dem Finden von Diensten und Resourcen zu tun hat. Namensauflösung dient dazu, über einen "Nickname" einen Host im Netzwerk korrekt anzusprechen: http://www.xyz.lokal heißt nichts weiter als dass ich über den "Nickname" www.xyz.lokal des Gerät mit der IP aaa.bbb.ccc.ddd anspreche. Und ich frage konkret, ob dort der HTTP-Dienst verfügbar ist. Wenn ja bekomme ich eine positive Antwort (Webseite), wenn nein "Zeitüberschreitung". --> nachfrage-orientiertes TCP/IP-Protokoll.
Um allen Clients bekanntzumachen, welche Dienste und Resoucen im Netzwerk verfügbar sind, brauche ich einen "Anbieter", der regelmäßig darüber informiert und vorher diese Informationen im Netz einsammelt. ZB. SLP ( https://de.wikipedia.org/wiki/Service_Location_Protocol )
Jürgen
Das Doofe ist, dass es aber im Widerspruch zum von Jürgen und Aqui Gesagten trotz korrekter TCP/IP Namensauflösung mittels hosts/lmhosts eben nicht funktioniert, aber funktionieren müsste.
Du machst vermutlich immer nioch einen Denkfehler....Fakt ist das diese Broadcasts NICHT über die Segmente übertragen werden, jedenfalls nicht wenn du keine IP Helper konfiguriert hast auf dem Switch.
Das bedeutet dann das die Freigaben niemals automatisch angezeigt werden können, denn das können die Clients im VLAN 2 ja nur sehen wenn sie diese Broadcasts auch empfangen, was wie gesagt OHNE die IP Helper nicht möglich ist durch die Routertrennung.
Der statische Eintrag in der hosts oder lmhosts Datei bewirkt dann auch lediglich nur das du als Zieladresse beim Ping oder bei der Verbindung mit Shares eben den Hostnamen angeben kannst.
Es bedeutet aber NICHT das die Name Service Broadcasts über den Router übertragen werden was aber für das automatische Anzeigen der Shares zwingend nötig wäre.
Fakt ist also das die Broadcasts nicht im VLAN 2 landen !
Das ist aber kinderleicht zu lösen wenn dein L3 Switch UDP Broadcasts Forwarding supportet. Fast alle Switches können das heutzutage und supporten das. In der Regel wird das für DHCP Forwarding benutzt wenn man in segementierten Netzwerken einen zentralen DHCP Server benutzt.
Es funktioniert aber auch wunderbar für den MS Naming Service.
Damit ist das dann sehr einfach mit einer simplen Konfig Zeile am Switch zu lösen !
HI,
ich glaube, das habe ich soweit begriffen, ist mir nur noch nicht ganz klar, warum rdesktop z.B. auf den durch hosts/lmhosts korrekt auflösbaren Namen dann nicht geht. Aber vielleicht gibts da einen anderen Grund, auf die IP geht es ja auch nicht. Wobei da ein Fehler kommt (Host nicht gefunden oder so), während es bei einem hosts-Eintrag einfach nur rödelt ohne anzumelden...
Da ich erst nächste Woche wieder an das Netz komme, sage ich erstmal für alle Tipps einen herzlichen Dank! Ich werde dann zunächst mal das mit dem UDP Broadcasts Forwarding versuchen, das ist eine ganz neue Cisco, die das VLAN-Routing macht, die kann das definitiv. Vielleicht ist es ja wirklich nur der Haken in der Config... Ansonsten werde ich es mal mit WINS versuchen...
Danke & Grüße
Jörg
ich glaube, das habe ich soweit begriffen, ist mir nur noch nicht ganz klar, warum rdesktop z.B. auf den durch hosts/lmhosts korrekt auflösbaren Namen dann nicht geht. Aber vielleicht gibts da einen anderen Grund, auf die IP geht es ja auch nicht. Wobei da ein Fehler kommt (Host nicht gefunden oder so), während es bei einem hosts-Eintrag einfach nur rödelt ohne anzumelden...
Da ich erst nächste Woche wieder an das Netz komme, sage ich erstmal für alle Tipps einen herzlichen Dank! Ich werde dann zunächst mal das mit dem UDP Broadcasts Forwarding versuchen, das ist eine ganz neue Cisco, die das VLAN-Routing macht, die kann das definitiv. Vielleicht ist es ja wirklich nur der Haken in der Config... Ansonsten werde ich es mal mit WINS versuchen...
Danke & Grüße
Jörg
ist mir nur noch nicht ganz klar, warum rdesktop z.B. auf den durch hosts/lmhosts korrekt auflösbaren Namen dann nicht geht.
Das ist in der Tat ungewöhnlich, kann aber nur ein Konfig Fehler deinerseits sein. Hier funktioniert das fehlerlos auf einem Raspberry Pi und einem Win 2008 R2 Server !https://www.youtube.com/watch?v=rUhSR2xPmuw&index=1&list=PLHX2AZ ...
https://www.dropbox.com/s/4gnfnl09vwjwgva/Raspberry%20Pi%20as%20Thinclie ...
Wenn der Ping auf den in der /etc/hosts angegebenen Namen funktioniert tut es auch alles andere aus allen Applikationen.
Aber vielleicht gibts da einen anderen Grund, auf die IP geht es ja auch nicht.
Sieh !! Da ist also was anderes im Argen !Vermutlich wie immer die lokale Firewall auf dem Zielrechner, denn die merkt ja anhand der Absender IP im Paket das du aus einem fremden Netz kommst und blockiert dann somit den Zugriff....sofern du die lokale Firewall nicht entsprechend anpasst !
das ist eine ganz neue Cisco, die das VLAN-Routing macht, die kann das definitiv.
Was macht dich da so sicher ??Vielleicht ist es ja wirklich nur der Haken in der Config..
Ganz sicher nicht, denn ein IOS basiert Catalyst hat keinen "Haken" ! Da gilt der allgemeine Grundsatz: "Real networkers do CLI !" und kein Klicki Bunti für Winblows Knechte.Es sei denn du hast einen Cisco Billigswitch aus der SG Serie der aber nur Bootp und DHCP forwarden kann aber ein Naming Broadcast weil ihm dazu das Kommando ip forward protocoll udp xyz fehlt.
Wenn es ein Switch aus der Catalyst Reihe mit IOS ist dann kann er das aber. Das Kommando lautet ip helper address x.y.z.a auf dem entsprechenden Source vlan L3 Interface auf dem Switch.
Wobei du bei ".a" statt einer dedizierten Adresse dann einfach die Ziel Netzwerk Adresse angibst und et voila..... schon kannst du dann deine Shares alle im VLAN 2 sehen.
Hallo,
das Broadcast nicht geroutet wird, also im eigenen Subnetz bleibt, hat schon seinen Grund! Viele Dienste nutzen Broadcast zur erstmaligen Kommunikation usw. Das "interessiert" in der Regel nur die Geräte, die sich im gleichen Subnetz befinden. Wenn man nun Broadcast aus dem eigenem Subnetz "heraus läßt", flutet man das Netz mit "sinnlosen" Datenpaketen und treibt die Auslastung von Netzwerkbandbreite, Routerauslastung usw. in die Höhe. Das ist auch nicht das "gelbe vom Ei".
Ist es nicht sinnvoller die Shares über feste Links (zb. als Icon) auf die Clients zu binden? Oder "Netzwerklaufwerke" fest zuzuordnen (Anmeldescript)?
Jürgen
PS. Wenn der ganze "Ärger" nur anfällt, weil ihr zuwenig freie IPs im Subnetz habt und deshalb 2 Subnetze einsetzt, stellt sich natürlich auch die Frage, warum Du nicht auf ein Class B-Subnetz gegangen bist. Da brauchst Du nicht routen, alles ist in einer Broadcast-Domäne, Du brauchst keinen L3-Switch, alle sehen sich und sind glücklich.
das Broadcast nicht geroutet wird, also im eigenen Subnetz bleibt, hat schon seinen Grund! Viele Dienste nutzen Broadcast zur erstmaligen Kommunikation usw. Das "interessiert" in der Regel nur die Geräte, die sich im gleichen Subnetz befinden. Wenn man nun Broadcast aus dem eigenem Subnetz "heraus läßt", flutet man das Netz mit "sinnlosen" Datenpaketen und treibt die Auslastung von Netzwerkbandbreite, Routerauslastung usw. in die Höhe. Das ist auch nicht das "gelbe vom Ei".
Ist es nicht sinnvoller die Shares über feste Links (zb. als Icon) auf die Clients zu binden? Oder "Netzwerklaufwerke" fest zuzuordnen (Anmeldescript)?
Jürgen
PS. Wenn der ganze "Ärger" nur anfällt, weil ihr zuwenig freie IPs im Subnetz habt und deshalb 2 Subnetze einsetzt, stellt sich natürlich auch die Frage, warum Du nicht auf ein Class B-Subnetz gegangen bist. Da brauchst Du nicht routen, alles ist in einer Broadcast-Domäne, Du brauchst keinen L3-Switch, alle sehen sich und sind glücklich.
Die Cisco hat eine Weboberfläche. Ganz abgesehen davon, dass ich mich vor der Commandline nicht direkt fürchte...
Es ist nicht mein Netz. Die brauchten sowieso VLANs und L3, weil sie erstens noch eine Direktfunkstrecke, zweitens ein VLAN für eine Telefonanlage und drittens noch ein anderes VLAN drinhaben... ich hätte sicher auch zu B-Netz geraten... ŵie gesagt, ich seh das Ding erst nächste Woche wieder. Dann werde ich Eure Tipps nochmal lesen.
Danke jedenfalls
Jörg
Danke jedenfalls
Jörg
Die Cisco hat eine Weboberfläche.
Ein Auto hat auch 4 schwarze Reifen... Solche sinnfreien Angaben nützen gar nichts wenn man nicht mal in der Lage ist Ross und Reiter zu benennen sprich SG Billigserie oder Cat IOS Switch Serie 
Die brauchten sowieso VLANs und L3, weil sie erstens noch eine Direktfunkstrecke, zweitens ein VLAN für eine Telefonanlage und drittens noch ein anderes VLAN drinhaben
Eine sehr gute und auch weise Entscheidung eines Netzwerkers hier zu segmentieren. ich hätte sicher auch zu B-Netz geraten...
Das ist immer die dümmste Lösung eines Laien der wenig von Netzwerken und Networking versteht. Große Broadcast Domains = große Probleme. Das lernt Klein Fritzchen in der 1. Klasse Netzwerk Grundlagen.Vielleicht solltest du dort besser doch jemanden ranlassen der weiss was er tut oder denjenigen der die technisch richtige Segmentierung beschlossen hat... ?!
Ist nicht böse gemeint nur ein weiser Tip um dir weiteren Stress zu ersparen.
Hallo,
nun wenn du uns den genauen Namen des Cisco Switches nennst dann kriegen wir das schon hin....
@aqui wird die config im halbschlaf tippen...
Und, zu dem Hinweis von @aqui das die Vergrößerung desr Broadcast domain durch aufbohren der Netzwerk Maske die dümmste der möglichen Ideen ist, noch ein Hinweis von mir...
Die Aufteilung der IP Adressen in Klassen wurde 1993 im Rahmen der Umstellung auf CIDR
komplett abgeschafft, seitdem gibt es die KLassen A B C und so weiter nicht mehr... Leider hält es sich bis heute in aktuellen Fachbüchern....
brammer
nun wenn du uns den genauen Namen des Cisco Switches nennst dann kriegen wir das schon hin....
@aqui wird die config im halbschlaf tippen...
Und, zu dem Hinweis von @aqui das die Vergrößerung desr Broadcast domain durch aufbohren der Netzwerk Maske die dümmste der möglichen Ideen ist, noch ein Hinweis von mir...
ich hätte sicher auch zu B-Netz geraten..
Die Aufteilung der IP Adressen in Klassen wurde 1993 im Rahmen der Umstellung auf CIDR
komplett abgeschafft, seitdem gibt es die KLassen A B C und so weiter nicht mehr... Leider hält es sich bis heute in aktuellen Fachbüchern....
brammer
Hallo @brammer,
nach meinem Kenntnisstand hat sich aber an den für private, nicht ins öffentliche Netz geroutete, IP-Adressbereiche nichts geändert. Du mußt also den privaten (Class B-) Adressbereich 172.x.y.z oder den privaten (Class A-) Adressbereich 10.x.y.z nehmen und über entsprechende Subnetzmasken die gewünschte IP-Anzahl einstellen.
Ansonsten hast Du natürlich recht.
Jürgen
nach meinem Kenntnisstand hat sich aber an den für private, nicht ins öffentliche Netz geroutete, IP-Adressbereiche nichts geändert. Du mußt also den privaten (Class B-) Adressbereich 172.x.y.z oder den privaten (Class A-) Adressbereich 10.x.y.z nehmen und über entsprechende Subnetzmasken die gewünschte IP-Anzahl einstellen.
Ansonsten hast Du natürlich recht.
Jürgen
Hallo,
@chiefteddy
Den verlinkten Artikel gelesen?
...
btw. es gibt 3 pivaten IP Adressbereiche:
10.0.0.0 bis 10.255.255.255 10.0.0.0/8
172.16.0.0 bis 172.31.255.255 172.16.0.0/12
192.168.0.0 bis 192.168.255.255 192.168.0.0/16
brammer
@chiefteddy
Den verlinkten Artikel gelesen?
Bei CIDR führte man als neue Notation so genannte Suffixe ein. Das Suffix gibt die Anzahl der 1-Bits in der Netzmaske an. Diese Schreibform, z. B.
172.17.0.0/17, ist viel kürzer und im Umgang einfacher als die Dotted decimal notation wie 172.17.0.0/255.255.128.0 und ebenfalls eindeutig.
172.17.0.0/17, ist viel kürzer und im Umgang einfacher als die Dotted decimal notation wie 172.17.0.0/255.255.128.0 und ebenfalls eindeutig.
...
Seit der Einführung von CIDR ist classful routing zwar praktisch abgeschafft, beispielsweise ein /24-Netz als „Class C“ zu bezeichnen ist jedoch,
zumindest umgangssprachlich, erhalten geblieben – obwohl diese Bezeichnung zumeist sogar falsch ist, da mittlerweile ehemalige Class A- oder
Class B-Netze als kleinere Allokationen/Assignments zugeteilt werden und man somit ggf. von einem „Class C“-großen Netz spricht, was nach
klassischer Notation ein Subnetz eines Class-A- oder B-Netzes wäre.
zumindest umgangssprachlich, erhalten geblieben – obwohl diese Bezeichnung zumeist sogar falsch ist, da mittlerweile ehemalige Class A- oder
Class B-Netze als kleinere Allokationen/Assignments zugeteilt werden und man somit ggf. von einem „Class C“-großen Netz spricht, was nach
klassischer Notation ein Subnetz eines Class-A- oder B-Netzes wäre.
btw. es gibt 3 pivaten IP Adressbereiche:
10.0.0.0 bis 10.255.255.255 10.0.0.0/8
172.16.0.0 bis 172.31.255.255 172.16.0.0/12
192.168.0.0 bis 192.168.255.255 192.168.0.0/16
brammer
@chiefteddy
Die Klasseneinteilung gibt es seit CIDR nur noch sprachlich aber nicht mehr technisch.
und über entsprechende Subnetzmasken die gewünschte IP-Anzahl einstellen.
Das gilt aber wie der Kollege brammer schon richtig sagt auch für alle öffentlichen IPs auch eine 22.0.0.0 oder 154.1.2.0 usw. kann man frei subnetten wie man lustig ist und was von der IANA ja auch gemacht wird. Ansonsten wäre die derzeitige IPv4 Mangelverwaltung der weltweiten Adresskontingente gar nicht mehr möglich.Die Klasseneinteilung gibt es seit CIDR nur noch sprachlich aber nicht mehr technisch.
Hallo Freunde,
ich weiß wie Subneting funktioniert und kenne die einschlägigen Normen.
Die Subnetz-Masken-Schreibweise /24 mag zwar kürzer (und normgerechter) sein, eingeben bei der Konfiguration von Routern, Netzwerkkarten usw. mußt Du aber immer noch 255.255.255.0. Und wenn Du die Anzahl der max. Host je Subnetz ausrechnen willst, geht das immernoch am Besten mit der binär-Schreibweise.
Also gestattet einem fast 60ig jährigen ein Netzwerk 192.168.1.0/24 als Class C-Netzwerk zu bezeichnen, auch wenn das nicht mehr ganz korekt ist.
Und das man aus 10.1.0.0/8 auch 10.1.0.0/24 machen kann, ist ja das Wesen von Subneting.
Das Subneting für alle IP-Adressbereiche gilt, also auch die öffentlichen, ist mir durchaus bewußt. Ich habe es aber, wie die meisten hier, eher selten mit Subneting von öffentlichen IP-Adressbereichen zu tun.
Ich wünsche Euch noch einen schönen Abend.
Jürgen
ich weiß wie Subneting funktioniert und kenne die einschlägigen Normen.
Die Subnetz-Masken-Schreibweise /24 mag zwar kürzer (und normgerechter) sein, eingeben bei der Konfiguration von Routern, Netzwerkkarten usw. mußt Du aber immer noch 255.255.255.0. Und wenn Du die Anzahl der max. Host je Subnetz ausrechnen willst, geht das immernoch am Besten mit der binär-Schreibweise.
Also gestattet einem fast 60ig jährigen ein Netzwerk 192.168.1.0/24 als Class C-Netzwerk zu bezeichnen, auch wenn das nicht mehr ganz korekt ist.
Und das man aus 10.1.0.0/8 auch 10.1.0.0/24 machen kann, ist ja das Wesen von Subneting.
Das Subneting für alle IP-Adressbereiche gilt, also auch die öffentlichen, ist mir durchaus bewußt. Ich habe es aber, wie die meisten hier, eher selten mit Subneting von öffentlichen IP-Adressbereichen zu tun.
Ich wünsche Euch noch einen schönen Abend.
Jürgen
Hallo,
@chiefteddy,
Das war in keiner Weise als persönliche Kritik gemeint.
ich gehe mal davon aus das die meisten Netzwerker, gerade die mit langjähriger Erfahrung, durchaus aus noch die Klassen Bezeichnungen kennen.
Mich stört in diesem Zusammenhang nur, das in Fachbüchern diese Bezeichnungen noch heute gelebt wird.
Ich habe vor einiger Zeit eine Diskussion mit einem unserer Stdenten zu diesem Thema gehabt, der eine Klausur in der Uni versaut hat, weil er die Klassen in der Klausur nicht (!) genannt hat. Ich habe darauf hin mit dem Professor gesprochen und dieser musste einsehen und eingestehen das er im Unrecht war und der Student doch die Klausur bestanden hat.
Deswegen bin ich bei diesem Thema inzwischen entwas sensibel.
Für den Sprachgebrauch okay... aber leider geht die Verwendung weit über den Sprachgebrauch hinaus... und das halte ich für wenig zielführend...
brammer
btw.: selbst das Cisco IOS kennt inzwischen an manchen Stellen die Schreibweise /24.
@chiefteddy,
Das war in keiner Weise als persönliche Kritik gemeint.
ich gehe mal davon aus das die meisten Netzwerker, gerade die mit langjähriger Erfahrung, durchaus aus noch die Klassen Bezeichnungen kennen.
Mich stört in diesem Zusammenhang nur, das in Fachbüchern diese Bezeichnungen noch heute gelebt wird.
Ich habe vor einiger Zeit eine Diskussion mit einem unserer Stdenten zu diesem Thema gehabt, der eine Klausur in der Uni versaut hat, weil er die Klassen in der Klausur nicht (!) genannt hat. Ich habe darauf hin mit dem Professor gesprochen und dieser musste einsehen und eingestehen das er im Unrecht war und der Student doch die Klausur bestanden hat.
Deswegen bin ich bei diesem Thema inzwischen entwas sensibel.
Für den Sprachgebrauch okay... aber leider geht die Verwendung weit über den Sprachgebrauch hinaus... und das halte ich für wenig zielführend...
brammer
btw.: selbst das Cisco IOS kennt inzwischen an manchen Stellen die Schreibweise /24.
Ja, nicht falsch verstehen bitte. Das war in keinster Weise als Kritik gemeint. Ob du /24 oder 3mal 255 schreibst oder binär ist kosmetisch. Eine "Norm" in dem Sinne gibt es da nicht. Also alles gut wie es ist.
Es ist rein die Klasseneinteilung die sich früher aus den ersten 2 Bits der Adresse ergeben hat, die ist tod mit CIDR. Natürlich wissen aber alte IP Hasen immer was damit gemeint ist
Aber egal...alles kosmetisch
Es ist rein die Klasseneinteilung die sich früher aus den ersten 2 Bits der Adresse ergeben hat, die ist tod mit CIDR. Natürlich wissen aber alte IP Hasen immer was damit gemeint ist
wie die meisten hier, eher selten mit Subneting von öffentlichen IP-Adressbereichen zu tun
Mmmhhh...die meisten und selten...woher weisst du das. Hier ist das eher Tagesgeschäft und von selten kann man nicht sprechen...Aber egal...alles kosmetisch
Hallo,
also, wenn mich die flüchtige Notiz nicht täuscht, ist es eine Cisco 880, lt. Doku kennt die "ip helper-address x.y.z.a", ob man das auch in der Weboberfläche eintragen kann, kann ich gerade nicht sagen, weil es für die keine richtige Doku zu geben scheint... aber cmdline ist nicht das Problem... nach etwas Lesen würde ich annehmensollte gegenseitige bcasts von/nach 192.168.0.xxx / 192.168.1.xxx hinbekommen? Oder liege ich da falsch?
Ansonsten scheint es mir wie bei Anwälten zu sein: 2 Netzwerke und 3 Meinungen... ich denke, mit ca. 400 benutzten IPs wäre das Broadcasting in einem B-Netz auch nicht sonderlich in die Knie gegangen... die mit der "technisch richtigen Segmentierung" haben immerhin mehrere Tage gebraucht, um die VLANs so einzurichten, dass wenigstens Pings durchgehen, theoretisch hätten sie das bcast forwarding gleich mitmachen können, ... und das waren bezahlte "Profis", da tummeln sich wahrscheinlich jede Menge Flachzangen auf dem Markt.
Dafür, dass ich als DB-Entwickler und Linuxer mit einem reinen C-Netz und sonst begrenzter Erfahrung mit Netzwerken da nicht sofort durchsehe, schäme ich mich nicht direkt... Aber es ist die gelebte Realität in deutschen KMUs, dass weder der Weiterbildungsetat noch die personelle Kapazität der Breite heutiger IT angemessen sind... also wursteln wir uns durch...
Danke jedenfalls für Eure Hinweise
jörg
also, wenn mich die flüchtige Notiz nicht täuscht, ist es eine Cisco 880, lt. Doku kennt die "ip helper-address x.y.z.a", ob man das auch in der Weboberfläche eintragen kann, kann ich gerade nicht sagen, weil es für die keine richtige Doku zu geben scheint... aber cmdline ist nicht das Problem... nach etwas Lesen würde ich annehmen
ip helper-address 192.168.255.255Ansonsten scheint es mir wie bei Anwälten zu sein: 2 Netzwerke und 3 Meinungen... ich denke, mit ca. 400 benutzten IPs wäre das Broadcasting in einem B-Netz auch nicht sonderlich in die Knie gegangen... die mit der "technisch richtigen Segmentierung" haben immerhin mehrere Tage gebraucht, um die VLANs so einzurichten, dass wenigstens Pings durchgehen, theoretisch hätten sie das bcast forwarding gleich mitmachen können, ... und das waren bezahlte "Profis", da tummeln sich wahrscheinlich jede Menge Flachzangen auf dem Markt.
Dafür, dass ich als DB-Entwickler und Linuxer mit einem reinen C-Netz und sonst begrenzter Erfahrung mit Netzwerken da nicht sofort durchsehe, schäme ich mich nicht direkt... Aber es ist die gelebte Realität in deutschen KMUs, dass weder der Weiterbildungsetat noch die personelle Kapazität der Breite heutiger IT angemessen sind... also wursteln wir uns durch...
Danke jedenfalls für Eure Hinweise
jörg
Hallo,
nein!
Genau das kommt von den Klassenbezeichnungen
192.168.0.1 mit einer vermutlichen Maske 255.255.255.0 (oder /24) geht von 192.168.0.0 - 192.168.0.255
192.168.1.1 mit einer vermutlichen Maske 255.255.255.0 (oder /24) geht von 192.168.1.0 - 192.168.1.255
ich gehe von einer /24 Maske aus da du von zwei VLAN mit diesen IP Adressen in deinem Post schreibst, aber zu einer IP Adresse gehört immer auch die Maske!
bzw.
wäre richtig!
und die .255 ist nur dan richtig wenn der Dienst dahinter auch erreichbar ist!
Was die Größe einer Broadcast Domain angeht...
das hängt davon ab welche Komponenten in dem Netz aktiv sind...
Wenn du nur starke performante Server aktiv hast... kein Problem
Hast du evtl ältere Komponenten oder Steuerungssysteme oder propietäre Systeme dabei dann können 50 user schon zuviel sein!
brammer
nein!
Genau das kommt von den Klassenbezeichnungen
192.168.0.1 mit einer vermutlichen Maske 255.255.255.0 (oder /24) geht von 192.168.0.0 - 192.168.0.255
192.168.1.1 mit einer vermutlichen Maske 255.255.255.0 (oder /24) geht von 192.168.1.0 - 192.168.1.255
ich gehe von einer /24 Maske aus da du von zwei VLAN mit diesen IP Adressen in deinem Post schreibst, aber zu einer IP Adresse gehört immer auch die Maske!
ip helper-address 192.168.0.255
ip helper-address 192.168.1.255 wäre richtig!
und die .255 ist nur dan richtig wenn der Dienst dahinter auch erreichbar ist!
Was die Größe einer Broadcast Domain angeht...
das hängt davon ab welche Komponenten in dem Netz aktiv sind...
Wenn du nur starke performante Server aktiv hast... kein Problem
Hast du evtl ältere Komponenten oder Steuerungssysteme oder propietäre Systeme dabei dann können 50 user schon zuviel sein!
brammer
Ansonsten scheint es mir wie bei Anwälten zu sein: 2 Netzwerke und 3 Meinungen...
Jeder ITler weiss das es so einen Blödsinn im Bereich der IT niemals gibt. Dort ist alles digital...nix also mit 3 Meinungen... Den Rest hat Kollege brammer ja oben schon umfassend erklärt.
Wenn es aber schon an solchen Banalitäten wie das richtige Erkennen von IP Subnetzmasken scheitert, dann siehts für den Rest aber nicht rosig aus.
Vielleicht solltest du dir dann doch jemanden an Bord holen der wenigstens weiss was er da macht. Nur mal so als gut gemeinter Tip.
Hallo,
bin längere Zeit nicht zu der Kiste gekommen, nun hatte ich mal Zeit, etwas mehr zu sehen: die Cisco hängt woanders (Gateway, FW...) dran, stattdessen wird die VLAN-Segmentierung von einer DLINK DGS1510 (-52 wenn ich mich nicht irre) gemacht. Die hat eine Weboberfläche, auf der man zwar das VLAN-tagging einstellen kann (neben vielem Anderen) aber kein ip helper-address. Ich habe mich mal durch das CLI gebuddelt, da gibt es das auch nicht, auch nix, was so ähnlich klang, dass ich es hätte probieren wollen. Die PDF mit der Doku ist da auch schweigsam, es gibt zwar broadcast storm control, aber sonst nix zu broadcast. Sieht also so aus, als ob da Schluss wäre.
Dann habe ich mal einen DNS aufgesetzt, pings, nslookup, Zugriffe auf lokale Webserver funzen über die Segmentgrenzen prächtig, aber kein remote desktop. Der PC, der sich einwählen soll, rödelt endlos ohne Ergebnis. Steht er im gleichen Subnet, ist es kein Problem. Gibt es da eine Option, mit der man rdp auf das "eigene" Subnet begrenzen kann?
Anderer Test: Ich habe mal spaßeshalber 3 PCs über einen (unmanaged) switch verbunden, 192.168.0.6/23, 192.168.0.135/23 und 192.168.1.200/23. Die sehen sich sofort, ping, broadcasts, Freigaben, sofort alles da. Nun überlege ich doch wieder, ob ich die Segmentierung wieder rausnehme, stattdessen allen, die sich über die bisherigen Segmentgrenzen per broadcast sehen sollen, eine NM /23 zu geben (mehr als die 500 IPs werden es wohl nie werden, solange IP v4 noch lebt). Gibt es denn in der Größe wirklich Probleme mit dem Umfang der Broadcasts oder andere? Im Test sieht das alles ganz manierlich aus, ich müsste im "alten" 192.168.0.xxx/24 lediglich dem Gateway und ein paar kleinen Servern und bestimmten Druckern auch eine NM /23 verpassen und halt allen im "neuen" 192.168.1.xxx/24 auch. Die anderen könnten ja bei /24 bleiben und nur einander sehen, wie bisher auch... vorausgesetzt, der DLINK würde die Broadcasts auch alle so durchleiten, wie der unamanaged switch, was ich erstmal testen müsste...
Ich weiss, dass das nicht schön ist. Aber Ziel ist dort nunmal, dass ein ins Netz eingehängtes Gerät automatisch von den ganzen Windozen gesehen wird, seine Freigaben und Drucker. Aqui wird es sicher verreißen
Thx & grüße
jth
bin längere Zeit nicht zu der Kiste gekommen, nun hatte ich mal Zeit, etwas mehr zu sehen: die Cisco hängt woanders (Gateway, FW...) dran, stattdessen wird die VLAN-Segmentierung von einer DLINK DGS1510 (-52 wenn ich mich nicht irre) gemacht. Die hat eine Weboberfläche, auf der man zwar das VLAN-tagging einstellen kann (neben vielem Anderen) aber kein ip helper-address. Ich habe mich mal durch das CLI gebuddelt, da gibt es das auch nicht, auch nix, was so ähnlich klang, dass ich es hätte probieren wollen. Die PDF mit der Doku ist da auch schweigsam, es gibt zwar broadcast storm control, aber sonst nix zu broadcast. Sieht also so aus, als ob da Schluss wäre.
Dann habe ich mal einen DNS aufgesetzt, pings, nslookup, Zugriffe auf lokale Webserver funzen über die Segmentgrenzen prächtig, aber kein remote desktop. Der PC, der sich einwählen soll, rödelt endlos ohne Ergebnis. Steht er im gleichen Subnet, ist es kein Problem. Gibt es da eine Option, mit der man rdp auf das "eigene" Subnet begrenzen kann?
Anderer Test: Ich habe mal spaßeshalber 3 PCs über einen (unmanaged) switch verbunden, 192.168.0.6/23, 192.168.0.135/23 und 192.168.1.200/23. Die sehen sich sofort, ping, broadcasts, Freigaben, sofort alles da. Nun überlege ich doch wieder, ob ich die Segmentierung wieder rausnehme, stattdessen allen, die sich über die bisherigen Segmentgrenzen per broadcast sehen sollen, eine NM /23 zu geben (mehr als die 500 IPs werden es wohl nie werden, solange IP v4 noch lebt). Gibt es denn in der Größe wirklich Probleme mit dem Umfang der Broadcasts oder andere? Im Test sieht das alles ganz manierlich aus, ich müsste im "alten" 192.168.0.xxx/24 lediglich dem Gateway und ein paar kleinen Servern und bestimmten Druckern auch eine NM /23 verpassen und halt allen im "neuen" 192.168.1.xxx/24 auch. Die anderen könnten ja bei /24 bleiben und nur einander sehen, wie bisher auch... vorausgesetzt, der DLINK würde die Broadcasts auch alle so durchleiten, wie der unamanaged switch, was ich erstmal testen müsste...
Ich weiss, dass das nicht schön ist. Aber Ziel ist dort nunmal, dass ein ins Netz eingehängtes Gerät automatisch von den ganzen Windozen gesehen wird, seine Freigaben und Drucker. Aqui wird es sicher verreißen
Thx & grüße
jth
Hallo,
nochmal zum Nachlesen: Es gibt nachfrage-orientierte Protokolle und angebots-orientierte Protokolle.
Bei letzterem teilt der Dienst-ANBIETER in regelmäßigen Abständen im Netzwerk (meist über Broadcast) mit, das er einen Dienst bereitstellt --> anbietet. Die Clients, egal wann sie ins Netzkommen, lauschen einfach eine Weile am Netzwerk (Broadcast) und wissen dann, welche Dienste von welchen Geräten (Adressen) im Netzwerk bereitgestellt werden. Das können sie dann auch auf der Client-Oberfläche darstellen. Ein typischer Vertreter dieser angebots-orientierten Protokolle ist das alte IPX/SPX-Protokoll von Novell Netware. Deshalb sehen auch alle Novell-Clients sofort die verfügbaren Netware-Server mit ihren Freigaben.
TCP/IP ist ein nachfrage-orientiertes Protokoll, dh. der Client muß, wenn er einen Netzwerkdienst benötigt, gezielt im Netz nach diesem Dienst fragen.
http://192.168.150.10 oder http://www.domaene.de heißt nichts weiter als dass der Client den entsprechenden Host anfragt, ob er diesen Dienst (http) anbietet. Wenn ja, dann bekommt der Client die angefragte Seite ausgeliefert, wenn nein, Fehlermendung. Der Client muß also wissen, wo im Netzwerk welcher Dienst angeboten wird! Die Dienste machen von sich aus keine "Werbung" im Netz.
Das Problem ist natürlich, dass der Client in der Regel nicht weiß, wo im Netz welcher Dienst erreichbar ist. Man muß es ihm "sagen". Bei DNS macht man es durch die Konfiguration der Netzwerkschnittstelle. Bei anderen Diensten (zB. Multimedia) müssen weitere (höhere) Protokolle implementiert werden (zB. UPNP, DLNA).
Ein simples Suchen nach verfügbaren Diensten durch den Client kann protokolltechnisch nur über Broadcast erfolgen (oder es müßten alle möglichen Adressen für jedes Dienst-Protokoll per Unicast angefragt werden). Und bei Broadcast sind wir wieder auf die Broadcast-Domäne beschränkt (also bis zum nächsten Router).
Das ist nun mal per Protokoll-Design bei TCP/IP so. (Dafür soll es auch nach einem Atom-Krieg noch funktionieren )
Es gibt natürlich Ansätze, dieses Dilemma zu lösen (DHCP-Relay, IP-Helper, SLP). Das ändert aber nichts am grundsätzlichen Problem.
Jürgen
PS Im Handbuch des DLink-Switches gibt es einen Abschnitt über DHCP-Relay (Kap. 4) und IP-Helper (Kap. 6).
ftp://ftp.dlink.de/dgs/dgs-1510-20/documentation/DGS-1510-20_man_RevA_1-30_all_en_20151028.pdf
nochmal zum Nachlesen: Es gibt nachfrage-orientierte Protokolle und angebots-orientierte Protokolle.
Bei letzterem teilt der Dienst-ANBIETER in regelmäßigen Abständen im Netzwerk (meist über Broadcast) mit, das er einen Dienst bereitstellt --> anbietet. Die Clients, egal wann sie ins Netzkommen, lauschen einfach eine Weile am Netzwerk (Broadcast) und wissen dann, welche Dienste von welchen Geräten (Adressen) im Netzwerk bereitgestellt werden. Das können sie dann auch auf der Client-Oberfläche darstellen. Ein typischer Vertreter dieser angebots-orientierten Protokolle ist das alte IPX/SPX-Protokoll von Novell Netware. Deshalb sehen auch alle Novell-Clients sofort die verfügbaren Netware-Server mit ihren Freigaben.
TCP/IP ist ein nachfrage-orientiertes Protokoll, dh. der Client muß, wenn er einen Netzwerkdienst benötigt, gezielt im Netz nach diesem Dienst fragen.
http://192.168.150.10 oder http://www.domaene.de heißt nichts weiter als dass der Client den entsprechenden Host anfragt, ob er diesen Dienst (http) anbietet. Wenn ja, dann bekommt der Client die angefragte Seite ausgeliefert, wenn nein, Fehlermendung. Der Client muß also wissen, wo im Netzwerk welcher Dienst angeboten wird! Die Dienste machen von sich aus keine "Werbung" im Netz.
Das Problem ist natürlich, dass der Client in der Regel nicht weiß, wo im Netz welcher Dienst erreichbar ist. Man muß es ihm "sagen". Bei DNS macht man es durch die Konfiguration der Netzwerkschnittstelle. Bei anderen Diensten (zB. Multimedia) müssen weitere (höhere) Protokolle implementiert werden (zB. UPNP, DLNA).
Ein simples Suchen nach verfügbaren Diensten durch den Client kann protokolltechnisch nur über Broadcast erfolgen (oder es müßten alle möglichen Adressen für jedes Dienst-Protokoll per Unicast angefragt werden). Und bei Broadcast sind wir wieder auf die Broadcast-Domäne beschränkt (also bis zum nächsten Router).
Das ist nun mal per Protokoll-Design bei TCP/IP so. (Dafür soll es auch nach einem Atom-Krieg noch funktionieren
)Es gibt natürlich Ansätze, dieses Dilemma zu lösen (DHCP-Relay, IP-Helper, SLP). Das ändert aber nichts am grundsätzlichen Problem.
Jürgen
PS Im Handbuch des DLink-Switches gibt es einen Abschnitt über DHCP-Relay (Kap. 4) und IP-Helper (Kap. 6).
ftp://ftp.dlink.de/dgs/dgs-1510-20/documentation/DGS-1510-20_man_RevA_1-30_all_en_20151028.pdf
Hallo und Danke für die Klarstellung.
Das war mir aber nicht neu. Im Linux-Bereich hat man es eh immer mit Nachfrage zu tun (i.allg. heißt es da immer der jeweilige Serverprozess "lauscht" ..., cups, apache, ftp, wer auch immer).
Aber Windows erkennt dennoch - und ich wüßte nicht, wie das ohne broadcasts gehen soll - wenn ein anderer Windows-PC neu im Netzwerk "erscheint" und zeigt dessen Shares in seinem "Netzwerk" an. Selbst wenn es intern anders abläuft, für den User "bietet" der neue PC quasi seine Shares an. Und das soll er bitteschön über die VLAN-Segmentgrenzen tun. Was allerdings nicht klärt, warum das RDP auch nicht über die Segmentgrenze will.
Danke für das PS mit der Literatur, ich habe eine andere PDF, vielleicht eine ältere Version. Unter den L3-Funktionen habe ich dort - und auch auf der Maschine - zuerst nach IP helper gesucht, wenn ich es nicht aus Dusseligkeit übersehen habe, gibt es das da nicht, aber natürlich prüfe ich das nochmal, mache mir allerdings nicht allzu viel Hoffnung, weil es im CLI (das irgendsoein ios-Derivat zu sein scheint) auch nicht aufgetaucht ist. Das würde ich ja zumindest erwarten, aber unter den IP-Befehlen war da nix. Kann natürlich sein, ich habe an der falschen Ecke gesucht und es steht irgendwo in UDP... ich werde das auf jeden Fall nochmal nachsehen.
Entweder werde ich da fündig oder ich werde wohl auf NM /23 umstellen, und hoffen, dass die Broadcasts dann auch über den managed router gehen, wenn ich das VLAN-tagging abschalte. Kann ich ja an einem einzelnen Port erstmal testen.
Danke jedenfalls allen für die Hinweise
cu jth
Das war mir aber nicht neu. Im Linux-Bereich hat man es eh immer mit Nachfrage zu tun (i.allg. heißt es da immer der jeweilige Serverprozess "lauscht" ..., cups, apache, ftp, wer auch immer).
Aber Windows erkennt dennoch - und ich wüßte nicht, wie das ohne broadcasts gehen soll - wenn ein anderer Windows-PC neu im Netzwerk "erscheint" und zeigt dessen Shares in seinem "Netzwerk" an. Selbst wenn es intern anders abläuft, für den User "bietet" der neue PC quasi seine Shares an. Und das soll er bitteschön über die VLAN-Segmentgrenzen tun. Was allerdings nicht klärt, warum das RDP auch nicht über die Segmentgrenze will.
Danke für das PS mit der Literatur, ich habe eine andere PDF, vielleicht eine ältere Version. Unter den L3-Funktionen habe ich dort - und auch auf der Maschine - zuerst nach IP helper gesucht, wenn ich es nicht aus Dusseligkeit übersehen habe, gibt es das da nicht, aber natürlich prüfe ich das nochmal, mache mir allerdings nicht allzu viel Hoffnung, weil es im CLI (das irgendsoein ios-Derivat zu sein scheint) auch nicht aufgetaucht ist. Das würde ich ja zumindest erwarten, aber unter den IP-Befehlen war da nix. Kann natürlich sein, ich habe an der falschen Ecke gesucht und es steht irgendwo in UDP... ich werde das auf jeden Fall nochmal nachsehen.
Entweder werde ich da fündig oder ich werde wohl auf NM /23 umstellen, und hoffen, dass die Broadcasts dann auch über den managed router gehen, wenn ich das VLAN-tagging abschalte. Kann ich ja an einem einzelnen Port erstmal testen.
Danke jedenfalls allen für die Hinweise
cu jth
Anderer Test: Ich habe mal spaßeshalber 3 PCs über einen (unmanaged) switch verbunden, 192.168.0.6/23, 192.168.0.135/23 und 192.168.1.200/23. Die sehen sich sofort, ping, broadcasts, Freigaben, sofort alles da.
Kein Wunder !Jeder Netzwerk Dummie sieht das die Rechner ja alle in einem gemeinsamen IP Netzwerk sind mit der 23 Bit Maske....warum sollte das also nicht gehen ? Banale Binsenweisheit die jeder Netzwerker sofort sieht !
ob ich die Segmentierung wieder rausnehme
Häää...? Was für eine "Segmentierung" denn ?? Dein definiertes IP Netzwerk geht laut deiner Maske ja von 192.168.0.1bis 192.168.1.254.
Wo bitte siehst du hier eine "Segmentierung" ?
Gibt es denn in der Größe wirklich Probleme mit dem Umfang der Broadcasts oder andere?
Ja, denn jedes Broad- und Multicast Paket belastet die Endgeräte überflüssigerweise. Ist deinen Layer 2 Broadcast Domain zu groß kann das erheblichen Einfluss auf die Netzwerk Performance haben. bedenke auch das ein Switch solche Pakete fluten muss, sprich er muss sie auf alle Ports der L2 Doamin (VLAN) kopieren. Schwachbrüstige Billigswitches wie deine D-Link Gurke legen sich da gerne mal die Karten...vorausgesetzt, der DLINK würde die Broadcasts auch alle so durchleiten, wie der unamanaged switch, was ich erstmal testen müsste...
Der Satz zeigt aber einmal mehr das du erhebliche Defizite im Verständnis von Netzwerk Protokollen und deren Kommunikation hast.Ein unmanaged Dummswitch macht genau das gleiche wie ein managebarer. Sowas muss man normal nicht "testen". Das ist so sinnfrei als wenn man Patchkabel testen will ob da außer IP Paketen auch NetBios oder OSPF durchgeht....
Aqui wird es sicher verreißen
So ist es ! Dein Vorhaben ist natürlich grösstmöglicher Unsinn die Funktionalität eines Netzes einzig an der Erreichbarkeit von Broadcast basierten Windows SMB Rechnern zu orientieren. Das darfst du niemanden laut erzählen....mehr muss man dazu nicht sagen.Mit einem gescheiten Switch, der UDP Brodcast Relay (IP Helper Adressen) supportet ist das übrigens auch in wirklich segmentierten Netzen kein Problem obwohl diese Lösung auch von hinten durch die Brust ins Auge ist.
Da wäre das statische Eintragen der Rechner in die hosts oder lmhosts Datei fast noch besser.....aber egal.
Aber Windows erkennt dennoch - und ich wüßte nicht, wie das ohne broadcasts gehen soll
Mit einem DNS Server macht man das normalerweise....für den User "bietet" der neue PC quasi seine Shares an.
Ist bei neueren Winblows aber nicht mehr so ! Da muss man es explizit einrichten und erlauben, da es natürlich ein Sicherheitsrisiko darstellt.Und das soll er bitteschön über die VLAN-Segmentgrenzen tun.
Was ja auch problemlos geht mit IP Helpern oder eben der statischen Festlegung un der hosts oder lmhosts Datei.Was allerdings nicht klärt, warum das RDP auch nicht über die Segmentgrenze will.
Das geht ganz sicher, denn das basiert ja NICHT auf Brodcasts sondern ist ein stinknormal routebares TCP Protokoll.Sollte es bei dir scheitern ist das zu 99,9% eine fehlerhafte lokale Winblows Firewall die das verhindert, denn die blockt im Default Absender Pakete mit IP Adressen aus fremden IP Netzen...weiss man aber als Winblows Knecht auch.
Aber egal...nimm am besten eine IP Adresse mit einem 16 Bit Prefix / Maske das löst alle deine Probleme und wir können uns weitere Argumente sparen hier...
Hi,
dass Du Dich definitiv besser auskennst in dieser Windows-Sch... rechtfertigt Deinen Ton keinesfalls...
bis 192.168.1.254.
Wo bitte siehst du hier eine "Segmentierung" ?
Wenn Du richtig gelesen hättest,wäre klar, dass ich den Zustand vor der NM /23 meine...
... naja, Genaues weißt Du aber nix, oder?
Ein unmanaged Dummswitch macht genau das gleiche wie ein managebarer. Sowas muss man normal nicht "testen". Das ist so sinnfrei als wenn man Patchkabel testen will ob da außer IP Paketen auch NetBios oder OSPF durchgeht....
Wieder nicht richtig gelesen. Die Frage ist doch, ob die "DLink-Gurke", wenn ich das VLAN-tagging rausnehme, wirklich wie ein unmanaged switch arbeitet... sollte sie vielleicht, aber...
Sorry. Das ist nicht mein Vorhaben. Es ist mein Auftrag. Du kannst ja mal unverbindlich mit der Firmenleitung sprechen
Ich habe im Übrigen schon dümmere Anforderungen gesehen...
exakt. Aber der führt trotz korrekter nslookups nicht zu dem gewünschten Ergebnis (hättest Du auch lesen können)
So? Naja, in der Praxis ist es dann komischerweise immer erlaubt... ganz zu schweigen von Abteilungsdruckern etc., die wahrscheinlich nicht mal wissen, dass man es verbieten könnte...
nein. tut es eben nicht. Nicht mit lmhosts, hosts und dns. macht es einfach nicht. ip helper muss ich sehen, aber wie o.g. gibt es das evt. da nicht
Sollte es bei dir scheitern ist das zu 99,9% eine fehlerhafte lokale Winblows Firewall die das verhindert, denn die blockt im Default Absender Pakete mit IP Adressen aus fremden IP Netzen...weiss man aber als Winblows Knecht auch.
das war mein erster Gedanke... so trivial ist es aber anscheinend nicht, ich habs probiert. Was sind die restlichen 0,1 Prozent ?
Freundliche Grüße
dass Du Dich definitiv besser auskennst in dieser Windows-Sch... rechtfertigt Deinen Ton keinesfalls...
Zitat von @aqui:
Jeder Netzwerk Dummie sieht das die Rechner ja alle in einem gemeinsamen IP Netzwerk sind mit der 23 Bit Maske....warum sollte das also nicht gehen ? Banale Binsenweisheit die jeder Netzwerker sofort sieht !
Natürlich ist es kein Wunder... ich wollte ja nur sehen, ob es neben der Segmentierung _andere_ Hindernisse gibt...Anderer Test: Ich habe mal spaßeshalber 3 PCs über einen (unmanaged) switch verbunden, 192.168.0.6/23, 192.168.0.135/23 und 192.168.1.200/23. Die sehen sich sofort, ping, broadcasts, Freigaben, sofort alles da.
Kein Wunder !Jeder Netzwerk Dummie sieht das die Rechner ja alle in einem gemeinsamen IP Netzwerk sind mit der 23 Bit Maske....warum sollte das also nicht gehen ? Banale Binsenweisheit die jeder Netzwerker sofort sieht !
ob ich die Segmentierung wieder rausnehme
Häää...? Was für eine "Segmentierung" denn ?? Dein definiertes IP Netzwerk geht laut deiner Maske ja von 192.168.0.1bis 192.168.1.254.
Wo bitte siehst du hier eine "Segmentierung" ?
Gibt es denn in der Größe wirklich Probleme mit dem Umfang der Broadcasts oder andere?
Ja, denn jedes Broad- und Multicast Paket belastet die Endgeräte überflüssigerweise. Ist deinen Layer 2 Broadcast Domain zu groß kann das erheblichen Einfluss auf die Netzwerk Performance haben. bedenke auch das ein Switch solche Pakete fluten muss, sprich er muss sie auf alle Ports der L2 Doamin (VLAN) kopieren. Schwachbrüstige Billigswitches wie deine D-Link Gurke legen sich da gerne mal die Karten...vorausgesetzt, der DLINK würde die Broadcasts auch alle so durchleiten, wie der unamanaged switch, was ich erstmal testen müsste...
Der Satz zeigt aber einmal mehr das du erhebliche Defizite im Verständnis von Netzwerk Protokollen und deren Kommunikation hast.Ein unmanaged Dummswitch macht genau das gleiche wie ein managebarer. Sowas muss man normal nicht "testen". Das ist so sinnfrei als wenn man Patchkabel testen will ob da außer IP Paketen auch NetBios oder OSPF durchgeht....
Aqui wird es sicher verreißen
So ist es ! Dein Vorhaben ist natürlich grösstmöglicher Unsinn die Funktionalität eines Netzes einzig an der Erreichbarkeit von Broadcast basierten Windows SMB Rechnern zu orientieren. Das darfst du niemanden laut erzählen....mehr muss man dazu nicht sagen.Ich habe im Übrigen schon dümmere Anforderungen gesehen...
Mit einem gescheiten Switch, der UDP Brodcast Relay (IP Helper Adressen) supportet ist das übrigens auch in wirklich segmentierten Netzen kein Problem obwohl diese Lösung auch von hinten durch die Brust ins Auge ist.
Da wäre das statische Eintragen der Rechner in die hosts oder lmhosts Datei fast noch besser.....aber egal.
Ja, aber das geht eben nicht. Ich habe einige Zeit darauf verschwendet.Da wäre das statische Eintragen der Rechner in die hosts oder lmhosts Datei fast noch besser.....aber egal.
Aber Windows erkennt dennoch - und ich wüßte nicht, wie das ohne broadcasts gehen soll
Mit einem DNS Server macht man das normalerweise....für den User "bietet" der neue PC quasi seine Shares an.
Ist bei neueren Winblows aber nicht mehr so ! Da muss man es explizit einrichten und erlauben, da es natürlich ein Sicherheitsrisiko darstellt.Und das soll er bitteschön über die VLAN-Segmentgrenzen tun.
Was ja auch problemlos geht mit IP Helpern oder eben der statischen Festlegung un der hosts oder lmhosts Datei.Was allerdings nicht klärt, warum das RDP auch nicht über die Segmentgrenze will.
Das geht ganz sicher, denn das basiert ja NICHT auf Brodcasts sondern ist ein stinknormal routebares TCP Protokoll.Sollte es bei dir scheitern ist das zu 99,9% eine fehlerhafte lokale Winblows Firewall die das verhindert, denn die blockt im Default Absender Pakete mit IP Adressen aus fremden IP Netzen...weiss man aber als Winblows Knecht auch.
Aber egal...nimm am besten eine IP Adresse mit einem 16 Bit Prefix / Maske das löst alle deine Probleme und wir können uns weitere Argumente sparen hier...
Freundliche Grüße
dass Du Dich definitiv besser auskennst in dieser Windows-Sch...
Tu ich ja gar nicht...im Gegenteil ! Ich habe nur mal einen Wireshark Sniffer angeschmissen und nachgesehen was diese Windows-Sch.. so im Netzwerk rumschwätzt.Im übrigens ollte man in einem Administrator Forum soviel Rückgrad besitzen es auszuhalten wenn der Ton mal etwas rauher wird. Ist ja nie bös gemeint hier...
ich wollte ja nur sehen, ob es neben der Segmentierung
In dem von dir genannten Beispiel machst du ja gerade keine Segmentierung !Aber OK, vermutlich hast du davor was mit /24 oder noch kleiner gemacht ?!
... naja, Genaues weißt Du aber nix, oder?
WAS genaueres denn ??? Bahnhof...???Die Frage ist doch, ob die "DLink-Gurke", wenn ich das VLAN-tagging rausnehme, wirklich wie ein unmanaged switch arbeitet...
Ja, natürlich.... was soll sie denn sonst machen ? Die Frage ist so wie: Fährt mein Auto noch wenn ich statt Winterreifen Sommerreifen aufzieh ?? No comment...Es ist mein Auftrag.
OK, dann nimm doch ein /16 ! Wer oder was hindert dich daran und wir bruachen keine weiteren Argumente mehr hier.mit der Firmenleitung sprechen
Tolle Wurst...das sind alles Kaufleute mit Sicherheit...sinnlos da dann fundiert zu argumentieren. Jedenfalls mit technischen Argumenten. Die verstehen nur wenns ihnen an den Geldbeutel geht.Ja, aber das geht eben nicht. Ich habe einige Zeit darauf verschwendet.
Doch, tut es wenn man es richtig macht...oder die richtige HW nutzt. D-Link gehört nicht dazu !das war mein erster Gedanke... so trivial ist es aber anscheinend nicht, ich habs probiert.
Hier im Labor auf 3 Routerhops nahcgestellt, Firewall angepasst, funktioniert in 3 Minuten.Die meisten Unwissenden im Internet die einen Winblows Server bei einem öffentlichen Hoster betreiben administrieren diese Büchsen mit RDP. Da muss man dann über 10 und mehr Routerhops.
Wenn es wirklich nicht gehen würde hätten die Hoster 1000e Supportanfragen täglich.
Fazit: Du hast also was grundsätzlich falsch gemacht in deiner RDP Konfig !
Firewall und Winblows Zugriffsrechte sind zu 99,9% die Ursachen.
Wireshark nehmen und nachmessen...das ist wasserdicht !
Freundliche Grüße
Zitat von @aqui:
Im übrigens ollte man in einem Administrator Forum soviel Rückgrad besitzen es auszuhalten wenn der Ton mal etwas rauher wird. Ist ja nie bös gemeint hier...
nee, wollte ich ja nur mal so erwähnen dass Du Dich definitiv besser auskennst in dieser Windows-Sch...
Tu ich ja gar nicht...im Gegenteil ! Ich habe nur mal einen Wireshark Sniffer angeschmissen und nachgesehen was diese Windows-Sch.. so im Netzwerk rumschwätzt.Im übrigens ollte man in einem Administrator Forum soviel Rückgrad besitzen es auszuhalten wenn der Ton mal etwas rauher wird. Ist ja nie bös gemeint hier...
um mich ernsthaft zu ärgern, braucht es mehr...ich wollte ja nur sehen, ob es neben der Segmentierung
In dem von dir genannten Beispiel machst du ja gerade keine Segmentierung !Aber OK, vermutlich hast du davor was mit /24 oder noch kleiner gemacht ?!
ja eben, tagged VLAN und 192.168.0.0/24 und ...1.0/24... naja, Genaues weißt Du aber nix, oder?
WAS genaueres denn ??? Bahnhof...???Die Frage ist doch, ob die "DLink-Gurke", wenn ich das VLAN-tagging rausnehme, wirklich wie ein unmanaged switch arbeitet...
Ja, natürlich.... was soll sie denn sonst machen ? Die Frage ist so wie: Fährt mein Auto noch wenn ich statt Winterreifen Sommerreifen aufzieh ?? No comment...Schreib mal an BMW. Die bauen das garantiert ein. Falls sie es nicht schon eingebaut haben...
Es ist mein Auftrag.
OK, dann nimm doch ein /16 ! Wer oder was hindert dich daran und wir bruachen keine weiteren Argumente mehr hier.mit der Firmenleitung sprechen
Tolle Wurst...das sind alles Kaufleute mit Sicherheit...sinnlos da dann fundiert zu argumentieren. Jedenfalls mit technischen Argumenten. Die verstehen nur wenns ihnen an den Geldbeutel geht.Ja, aber das geht eben nicht. Ich habe einige Zeit darauf verschwendet.
Doch, tut es wenn man es richtig macht...oder die richtige HW nutzt. D-Link gehört nicht dazu !das war mein erster Gedanke... so trivial ist es aber anscheinend nicht, ich habs probiert.
Hier im Labor auf 3 Routerhops nahcgestellt, Firewall angepasst, funktioniert in 3 Minuten.Die meisten Unwissenden im Internet die einen Winblows Server bei einem öffentlichen Hoster betreiben administrieren diese Büchsen mit RDP. Da muss man dann über 10 und mehr Routerhops.
Wenn es wirklich nicht gehen würde hätten die Hoster 1000e Supportanfragen täglich.
Fazit: Du hast also was grundsätzlich falsch gemacht in deiner RDP Konfig !
Firewall und Winblows Zugriffsrechte sind zu 99,9% die Ursachen.
Wireshark nehmen und nachmessen...das ist wasserdicht !
ja. werde ich mal tunWireshark nehmen und nachmessen...das ist wasserdicht !
Freundliche Grüße
Ich stelle das jetzt mal auf gelöst. Danke an alle. Wenn sich (evt. morgen) was ergibt, kann ich ja eine neue Frage starten.
cu jth
Hallo,
kann es sein, dass die Shares, auf die alle so dringend zugreifen müssen und die nicht fest gemappt werden können, auf lokalen Desktop-PCs liegen??
Wenn dem so ist, sollte man der Geschäftsleitung mal ihre im Gesetz verankerte Sorgfaltspflicht bei der Datenhaltung von geschäftsrelevanten Informationen erklären und ihnen die drakonischen Strafen für Verstöße dagegen erläutern.
Bei mir liegen die Daten auf einem File-Server, dessen Freigaben sind entsprechend den Abteilungszugehörigkeiten über ein Anmelde-Script für jeden User gemappt. (wie es in jedem Netzwerk üblich ist).
Damit gibt es auch keine Probleme mit Datensicherung, -Archivierung, Rechteverwaltung und Zugriffsschutz usw. So wie es der Gestzgeber fordert und es üblich ist.
Jürgen
kann es sein, dass die Shares, auf die alle so dringend zugreifen müssen und die nicht fest gemappt werden können, auf lokalen Desktop-PCs liegen??
Wenn dem so ist, sollte man der Geschäftsleitung mal ihre im Gesetz verankerte Sorgfaltspflicht bei der Datenhaltung von geschäftsrelevanten Informationen erklären und ihnen die drakonischen Strafen für Verstöße dagegen erläutern.
Bei mir liegen die Daten auf einem File-Server, dessen Freigaben sind entsprechend den Abteilungszugehörigkeiten über ein Anmelde-Script für jeden User gemappt. (wie es in jedem Netzwerk üblich ist).
Damit gibt es auch keine Probleme mit Datensicherung, -Archivierung, Rechteverwaltung und Zugriffsschutz usw. So wie es der Gestzgeber fordert und es üblich ist.
Jürgen
Hallo und Danke,
"Sein sollte" wäre vielleicht zutreffender. Dass jeder PC erstmal jeden PC sieht, heißt ja noch nicht, dass er auf jede Share zugreifen darf...
cu jth
"Sein sollte" wäre vielleicht zutreffender. Dass jeder PC erstmal jeden PC sieht, heißt ja noch nicht, dass er auf jede Share zugreifen darf...cu jth
Hallo,
ja, was interessiert mich der PC meines Kollegen, wenn er nicht einen für mich notwendigen Dienst bereit stellt??
Das ist eigentlich kontraproduktiv und ein Sicherheitsrisiko, denn was ich "sehe" verleitet mich, es "auszuprobieren" .
Wie heißt es doch so schön in einem Sprichwort: "Was ich nicht weiß, macht mich nicht heiß."
Auf die Resourcen, die der User braucht, kann er auch in einem (ordentlich konfiguriertem) TCP/IP Windows-Netzwerk problemlos zugreifen. Auch bei VLAN-Segmentierung und Routing.
Wenn ich als Admin wissen will/muß, welche Geräte gerade im meinem Netz online sind, gibt es andere Möglichkeiten. Aber davon war bis jetzt nicht die Rede!
Jürgen
PS: Du bist Dir sicher, dass die Mitarbeiter nicht untereinander ihre Paßworte kennen?
Und Du hast, entsprechend den BSI-Vorgaben, ein Paßwort-Management, das Paßworte von mindestens 10 Zeichen (Groß-/Klein-Buchstaben, Zahlen und Sonderzeichen) vordert, die alle 3 Wochen geändert
werden müssen und sich innerhalb von 10 Änderungen nicht wiederholen dürfen?
Bedenke: Ein Paßwort, welches täglich genutzt wird, gilt nach spätestens 3 Wochen als bekannt!
ja, was interessiert mich der PC meines Kollegen, wenn er nicht einen für mich notwendigen Dienst bereit stellt??
Dass jeder PC erstmal jeden PC sieht,
Das ist eigentlich kontraproduktiv und ein Sicherheitsrisiko, denn was ich "sehe" verleitet mich, es "auszuprobieren" .
Wie heißt es doch so schön in einem Sprichwort: "Was ich nicht weiß, macht mich nicht heiß."
Auf die Resourcen, die der User braucht, kann er auch in einem (ordentlich konfiguriertem) TCP/IP Windows-Netzwerk problemlos zugreifen. Auch bei VLAN-Segmentierung und Routing.
Wenn ich als Admin wissen will/muß, welche Geräte gerade im meinem Netz online sind, gibt es andere Möglichkeiten. Aber davon war bis jetzt nicht die Rede!
Jürgen
PS: Du bist Dir sicher, dass die Mitarbeiter nicht untereinander ihre Paßworte kennen?
Und Du hast, entsprechend den BSI-Vorgaben, ein Paßwort-Management, das Paßworte von mindestens 10 Zeichen (Groß-/Klein-Buchstaben, Zahlen und Sonderzeichen) vordert, die alle 3 Wochen geändert
werden müssen und sich innerhalb von 10 Änderungen nicht wiederholen dürfen?
Bedenke: Ein Paßwort, welches täglich genutzt wird, gilt nach spätestens 3 Wochen als bekannt!
Lassen wir das. Ich bin dort zum Glück nicht der Datenschutzbeauftragte. Und werde mich hüten, das zu werden...
Hallo,
zur Info: Das darfst Du gar nicht werden! Interessenkonflikt. Der Admin kann sich doch nicht selbst kontrollieren.
Es ging mir hier aber auch gar nicht primär um den Datenschutz. Vielmehr dachte ich bei nicht zentraler Datenhaltung von steuerrelevanten Informationen (also den gesamten Geschäftsverkehr) an die Schwierigkeiten der gesetzes-konformen Datensicherung und -Archivierung.
Und wenn dann das Finanzamt die Firmenbilanz deswegen nicht akzeptiert und die Unternehmenssteuer schätzt, schätzt es sicher zu Gunsten des Staates. Das hat schon einige Firmen in oder an den Rand der Insolvenz gebracht. Und dann kommt noch die Strafe obendrauf.
http://www.ttimd.de/de/download/category/9-vortraege-vortraege-2016
Jürgen
zur Info: Das darfst Du gar nicht werden! Interessenkonflikt. Der Admin kann sich doch nicht selbst kontrollieren.
Es ging mir hier aber auch gar nicht primär um den Datenschutz. Vielmehr dachte ich bei nicht zentraler Datenhaltung von steuerrelevanten Informationen (also den gesamten Geschäftsverkehr) an die Schwierigkeiten der gesetzes-konformen Datensicherung und -Archivierung.
Und wenn dann das Finanzamt die Firmenbilanz deswegen nicht akzeptiert und die Unternehmenssteuer schätzt, schätzt es sicher zu Gunsten des Staates. Das hat schon einige Firmen in oder an den Rand der Insolvenz gebracht. Und dann kommt noch die Strafe obendrauf.
http://www.ttimd.de/de/download/category/9-vortraege-vortraege-2016
Jürgen
