Einführung
In diesem Labor werden Sie die grundlegende Interaktion zwischen der Netzwerkschicht (Schicht 3) und der Sicherungsschicht (Schicht 2) in einer Linux-Umgebung untersuchen. Sie werden die gängigen Kommandozeilen-Utilities ping und arp verwenden, um das Address Resolution Protocol (ARP) in Aktion zu beobachten. Das Hauptziel ist es zu verstehen, wie Ihr System IP-Adressen in physische MAC-Adressen für Geräte im lokalen Netzwerk auflöst und wie es die Kommunikation mit entfernten Hosts handhabt.
Sie beginnen mit der Inspektion des Zustands des ARP-Caches. Anschließend verwenden Sie ping, um mit einem lokalen Gerät (Ihrem Standard-Gateway) und einem entfernten Gerät (google.com) zu kommunizieren. Durch die Beobachtung des ARP-Caches vor und nach diesen Aktionen sehen Sie, wie Ihr System MAC-Adressen für die lokale Kommunikation verwendet und sich für den Fernverkehr auf das Standard-Gateway verlässt.
Anfänglichen ARP-Cache mit arp -a anzeigen
In diesem Schritt werden Sie den initialen Zustand des Address Resolution Protocol (ARP)-Caches Ihres Systems überprüfen. Der ARP-Cache ist eine entscheidende Netzwerkkomponente, die die Zuordnungen zwischen Layer-3- (IP-)Adressen und ihren entsprechenden Layer-2- (MAC-)Adressen für Geräte im selben lokalen Netzwerk speichert.
Überprüfen wir zunächst den aktuellen Zustand des ARP-Caches mit dem Befehl arp. Das Flag -a weist den Befehl an, alle aktuellen Einträge anzuzeigen.
Führen Sie in Ihrem Terminal, das sich bereits im Pfad ~/project befindet, den folgenden Befehl aus:
arp -a
Sie werden wahrscheinlich einen oder mehrere Einträge sehen. Es ist üblich, dass das Standard-Gateway bereits im Cache vorhanden ist. Ihre Ausgabe könnte in etwa so aussehen:
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Es ist wichtig zu beachten, dass es aufgrund der virtualisierten Natur der LabEx-Umgebung nicht immer möglich ist, den ARP-Cache vollständig zu leeren. Daher werden Sie wahrscheinlich von Anfang an einen vorab gefüllten Cache sehen. In einer typischen nicht-virtualisierten Einrichtung würden Sie eher einen leeren oder einen
<incomplete>-Eintrag für das Gateway sehen, bevor die erste Kommunikation stattfindet.
Diese Ausgabe zeigt den initialen Zustand unseres ARP-Caches. Sie dient als Basis für unsere nächsten Schritte, bei denen wir Netzwerkaktivitäten auslösen und beobachten werden, wie diese Tabelle verwendet wird.
Lokales Gerät mit ping anpingen, um eine ARP-Anfrage auszulösen
In diesem Schritt verwenden Sie den Befehl ping, um die Kommunikation mit einem anderen Gerät in Ihrem lokalen Netzwerk zu initiieren. Diese Aktion wird die Address Resolution Protocol (ARP)-Zuordnung verwenden, falls eine erforderlich ist. Wenn Ihr System versucht, ein Paket an eine lokale IP-Adresse zu senden, prüft es zuerst seinen ARP-Cache. Wenn es keine entsprechende MAC-Adresse findet, sendet es eine Broadcast-ARP-Anfrage. Wenn der Eintrag bereits vorhanden ist, wird die zwischengespeicherte MAC-Adresse verwendet.
Um dies durchzuführen, müssen wir zuerst die IP-Adresse eines Geräts im lokalen Netzwerk ermitteln. Das zuverlässigste Ziel in dieser Umgebung ist Ihr Standard-Gateway (der virtuelle Router). Sie können dessen IP-Adresse ermitteln, indem Sie die Routing-Tabelle inspizieren.
Führen Sie in Ihrem Terminal den folgenden Befehl aus, um die Routing-Tabelle anzuzeigen:
ip route show
Die Ausgabe zeigt Ihnen die Standardroute. Suchen Sie nach der Zeile, die mit default via beginnt. Die dort aufgeführte IP-Adresse ist Ihr Gateway.
default via 172.16.50.253 dev eth0 ...
...
Aus der obigen Beispielausgabe ist die IP-Adresse des Gateways 172.16.50.253. Verwenden Sie nun diese IP-Adresse, um einige ping-Pakete zu senden. Die Option -c 4 weist ping an, genau 4 Pakete zu senden und dann zu stoppen. Ersetzen Sie 172.16.50.253 durch die tatsächliche Gateway-IP, die Sie gefunden haben.
ping -c 4 172.16.50.253
Sie sollten für jedes Paket eine erfolgreiche Antwort sehen, die bestätigt, dass Ihr System mit dem Gateway kommunizieren konnte.
PING 172.16.50.253 (172.16.50.253) 56(84) bytes of data.
64 bytes from 172.16.50.253: icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from 172.16.50.253: icmp_seq=2 ttl=64 time=0.060 ms
64 bytes from 172.16.50.253: icmp_seq=3 ttl=64 time=0.055 ms
64 bytes from 172.16.50.253: icmp_seq=4 ttl=64 time=0.045 ms
--- 172.16.50.253 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3060ms
rtt min/avg/max/mdev = 0.045/0.056/0.066/0.007 ms
Diese einfache Aktion hat Ihr System gezwungen, eine ARP-Auflösung durchzuführen. Im nächsten Schritt werden wir den ARP-Cache erneut inspizieren, um das Ergebnis zu sehen.
Lokale IP-zu-MAC-Auflösung im ARP-Cache überprüfen
In diesem Schritt werden Sie den ARP-Cache erneut untersuchen, um das direkte Ergebnis des zuvor ausgeführten ping-Befehls zu sehen. Da Ihr System erfolgreich mit dem lokalen Gateway kommuniziert hat, muss es eine gültige IP-zu-MAC-Adresszuordnung gehabt haben. Sehen wir uns an, ob sich die Tabelle geändert hat.
Lassen Sie uns den ARP-Cache erneut inspizieren. Führen Sie in Ihrem Terminal denselben Befehl wie in Schritt 1 aus:
arp -a
Dieses Mal wird die Ausgabe nur dann anders sein, wenn der Eintrag noch nicht vollständig war. In unserem Fall, da der Eintrag in Schritt 1 bereits aufgelöst wurde, wird die Ausgabe identisch sein.
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Vergleichen Sie diese Ausgabe mit der aus Schritt 1. Sie ist identisch. Das liegt daran, dass der ARP-Eintrag für das Gateway bereits vollständig war, bevor wir den ping gesendet haben. Ihr System musste keine neue ARP-Anfrage durchführen; es hat sich einfach auf die bereits im Cache vorhandenen Informationen verlassen.
Dies demonstriert ein Schlüsselprinzip: Der ARP-Cache verhindert redundante ARP-Anfragen. Wenn der Eintrag <incomplete> (unvollständig) gewesen wäre oder gefehlt hätte, hätte dieser ping-Befehl ihn gefüllt, und Sie hätten eine Änderung in der Ausgabe gesehen.
Externen Host anpingen, um das Standard-Gateway einzubeziehen
In diesem Schritt wechseln Sie von der Kommunikation mit einem lokalen Gerät zur Kommunikation mit einem Host im Internet. Dies demonstriert ein grundlegendes Netzwerkkonzept: wie Ihr Computer sein Standard-Gateway verwendet, um Ziele außerhalb seines eigenen lokalen Netzwerks zu erreichen.
Wenn die Ziel-IP-Adresse nicht im selben Subnetz wie Ihr Computer liegt, weiß Ihr System, dass es das Paket nicht direkt senden kann. Stattdessen muss es das Paket an sein zugewiesenes Standard-Gateway senden. Das Gateway (ein Router) ist dafür verantwortlich, das Paket an sein endgültiges Ziel über das Internet weiterzuleiten.
Um dies in Aktion zu sehen, werden Sie einen bekannten externen Host, google.com, anpingen.
Führen Sie in Ihrem Terminal den folgenden Befehl aus:
ping -c 4 google.com
Sie werden sehen, wie die Domain google.com zu einer IP-Adresse aufgelöst wird, und dann erhalten Sie Antworten von dieser Adresse.
PING google.com (142.250.189.174) 56(84) bytes of data.
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=1 ttl=118 time=4.38 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=2 ttl=118 time=4.40 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=3 ttl=118 time=4.35 ms
64 bytes from sfo03s24-in-f14.1e100.net (142.250.189.174): icmp_seq=4 ttl=118 time=4.39 ms
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 4.353/4.380/4.401/0.017 ms
Obwohl Sie erfolgreich mit google.com kommuniziert haben, hat Ihr Computer keine ARP-Anfrage für die IP-Adresse von Google durchgeführt. Es benötigte nur die MAC-Adresse seines lokalen Gateways, die es bereits in den vorherigen Schritten gefunden hatte. Im nächsten Schritt werden Sie den ARP-Cache analysieren, um dieses Verhalten zu bestätigen.
ARP-Cache für die Fernkommunikation analysieren
In diesem letzten Schritt analysieren Sie den ARP-Cache ein letztes Mal, um zu bestätigen, wie Ihr System mit entfernten Hosts kommuniziert. Dies wird die Unterscheidung zwischen lokaler und entfernter Netzwerkkommunikation festigen und die Rolle des Standard-Gateways hervorheben.
Nachdem Sie erfolgreich google.com angepingt haben, überprüfen wir nun erneut den ARP-Cache. Führen Sie in Ihrem Terminal den Befehl arp -a aus:
arp -a
Untersuchen Sie die Ausgabe sorgfältig. Sie sollte identisch mit dem Cache-Status aus den vorherigen Schritten sein.
_gateway (172.16.50.253) at ee:ff:ff:ff:ff:ff [ether] on eth0
? (172.16.50.251) at ee:ff:ff:ff:ff:ff [ether] on eth0
Sie werden feststellen, dass es keinen Eintrag für google.com oder seine IP-Adresse (z. B. 142.250.189.174) gibt. Der einzige signifikante Eintrag, der vorhanden ist, ist immer noch der für Ihr Standard-Gateway.
Dies ist die wichtigste Erkenntnis dieses Labs. ARP arbeitet auf Schicht 2 und wird nur verwendet, um MAC-Adressen im lokalen Netzwerksegment zu finden. Wenn Ihr Computer ein Paket an ein entferntes Ziel sendet, weiß er, dass das Ziel nicht lokal ist, und sendet das Paket daher an die MAC-Adresse des nächsten Hops – Ihres Standard-Gateways. Der Router übernimmt dann die Verantwortung für die Weiterleitung des IP-Pakets an sein endgültiges Ziel. Ihr Computer muss die MAC-Adresse von google.com nicht kennen; er muss nur die MAC-Adresse des Geräts kennen, das das Paket für ihn weiterleiten kann.
Zusammenfassung
In diesem Lab haben Sie die grundlegende Interaktion zwischen den Netzwerkschichten 3 (IP) und 2 (MAC) mithilfe der Befehle ping und arp unter Linux untersucht. Sie begannen mit der Inspektion des Zustands des Address Resolution Protocol (ARP)-Caches mit arp -a und stellten fest, dass dieser möglicherweise bereits Einträge für kritische Geräte wie das Standard-Gateway enthält. Durch das Anpingen des lokalen Gateways haben Sie bestätigt, dass das System diese zwischengespeicherten Informationen für die lokale Kommunikation verwendet und redundante Adressabfragen vermeidet.
Darüber hinaus haben Sie untersucht, wie sich die Kommunikation mit einem entfernten Host unterscheidet. Als Sie eine externe IP-Adresse angepingt haben, haben Sie beobachtet, dass das System keine ARP-Anfrage für das endgültige Ziel durchführt. Stattdessen sendet es das Paket an das Standard-Gateway, um es außerhalb des lokalen Netzwerks zu routen. Die abschließende Analyse des ARP-Caches hat dieses Konzept verstärkt und gezeigt, dass kein Eintrag für den entfernten Host hinzugefügt wurde. Der einzige relevante Eintrag blieb der des Standard-Gateways, was seine entscheidende Rolle als Vermittler für den gesamten Datenverkehr zu externen Netzwerken unterstreicht.
