mit Methodik (nicht kreuz & quer, sondern mit Plan) und Intuition:
- Divide and Conquer
– Prinzip des optimalen Zahlenratens: in der Mitte anfangen, nach oben oder nach unten korrigieren („agile Wegfindung“); ausgehend von der Mitte entscheidet man, ob es sich um ein Netzwerk- oder Anwendungsproblem handelt
– beginnend in der Mitte des OSI-Modells, Test der Netzwerkebene (Layer 3), z.B. mit Ping
– dann je nach Ergebnis schichtweise nach unten (Data Link Layer, Physical Layer) oder nach oben (Transport Layer, Application Layer) vorarbeiten - Follow the Path
– dem Weg der Kommunikation von Quelle zum Ziel folgen
– wird eingesetzt, wenn ausgeschlossen werden kann, dass der Fehler auf den Kommunikations-Endpunkten (Server, Client) liegt - Spot the differences
– Vergleich SOLL-IST-Zustand
– Vergleich mit verschiedenen, alternierenden Konfigurationen - Top-Down
vom OSI-Modell ausgehend wird versucht, zunächst ein Problem in der Anwendungsschicht (Application Layer 5 bis 7) auszuschließen und sich weiter von oben nach unten zu arbeiten - Bottom-Up
wie Top-Down, nur vom Physical Layer 1 hochwärts
Generell:
- Welche Protokolle sind beteiligt?
- Welche Netzwerk-Komponenten sind beteiligt?
- Welche Endsysteme sind beteiligt?
- Welche Punkte können aufgrund der Problembeschreibung bereits ausgeschlossen werden?
- Welche wahrscheinlichsten Ursachen sollen zuerst gecheckt werden?
Werkzeuge:
- ip / ipconfig
– als erster Troubleshooting-Befehl auf einem Endsystem
– IPv4-/IPv6-Adress-Kontrolle
– Kontrolle der verschiedenen DNS-Suffixe
– Kontrolle der DNS-Serveradressen
– Kontrolle der MAC-Adressen (Layer 2 Problem)
– Übereinstimmung von Subnetzmaske und Subnetz
– Ist das Default-Gateway korrekt und im selben Subnetz?
– Hat der richtige DHCP-Server die Lease vergeben?
– Kontrolle und Reinitialisierung des DNS-Cache
– IP-Lease freigeben und erneut übergeben lassen - ping
– Test der Verbindung auf Netzwerkebene
– steht auf den meisten TCP/IP-Systemen zur Verfügung
– ermittelt mittels ICMP Typ 8 (Echo Request) ob das System erreichbar ist (Antwort mit ICMP Typ 0, Echo Reply)
– im eigenen Subnetz-Bereich antwortet bei ausbleibender Antwort das eigene System und ggf. das Gateway (Proxy-ARP-Prinzip: Gateway sendet arp-Request, stellt fest, dass keine Antwort kommt und antwortet dem System, dass auch dieser Test erfolglos war) mit „Zielhost nicht erreichbar“
– mit Ping auf subnetzfremde Adressen ggf. „Zeitüberschreitung der Anforderung„, Ping läuft hinter dem Router ins Leere (bei eingetragenem Gateway)
– bei Fehlen des Standard-Gateways (bzw. fehlender Route zum Ziel): „Fehler bei der Übertragung. Allgemeiner Fehler.“
– Antwortzeiten zeigen zudem, wie gut die Leitung bzw. Übertragung (Latenz) ist: bei < 30ms – gute Anbindung, bei > 100ms Probleme auf der Leitung
– Dauerping zur Detektion von Aussetzern, Übertragungs-Schwankungen (Jitter)
– Zusammenfassung der Analyse mit statistischen Durchschnittswerten - arp
– Zuordnung von MAC-Adressen auf IP-Adressen kontrollieren
– ggf. ARP-Cache löschen und neu initialisieren lassen - traceroute / traceroute6 / tracepath (MS-Extrawurst: tracert)
– zeigt die Stationen zwischen Quelle und Ziel auf
– nutzt schrittweise Erhöhung des TTLs im IP-Header (Abzählen/Verwerfen der maximal zu überspringenden Router / „Hops“)
– die Antwort auf IP-Pakete kann aber von Firewalls abgelehnt werden, dann bekommt traceroute für dieses verworfene Paket keine Informationen
– mit oder ohne Namensauflösung (z.B. „traceroute -d„)
– Problemdiagnose beim xten host, der nicht antwortet („Follow the path„-Ansatz), wird mit anderen Tools kombiniert - netstat
– „Netzwerk-Status„, Schweizer Taschenmesser
– umfasst Routing-Tabelle, gebundene UDP- und TCP-Ports
– Konfigurations-Optionen: siehe man-Page zu netstat
– typische Konfigurationen: $ netstat -nr, $ netstat -nap, # netstat -tulpn (u.a.)
– ABHÖREN/Listening: Port bereit, eine Verbindung anzunehmen
– HERGESTELLT/Established: existierende Verbindung
– „Lokale Adresse: 0.0.0.0“ – von außen nicht erreichbar - telnet
– als generischer Client zur Überprüfung von TCP-basierten Diensten - nslookup
– zur Überprüfung von UDP-basierten Diensten, z.B. DNS
– Durchführung von DNS-Namensauflösungen: der lokale DNS-Client wird aktiviert und entsprechende Anfragen provoziert (keine Nutzung eines lokalen Caches!)
– unter Linux: legacy-Status, „sollte nicht eingesetzt werden“ (?)
– mit „$ nslookup“ startet die nslookup-Shell z.B. zur Namensauflösung vorwärts/rückwärts mit einfacher Angabe eines Namens bei default „set q=a“ (Query-Type A bzw. Quad-A bei IPv6) bzw. einer IP-Adresse (Query-Type PTR), „set q=ns“ (Query-Type Nameserver) zur Ermittlung verantwortlicher Nameserver, „set q=soa“ (Query-Type Start of Authority) zur Zonenabgleichs-Definition (Verwaltungs-Informationen), „set q=mx“ (Query-Type MX/Mailserver) zur Abfrage der Mailserver-Definitionen und Priorisierung bezüglich einer Domäne - dig
– z.B „dig @8.8.8.8 A www.generica.net„: Abfrage über DNS 8.8.8.8 nach IPv4-Zonen-Informationen zur Domain www.generica.net
– z.B. „dig @8.8.8.8 AAAA www.generica.net„: Abfrage über DNS 8.8.8.8 nach IPv6-Zonen-Informationen zur Domain www.generica.net - Wireshark
– Netzwerksniffer, schneidet Datenverkehr eines Netzwerks an der ausgewählten, lokalen Schnittstelle mit und analysiert diese
– ohne Blackbox: alle Pakete werden komplett
– wichtigste Spalten: SOURCE und DESTINATION
– PROTOCOL enthält das höchste transportierte Protokoll gemäß OSI & TCP/IP
– INFO zeigt die wichtigsten Informationen zum jeweiligen Paket im Überblick
– mit dem Detailfenster in der Mitte lassen sich die einzelnen Protokoll analysieren
– mit Filtern (CAPTURE-Filter vor dem Mitschnitt, DISPLAY-Filter beim Mitschnitt; jeweils eigene Syntax!) uninteressanten Traffic ausblenden
– MAC-Adress-, Netzwerknamens- und Transportschichtnamens-Auflösung kann in den Optionen deaktiviert werden
– einem (TCP-) Stream kann gefolgt werden („Analyse“ => „Folgen“ => …)