Werkzeuge für Netzwerkprobleme

Zum Testen der Internetverbindung gibt es eine Reihe von Werkzeugen unter Windows und Unix, mit deren Hilfe man Verbindungen oder Dienste testen kann und die gute Werkzeuge für Netzwerkprobleme sind.

Die folgenden Beispiele gehen davon aus, dass für eine Website www.beispiel.de Netzwerkprobleme bestehen:

Probleme mit der Internetverbindung? Die erste Frage bei Konnektivitätsproblemen ist natürlich immer, ob der Rechner denn überhaupt prinzipiell Systeme im Internet erreichen kann. Hierzu läßt sich ein kurzer Test mit ping auf das System mit der IP-Adresse 4.2.2.2 oder eine andere, wohlbekannte IP-Adresse durchführen.

# ping 4.2.2.2
PING 4.2.2.2 (4.2.2.2): 56 data bytes
64 bytes from 4.2.2.2: icmp_seq=0 ttl=244 time=31 ms
64 bytes from 4.2.2.2: icmp_seq=1 ttl=244 time=31 ms
64 bytes from 4.2.2.2: icmp_seq=2 ttl=244 time=31 ms

—-www.sipgate.de PING Statistics—-
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip (ms) min/avg/max/med = 31/31/31/31
#

Man kann auch eine andere IP-Adresse im Internet für diesen Test verwenden, 4.2.2.2 läßt sich jedoch gut merken. Im nächsten Schritt sollte man per Webbrowser bekannte Websites sowie den Website des eigenen Internet-Providers aufrufen.

Lassen sich diese Websites nicht aufrufen, liegt – je nach Fehlermeldung des Browsers – ein Problem mit dem Domain Name Service (DNS-Einträge) oder der eigenen Internet-Verbindung vor. Vielleicht ist auch ein falscher Proxy konfiguriert. Lassen sich diese Websites aufrufen, nicht jedoch die problematische Seite, so kann ein Problem mit dieser Website vermutet werden.
Lassen sich Websites mit Seiten von z.B. mehr als 1400 Bytes Inhalt nicht aufrufen, kleine Daten (z.B. der Abruf kleiner GIF-Bilder) jedoch schon, so kann auch ein MTU-Problem die Ursache dafür sein, daß Pakete ab einer bestimmten Größe nicht korrekt übertragen werden. Hier finden Sie mehr Informationen zu MTU und RWIN.

Es ist auch zu bedenken, daß der eigene Internetrouter ggf. durch Filesharing überlastet sein kann und dann keine weiteren Verbindungen herstellt.

Ist die Website korrekt erreichbar, so sollte die Ausgabe von ping als eines der Werkzeuge für Netzwerkprobleme wie folgt aussehen:

# ping www.beispiel.de
PING www.beispiel.de (217.10.79.6): 56 data bytes
64 bytes from 217.10.79.6: icmp_seq=0 ttl=54 time=13 ms
64 bytes from 217.10.79.6: icmp_seq=1 ttl=54 time=17 ms
64 bytes from 217.10.79.6: icmp_seq=2 ttl=54 time=14 ms
—-www.beispiel.de PING Statistics—-
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip (ms) min/avg/max/med = 13/15/17/14
#

Ist die Website nicht erreichbar oder unterdrückt das Senden von Antworten auf ping (oder ein Router auf dem Weg zur Website verwirft die ping-Pakete), so sieht das Ergebnis wie folgt aus:

# ping www.beispiel.de
PING www.beispiel.de (217.10.79.6): 56 data bytes
—-www.beispiel.de PING Statistics—-
10 packets transmitted, 0 packets received, 100.0% packet loss
#

Die Nichterreichbarkeit eines Systems per „ping“ darf nicht so verstanden werden, daß dieses System generell nicht erreichbar ist. Es kann sich auf dem Weg zum Ziel ein Router befinden, der gezielt „ping“-Pakete blockiert und damit diesen Effekt verursacht. Konnte jedoch das Zielsystem bisher erreicht werden und funktioniert dies nun nicht mehr, so kann man davon ausgehen, daß wahrscheinlich ein Fehler im Netzwerk oder beim Zielsystem vorliegt.

Ist die Website weder per ping, noch per telnet auf den korrekten Port erreichbar, so liegt die Vermutung nahe, daß die Website oder der Weg dorthin gestört ist. Der Weg kann mit „traceroute“ getestet werden. Dies kann beispielsweise so aussehen:

# tracert www.beispiel.de
Routenverfolgung zu www.beispiel.de [217.10.79.6] über maximal 30 Abschnitte:
1 1 ms <1 ms <1 ms HSI-KBW-085-216-040-162.hsi.kabelbw.de [85.216.40.162] 2 9 ms 9 ms 8 ms HSI-KBW-085-216-040-001.hsi.kabelbw.de [85.216.40.1] 3 10 ms 8 ms 8 ms 172.30.1.49
4 6 ms 6 ms 8 ms 172.30.1.1
5 14 ms 10 ms 12 ms 172.30.30.9
6 18 ms 8 ms 8 ms DE-CIX1.F-8-eth130.de.lambdanet.net [80.81.193.74] 7 13 ms 10 ms 11 ms FRA-8-pos300.de.lambdanet.net [217.71.105.225] 8 13 ms 10 ms 12 ms bellaxa-2-FRA.de.lambdanet.net [217.71.104.206] 9 12 ms 11 ms 11 ms 217.118.18.38
10 18 ms 11 ms 12 ms 217.118.18.34
11 17 ms 14 ms 13 ms r3-1-5.netzquadrat.net [217.10.64.14] 12 16 ms 15 ms 15 ms r2-5-1.netzquadrat.net [217.10.64.5] 13 17 ms 15 ms 16 ms www.beispiel.de [217.10.79.6] Ablaufverfolgung beendet.
#

Bricht der Pfad irgendwo ab und es wird nicht das Ziel in der letzten Zeile aufgeführt, so ist das Routing gestört, d.h. innerhalb des Internet Service Providers oder zwischen zwei ISPs auf dem Weg gibt es ein Problem. Diese sind meistens nur von kurzer, vorübergehender Natur, d.h. es ist zunächst etwas Geduld angesagt.

Es kann jedoch auch hier sein, daß auf dem Weg ein Router diese Art der traceroute-Pakete blockiert und daher ab einem gewissen Punkt in der Pfadverfolgung keine Werte mehr ausgegeben werden.

Mit telnet kann die Verbindung zu einem Webserver manuell hergestellt werden. Da HTTP-Dienste den Port 80 benutzen, muß dieser mit angegeben werden. Lautet der zu testende Port für den Webserver anders (z.B. 8080 oder 8000), so muß dieser verwendet werden. Die Eingabe von „GET / HTTP/1.0“ und zweimal Return sollte dann eine HTTP-Ausgabe liefern. Korrekt würde dies wie folgt aussehen:

# telnet www.beispiel.de 80
Trying 217.10.79.6…
Connected to www.beispiel.de.
Escape character is ‘^]’.
GET / HTTP/1.0

HTTP/1.1 302 Found
Date: Mon, 13 Mar 2006 16:22:11 GMT
Server: Apache/1.3.26
X-Powered-By: PHP/4.1.2
Set-Cookie: REFID=9776ecc162458409d9d073ce82088d5e; expires=Sun, 11-Jun-06 16:22:11 GMT; path=/
Location: http://www.beispiel.de/user_interface/start.php
Connection: close
Content-Type: text/html; charset=iso-8859-1

Connection closed by foreign host.

#

Dies liefert eine Umleitung zur Einstiegsseite, d.h. entspricht einer korrekten Arbeitsweise.  Lautet die Ausgabe „www.beispiel.de: Unknown host“, so funktioniert DNS-Lookup nicht korrekt. Alternativ kann man auch die IP-Adresse verwenden. Die Funktion des DNS wird mit „nslookup“ getestet.

# nslookup www.beispiel.de 4.2.2.2
Server: vnsc-bak.sys.gtei.net
Address: 4.2.2.2

Nicht autorisierte Antwort:
Name: www.beispiel.de
Address: 217.10.79.6
# telnet 217.10.79.6 80
Trying 217.10.79.6…
Connected to 217.10.79.6.
Escape character is ‘^]’.
GET / HTTP/1.0

Liefert „telnet“ überhaupt nicht die Nachricht „Connected to…“ bzw. „Verbunden mit…“, so konnte keine Verbindung hergestellt werden. Sind jedoch Verbindungen auf andere Systeme (z.B. auch per Webbrowser) problemlos möglich, so kann ein Fehler im Zielnetz oder Zielsystem vermutet werden.