Website ist nicht erreichbar

Wenn ein Website nicht erreichbar ist, sollte man sich zunächst mal Schritt für Schritt vortasten, um herauszufinden, an welchem Punkt zwischen dem eigenen Internetzugang und dem jeweiligen Website das Problem liegt.

In den meisten Fällen sitzt der Fehler vor dem Rechner, d.h. man sollte zunächst die Möglichkeit der Fehlbedienung und Fehlkonfiguration der eigenen Systeme in Betracht ziehen.

Wo ist der Fehler?

Probleme können an einer Reihe von Punkten bestehen, die es der Reihe nach gilt, zu untersuchen:

  • Zunächst mal sollte man natürlich feststellen, ob der Rechner, auf dem getestet wird, überhaupt eine stabile LAN- oder WLAN-Verbindung hat. Meldet das System „eingeschränkte Konnektivität“, so besteht vielleicht ein Problem mit DHCP und der Rechner bekam noch überhaupt keine lokale IP-Adresse zugeteilt. Die IP-Adresse des Rechners lautet dann meistens 169.254.x.x („local link“).
  • Die Anwendung, in der das Problem entsteht, ist nicht richtig konfiguriert. Kann ein Browser beispielsweise einen Website nicht erreichen, so kann dies an einem falschen bzw. nicht erforderlichen oder fehlenden HTTP-Proxy liegen.
  • Der Domain Name Service zur Auflösung von Namen zu IP-Adressen funktioniert nicht korrekt. Dies kann daran liegen, daß die Konfiguration der DNS-Server falsch ist oder daß die konfigurierten DNS-Server nur DNS per UDP, nicht jedoch DNS per TCP unterstützen. Ein Test mit nslookup ist empfehlenswert.
  • Die Verbindung zwischen Gerät, von dem aus getestet wird, und dem eigenen Internetrouter ist nicht stabil. Dies kann beispielsweise bei nicht kabelgebundenen Zugangstechnologien wie WLAN (wireless) oder dLAN (über das Stromnetz) passieren. Jedoch auch bei kabelgebundenen Verbindungen können Fehler im Kabel bestehen.
  • Der eigene Internetrouter ist falsch konfiguriert. Hierzu zählen vor allem Filter und Firewall-Einstellungen bzw. Portweiterleitungen, die ggf. verhindern, daß Anfragen vom eigenen Rechner das LAN verlassen bzw. die Rückantworten von Servern im Internet nicht mehr zurück in das LAN gelassen werden.
  • Der Internetzugang hat ein Problem. Dies können ein defektes Kabelmodem, ein fehlerhafter DSL-Splitter, eine Störung in einer Vermittlungssteller oder beim Provider, bis hin zu regionalen Ausfällen von DSL- oder Kabel-Internet-Knoten sein. Sofern es sich um Geräte und Einrichtungen handelt, die nicht in der Kontrolle des Endkunden sind, muss die Störungshotline des Internetanbieters verständigt werden.
  • Der Internet-Service-Provider hat ein Problem im eigenen Netz. Durch Routingstörungen oder Ausfälle einzelner Komponenten kann es auch im Netzwerk des ISP zu Störungen kommen, die die Verfügbarkeit von Internetzugang für Endkunden einschränken oder reduzieren. Hier kann nur die Störungshotline des ISP weiterhelfen.
  • Der Internet-Service-Provider hat ein Peering-Problem. „Peering“ ist das Zusammenschalten von Netzen mehrerer Service-Provider zu einem Interconnect-Netzwerk - zu einem Internet. Fallen solche Interconnections aus, kann man nur einen Teil des weltweiten Internet erreichen. Auch hier muss die Störungshotline des ISP informiert werden.
  • Der Weg zum Zielsystem ist gestört. Ebenso wie Interconnect-Probleme zwischen dem eigenen ISP und anderen auftreten können, kann dies natürlich auch auf dem Weg zum Zielserver im Internet an beliebigen anderen Übergängen zwischen Netzwerken passieren. Ist der Weg zum Zielsystem gestört, so sollte man geduldig sein, denn das Problem ist selten einfach einzugrenzen und zu beheben. Mit Hilfe des unten erwähnten „traceroute“ kann man versuchen, eine Indikation der Fehlerstelle zu erhalten, da hier angezeigt wird, welchen Weg Pakete nehmen und ab wo keine Rückantwort mehr erfolgt. Dies kann jedoch auch andere Ursachen haben.
  • Das Zielnetz oder der Zielserver sind gestört. Hierzu muss man eigentlich nichts mehr sagen, denn logischerweise können die gleichen Probleme wie eingangs genannt auch beim Zielserver auftreten. Kann man dies feststellen, so sollte man den Betreiber des Zielservers informieren.
  • Schließlich gibt es noch die Möglichkeit, daß die IP-Adresse, die man von seinem eigenen ISP zugewiesen bekam, aus einem auf dem Zielserver gesperrten IP-Adressbereich stammt. Manche Websites verwenden sogenannte Bogonlisten, um SPAM oder getürkte IP-Adressen vom eigenen Site fernzuhalten. Wechseln diese IP-Adressbereiche den Besitzer und werden sie beispielsweise einem großen ISP zugewiesen, so führt dies zu Nichterreichbarkeit. Hier muss man den Betreiber des Zielservers informieren.

Fehler, die systematisch auftreten, lassen sich reproduzieren und auch einfacher diagnostizieren. In erster Linie geht es bei der Fehleranalyse also darum, die Reproduzierbarkeit herzustellen und die Bestimmung der Art des Fehlers durchzuführen. Aussagen in der Art „mein Internet geht nicht“ sind nicht geeignet, irgendeine Massnahme einzuleiten und helfen daher weder in Foren, noch mit Hotlines weiter.

Werkzeuge

Zum Testen gibt es eine Reihe von Werkzeugen unter Windows und Unix, mit deren Hilfe man Verbindungen oder Dienste testen kann:

  • ping - sendet ein Paket zu einem anderen System und erhält ein Echo zurück. Manche Router blockieren allerdings diese Pakete und Websites etc. können durch Firewalls so isoliert werden, daß sie das Echopaket nicht zurücksenden.
  • traceroute - (tracert unter Windows) sendet Pakete mit unterschiedlichen TTL-Werten (Time-to-Live, eine Angabe, wieviele Router maximal auf dem Weg zum Ziel durchlaufen werden dürfen) an ein System und erhält Antwortpakete zurück, die von den jeweiligen Routern auf dem Weg zum Ziel kommen.
  • nslookup - zur Prüfung von DNS-Einträgen, die Namen auf IP-Adressen abbilden.
  • telnet - zur Herstellung einer Verbindung zu einem TCP-Port eines Servers im Internet.

Die folgenden Beispiele gehen davon aus, daß mit einem Website www.beispiel.de ein Problem angenommen wird.

Probleme mit Internetzugang und Rechner ausschliessen

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 wie www.google.de, www.yahoo.de, www.ebay.de, www.amazon.de, www.bund.de 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 www.beispiel.de, so kann ein Problem mit diesem Website vermutet werden.

Lassen sich Websites mit Seiten von z.B. mehr als 1400 Bytes Inhalt nicht aufrufen, jedoch kleine Daten funktionieren (z.B. der Abruf kleiner GIF-Bilder), so kann auch ein MTU-Problem die Ursache dafür sein, daß Pakete ab einer bestimmten Größe nicht korrekt übertragen werden. Hierzu gibt es eine eigene Seite: MTU und RWIN.

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

Test der Konnektivität mit ping

Ist der Website korrekt erreichbar, so sollte die Ausgabe von ping 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 der Website nicht erreichbar oder unterdrückt das Senden von Antworten auf ping (oder ein Router auf dem Weg zum 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.

Netzwerkpfad zum Zielsystem überprüfen

Ist der Website weder per ping, noch per telnet auf den korrekten Port erreichbar, so liegt die Vermutung nahe, daß der 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.

Manuelle Verbindung zum Website herstellen

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.beispien.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.

Weitere Tools

Port Query ist ein weiteres Tool zum gezielten Test von Ports unter Windows.

 
internet/unreachable.txt · Zuletzt geändert: 2007/12/31 11:13 von gandalf94305
 
Impressum
Recent changes RSS feed Creative Commons License Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki