Einführung
In diesem Labor werden Sie die grundlegenden Prinzipien der Netzwerkschichtkonnektivität in einer Linux-Umgebung erkunden. Anhand von Docker-Containern, die zwei separate Knoten simulieren, lernen Sie, wie Sie mit dem Befehl ip manuell statische IP-Adressen zuweisen. Anschließend verwenden Sie das Dienstprogramm ping, um den direkten Kommunikationspfad zwischen diesen Knoten in einem gemeinsamen virtuellen Netzwerk zu testen.
Nachdem Sie die Knoten zunächst im selben Subnetz konfiguriert haben, werden Sie eine erfolgreiche Konnektivität beobachten. Anschließend konfigurieren Sie einen Knoten in ein anderes Subnetz um, um einen vorhersehbaren Kommunikationsfehler zu erleben – den Fehler „Destination Host Unreachable“. Diese praktische Übung bietet eine klare, anschauliche Demonstration, wie IP-Subnetze die direkte Kommunikation steuern und warum Geräte in verschiedenen logischen Netzwerken ohne Router keine Verbindung herstellen können.
Vorbereitung der Zwei-Knoten-Laborumgebung
In diesem Schritt richten Sie die grundlegende Umgebung für unser Labor ein. Anstatt vollständige virtuelle Maschinen zu verwenden, nutzen wir leichtgewichtige und isolierte Docker-Container, um zwei separate Netzwerkknoten zu simulieren. Um die Kommunikation zwischen ihnen zu ermöglichen, erstellen wir zunächst ein benutzerdefiniertes Docker-Netzwerk. Dieses virtuelle Netzwerk fungiert wie ein physischer Netzwerk-Switch und platziert beide Knoten im selben gemeinsamen Kommunikationssegment.
Lassen Sie uns das Ubuntu 22.04 Docker-Image für die Knoten herunterladen.
docker pull ubuntu:22.04
Zuerst erstellen wir das virtuelle Netzwerk, das unsere beiden Knoten verwenden werden. Wir nennen es lab_net und weisen ihm einen spezifischen IP-Adressbereich zu, der in späteren Schritten wichtig sein wird.
Führen Sie den folgenden Befehl in Ihrem Terminal aus:
docker network create --subnet=192.168.56.0/24 lab_net
Dieser Befehl weist Docker an, ein neues Bridge-Netzwerk namens lab_net zu erstellen und es für die Verwendung des Subnetzes 192.168.56.0/24 zu konfigurieren. Sie sehen eine lange eindeutige ID für das Netzwerk als Ausgabe, die seine Erstellung bestätigt.
e8c1c2a3b4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1
Als Nächstes starten wir unseren ersten Knoten, einen Container namens node1, und verbinden ihn mit dem lab_net-Netzwerk.
docker run -d --name node1 --network lab_net --cap-add=NET_ADMIN ubuntu:22.04 sleep infinity
Lassen Sie uns diesen Befehl aufschlüsseln:
docker run: Der Standardbefehl zum Erstellen und Starten eines neuen Containers.-d: Führt den Container im "detached"-Modus aus, d. h. er läuft im Hintergrund.--name node1: Weist unserem Container einen einfachen, einprägsamen Namen zu.--network lab_net: Verbindet den Container mit dem zuvor erstellten virtuellen Netzwerk.--cap-add=NET_ADMIN: Gewährt dem Container dieNET_ADMIN-Berechtigung, die zum Ändern von Netzwerkeinstellungen wie dem Hinzufügen von IP-Adressen erforderlich ist.ubuntu:22.04: Das von uns verwendete Docker-Image, das eine Standard-Ubuntu-Umgebung bereitstellt.sleep infinity: Ein einfacher Befehl, der unendlich lange läuft, um den Container aktiv zu halten.
Starten Sie nun den zweiten Knoten, node2, mit einem ähnlichen Befehl:
docker run -d --name node2 --network lab_net --cap-add=NET_ADMIN ubuntu:22.04 sleep infinity
Schließlich überprüfen wir, ob beide Knoten korrekt ausgeführt werden. Der Befehl docker ps listet alle aktuell laufenden Container auf.
docker ps
Sie sollten eine Ausgabe ähnlich der folgenden sehen, die bestätigt, dass node1 und node2 beide gestartet sind und laufen.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1b2c3d4e5f6 ubuntu:22.04 "sleep infinity" 5 seconds ago Up 4 seconds node2
g7h8i9j0k1l2 ubuntu:22.04 "sleep infinity" 15 seconds ago Up 14 seconds node1
Da beide Knoten im selben virtuellen Netzwerk laufen, ist unsere Laborumgebung nun vorbereitet. In den folgenden Schritten werden wir ihre IP-Adressen konfigurieren und ihre Konnektivität testen.
Statische IP auf dem ersten Knoten mit ip addr konfigurieren
In diesem Schritt weisen Sie unserem ersten Container, node1, eine statische IP-Adresse zu. Eine statische IP ist eine Adresse, die manuell konfiguriert wird und sich nicht ändert, im Gegensatz zu einer dynamischen IP, die oft automatisch von einem DHCP-Server zugewiesen wird. Für unsere Simulation gibt uns die Verwendung statischer IPs die präzise Kontrolle über die Netzwerkkonfiguration.
Wir führen alle Aktionen von Ihrem Hauptterminal auf dem Host aus und verwenden den Befehl docker exec, um Befehle innerhalb des node1-Containers auszuführen.
Zuerst ist das Basis-Image ubuntu:22.04 sehr minimal. Wir müssen die notwendigen Netzwerk-Tools installieren. Beginnen wir mit der Aktualisierung der Paketliste innerhalb des node1-Containers:
docker exec node1 apt-get update
Sie sehen die Ausgabe, während der Container die neuesten Paketinformationen abruft.
Installieren Sie als Nächstes das Paket iproute2 (das den Befehl ip bereitstellt) und iputils-ping (das den Befehl ping bereitstellt, den wir später verwenden werden).
docker exec node1 apt-get install -y iproute2 iputils-ping
Nachdem die Tools installiert sind, inspizieren wir die aktuelle Netzwerkkonfiguration von node1. Die Netzwerkschnittstelle innerhalb eines Standard-Docker-Containers heißt typischerweise eth0.
docker exec node1 ip addr show eth0
Die Ausgabe zeigt die Details für die Schnittstelle eth0. Möglicherweise sehen Sie bereits eine von Dockers internem DHCP-Server zugewiesene IP-Adresse (z. B. 192.168.56.2). Wir werden unsere eigene statische IP hinzufügen.
9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.56.2/24 brd 192.168.56.255 scope global eth0
valid_lft forever preferred_lft forever
Nun weisen wir node1 die statische IP-Adresse 192.168.56.10 zu. Die /24 ist die CIDR-Notation für die Netzmaske 255.255.255.0, die die Größe des Netzwerks definiert.
docker exec node1 ip addr add 192.168.56.10/24 dev eth0
Dieser Befehl sollte bei Erfolg keine Ausgabe erzeugen. Um die Änderung zu bestätigen, führen Sie den Befehl ip addr show eth0 erneut aus:
docker exec node1 ip addr show eth0
Sie sollten nun Ihre neue statische IP-Adresse neben der ursprünglichen sehen, die als secondary gekennzeichnet ist. Dies bestätigt, dass node1 nun mit der Adresse 192.168.56.10 konfiguriert ist.
9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.56.2/24 brd 192.168.56.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.56.10/24 scope global secondary eth0
valid_lft forever preferred_lft forever
Statische IP auf dem zweiten Knoten im selben Subnetz konfigurieren
In diesem Schritt konfigurieren wir unseren zweiten Knoten, node2, mit einer statischen IP-Adresse. Damit zwei Geräte direkt ohne Router kommunizieren können, müssen sie sich im selben logischen Subnetz befinden. Wir weisen node2 eine IP-Adresse aus demselben 192.168.56.0/24-Subnetz zu, das wir für node1 verwendet haben. Diese Konfiguration ahmt logisch zwei PCs nach, die mit einem Crossover-Kabel verbunden sind, wobei beide Teil desselben lokalen Netzwerks sind.
Zuerst müssen wir, genau wie bei node1, die notwendigen Netzwerk-Tools innerhalb des node2-Containers installieren. Beginnen Sie mit der Aktualisierung der Paketliste:
docker exec node2 apt-get update
Installieren Sie als Nächstes die Pakete iproute2 und iputils-ping auf node2:
docker exec node2 apt-get install -y iproute2 iputils-ping
Nachdem die Tools installiert sind, können wir node2 nun eine statische IP-Adresse zuweisen. Wir verwenden 192.168.56.11, die sich im selben Subnetz wie node1 (192.168.56.10) befindet, aber eine eindeutige Adresse ist.
docker exec node2 ip addr add 192.168.56.11/24 dev eth0
Dieser Befehl fügt die IP-Adresse 192.168.56.11 mit einer /24-Netzmaske zur eth0-Netzwerkschnittstelle des node2-Containers hinzu. Wenn der Befehl erfolgreich ist, wird keine Ausgabe erzeugt.
Um zu überprüfen, ob die IP-Adresse korrekt zugewiesen wurde, inspizieren wir die Netzwerkkonfiguration von node2:
docker exec node2 ip addr show eth0
Die Ausgabe sollte nun die neu hinzugefügte statische IP-Adresse anzeigen, die als secondary gekennzeichnet ist. Dies bestätigt, dass node2 ordnungsgemäß konfiguriert ist und für den nächsten Schritt bereit ist, in dem wir die Konnektivität testen werden.
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.56.3/24 brd 192.168.56.255 scope global eth0
valid_lft forever preferred_lft forever
inet 192.168.56.11/24 scope global secondary eth0
valid_lft forever preferred_lft forever
Direkte Konnektivität zwischen Knoten mit ping überprüfen
In diesem Schritt testen Sie die Netzwerkkonnektivität zwischen node1 und node2. Da beide Knoten IP-Adressen im selben Subnetz haben, sollten sie direkt kommunizieren können. Wir verwenden den Befehl ping, ein grundlegendes Netzwerk-Tool, das ein kleines Datenpaket (eine ICMP Echo Request) an einen Zielhost sendet und auf eine Antwort wartet. Eine erfolgreiche Antwort bestätigt, dass ein Netzwerkpfad zwischen den beiden Geräten besteht.
Dieser erfolgreiche Test ist analog zum Verbinden zweier PCs mit einem Crossover-Kabel, bei dem beide Geräte im selben lokalen Netzwerk sind und sich direkt sehen können.
Zuerst versuchen wir, node2 von node1 aus anzupingen. Wir führen den Befehl ping innerhalb des node1-Containers aus und zielen auf die IP-Adresse von node2, 192.168.56.11.
docker exec node1 ping -c 4 192.168.56.11
Lassen Sie uns diesen Befehl aufschlüsseln:
docker exec node1: Führt den folgenden Befehl innerhalb desnode1-Containers aus.ping: Das Dienstprogramm zum Testen der Konnektivität.-c 4: Ein Flag, daspinganweist, genau 4 Pakete zu senden und dann zu stoppen. Ohne dieses Flag würdepingunbegrenzt laufen.192.168.56.11: Die Ziel-IP-Adresse vonnode2.
Sie sollten eine erfolgreiche Ausgabe sehen, mit erhaltenen Antworten von node2.
PING 192.168.56.11 (192.168.56.11) 56(84) bytes of data.
64 bytes from 192.168.56.11: icmp_seq=1 ttl=64 time=0.123 ms
64 bytes from 192.168.56.11: icmp_seq=2 ttl=64 time=0.087 ms
64 bytes from 192.168.56.11: icmp_seq=3 ttl=64 time=0.091 ms
64 bytes from 192.168.56.11: icmp_seq=4 ttl=64 time=0.085 ms
--- 192.168.56.11 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3074ms
rtt min/avg/max/mdev = 0.085/0.096/0.123/0.015 ms
Die Zeile "4 received, 0% packet loss" bestätigt, dass die Verbindung funktioniert. Nun überprüfen wir die Verbindung in die andere Richtung, indem wir node1 von node2 aus anpingen.
docker exec node2 ping -c 4 192.168.56.10
Auch hier sollten Sie eine erfolgreiche Reihe von Antworten sehen, die bestätigen, dass die Kommunikation bidirektional ist.
PING 192.168.56.10 (192.168.56.10) 56(84) bytes of data.
64 bytes from 192.168.56.10: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from 192.168.56.10: icmp_seq=2 ttl=64 time=0.088 ms
64 bytes from 192.168.56.10: icmp_seq=3 ttl=64 time=0.092 ms
64 bytes from 192.168.56.10: icmp_seq=4 ttl=64 time=0.089 ms
--- 192.168.56.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3081ms
rtt min/avg/max/mdev = 0.088/0.092/0.099/0.004 ms
Erfolg! Beide Knoten können miteinander kommunizieren, so als wären sie zwei Computer in demselben lokalen Netzwerksegment.
Zweiten Knoten auf ein anderes Subnetz neu konfigurieren
In diesem Schritt werden wir absichtlich die direkte Konnektivität zwischen unseren beiden Knoten unterbrechen. Dies erreichen wir, indem wir node2 so konfigurieren, dass es sich in einem völlig anderen IP-Subnetz als node1 befindet. Dies simuliert ein Szenario, in dem zwei Geräte physisch verbunden sind, aber logisch in verschiedene Netzwerke aufgeteilt sind.
Derzeit befindet sich node1 im Subnetz 192.168.56.0/24. Wir werden node2 nun in das Subnetz 192.168.58.0/24 verschieben. Da die dritte Zahl (das Oktett) unterschiedlich ist (56 vs. 58), gelten diese als getrennte Subnetze.
Um sicherzustellen, dass node2 im neuen Netzwerk vollständig isoliert ist, müssen wir zuerst alle vorhandenen IP-Adressen von seiner eth0-Schnittstelle entfernen. Dies schließt sowohl die statische IP, die wir zuvor hinzugefügt haben, als auch die ursprüngliche IP ein, die Docker automatisch zugewiesen hat. Der Befehl ip addr flush ist das richtige Werkzeug für diese Aufgabe.
docker exec node2 ip addr flush dev eth0
Dieser Befehl entfernt alle IP-Konfigurationen von eth0 und sorgt für einen sauberen Zustand. Wenn er erfolgreich ist, sollte er keine Ausgabe erzeugen.
Nun fügen wir die neue IP-Adresse 192.168.58.11 hinzu, die zum neuen Subnetz gehört.
docker exec node2 ip addr add 192.168.58.11/24 dev eth0
Um die Änderungen zu bestätigen, inspizieren wir erneut die Netzwerkkonfiguration von node2.
docker exec node2 ip addr show eth0
Sie werden sehen, dass alle alten IP-Adressen verschwunden sind und nur die neue (192.168.58.11) vorhanden ist. Dies bestätigt, dass sich node2 nicht mehr im Subnetz 192.168.56.0/24 befindet.
11: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c0:a8:38:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.58.11/24 scope global eth0
valid_lft forever preferred_lft forever
Mit node1 im Subnetz 192.168.56.0/24 und node2 im Subnetz 192.168.58.0/24 sind sie nun logisch isoliert.
Konnektivität testen und Fehler beobachten
Im letzten Schritt versuchen wir erneut, zwischen den Knoten zu pingen. Da node2 nun wirklich in einem neuen Subnetz isoliert ist, erwarten wir, dass die Kommunikation fehlschlägt, aber auf zwei unterschiedliche und wichtige Weisen, die zeigen, wie Netzwerk-Layer funktionieren.
Zuerst versuchen wir, die neue IP-Adresse von node2 (192.168.58.11) von node1 aus anzupingen.
docker exec node1 ping -c 4 192.168.58.11
Beobachten Sie die Ausgabe. Der Befehl wird mit einem Timeout enden, was zu einem Paketverlust von 100 % führt.
PING 192.168.58.11 (192.168.58.11) 56(84) bytes of data.
--- 192.168.58.11 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3076ms
Dieser Timeout tritt auf, weil node1 immer noch eine Route zum Docker-Netzwerk hat, sodass es das Ping-Paket sendet. Das Netzwerk leitet es an node2 weiter. Da node2 jedoch nicht mehr in diesem Netzwerk ist und keine Route zurück hat, kann es keine Antwort senden. Der Ping von node1 erhält nie eine Antwort.
Als Nächstes testen wir die andere Richtung. Versuchen Sie, node1 von node2 aus anzupingen.
docker exec node2 ping -c 4 192.168.56.10
Dieses Mal sehen Sie fast sofort eine andere Fehlermeldung.
ping: connect: Network is unreachable
Die Meldung ping: connect: Network is unreachable ist bedeutsam. Es ist eine sofortige Antwort des Betriebssystems auf node2. Sie bedeutet, dass das Betriebssystem seine Routing-Tabelle überprüft hat, festgestellt hat, dass das Ziel 192.168.56.10 in einem Netzwerk liegt, zu dem es keinen Pfad hat, und sich geweigert hat, überhaupt zu versuchen, das Paket zu senden. Dies ist eine direkte Folge der Verwendung von ip addr flush, das alle Routen gelöscht hat und den Container vollständig von anderen Netzwerken isoliert hat.
Dieses Lab hat die entscheidende Rolle von IP-Subnetting und Routing erfolgreich demonstriert. Wenn sich Geräte im selben Subnetz befinden, können sie direkt kommunizieren. Wenn sie sich in unterschiedlichen Subnetzen befinden, ist ein Layer-3-Gerät wie ein Router mit entsprechenden Routen erforderlich, um den Datenverkehr zwischen ihnen weiterzuleiten.
Zusammenfassung
In diesem Lab haben Sie gelernt, eine Zwei-Knoten-Netzwerkumgebung mit Docker-Containern zu simulieren, die mit einem benutzerdefinierten Bridge-Netzwerk verbunden sind. Sie haben die wesentliche Linux-Fähigkeit geübt, statische IP-Adressen auf Netzwerkschnittstellen mit dem Befehl ip addr zu konfigurieren. Durch die Zuweisung von IP-Adressen aus demselben Subnetz an beide Knoten haben Sie die direkte Layer-3-Konnektivität zwischen ihnen mit dem ping-Dienstprogramm erfolgreich verifiziert und damit die grundlegende Voraussetzung für die Kommunikation in einem lokalen Netzwerksegment demonstriert.
Das Lab hat weiter ein kritisches Netzwerkkonzept veranschaulicht, indem ein Knoten mit einer IP-Adresse aus einem anderen Subnetz neu konfiguriert wurde, nachdem seine ursprüngliche Netzwerkkonfiguration vollständig gelöscht wurde. Die anschließenden Kommunikationsversuche über ping schlugen mit zwei unterschiedlichen Ergebnissen fehl: ein Timeout in einer Richtung und eine Fehlermeldung "Destination Host Unreachable" in der anderen. Dieses Ergebnis zeigte effektiv, dass Knoten in verschiedenen logischen Subnetzen ohne Router nicht direkt kommunizieren können, und verdeutlichte, wie Routing-Tabellen und Schnittstellenkonfigurationen die Netzwerkkonnektivität beeinflussen.
