Internetverbindung: Manche Webseiten lassen sich nicht aufrufen

Supportdatenbank (cg_internet)
Bezieht sich auf

Kernel: Versionen ab 2.4.0

Symptom

Die Internet Einwahl funktioniert prinzipiell und Sie können viele Webseiten anschauen und andere Internetdienste nutzen. Zu manchen Servern können Sie aber partout keine Verbindung aufbauen. "Übliche" Verdächtige sind z.B. www.postbank.de oder z.B. www.mediamarkt.de. Wenn Sie einen Webproxy verwenden können Sie die Seiten aber wieder betrachten. Versuchen Sie aber beispielsweise im Falle der Postbank das Onlinebanking oder andere Webseiten die https verwenden aufzurufen bleibt die Verbindung wieder hängen.

Ursache

Dieses Phänomen kann zwei verschiedene Ursachen haben. Hier soll Ihnen gezeigt werden wie Sie den Fehler untersuchen und beheben können.

  1. ICMP Pakete des Path MTU discovery kommen nicht beim entfernten Server an. Dies ist inklusive Fehlerbehebung im SDB Artikel "T-DSL (u.a.): Manche Server sind nicht erreichbar" (http://sdb.suse.de/de/sdb/html/cg_pmtu2.html) beschrieben.
  2. Sie haben die standardmässig abgeschaltete TCP-option "ECN" - Explicit congestion notification aktiviert.

Der 1. Fehler tritt überwiegend in Verbindung mit T-DSL oder anderen ADSL Anbietern auf die PPPoE als Protokoll einsetzen. Bei diesen Anbietern ist die zulässige Paketgröße eines Datenpaketes nicht mehr 1500 Byte sondern nur noch 1492 Byte da der PPPOE Header insgesamt 6+2 Byte verbraucht.

Der 2. Fehler tritt auf, wenn Sie die Option DISABLE_ECN in der Datei /etc/rc.config auf "no" gestellt haben. Dies geschieht nur wenn Sie diese Einstellung manuell geändert haben, da nach der Installation diese Einstellung auf "yes" steht. Üblicherweise ist "ECN" damit deaktiviert. Eine detaillierte technische Beschreibung was ECN ist finden Sie im RFC 2481.

Lösung

Die Lösung zu Punkt 1 finden Sie erschöpfend im Artikel "T-DSL (u.a.): Manche Server sind nicht erreichbar" (http://sdb.suse.de/de/sdb/html/cg_pmtu2.html) behandelt.

Die Lösung zu Punkt 2 ist ebenfalls einfach. Geben Sie bitte folgendes Kommando ein:

echo "0" > /proc/sys/net/ipv4/tcp_ecn

Damit ist ECN deaktiviert. Wenn Sie nun probieren den Server zu erreichen so sollte dies sofort funktionieren. Damit diese Einstellung auch nach dem reboot aktiviert ist verändern Sie /etc/rc.config bitte folgendermassen:

Suchen Sie nach

DISABLE_ECN="no"

setzen Sie stattdessen ein

DISABLE_ECN="yes"

Problemuntersuchung/Hintergrundinformationen

Sie können den Fehler auch mit den Kommandos tcpdump und lynx (Beide Serie n) genauer untersuchen und voneinander unterscheiden.

Geben Sie hierzu in einem xterm oder auf der Console das folgende Kommando ein

tcpdump -p -i any port 80

Damit werden die Datenpakete einer Webanfrage die Sie über eine beliebige Netzwerkschnittstelle herausschicken auf dem Bildschirm ausgegeben.

Damit nicht zuviel auf einmal passiert verwenden Sie für die Testanfrage am besten den Consolen-Webbroswer lynx. Geben Sie in einer zweiten Console z.B. folgendes ein:

unset http_proxy
lynx http://www.postbank.de/

Hier steht www.postbank.de für den zu untersuchenden Web-Server.

Beispiel 1: ECN aktiv

Wenn Sie ECN aktiviert haben und Sie den Server (Hier im Beispiel www.mediamarkt.de) nicht erreichen können wird die Ausgabe von tcpdump auf dem Bildschirm ungefähr wie folgt aussehen.

11:11:03.624736 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 492568 0,nop,wscale 0> (DF)
11:11:06.624765 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 492868 0,nop,wscale 0> (DF)
11:11:12.624823 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 493468 0,nop,wscale 0> (DF)
11:11:24.624939 babbage.suse.de.33045 > 62.26.5.66.http: S [ECN-Echo,CWR] 304018638:304018638(0) win 5840 <mss 1460,sackOK,timestamp 494668 0,nop,wscale 0> (DF)

Symptom: Wie Sie sehen kommt vom entfernten Server überhaupt keine Antwort. Ihr Rechner versucht immer wieder in wachsenden Abständen eine Verbindung aufzubauen (Das sehen Sie an dem oben dick hervorgehobenen S) bekommt aber keine Antwort. Zusätzlich ist ECN aktiviert (Das sehen Sie an [ECN-Echo,CWR]).

Workaround-Lösung: Schalten Sie ECN wie oben beschrieben ab.

Eigentliche Fehlerursache: Entweder eine falsch konfigurierte Firewall oder ein Betriebssystem das die ECN Option nicht versteht und (fehlerhaft) die Pakete verwirft.

Beispiel 2: PMTU Problem

Starten Sie die beiden Programme wieder wie oben. Beobachten Sie die Ausgaben von tcpdump:

11:21:05.943114 Plato.suse.de.3874 > www.postbank.de.http: S 933875796:933875796(0) win 32120 <mss 1460,sackOK,timestamp 1892930261 0,nop,wscale 0> (DF)
11:21:06.088764 www.postbank.de.http > Plato.suse.de.3874: S 3593485934:3593485934(0) ack 933875797 win 10136 <nop,nop,timestamp 422243768 1892930261,nop,wscale 0,nop,nop,sackOK,mss 1460> (DF)
11:21:06.088832 Plato.suse.de.3874 > www.postbank.de.http: . 1:1(0) ack 1 win 32120 <nop,nop,timestamp 1892930276 422243768> (DF)
11:21:06.090514 Plato.suse.de.3874 > www.postbank.de.http: P 1:927(926) ack 1 win 32120 <nop,nop,timestamp 1892930276 422243768> (DF)
11:21:06.264159 www.postbank.de.http > Plato.suse.de.3874: . 1:1(0) ack 927 win 9210 <nop,nop,timestamp 422243782 1892930276> (DF)

Symptom: Wie Sie im Unterschied zum obigen Beispiel sehen können wird hier zwischen beiden Rechnern die Verbindung richtig aufgebaut. Beide Rechner haben erfolgreich "Synchronisationspakete" (Die Pakete mit dem hervorgehobenen S) ausgetauscht. Es wurden sogar richtig Daten übertragen - das sehen Sie an dem Paket mit der eingeklammerten, hervorgehobenen 926. Üblicherweise klappt allerdings nur die Anfrage an den Webserver (hier: www.postbank.de). Nach dem Bestätigungspaket daß die Daten eingetroffen sind "hängt" die Verbindung. Normalerweise würde der Web-Server jetzt die Startseite übertragen. Offensichtlich klappt das aber nicht.

Analyse: Irgendwo auf dem Weg zu Ihnen geht das Paket des Web-Servers verloren. Sehr wahrscheinlich war es zu groß und konnte nicht fragmentiert werden (Das ist durch das "DF" Bit - sehen Sie am Zeilenende - verboten).

Workaround-Lösung: Siehe "T-DSL (u.a.): Manche Server sind nicht erreichbar" (http://sdb.suse.de/de/sdb/html/cg_pmtu2.html)

Eigentliche Fehlerursache: Falsch konfigurierte Firewall auf der Seite des Betreibers des Web-Servers die ICMP Pakete verwirft.


Siehe auch:
o T-DSL (u.a.): Manche Server sind nicht erreichbar

Stichwörter: PMTU, DISCOVERY, INTERNET, ECN

Kategorien: Internet

Feedback willkommen: Send Mail to cg+sdb@suse.de (Geben Sie bitte folgendes Stichwort an: SDB-cg_internet)
SDB-cg_internet, Copyright SuSE Linux AG, Nürnberg, Germany - Version: 19. Nov 2001
SuSE Linux AG - Zuletzt generiert: 16. Jan 2003 von cg (sdb_gen 1.40.0)