# Network Troubleshooting Tools: Der ultimative Werkzeugkasten für Admins

TL;DR / Management Summary Ein Senior Admin ist nur so gut wie seine Tools. Bei Netzwerkfehlern zählt Geschwindigkeit und Präzision. Wir nutzen den iproute2-Stack zur Konfigurationsprüfung, tcpdump zur Paket-Analyse und nmap zum Scannen von Diensten. Ziel ist es, von der physischen Verbindung (Layer 1) bis zur Applikation (Layer 7) jeden Fehler innerhalb von Minuten zu isolieren. Dieser Artikel stellt die wichtigsten CLI-Werkzeuge und deren Praxiseinsatz vor.

# 1. Die Basis: iproute2 Suite

Vom alten ‘ifconfig’ zur Moderne.

Vermeiden Sie veraltete Tools. Nutzen Sie unter Linux (Proxmox/Debian):

# 2. Erreichbarkeit & Pfade: Ping, MTR & Dig

Die Suche nach dem Ziel.

# 1. MTR (My Traceroute)

Ersetzt ping und traceroute.

# 2. Dig (Domain Information Groper)

Das Schweizer Taschenmesser für DNS.

# Fragt den autoritativen Server direkt ab
dig @ns1.google.com www.google.de A

# 3. Deep Dive: tcpdump (Das Stethoskop)

Live-Blick auf die Pakete.

Wenn die Applikation “keine Verbindung” meldet, müssen Sie die Bridge (Artikel 679) belauschen.

# Zeigt alle SYN-Pakete (Verbindungsversuche) auf Port 443
tcpdump -i any 'tcp[tcpflags] & tcp-syn != 0 and port 443'

# 4. Port-Scans & Security: Nmap

Den Horizont scannen.

Prüfen Sie, ob Ihre OPNsense-Regeln (Artikel 553) wirklich greifen.

# Schneller Scan der Top 1000 Ports
nmap -sV -T4 10.0.1.50

# 5. Day-2 Operations: Verbindung-Statistiken (SS / Netstat)

Wer spricht gerade?

Der Befehl ss (Socket Statistics) ist der performante Nachfolger von netstat.

# Zeigt alle hörenden Ports und die zugehörigen Prozesse
ss -tulpn

# 6. Troubleshooting & “War Stories”

Wenn die Tools lügen.

# Top 3 Fehlerbilder

  1. Symptom: Ping geht, aber das Tool curl liefert “Connection Refused”.

    • Ursache: Layer 3 (IP) ist ok, aber Layer 4 (Port) ist zu.
    • Lösung: nc -zv <IP> <Port> zum Testen nutzen.

  2. Symptom: tcpdump zeigt keine Pakete auf eth0.

    • Ursache: Die Pakete fließen über eine Bridge (vmbr0) und werden dort bereits von der Proxmox-Firewall gefiltert.
    • Lösung: Auf der Bridge lauschen!

  3. Symptom: Hostnamen-Auflösung geht in der Shell, aber nicht in der Applikation.

    • Ursache: Die Applikation nutzt einen anderen Resolver-Pfad (z.B. fest codierter DNS).

# “War Story”: Der “Stumme” Port-Scanner

Ein Admin wunderte sich, warum sein nmap Scan gegen einen Server im Internet immer nur “Filtert” anzeigte, obwohl er sicher war, dass der Port offen war. Die Ursache: Er nutzte den Standard-Scan (TCP SYN). Die OPNsense-Firewall am anderen Ende nutzte ein Rate-Limiting (Artikel 590) und sperrte seine IP nach den ersten 5 Paketen für 1 Stunde. Lehre: Moderne Firewalls erkennen Port-Scans. Nutzen Sie für legale Tests langsame Scans (-T1) oder bitten Sie die Security-Admins um eine temporäre Whitelist.

# 7. Monitoring & Reporting

Selbstdiagnose-Scripts.

# Der 60-Sekunden Health Check (Script)

Bauen Sie sich ein Script, das Sie bei jedem Login ausführen:

#!/bin/bash
echo "Check GW..." && ping -c 1 8.8.8.8 > /dev/null || echo "Internet DOWN"
echo "Check DNS..." && host google.de > /dev/null || echo "DNS DOWN"
echo "Check Load..." && uptime

# 8. Fazit & Empfehlung

Troubleshooting ist keine Magie, sondern methodischer Einsatz der richtigen Werkzeuge.

# Anhang: Cheatsheet (Quick Reference)

Problem Erstes Tool Zweites Tool
Keine IP ip addr tcpdump (DHCP)
Internet weg ping mtr
Port zu? nc nmap
Dienst Down? ss journalctl

# Referenzen