DNS problem?

[zero0109]

Ich habe mir hier Debian Sarge installiert, und es geht eigentlich auch alles wunderbar. Auch der Internet Zugang über meinen Router läuft problemlos. Nur die seite www.google.de lässt sich nicht aufrufen. Ich vermute, dass es was mit der Namensauflösung zu tun hat. Komisch ist nur, dass alle anderen Seiten prima laufen. Es steht dann immer ewig da resolving host www.google.de, bis die Sache halt dann abgebrochen wird. Das selbe Problem habe ich übrigends bei people.icq.com bemerkt, obwohl icq.com problemlos läuft.

 

[oc2pus]

das sieht ganz nach einem MSS Clamping Problem aus:

http://lartc.org/howto/lartc.cookbook.mtu-mss.html

oder hier die Lösung:
http://www.linux-club.de/viewtopic.php?t=11549&highlight=

 

[zero0109]

So ich hab jetzt alles mögliche durchprobiert, und es hat nichts gebracht. Es ist echt ein wenig nervig, denn jede 5. Seite lässt sich nicht abrufen. Kann das nicht auch noch an was anderem liegen?

 

[oc2pus]

jaaa

dann greifen wir mal in die Kiste:

A) welcher Browser?
Mozilla bzw Firebird, dazu gibt es einen Artikel in der SDB. Das hat was mit ipv6 zu tun, das muss dann in der /etc/modules.conf deaktiviert werden.

B) DNS Einstellungen
da gibt es auch schon ein paar Tips im Forum.

da du dich auch in dem anderen Thread getümmelt hast, gehe ich davon aus, das du schon kleinere MTU ausprobiert hast ?

 

[oc2pus]

du kannst auch mal probieren:

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

zum testen:
www.postbank.de oder z.B. www.mediamarkt.de

 

[oc2pus]

zur weiteren Problemeingrenzung aus der SuSE SDB:

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