| orm@doc-tcpip.org | Erstellt: Mai 2001 - Letzte Modifikation: Mai 2001 |
Das wichtigste ist, das man eine tragfähige Annahme über den Fehler
hat. Nur so ist ein sinnvoller Trace möglich. Dann sollte man sich
genau überlegen, auf welchem Host man was tracen möchte. Es ist z.B.
keine guten Idee, in einer Telnet Session zum remoten Host einen
Trace zu starten, der dann ein FTP-Fehlerszenario zwischen diesen
Maschinen mitschneiden soll. (Man hätte dann beide Verbindungen
gemischt im Trace..). Generell ist es gut, wenn man den Verkehr
auf dem Link reduzieren kann und wirklich nur solange laufen läßt,
bis der Fehler reproduziert ist.
Ein weiteres Problem sind Netzwerkkomponenten. Ein Switch sorgt
z.B. für virtuelle Verbindungen, es sehen also nicht alle Hosts
alle Pakete. Der Switch kopiert nicht alle Frames auf alle Ports,
und man sieht dann nur Broadcasts oder geflutete Paket. Bei vielen
Switches kann man einen Port auf einen anderen spiegeln und so
den Verkehr mitschneiden. Hier ist allerdings Vorsicht angebracht.
Die Konfiguration derartiger Komponenten ist komplex und häufig
sind die Administratoren überfordert.
In solchen Fällen kann es nötig werden, sich physikalisch an eine
bestimmte Stelle zu setzen und auf möglichst primitive Komponenten
zurückzugreifen (also z.B. zwischen Host und Switch einen billigen
Hub einfügen und mit einem Laptop tracen).
Dann, was auch gerne Vergessen wird, sieht man bestimmte Pakete nur
an bestimmten Orten - vermutet man Probleme mit ARP oder anderen
Broadcast, so muß man auf dem lokalen Netz bzw. in der Broadcast-Domain
tracen.
Es ist jedenfalls immer besser, vorher nachzudenken statt hinterher
durch mehrer hundert MB Trace zu waten.
Das iptrace-Kommando ist das Arbeitspferd unter AIX.
Die angebotenen Features reichen für die allermeisten Zwecke aus, auch
wenn man sich manchmal gut überlegen muß, wie man es anstellt. Es gibt
sehr wenig Filtermöglichkeiten. Die Handhabung ist einfach, man kann
den Dienst über den SRC bequem starten und stoppen. Es wird immer ein
binäres Trace-File erzeugt, was man später mit dem Kommando ipreport
formatieren muß. Es ist keine Online-Ausgabe nach STDOUT möglich. Die
von ipreport erzeugten Ausgaben sind übersichtlich und die meisten
Services werden ordentlich aufgelöst (DNS, DHCP, RPC, NFS, Portmapper).
Mein letzter Stand ist, daß das Tool noch kein IPv6 kann.
Um den iptrace zur Verfügung zu haben muß das Fileset bos.net.tcp.server
installiert sein.
Wenn man IPtrace startet, so liest es die Kommandozeilen Argumente ein, öffnet das Tracefile, setzt Signal-Handler auf, lädt die netintf-Kernelextension , öffnet einen raw AF_INET Socket und setzt das IFF_DEBUG-Flag auf dem Interface. AF_INET liest alle Pakete von allen Interfaces.
Die vorhandenen Schalter:
Es ist am einfachsten, den iptrace-Service über den startsrc/stopsrc
Mechanismus einzusetzen. Das spart die Suche nach der PID etc.
Folgender Trace schneidet keine ARP-Pakete mit (Schalter -a) und
zeichnet den Verkehr zwischen den Hosts Cristina und Nimmaster auf. Das
File mit den binären Daten ist /tmp/telnet.bin. Die Anführungsstriche
begrenzen den String, den das startsrc-Kommando an den iptrace
Prozesse übergibt. Die beiden "-a" haben also volle Berechtigung: das erste
gehört zum Startsrc und zeigt an, das noch ein String mit Argumenten folgt.
Das zweite "-a" ist für den IPTrace und zeigt an, das keine ARP Pakete
mitgeschnitten werden sollen.
startsrc -s iptrace -a "-a -s cristina -d nimmaster /tmp/telnet.bin"
Mit ipreport muß der Trace formatiert werden. In diesem Format
werden alle Pakete mit einer Nummer versehen (-n), es werden die RPC-Calls
entsprechend aufgelöst (-r) und vor jede Zeile kommt eine dem Protokoll
entsprechende Marke (-s). Die Abkürzungen sind selbsterklärend (TOK, ETH,
TCP, DNS ...). Was das Flag "v" macht, habe ich nie so richtig verstanden.
In diesem Fall nicht eingesetzt, aber sehr vernünftig, wenn man in einem
anderem Netz formatiert, ist das "-N" Flag. Es wird dann die Namensauflösung
unterdrückt, und alles geht deutlich schneller.
Die Ausgabe des ipreports wird durch einen "grep" gejagt, und am Ende sind
nur Pakete zu sehen, die über das Interface tr0 gingen.
ipreport -rnsv /tmp/telnet.bin |grep -p "interface tr0" |more
Hier Beispiele für Traces auf Ports. Einmal NTP (Port 123) und DNS (Port 53).
Das sind sehr nützliche Ansätze zum Debuggen in diesem Bereich.
startsrc -s iptrace -a "-a -p 123 /tmp/ntp.bin"
startsrc -s iptrace -a "-a -p 53 -b /tmp/dns.bin"
Die Analyse eines Traces gestaltet sich sehr einfach, wenn man mit dem
"grep" aus den ganzen Informationen gezielt einzelne Zeilen ausschneidet
und direkt nebeneinander sehen kann. Ein Beispiel wären die Zeitstempel
oder die Sequenznummern.
egrep "interface | src | th_seq | flags"
Es ist auf diese Art sehr einfach, im Trace eindeutige Marker zu bestimmen
und dann die entsprechende Information herauszuziehen.Tcpdump ist sicher das verbreiteste Tool dieser Art. Es ist für alle Unix-Plattformen zu haben, und für eine ganze Reihe anderer auch. Die Syntax ist etwas unübersichtlich und von Implementation zu Implementation auch verschieden. Trotzdem besticht tcpdump durch die Mächtigkeit und Vielfalt der Filter, die man konstruieren kann. Bei schwierigen Problemen geht meist kein Weg an tcpdump vorbei - wobei ein Blick in die man-Pages unumgänglich ist.
Die Filterregeln werden aus "Qualifiern" und "Keywörtern" zusammengesetzt und
beziehen sich immer auf die angebene ID, entweder Hostname oder IP-Adresse.
Folgende Typen von Qualifiern sind erlaubt:
Wem das alles zu kompliziert ist, der kann zu Ethereal greifen.
Das ist ein sehr umfangreiches und gutes, grafisches Tool. Es liest eine
ganze Reihe anderer Formate ein und gibt die Pakete klar gegliedert wieder.
Man kann mit dem dem Tool auch Filter aufsetzen und Traces fahren.
Besonders schön ist, das man immer ein Fenster mit dem Hex-Dump hat.
Klickt man mit der Maus auf eine Stelle, meinetwegen ein Flag oder eine
MAC-Adresse, so erscheint die entsprechende Stelle im Hex-Dump hervorgehoben.
Zum Lernen und als Arbeitspferd ideal. Trotzdem sollte man sich mit den
propietären Tools der einzelnen Plattformen und tcpdump gut vertraut machen -
schließlich kann es ja mal passieren, das man Ethereal nicht zur Hand hat...
Zum Tool selbst ist nicht viel zu sagen, es ist leicht verständlich, obwohl
man seine Zeit braucht, um alle Features einsetzen zu können.
Mit snoop habe ich wenig Erfahrung. Mir scheint es ein tcpdump auf
Solaris zu sein, mit einer weniger kryptischen Bedienung.
Das wenige, was ich gemacht habe:
snoop -d nei0 between elrapido elbueno
snoop -d nei0 arp
snoop -d nei0 -o /tmp/snarf.bin -c 10000
Zum auslesen dieses Files geht man so vor:
snoop -i /tmp/snarf.bin > /tmp/snarf.out
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL