28
Wieso kann ein Switch nicht zwischen verschiedenen Netzwerken vermitteln, denn er realisiert ja gar nicht das verschiedene Netzwerke vorhanden sind?
Ein Switch arbetiet ja auf der Ebene 2 des OSI-Referenzmodeles. Das heisst er vermittelt zwischen MAC-Adressen und schaut anschliessend auf welchem physikalischen Port dieser liegt und leitet die entpsrechenden Pakete dort weiter. Wieso kann ein Switch jetzt nich ein Paket, welches ich an eine MAC-Adresse aus einem anderen Netzwerk adressiere, übermitteln?
Danke für euren Support.
Grüsse
Danke für euren Support.
Grüsse
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: 218972
Url: https://administrator.de/contentid/218972
Ausgedruckt am: 25.11.2024 um 19:11 Uhr
28 Kommentare
Neuester Kommentar
Weil ein Switch switcht und nicht routet und daher auch nicht zwischen den Netzen "übersetzen" kann. Wobei es natürlich auch Switche gibt, die routen können.
Abgesehen davon gibst du dir deine Antwort bereits selbst: Ein Switch erkennt die unterschiedlichen Netze nicht - wenn du eine Sprache nicht sprichst kannst du in diese nicht übersetzen. Zum Routen gehört aber, dass Wegemerkmale identifiziert und entsprechend ersetzt werden können um dem "Stupiden" (1 Netz) Geräten eine effektive Kommunikation zu erlauben.
Abgesehen davon gibst du dir deine Antwort bereits selbst: Ein Switch erkennt die unterschiedlichen Netze nicht - wenn du eine Sprache nicht sprichst kannst du in diese nicht übersetzen. Zum Routen gehört aber, dass Wegemerkmale identifiziert und entsprechend ersetzt werden können um dem "Stupiden" (1 Netz) Geräten eine effektive Kommunikation zu erlauben.
Danke für deine Antwort. Das habe ich schon verstanden. Aber wie merkt ein Switch ob es ein anderes Netzwerk ist, da er ja nur auf der MAC-Adressen-Ebene funktioniert. Für ihn dürfte ein Netz, getrennt durch IPs, nicht sichtbar sein. Oder doch?
Ich denke ein praktischer Test sollte dir klarere Antworten geben, ist außerdem oft einprägsamer.
Mir ist schon klar, dass es nicht funktioniert. Aber mich interessiert weshalb?
Da ich denke dir fehlen hier grundlegende Wissenselemente (und da die entscheidenden Dinge bereits selbst von dir beantwortet wurden)
http://windows.microsoft.com/de-de/windows-vista/how-do-hubs-switches-r ...
http://windows.microsoft.com/de-de/windows-vista/how-do-hubs-switches-r ...
Danke für den Link. Aber der Unterschied ist mir durchaus bewusst - zumindest in den Grundzügen. Jedoch möchte ich mich nicht mit der Antwort begnüngen: "Es geht nicht, also ist es so."
Ein Switch muss ja in diesem Fall trotzdem den Layer 3 und somit die IP-Adresse berücksichtigen. Er funktioniert lediglich auf der OSI Schicht 2, aber kennt die anderen Schichten durchaus auch. Den ansonsten würde er ja ein Paket mit der entpsrechenden MAC-Adresse auch durchleiten.
Sorry, fürs nachboren. Aber ich möchte die Grundlagen wirklich verstehen. Habe das Ganze schon mit dem Cisco Packet Tracer ausprobiert. Aber dort werde ich auch nicht schlauer, weshalb das Packet nicht ankommt.
Es ist wirklich ein theoretische Frage, die mein ganzheitliches Verständis erweitern soll.
Ein Switch muss ja in diesem Fall trotzdem den Layer 3 und somit die IP-Adresse berücksichtigen. Er funktioniert lediglich auf der OSI Schicht 2, aber kennt die anderen Schichten durchaus auch. Den ansonsten würde er ja ein Paket mit der entpsrechenden MAC-Adresse auch durchleiten.
Sorry, fürs nachboren. Aber ich möchte die Grundlagen wirklich verstehen. Habe das Ganze schon mit dem Cisco Packet Tracer ausprobiert. Aber dort werde ich auch nicht schlauer, weshalb das Packet nicht ankommt.
Es ist wirklich ein theoretische Frage, die mein ganzheitliches Verständis erweitern soll.
Ich glaube die Lösung gefunden zu haben. Ein Switch, der auf dem Layer 2 arbeitet hat durchaus in der ARP Tabelle die IP zu der zugehörigen MAC-Adresse erfasst. Wenn der Switch nun merkt, dass die IP nicht zum selben Netzwerk gehört, dropt er das Packet. Richtig?
Moin,
Ein L2 Switch arbeitet auf Layer 2 (MAC) und nicht auf L3 ("IP"). Den interessieren die IP Adressen gar nicht! D.h. den Switch interessiert nur das PHYSISCHE Netzwerk, das er per MAC Adresse erreichen kann, nicht das LOGISCHE das per IP Adresse und ggfs. Routing erreichbar ist.
lg,
Slainte
Richtig
Nein!Ein L2 Switch arbeitet auf Layer 2 (MAC) und nicht auf L3 ("IP"). Den interessieren die IP Adressen gar nicht! D.h. den Switch interessiert nur das PHYSISCHE Netzwerk, das er per MAC Adresse erreichen kann, nicht das LOGISCHE das per IP Adresse und ggfs. Routing erreichbar ist.
lg,
Slainte
Nein,
Ein Switch kann nur zwischen MACs vermitteln, die er kennt.
Diese MACs lernt er mit der Zeit kennen.
MACs aus einem anderen Netz haben die MAC des Routers. Der Switch schickt die Pakete dann immer zum Router.
Eingehende Pakete haben ja die MAC des Routers. Unbekannte ausgehende Pakete bekommen vom Client die MAC des Routers.
Weiter nichts.
Gruß
Netman
P.S.: Ja dann gibt es noch VLANs und trunks und Statistiken und Festlegungen für die Portgeschwindigkeit ...
Ein Switch kann nur zwischen MACs vermitteln, die er kennt.
Diese MACs lernt er mit der Zeit kennen.
MACs aus einem anderen Netz haben die MAC des Routers. Der Switch schickt die Pakete dann immer zum Router.
Eingehende Pakete haben ja die MAC des Routers. Unbekannte ausgehende Pakete bekommen vom Client die MAC des Routers.
Weiter nichts.
Gruß
Netman
P.S.: Ja dann gibt es noch VLANs und trunks und Statistiken und Festlegungen für die Portgeschwindigkeit ...
Grundlagen zu dem Thema erklärt auch dieses Forumstutorial:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Tach wohl
Und ich meine wohl, dass ein Layer 2 Switch die ARP Tabelle berücksichtigt - aber nicht mittels dieser kommuniziert. Siehe Punkt Funktionsweise - Source Adresse Table: http://de.wikipedia.org/wiki/Switch_(Netzwerktechnik)
Wenn ich das ganze über den Cisco Packet Tracer nachbaue. Also 2 Clients und ein Switch (Cisco 2950-24). Und den Clients wird ein unterschiedliches Netz zugewiesen, erhalte ich bei einem Ping die Meldung "8 Source host isolated". D.h. der Switch versteht, dass die Clients nicht im Netz sind.
Und ich meine wohl, dass ein Layer 2 Switch die ARP Tabelle berücksichtigt - aber nicht mittels dieser kommuniziert. Siehe Punkt Funktionsweise - Source Adresse Table: http://de.wikipedia.org/wiki/Switch_(Netzwerktechnik)
Wenn ich das ganze über den Cisco Packet Tracer nachbaue. Also 2 Clients und ein Switch (Cisco 2950-24). Und den Clients wird ein unterschiedliches Netz zugewiesen, erhalte ich bei einem Ping die Meldung "8 Source host isolated". D.h. der Switch versteht, dass die Clients nicht im Netz sind.
Dein Tracer zweigt es richtig an und es gibt auch keine Widerspruch.
Wenn ein Client in einem andern Netz ist, dann muss der Switch ihn nicht kennen (könnte aber bei falschem Anschluß) und der eine Client sucht ja nicht nach der MAC des anderen Clients sondern nach der MAC des Routers.
Also so eine Schrottkonfiguration kannst du möglicherweise betreiben, aber dann sind es mehr oder weniger zwei Netze. Und die Applikationen scheren sich wieder nicht um MACs, sondern um IPs oder Namen.
Und auch für solche komplexe Simulationssoftware gilt: Erst RTFM installieren und sich um die Grundlagen kümmern. Was nutzt die beste Analysesoftware, wenn sie mit unsinnigen Daten gefüttert wird.
Wenn ein Client in einem andern Netz ist, dann muss der Switch ihn nicht kennen (könnte aber bei falschem Anschluß) und der eine Client sucht ja nicht nach der MAC des anderen Clients sondern nach der MAC des Routers.
Also so eine Schrottkonfiguration kannst du möglicherweise betreiben, aber dann sind es mehr oder weniger zwei Netze. Und die Applikationen scheren sich wieder nicht um MACs, sondern um IPs oder Namen.
Und auch für solche komplexe Simulationssoftware gilt: Erst RTFM installieren und sich um die Grundlagen kümmern. Was nutzt die beste Analysesoftware, wenn sie mit unsinnigen Daten gefüttert wird.
1
Und ich meine wohl, dass ein Layer 2 Switch die ARP Tabelle berücksichtigt
Nein, das ist schlicht falsch, denn ARP muss der Switch nur berücksichtigen wenn er ein Layer 3 Switch ist, ansonsten ist ARP für einen L2 Switch vollkommen nurtzlos, denn IP Adressen (und nur die werden mit ARP ermittelt) sind für ihn nicht relevant...wozu auch wenn er nur L2 (Mac Adressen) macht ?!
Eine einzige Ausnahme gibt es: Und das ist der Zugriff auf die IP Mangement Adresse dieses Switches. Einzig dafür antwortet dieser Switch auf ARP Anfragen und führt deswegen natürlich auch einen ARP Cache. Dort sind aber nur Endgeräte drin die einzig auf seine Management Funktion zugreifen. Niemals aber Produktivtraffic !
Nein, das ist schlicht falsch, denn ARP muss der Switch nur berücksichtigen wenn er ein Layer 3 Switch ist, ansonsten ist ARP für einen L2 Switch vollkommen nurtzlos, denn IP Adressen (und nur die werden mit ARP ermittelt) sind für ihn nicht relevant...wozu auch wenn er nur L2 (Mac Adressen) macht ?!
Eine einzige Ausnahme gibt es: Und das ist der Zugriff auf die IP Mangement Adresse dieses Switches. Einzig dafür antwortet dieser Switch auf ARP Anfragen und führt deswegen natürlich auch einen ARP Cache. Dort sind aber nur Endgeräte drin die einzig auf seine Management Funktion zugreifen. Niemals aber Produktivtraffic !
Danke für eure Antworten. Aber weshalb können dann zwei Clients, die sich in einem unterschiedlichen Netz befinden, nicht miteinander kommunizieren?
Da die wohl noch die Grundlagen fehlen: Stell dir vor, du sprichst english und der andere Chinesisch. Du bewegst zwar auf ähnliche Weise die Lippen, aber es gibt keine Möglichkeit für die andere Seite dies logisch auszuwerten.
Hallo,
das hat @aqui doch gerade einen Kommentar weiter oben, also über dieser Frage beantwortet, Du
fragst quasi nur noch einmal "rückwärts" gewannt!
bzw. die Firewall übernehmen, denn mittels routing vermittelt man oder verbindet man zwei unterschiedliche
Netzwerke miteinander. Und ergo wenn sie sich in ein und dem selben Netzwerk befinden muss man kein
Layer3 Routing benutzen sondern es reicht ein Switching auf Layer2!
Gruß
Dobby
P.S.
Nochmal kurz und bündig:
Beide Klienten (PCs) sind in ein und dem selben Netzwerk = Layer2 also ohne Routing.
Beide Klienten (PCs) sind in verschiedenen Netzwerken = Layer3 also mit Routing.
das hat @aqui doch gerade einen Kommentar weiter oben, also über dieser Frage beantwortet, Du
fragst quasi nur noch einmal "rückwärts" gewannt!
Danke für eure Antworten.
Aber lesen musst Du die auch oder zumindest verstehen was die Leute Dir schreiben.Aber weshalb können dann zwei Clients, die sich in einem unterschiedlichen Netz befinden, nicht miteinander kommunizieren?
Weil der Switch nicht selber routet! das muss dann entweder ein Layer3 Switch sein oder eben der Routerbzw. die Firewall übernehmen, denn mittels routing vermittelt man oder verbindet man zwei unterschiedliche
Netzwerke miteinander. Und ergo wenn sie sich in ein und dem selben Netzwerk befinden muss man kein
Layer3 Routing benutzen sondern es reicht ein Switching auf Layer2!
Gruß
Dobby
P.S.
Nochmal kurz und bündig:
Beide Klienten (PCs) sind in ein und dem selben Netzwerk = Layer2 also ohne Routing.
Beide Klienten (PCs) sind in verschiedenen Netzwerken = Layer3 also mit Routing.
Weil der Switch nicht selber routet! das muss dann entweder ein Layer3 Switch sein oder eben der Router
bzw. die Firewall übernehmen, denn mittels routing vermittelt man oder verbindet man zwei unterschiedliche
Netzwerke miteinander. Und ergo wenn sie sich in ein und dem selben Netzwerk befinden muss man kein
Layer3 Routing benutzen sondern es reicht ein Switching auf Layer2!
bzw. die Firewall übernehmen, denn mittels routing vermittelt man oder verbindet man zwei unterschiedliche
Netzwerke miteinander. Und ergo wenn sie sich in ein und dem selben Netzwerk befinden muss man kein
Layer3 Routing benutzen sondern es reicht ein Switching auf Layer2!
Aber das sich die Clients in einem anderen Netz befindet interessiert den Layer 2 Switch nicht, da dies durch den Layer 3 definiert wird. D.h. ja ein Paket arbeit sich nur bis zum Layer 2 hoch und dort sieht er die adressierbare MAC-Adressen der anderen Clients und deshalb müsste ja theoretisch auf dieser Ebene eine Kommunikation möglich sein. Ein Ethernetframe (https://upload.wikimedia.org/wikipedia/de/thumb/a/aa/Ethernetpaket.svg/8 ..) müsste ein Switch durchreichen, unabhängig von dem Netz, welches im Client konfiguriert ist. Denn Ziel und Hostadresse sind in diesem Frame bekannt und in der SAT gespeichert.
Ach ja und ein Kommentar kann ich mir nicht verkneiffen - danke für eure tollen Kommentare, dass ich die Grundlagen nicht verstanden habe, aber genau deshalb bin ich hier und stelle euch, als solche die die Grundlage verstanden habe, diese Frage. Danke deshalb für eure Geduld und das Verständis.
Genau und deswegen würde ich dir eine Schulung nahe legen, hier wurde auf die eine (konkret technische) oder andere Verbildlichte Art das Warum zu erläutern versucht. Besser aufbereitet wirst du das aber vor allem in einer entsprechenden Basics Schulung vermittelt bekommen. Konkret bist du durch unsere Hilfestellung offensichtlich noch nicht weiter gekommen.
Okay, das Akzeptiere ich und werde ich machen. Nur noch eine letzte Frage: Kann ein Switch ein Ethernet-Frame an einen Client weiterleiten, der nicht im selben Netz ist? Nur das Ethernetframe, in welchem ja nur die MAC-Ziel und Empfängeradresse erfasst ist. Und wie kann ich die SAT aus einem Switch auselsen?
Das klingt nach einem Deal. Auch diese Frage sollte dir der Schulende gut erklären können.
http://de.wikipedia.org/wiki/OSI-Modell#Die_sieben_Schichten
Ab zur Schulung
http://de.wikipedia.org/wiki/OSI-Modell#Die_sieben_Schichten
Ab zur Schulung
Kann ein Switch ein Ethernet-Frame an einen Client weiterleiten, der nicht im selben Netz ist?
Einfache Switches arbeiten auf der Schicht 2 (Sicherungsschicht) des OSI-Modells. Der Switch verarbeitet bei Erhalt eines Frames die 48 Bit lange MAC-Adresse (z. B. 08:00:20:ae:fd:7e) und legt dazu einen Eintrag in der Source-Address-Table (SAT) an, in der neben der MAC-Adresse auch der physische Port, an dem diese empfangen wurde, gespeichert wird. Im Unterschied zum Hub werden Frames nur noch an den Port weitergeleitet, der für die entsprechende Zieladresse in der SAT gelistet ist. Ist der Weg zur Zieladresse allerdings noch unbekannt (Lernphase), leitet der Switch das betreffende Frame an alle aktiven Ports.- Quelle
- Wikipedia: Switch
Und wie kann ich die SAT aus einem Switch auselsen?
Am Switch direkt wohl nur durch auslesen der Adresstabelle und aus den Paketen heraus wohl mit einem Monitorport oder auchSpiegelport ("mirrored Port") und im Zusammenhang mit WireShark.
Gruß
Dobby
Der Switch verarbeitet bei Erhalt eines Frames
die 48 Bit lange MAC-Adresse (z. B. 08:00:20:ae:fd:7e) und legt dazu einen Eintrag in der Source-Address-Table (SAT) an, in der
neben der MAC-Adresse auch der physische Port, an dem diese empfangen wurde, gespeichert wird. Im Unterschied zum Hub werden
Frames nur noch an den Port weitergeleitet, der für die entsprechende Zieladresse in der SAT gelistet ist. Ist der Weg zur
Zieladresse allerdings noch unbekannt (Lernphase), leitet der Switch das betreffende Frame an alle aktiven Ports.
die 48 Bit lange MAC-Adresse (z. B. 08:00:20:ae:fd:7e) und legt dazu einen Eintrag in der Source-Address-Table (SAT) an, in der
neben der MAC-Adresse auch der physische Port, an dem diese empfangen wurde, gespeichert wird. Im Unterschied zum Hub werden
Frames nur noch an den Port weitergeleitet, der für die entsprechende Zieladresse in der SAT gelistet ist. Ist der Weg zur
Zieladresse allerdings noch unbekannt (Lernphase), leitet der Switch das betreffende Frame an alle aktiven Ports.
Das heisst aber auch, dass Clients mit Raw Ethernet Frames über die Netzgrenzen hinaus kommunizieren können. Also nur auf der Ebene 2, aber das wäre ja somit eine Sicherheitslücke, da ein potentieller Angreifer so das Gegenüber in einem anderen Netz mit Raw Ethernet Packeten angfreifen kann. Wenn er dann gesicket ist, manipuliert er den Netzverkehr so, dass er das Ethernetframe so konfiguriert, dass es durchgereicht wird und dass im Ethernet gekapselte IP-Frame so manipuliert, dass es den Anschein macht, als wäre die Zieladresse (dieses mal die IP) aus dem gleichen Netzwerk und der Client (der Angegriffene) verarbeitet dieses.
Du kannst das auch ganz ohne Switch ausprobieren um das zu verifizieren wenn du 2 Rechner mal ganz einfach "back to back" also Rücken zu Rücken direkt über die NIC verbindest.
Wenn der eine Rechner die IP Adresse 1.1.1.1 /24 hat und der andere die 2.2.2.2 /24 können die ebenfalls nicht miteinander kommunizieren sofern sie mit IP kommunizieren müssen !!
Da sie aus IP Sicht sich mit ihren Host IP Adressen nicht in einem gemeinsamen IP Netzwerk befinden ist einen Kommunikation beider Rechner ohne Router unmöglich !
Erst ein Router (oder Layer 3 Switch) kann eine Kommunikation zwischen unterschiedlichen IP Netzen realisieren.
Benutzt du aber ein Kommunikations Protokoll was rein auf Layer 2 basiert wie z.B. das gute alte NetBui oder NetBios dann sind die IP Adressen egal, denn eine Kommunikation basiert ja dann rein auf Layer 2 also den Mac Adressen.
Hier können beide Rechner dann problemlso kommunizieren eben weil es kein IP basiertes Protokoll ist.
Nur mal für dich als Beispiel grob den Grundschritt bei einer IP Kommunikation wenn 2 Geräte miteinander reden wollen.
Das allererste ist ein ARP Paket (Adress resolution Protocoll) was ein Rechner der die Kommunikation initiiert zwingend senden muss um die Mac Adresse des Partners rauszubekommen.
Dazu sendet er ein Paket an die Broadcast IP Adresse z.B. mit dem obigen Beispiel 1.1.1.255 (alle Hostbits auf logisch "1" !)
Da der zweite Rechner nur auf seine Broadcast Adresse 2.2.2.255 "hört" würde er hier nie antworten
1.1.1.1 bekommt also niemals eine Antwort auf seinen ARP Request und dann scheitert schon die IP Verbindung von Anfang an.
Fazit: Lies dir also bitte mal die einfachsten Grundlagen einer IP Kommunikation an, dann wird dir das ganz schnell sonnenklar !!
Noch ein Fazit: Ja, ein L2 Switch leitet nur ganz primitiv MAC Adressen weiter mehr nicht ! IP kann er auch gar nicht, da er diesen Teil im Ethernet Paket gar nicht liest.
Ein L2 Switch geht dabei ganz primitiv vor:
Wenn der eine Rechner die IP Adresse 1.1.1.1 /24 hat und der andere die 2.2.2.2 /24 können die ebenfalls nicht miteinander kommunizieren sofern sie mit IP kommunizieren müssen !!
Da sie aus IP Sicht sich mit ihren Host IP Adressen nicht in einem gemeinsamen IP Netzwerk befinden ist einen Kommunikation beider Rechner ohne Router unmöglich !
Erst ein Router (oder Layer 3 Switch) kann eine Kommunikation zwischen unterschiedlichen IP Netzen realisieren.
Benutzt du aber ein Kommunikations Protokoll was rein auf Layer 2 basiert wie z.B. das gute alte NetBui oder NetBios dann sind die IP Adressen egal, denn eine Kommunikation basiert ja dann rein auf Layer 2 also den Mac Adressen.
Hier können beide Rechner dann problemlso kommunizieren eben weil es kein IP basiertes Protokoll ist.
Nur mal für dich als Beispiel grob den Grundschritt bei einer IP Kommunikation wenn 2 Geräte miteinander reden wollen.
Das allererste ist ein ARP Paket (Adress resolution Protocoll) was ein Rechner der die Kommunikation initiiert zwingend senden muss um die Mac Adresse des Partners rauszubekommen.
Dazu sendet er ein Paket an die Broadcast IP Adresse z.B. mit dem obigen Beispiel 1.1.1.255 (alle Hostbits auf logisch "1" !)
Da der zweite Rechner nur auf seine Broadcast Adresse 2.2.2.255 "hört" würde er hier nie antworten
1.1.1.1 bekommt also niemals eine Antwort auf seinen ARP Request und dann scheitert schon die IP Verbindung von Anfang an.
Fazit: Lies dir also bitte mal die einfachsten Grundlagen einer IP Kommunikation an, dann wird dir das ganz schnell sonnenklar !!
Noch ein Fazit: Ja, ein L2 Switch leitet nur ganz primitiv MAC Adressen weiter mehr nicht ! IP kann er auch gar nicht, da er diesen Teil im Ethernet Paket gar nicht liest.
Ein L2 Switch geht dabei ganz primitiv vor:
- Kommt ein Ethernet Paket rein liest er die Destination Mac Adresse des Paketes
- Dann sieht er in seine interne Mac Adress Tabelle welche Mac Adressen er kennt.
- Kennt er diese Mac Adrese sendet er das Paket an dem Port raus wo er die Mac Adresse "gesehen" hat bzw. in der Mac Tabelle hat
- Kennt er diese Mac Adresse nicht bzw. ist sie nicht in seiner Tabelle flutet er sie an alle Ports wie ein dummer Hub. Spätestens wenn die Destination mac antwortet "sieht" er sie ja und speichert sie dann in seiner Tabelle inkl. des Ports wo er sie "gesehen" hat !
2Benutzt du aber ein Kommunikations Protokoll was rein auf Layer 2 basiert wie z.B. das gute alte NetBui oder NetBios dann sind die
IP Adressen egal, denn eine Kommunikation basiert ja dann rein auf Layer 2 also den Mac Adressen.
Hier können beide Rechner dann problemlso kommunizieren eben weil es kein IP basiertes Protokoll ist.
IP Adressen egal, denn eine Kommunikation basiert ja dann rein auf Layer 2 also den Mac Adressen.
Hier können beide Rechner dann problemlso kommunizieren eben weil es kein IP basiertes Protokoll ist.
Das ist die Antwort, die ich schon so lange gesucht habe. Danke @aqui, dass du mich erlöst.
Denn seit deinem Kommentar vom...
aqui am 13.10.2013 um 16:42 Uhr
... .Und ich meine wohl, dass ein Layer 2 Switch die ARP Tabelle berücksichtigt
Nein, das ist schlicht falsch, denn ARP muss der Switch nur berücksichtigen wenn er ein Layer 3 Switch ist, ansonsten ist ARP für einen L2 Switch vollkommen nurtzlos, > denn IP Adressen (und nur die werden mit ARP ermittelt) sind für ihn nicht relevant...wozu auch wenn er nur L2 (Mac Adressen) macht ?!
Eine einzige Ausnahme gibt es: Und das ist der Zugriff auf die IP Mangement Adresse dieses Switches. Einzig dafür antwortet dieser Switch auf ARP Anfragen und führt > deswegen natürlich auch einen ARP Cache. Dort sind aber nur Endgeräte drin die einzig auf seine Management Funktion zugreifen. Niemals aber Produktivtraffic !
... .Und ich meine wohl, dass ein Layer 2 Switch die ARP Tabelle berücksichtigt
Nein, das ist schlicht falsch, denn ARP muss der Switch nur berücksichtigen wenn er ein Layer 3 Switch ist, ansonsten ist ARP für einen L2 Switch vollkommen nurtzlos, > denn IP Adressen (und nur die werden mit ARP ermittelt) sind für ihn nicht relevant...wozu auch wenn er nur L2 (Mac Adressen) macht ?!
Eine einzige Ausnahme gibt es: Und das ist der Zugriff auf die IP Mangement Adresse dieses Switches. Einzig dafür antwortet dieser Switch auf ARP Anfragen und führt > deswegen natürlich auch einen ARP Cache. Dort sind aber nur Endgeräte drin die einzig auf seine Management Funktion zugreifen. Niemals aber Produktivtraffic !
... habe ich nur noch von der Kommunikation von MAC-Adressen und Ethernet-Paketen gesprochen und nicht von einfache Kommunikation auf der Layer 3 Ebene. Soviel war mir zu diesem Zeitpunkt auch schon klar. Mir ist bewusst, dass für euch als Praktiker das Szenario einer Kommunikation auf der Ethernetebene kaum relevanz hat, da sich alles im grundlegenden Netzwerkmanagement eine Ebene weiter oben abspielt. Für mich war oder ist die Antwort von dir @aqui so spannend, da ich im weiteren herausfinden möchte, ob ich durch die Kommunikation auf der Layer 2 Ebene mit Clients über das logische Netz (dies wieder auf der IP Ebene) hinaus kommunizieren kann. Eben indem ich ein Ethernetframe adressiere, in dem ein IP-Frame gekappselt ist, welches für das im anderen Segement liegenden IP-Netz ein gültiges ARP-Paket enthälft, da die Herkunftadresse so manipuliert ist, dass er das ARP-Paket im Gegenüberliegenden logischen Netz verarbeitet, dass er durch das gültige Ethernet-Paket (da beide MAC-Adressen, Ziel und Host bekannt sind) weitergeleitet bekommen hat. Kurz zusammengefasst heisst das:
1. Übermittlung eines gültigen Ethernetframes (das funktioniert ja, da nur die MAC-Adressen benötigt werden und die Kommunikation auf dem Layer 2 läuft)
2. In diesem Ethernetframe befindet sich ein IP-Paket, dass simuliert, dass es von einem Client mit einer gütligen IP-Adresse kommt also aus dem selben Netz.
Mir geht es dabei auch darum herauszufinden, ob logisch voneinander getrennte IP-Netze sicher sind, oder ob diese über die Grenzen von Switches hinaus kompromitierbar sind und daher heute ungetagte Vlans mehr Sinn machen.
Danke nochmals für eure Gedult. Ich hoffe der eine oder die andere versteht nun eher was ich mit meiner hartnäckigen Fragerrei erreichen wollte oder wil.
Heisser Tip für dich:
Schnapp dir einen Rechner mit einem Wireshark_Paket_Sniffer oder installier ihn auf einem deiner Test- und Lernrechner und sniffer einfach mal den Kommunikationsaufbau einer simplen IP Telnet Session mit.
Das eröffnet dir den Horizont für noch viele weitere AHA Effekte in der Welt der OSI Protokollschichten !
Schnapp dir einen Rechner mit einem Wireshark_Paket_Sniffer oder installier ihn auf einem deiner Test- und Lernrechner und sniffer einfach mal den Kommunikationsaufbau einer simplen IP Telnet Session mit.
Das eröffnet dir den Horizont für noch viele weitere AHA Effekte in der Welt der OSI Protokollschichten !
Falls Du das ganze von @aqui beherzigst und Dir einen Testrechner aufsetzt, würde ich Dir noch zu einem
Buch raten was sich wirklich mit Grundlagen und dem ganzen Paketaufbau beschäftigt dort fängst Du quasi
bei 0 an und lernst "Step by Step" von der "Pike" auf wie man die Informationen in WireShark richtig ließt und
auch deutet. Das Buch kostet keine 10 € und ist in deutsch geschrieben und zusammen mit WINDUMP ist
es einfach unschlagbar die ersten Schritte damit zu unternehmen und anzufangen Pakete auszuwerten.
Buch: IDS: Intrusion Detection-Systeme (Spurensuche im Internet)
Programm: WinDump + WinPcap
Es ist kein Wunder- oder Allheilmittel aber für unter 10 € hilft es einem enorm die Angaben die einem
von WireShark geliefert werden auszuwerten und/oder zu verstehen und zwar in voller Länge und Umpfang.
Gruß
Dobby
Buch raten was sich wirklich mit Grundlagen und dem ganzen Paketaufbau beschäftigt dort fängst Du quasi
bei 0 an und lernst "Step by Step" von der "Pike" auf wie man die Informationen in WireShark richtig ließt und
auch deutet. Das Buch kostet keine 10 € und ist in deutsch geschrieben und zusammen mit WINDUMP ist
es einfach unschlagbar die ersten Schritte damit zu unternehmen und anzufangen Pakete auszuwerten.
Buch: IDS: Intrusion Detection-Systeme (Spurensuche im Internet)
Programm: WinDump + WinPcap
Es ist kein Wunder- oder Allheilmittel aber für unter 10 € hilft es einem enorm die Angaben die einem
von WireShark geliefert werden auszuwerten und/oder zu verstehen und zwar in voller Länge und Umpfang.
Gruß
Dobby
Danke für die Hinweise. Das Buch habe ich mir gleich mal bestellt.
Danke für die Hinweise.
Kein Thema.Das Buch habe ich mir gleich mal bestellt.
Ich habe das Buch auch seit 3 tagen hier zu hause und bin damit wirklich zufrieden, wenn man die Geschichtedie in dem Buch erzählt wird einfach mal bei Seite lässt dann ist das irgend wie wie ein Grundkurs für
IP Pakete verstehen und man kann auf jeden Fall um einiges mehr mit den Sachen anfangen die einem
von WireShark präsentiert werden!
Gruß
Dobby
