In diesem Abschnitt werden einige der Standard-Diagnoseprogramme für das Linux Netzwerk beschrieben. Man kann sie einsetzen um die Ursache von Störungen näher einzukreisen, oder einfach nur damit spielen, um mehr über die Interna eines TCP/IP-Netzwerkes zu lernen. Einige der vorgestellten Programme sind weit mächtiger als hier beschrieben, sie in ihrem vollen Leistungsumfang zu erläutern ist aber weit außerhalb der Intention dieser Einführung. Die gegebene Information sollte aber ausreichen um diese Programme für einfache Zwecke zu benutzen.
ping
ist Teil der NetKit-B Distribution. Das Programm sendet
ein spezielles Datagramm über das Netzwerk an einen anderen Rechner.
Wenn dieser eingeschaltet ist und es empfängt sendet er es wieder zurück
und man weit, daß Rechner und Netzwerk in Ordnung sind. In der
einfachsten Form sieht das so aus:
% ping gw
PING gw.vk2ktj.ampr.org (44.136.8.97): 56 data bytes
64 bytes from 44.136.8.97: icmp_seq=0 ttl=254 time=35.9 ms
64 bytes from 44.136.8.97: icmp_seq=1 ttl=254 time=22.1 ms
64 bytes from 44.136.8.97: icmp_seq=2 ttl=254 time=26.0 ms
^C
--- gw.vk2ktj.ampr.org ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 22.1/28.0/35.9 ms
ping
sucht zunächst die richtige IP-Adresse zu dem angegebene
Rechnernamen heraus (Voraussetzung ist natürlich, daß
/etc/hosts
und der Nameserver richtig konfiguriert sind) und
sendet dann in regelmäßigen Abständen ein bestimmtes Datagramm an diese
Adresse. Für jeden dieser icmp echo requests
wird der andere
Rechner dann ein icmp echo reply
als Antwort zurücksenden.
Jede der Zeilen 64 bytes from ...
stellt eine solche empfangene
Rückantwort dar. In jeder Zeile ist auch die Adresse des Absenders
dieses Paketes angegeben, die Nummer des echo requests
, auf den
mit diesem Paket geantwortet wurde, die time to live
(Lebensdauer) sowie die round trip time
, das ist die Zeit in
Millisekunden zwischen Absendung des request
und Empfang des
entsprechenden echo reply
. Damit ist dies in gewissen Grenzen
ein Maß für die Geschwindigkeit des Netzwerkes.
ping
würde endlos weiter seine Pakete senden, deshalb muß es
abgebrochen werden. Dies geschieht durch gleichzeitiges Drücken der
Tasten Control
(Strg) und C
. Danach gibt
ping
noch eine Statistik der gesendeten Pakete aus, dies sind
die letzten beiden Zeilen: Die Anzahl der gesendeten, empfangenen sowie
unbeantworteten Pakete sowie kürzeste, längste und mittlere Antwortzeit.
Eine hohe Verlustrate an Paketen deutet auf Probleme mit der Verbindung
hin, diese können durch schlechte Verbindungen, überlastete Router oder
Kollisionen im lokalen Ethernet verursacht werden. Man kann mit
ping
die schadhafte Stelle lokalisieren, indem man nacheinander
alle Knotenpunkte der Verbindung an-pingt und nachsieht, ab welchem
Punkt die Verlustrate stark ansteigt.
Mit traceroute
, einem Teil der NetKit-A Distribution, kann man
den Weg, den die Datagramme bei einer Verbindung zwischen zwei Rechnern
zurücklegen, testen und anzeigen. Wie auch ping
verwendet
traceroute
dazu das icmp Protokoll. Es verwendet
jedoch einen Trick, um von jeder durchlaufenen Knotenstelle eine
Rückmeldung zu bekommen, und das geht so: Das Feld time to
live
eines icmp-Datagramms dient eigentlich dazu zu
verhindern, das das Datenpaket ewig im Netz herumgeschickt wird,
z.B. wenn es in eine Routing-Endlosschleife gerät. Zu diesem Zweck
verringert jeder Router, der das Paket weiterleitet, den Zähler in
diesem Datenfeld um eins. Wird dabei der Wert Null erreicht, so wird
der Router, bei dem dies geschehen ist, eine icmp time to live
expired
Meldung an den ursprünglichen Absender des Datagramms
senden um ihm mitzuteilen daß das Datagramm `abgelaufen' ist.
traceroute
sendet nun nacheinander Datagramme ab, deren
time to live
, beginnend bei eins, jeweils um eins erhöht wird.
Indem es nun die eingehenden icmp time to live expired
Meldungen auswertet kann es genau den Weg, den die Datagramme nehmen,
verfolgen, bis der wirkliche Zielrechner erreicht ist.
Das sieht dann so aus:
% traceroute minnie.vk1xwt.ampr.org
traceroute to minnie.vk1xwt (44.136.7.129), 30 hops max, 40 byte packets
1 gw (44.136.8.97) 51.618 ms 30.431 ms 34.396 ms
2 gw.uts (44.136.8.68) 2017.322 ms 2060.121 ms 1997.793 ms
3 minnie.vk1xwt (44.136.7.129) 2205.335 ms 2319.728 ms 2279.643 ms
Die erste Spalte gibt die `Entfernung' an, also der wievielte Knoten
(Hop) in der Verbindung der bezeichnete Rechner ist. Dies entspricht
dem Eintrag im time to live
Feld des Datagramms, das vom
angegebenen Rechner als expired gemeldet wurde. Der nächste Eintrag ist
der Rechnername (falls dieser anhand der IP-Adresse herausgefunden
werden kann) und dessen IP-Adresse. Dann kommen drei Einträge mit den
Antwortzeiten für drei aufeinanderfolgende Datagramme an diesen Rechner.
Der erste Punkt in der Verbindung ist also der Rechner gw
.
Seine Antwortzeiten sind sehr kurz, die Verbindung ist ein lokales
Ethernet. Der nächste Router ist gw.uts
, von dort kommen die
Datagramme sehr viel langsamer zurück als von gw
. Der Grund
ist hier eine sehr langsame Verbindung über eine Funkstrecke. Der
nächste Knoten ist bereits der gesuchte Rechner, minnie.vk1xwt
.
Auch hier kommen die Antworten nur sehr langsam. Dies liegt aber daran,
daß die Antwortzeit jedes Rechners natürlich die Summe der
Verbindungszeiten aller dazwischenliegenden Teilstrecken ist, in diesem
Falle also vom eigenen Rechner zu gw
, von dort zu
gw.uts
und schließlich von gw.uts
zu
minnie.vk1xwt
. Berücksichtigt man diese Aufsummierung der
Zeiten sieht man, daß die letzte Verbindung von gw.uts
zu
minnie.vk1xwt
ebenfalls sehr schnell ist, diese beiden Rechner
hängen also vermutlich auch an einem lokalen, schnellen Netzwerk.
Taucht bei einem traceroute
Aufruf hinter den Zeiten ein
!N
auf so weist dies auf ein nicht erreichbares Netzwerk hin.
Es ist ein Zeichen dafür, daß ein Router nicht wußte, wohin er das
Datagramm weiterleiten soll. Er sendet dann ein network
unreachable
Datagramm an den Absender zurück. Meist deutet es
darauf hin, daß eine Netzverbindung (zeitweise) zusammengebrochen ist.
Anhand der letzten angegebenen Adresse vor dieser Fehlermeldung kann man
die defekte Stelle lokalisieren.
Ebenfalls auftauchen kann ein !H
als Hinweis darauf, daß ein
Rechner (Host) nicht erreicht werden konnte. Dies bedeutet i.A. daß man
bis in das lokale Netzwerk des Zielrechners gelangt ist, dieser sich
aber nicht meldet weil er z.B. abgeschaltet ist.
Adam Caldwell (acaldwel@103mort2.cs.ohiou.edu
) hat das Hilfprogramm
tcpdump
für Linux portiert. tcpdump
kann die gesamte
Aktivität auf dem Netzwerk überwachen indem es sämtlich Datagramme auf
dem Weg in den eigen Rechner hinein oder heraus abhört. Damit lassen
sich vom erfahrenen Administrator auch schwer zu identifizierende
Netzwerkprobleme lokalisieren.
Quellen und ausführbare Programme bekommt man von
ftp.funet.fi:/pub/OS/Linux/PEOPLE/Linus/net-source/tools/tcpdump-3.0.3.tar.gz
tcpdump
dekodiert jedes abgefangene Datagramm und zeigt es - in
einer etwas kryptischen Form - als Text an. tcpdump
bietet
sich an um Protokollfehler oder plötzliche Verbindungsabbrüche
aufzuspüren, denn man kann damit sehen, was auf dem Netzwerk passiert.
Um es jedoch sinnvoll einsetzen zu können bedarf es eines tieferen
Verständnisses der Protokolle und wie sie arbeiten, doch es kann auch
einfach dazu benutzt werden um sicherzustellen, daß z.B. Datagramme den
eigenen Rechner wirklich über die richtige Schnittstelle verlassen
oder um zu überprüfen, ob irgendwelche Datagramme von außerhalb
empfangen werden. Eine typische Ausgabe von tcpdump
sieht
etwa so aus:
% tcpdump -i eth0
tcpdump: listening on eth0
13:51:36.168219 arp who-has gw.vk2ktj.ampr.org tell albert.vk2ktj.ampr.org
13:51:36.193830 arp reply gw.vk2ktj.ampr.org is-at 2:60:8c:9c:ec:d4
13:51:37.373561 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request
13:51:37.388036 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply
13:51:38.383578 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request
13:51:38.400592 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply
13:51:49.303196 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: S 700506986:700506986(0) win 512 <mss 1436>
13:51:49.363933 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 1103372289 win 14261
13:51:49.367328 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: S 1103372288:1103372288(0) ack 700506987 win 2048 <mss 432>
13:51:49.391800 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 134 win 14198
13:51:49.394524 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: P 1:134(133) ack 1 win 2048
13:51:49.524930 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: P 1:28(27) ack 134 win 14335
..
tcpdump
ohne Argumente gestartet überwacht das Netzwerk-Device
mit der kleinsten Nummer, das kein Loopback-Device ist. Es kann aber -
wie im Beispiel - auch ein spezielles Device angegeben werden.
tcpdump
dekodiert dann jedes Datagramm das über diese Device
übertragen wird und zeigt es in einer lesbaren Form an. Der erste
Eintrag ist wie leicht zu ersehen der Zeitpunkt, zu dem das Datagramm
gesendet oder empfangen wurde. Der weitere Inhalt der Zeile hängt dann
von der Art des Datagramms ab. Die ersten beiden Zeilen im Beispiel
zeigen, wie ein arp request von albert.vk2ktj nach der Adresse von
gw.vk2ktj aussieht. Die nächsten vier Zeilen sind zwei ping
s
von albert.vk2ktj an gw.vk2ktj, tcpdump
gibt dabei auch die
genaue Art des icmp
Datagramms an. Das Größer-Zeichen (>)
gibt die Richtung an, in der das Datagramm übermittelt wurde, es zeigt
vom Sender zum Empfänger. Die restlichen Zeilen protokollieren den
Aufbau einer telnet
Verbindung von albert.vk2ktj zu gw.vk2ktj.
Die Zahl am Ende jeden Rechnernamens gibt die verwendete Socket Nummer
an, zu diesem Zweck wertet tcpdump
die Datei
/etc/services
aus.
Alle weiteren Optionen werden in der Online-Hilfe behandelt.
Vorsicht PPP-Benutzer: Die derzeitige Version von
tcpdump
unterstützt das PPP-Protokoll nicht. Es gibt zwei
Patches von Al Longyear die diese Unterstützung implementieren, es wurde
jedoch bislang noch kein vollständiges tcpdump
-Paket damit
zusammengestellt. Diese Patchdateien sind auf sunsite.unc.edu
im selben Verzeichnis wie tcpdump
.
Das Internet Control Message Protocol (icmp) liefert hilfreiche
Informationen über den Zustand des IP-Netzwerkes. Meist werden
derartige Meldungen vom System direkt empfangen und verarbeitet, ohne
daß man als Benutzer oder Netzwerkadministrator etwas davon mitbekommt.
icmpinfo
ist ein Programm, daß alle derartigen Meldungen
ähnlich wie tcpdump
mitprotokolliert und anzeigt. Laurent
Demailly (dl@hplyot.obspm.fr
) hat dieses Programm basierend auf den
Quellen des BSD ping geschrieben.
Version 1.10 ist erhältlich über:
hplyot.obspm.fr:/net/icmpinfo-1.10.tar.gz
Kompilierung und Installation sind sehr einfach:
% cd /usr/src
% gzip -dc icmpinfo-1.11.tar.gz | tar xvf -
% cd icmpinfo-1.11
% make
Um icmpinfo
zu benutzen muß man als root
eingelogged
sein. Die entschlüsselten Meldungen können wahlweise auf der Konsole
ausgegeben oder via syslog
protokolliert werden.
Um zu sehen wie icmpinfo
arbeitet ist es sehr lehrreich, das
Programm zu starten und dann ein traceroute
auf einen
entfernten Rechner auszuführen. Es werden dann die icmp-Meldungen, die
traceroute
verwendet, angezeigt.