Einführung
Die Netzwerkdiagnose wird einfacher, wenn Sie jeweils nur eine Ebene prüfen. Beginnen Sie mit der Identität des Hosts. Überprüfen Sie anschließend seine Schnittstellen und Adressen, die Routenauswahl, die grundlegende Erreichbarkeit, die Namensauflösung, lauschende Sockets, die Antwort der Anwendung und zuletzt die lokale Firewall-Richtlinie.
In diesem Lab durchlaufen Sie diese Reihenfolge auf einem Ubuntu-Host. Ein vorbereiteter HTTP-Dienst lauscht ausschließlich auf dem Loopback-Port 8088. Damit steht Ihnen ein sicheres Ziel zum Üben mit ss, curl und UFW-Regeln zur Verfügung. Sie ändern weder die Schnittstellenkonfiguration des Hosts noch die Standardroute, die DNS-Einstellungen oder den SSH-Dienst. Vor der Aktivierung von UFW stellen Sie den SSH-Zugriff ausdrücklich sicher.
Host identifizieren
In diesem Schritt überprüfen Sie den Hostnamen und die lokalen Namenseinträge, über die Programme diesen Rechner identifizieren.
Wechseln Sie in das Lab-Arbeitsverzeichnis:
cd /home/labex/project/network-lab
Geben Sie den aktuellen Hostnamen aus:
hostname
Zeigen Sie die statische, transiente und vom Betriebssystem erkannte Identität an, die systemd bekannt ist:
hostnamectl
Static hostname ist der konfigurierte Name. Auf Cloud-Trainingsmaschinen kann der transiente Name während des Systemstarts vergeben werden.
Untersuchen Sie die lokalen Host-Zuordnungen:
cat /etc/hosts
Die Loopback-Namen localhost, 127.0.0.1 und ::1 bezeichnen denselben Host, ohne ein externes Netzwerk zu verwenden. Zeigen Sie die dem Host zugewiesenen IP-Adressen in kompakter Form an:
hostname -I
Speichern Sie den Hostnamen und die Adressliste:
printf 'hostname=%s\naddresses=%s\n' "$(hostname)" "$(hostname -I | xargs)" > host-identity.txt
cat host-identity.txt
Schnittstellen und IP-Adressen untersuchen
In diesem Schritt ermitteln Sie Netzwerkschnittstellen, Link-Status, IPv4-Adressen, Präfixe und den Gültigkeitsbereich von Adressen.
Verwenden Sie die kompakte Ansicht der Links:
ip -brief link
lo ist die Loopback-Schnittstelle. Eine weitere Schnittstelle, die häufig eth0 oder ens... heißt, verbindet die VM mit ihrem Netzwerk. UP bedeutet, dass die Schnittstelle administrativ aktiviert ist.
Zeigen Sie die Adressen in kompakter Form an:
ip -brief address
Eine Adresse wie 192.0.2.10/24 kombiniert eine IPv4-Adresse mit einer Präfixlänge. Das Präfix beschreibt, welche führenden Bits das lokale Netzwerk bestimmen.
Untersuchen Sie die Loopback-Schnittstelle im Detail:
ip address show dev lo
Die IPv4-Adresse 127.0.0.1/8 hat den scope host und ist daher nur innerhalb dieses Hosts gültig. Ermitteln Sie die Schnittstelle, die von der Standardroute verwendet wird:
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Primary interface: $primary_if"
ip address show dev "$primary_if"
Der Befehl ifconfig ist ein älteres Werkzeug für Schnittstellen, das weiterhin in vorhandenen Runbooks und Anleitungen zur Fehlerbehebung vorkommt. Vergleichen Sie seine Ausgabe mit der modernen ip-Ausgabe, die Sie gerade gelesen haben:
ifconfig
Speichern Sie auch die Ansicht des älteren Werkzeugs:
ifconfig > ifconfig-addresses.txt
Speichern Sie eine kompakte Momentaufnahme der Schnittstellen:
ip -brief address > interface-addresses.txt
cat interface-addresses.txt
Routing-Tabelle lesen
In diesem Schritt ermitteln Sie das Standard-Gateway und fragen Linux, welche Route es zu einem Ziel verwenden würde.
Zeigen Sie die Haupt-Routing-Tabelle an:
ip route
Direkt verbundene Routen beschreiben unmittelbar angeschlossene Netzwerke. Eine Zeile, die mit default via beginnt, wird verwendet, wenn keine spezifischere Route passt.
Fragen Sie den Kernel, wie er ein öffentliches Ziel erreichen würde. Dieser Befehl meldet das ausgewählte Gateway, die Schnittstelle und die Quelladresse, ohne ein Paket zu senden:
ip route get 1.1.1.1
Ermitteln Sie das Standard-Gateway und die Schnittstelle:
gateway=$(ip route show default | awk 'NR==1 {print $3}')
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Default gateway: $gateway via $primary_if"
Speichern Sie die Routenübersicht:
printf 'gateway=%s\ninterface=%s\n' "$gateway" "$primary_if" > route-summary.txt
cat route-summary.txt
Netzwerkerreichbarkeit testen
In diesem Schritt verwenden Sie ping, um zunehmend weiter entfernte Grenzen zu testen. Beachten Sie dabei, dass manche Netzwerke Diagnosepakete blockieren.
Beginnen Sie mit dem Loopback. Die Optionen -c 2 senden zwei Anfragen, und -W 2 wartet höchstens zwei Sekunden auf jede Antwort:
ping -c 2 -W 2 127.0.0.1
Ein erfolgreicher Loopback-Test bestätigt, dass der lokale IP-Stack antwortet. Rufen Sie als Nächstes das Standard-Gateway ab und testen Sie es:
gateway=$(ip route show default | awk 'NR==1 {print $3}')
ping -c 2 -W 2 "$gateway" || echo "The gateway does not answer ICMP echo requests"
Die Fallback-Meldung ist wichtig, weil ein Router Datenverkehr weiterleiten kann, während er Ping-Anfragen ablehnt. Testen Sie eine öffentliche IP-Adresse, ohne DNS zu verwenden:
ping -c 2 -W 2 1.1.1.1 || echo "Public ICMP is blocked or unavailable"
Speichern Sie ein stabiles Ergebnis für die lokale Konnektivität, das nicht von externen Richtlinien abhängt:
ping -c 1 -W 2 127.0.0.1 > loopback-ping.txt
tail -n 2 loopback-ping.txt
Namensauflösung testen
In diesem Schritt untersuchen Sie die Resolver-Konfiguration und übersetzen Hostnamen in Adressen.
Zeigen Sie die Resolver-Datei an, die von standardmäßigen Linux-Anwendungen verwendet wird:
cat /etc/resolv.conf
Sie enthält häufig eine oder mehrere nameserver-Zeilen. Auf Hosts mit systemd-resolved kann die Adresse einen lokalen Stub-Resolver und nicht direkt einen externen DNS-Server bezeichnen.
Lösen Sie einen lokalen Namen über die vollständige Namensdienstkonfiguration des Systems auf:
getent hosts localhost
getent folgt /etc/nsswitch.conf und kann daher /etc/hosts, DNS und andere konfigurierte Quellen kombinieren. Lösen Sie einen externen Namen auf und fordern Sie IPv4-Socket-Adressen an:
getent ahostsv4 example.com
Wenn ein Ping an eine IP-Adresse erfolgreich ist, diese Abfrage jedoch fehlschlägt, prüfen Sie die Resolver-Konfiguration oder die Erreichbarkeit von DNS. Speichern Sie den ersten aufgelösten IPv4-Eintrag:
getent ahostsv4 example.com | head -n 1 > dns-result.txt
cat dns-result.txt
Einen lauschenden Port und eine HTTP-Antwort untersuchen
In diesem Schritt ordnen Sie einen lauschenden TCP-Socket dem zugehörigen Prozess zu und testen das Anwendungsprotokoll.
Der vorbereitete Demo-Dienst lauscht auf dem Loopback-Port 8088. Verwenden Sie ss, um lauschende TCP-Sockets zu untersuchen. Die Optionen -l, -t, -n und -p stehen für lauschend, TCP, numerische Adressen und Prozessinformationen:
sudo ss -ltnp | grep ':8088'
Suchen Sie nach 127.0.0.1:8088. Die Bindung an den Loopback bedeutet, dass der Dienst nur von diesem Host aus erreichbar ist.
Überprüfen Sie den Prozess hinter dem Socket:
systemctl status labex-network-demo.service --no-pager
Verwenden Sie curl -i, um die HTTP-Antwort-Header und den Inhalt anzuzeigen:
curl -i http://127.0.0.1:8088/
Ein HTTP-Status 200 OK bestätigt mehr als nur einen offenen Port: Die Anwendung hat eine HTTP-Anfrage angenommen und Inhalte zurückgegeben. Speichern Sie mit dem stillen Modus -s nur den Antwortinhalt:
cd /home/labex/project/network-lab
curl -s http://127.0.0.1:8088/ > http-response.html
grep 'network demo ready' http-response.html
Zugriff sichern und UFW aktivieren
In diesem Schritt überprüfen Sie den UFW-Status, sichern den Zugriff für die Fernverwaltung, erlauben den Port des Übungsdienstes und aktivieren die Firewall.
UFW ist ein Frontend für die Paketfilterregeln von Linux. Überprüfen Sie den aktuellen Status:
sudo ufw status verbose
Die Einrichtung lässt UFW mit einem sauberen Regelsatz deaktiviert. Bevor Sie eine Host-Firewall aus der Ferne aktivieren, erlauben Sie den Verwaltungsweg, auf den Sie angewiesen sind. Diese VM verwendet den TCP-Port 22 für SSH:
sudo ufw allow 22/tcp
Erlauben Sie nun eingehenden TCP-Datenverkehr zum Port des Übungsdienstes:
sudo ufw allow 8088/tcp
Überprüfen Sie die vorbereiteten Änderungen vor der Aktivierung:
sudo ufw show added
Aktivieren Sie UFW ohne eine interaktive Bestätigungsabfrage:
sudo ufw --force enable
Bestätigen Sie, dass die Firewall aktiv ist und beide Freigaben vorhanden sind:
sudo ufw status verbose
Der Dienst ist an den Loopback gebunden. Testen Sie ihn daher nach der Firewall-Änderung lokal:
curl -fsS http://127.0.0.1:8088/
Speichern Sie den aktiven Status als überprüfbares Ergebnis:
cd /home/labex/project/network-lab
sudo ufw status verbose > firewall-status.txt
cat firewall-status.txt
Die Reihenfolge ist wichtig: Sichern Sie zuerst den Verwaltungsweg, fügen Sie die erforderlichen Dienstregeln hinzu, aktivieren Sie die Firewall und überprüfen Sie anschließend sofort sowohl die Richtlinie als auch die Erreichbarkeit der Anwendung. Auf Produktions-Hosts kann ein anderer SSH-Port verwendet werden. Prüfen Sie daher den tatsächlich verwendeten Verwaltungsweg, statt Port 22 vorauszusetzen.
Zusammenfassung
Sie haben eine strukturierte Linux-Kette zur Netzwerkdiagnose durchlaufen: Host-Identität, Schnittstellen und IP-Adressen, Routenauswahl, Erreichbarkeit, Namensauflösung, lauschende Sockets und HTTP-Antwort. Sie haben gelernt, dass jede Ebene eine andere Frage beantwortet und dass ein Fehler an einer Grenze die nächste Untersuchung eingrenzt.
Außerdem haben Sie den SSH-Zugriff gesichert, einen Port für den Übungsdienst erlaubt, UFW aktiviert und sowohl die aktive Richtlinie als auch die Antwort der Anwendung überprüft. Diese Vorgehensweisen helfen Ihnen dabei, einen Netzwerkdienst zu diagnostizieren und abzusichern, ohne weitreichende oder störende Änderungen vorzunehmen.
