Internetverbindungsprobleme - IPv6 MTU DNS

Autor: Martin Breidenbach

Zunächst einmal muss geklärt werden:

ist die Datentransferrate niedrig (z.B. bei Downloads) oder dauert es ewig bis z.B. im Mozilla eine Seite aufgebaut wird? Oder lassen sich bestimmte Seiten einfach nicht aufrufen?

Es gibt drei Standardursachen für dieses "Problem" (nicht notwendigerweise in dieser Reihenfolge):

• ungewollte Verwendung von IPv6
• Multicast DNS/Zeroconf
• MTU/MSS-Probleme mit Routern
• ungelöste DNS-Probleme bei Routern

Ihr solltet keineswegs einfach mal alles so abändern wie hier beschrieben. Es geht hier darum, einen Fehler einzukreisen und zu umgehen. Ein 'korrekt' arbeitendes System wird hierdurch nicht schneller.

IPv6

IPv4 verwendet vier Bytes zur Adressierung von Rechnern. Durch das rasante Anwachsen des Internets besteht das Problem der zunehmenden Adressknappheit. Im Nachfolger IPv6 werden für die Adressierung 16 Bytes verwendet. Details: http://de.wikipedia.org/wiki/IPv6 .

Viele Programme versuchen, sich bevorzugt mit einer IPv6-Adresse zu verbinden. Erst wenn dies fehlschlägt (nach einem Timeout) oder es keine IPv6-Adresse zu einem Hostnamen gibt, wird IPv4 verwendet.

Sofern auf dem betroffenem Rechner nicht explizit eine IPv6-Adresse und -Routen konfiguriert wurden, gibt es nur die vom Linuxkernel automatisch angelegte Link Local-Adresse (fe80::... wenn man /sbin/ip a eingibt) und fe80::-Routen. Es fehlen 'normale' Routen und Standardgateway, sodass jeder Versuch, sich mit einer "dem Internet zugewiesenen" IPv6-Adresse zu verbinden (z.B. 2001::1), sofort scheitert und IPv6 somit eigentlich keine Ursache für einen langsamen Verbindungsaufbau sein kann.

Um dies zu überprüfen, kann man folgendes in einer Konsole eingeben:

ip r g 2001::1

Erhält man

unreachable 2001::1 from :: dev lo  table unspec  proto none  src ::1  metric -1  error -101 hoplimit 255

Error 101 steht für "Network unreachable", d.h. das Zielnetzwerk in dem sich 2001::1 befindet, ist nicht erreichbar. Die meisten Programme - bzw. wird es sogar die zentrale glibc-Bibliothek sein die das intern behandelt - versuchen somit gar nicht erst, sich mit IPv6 zu verbinden, oder machen es zumindest ohne es dem Benutzer zu sagen, wie in diesem Test:

$ telnet netfilter.org 80
Trying 213.95.27.115...
Connected to netfilter.org.
Escape character is '^]'.
^]
telnet> Connection closed.

(^] ist Strg-].) netfilter.org hat sowohl eine IPv4- als auch eine IPv6-Adresse. Gibt es eine passende IPv6-Route, sähe die Ausgabe wie folgt aus:

$ telnet netfilter.org 80
Trying 2001:780:45:1d:20d:93ff:fe9b:e443...

und bleibt dort für weniger als 10 Sekunden stehen, da mein Router auf IPv6 nicht reagiert. Wenn der Zielrechner nicht antwortet, kommt dann

telnet: connect to address 2001:780:45:1d:20d:93ff:fe9b:e443: No route to host
Trying 213.95.27.115...
Connected to netfilter.org.
Escape character is '^]'.

Wie aber oben beschrieben sollte man eigentlich keine IPv6-Route ins Internet haben, wenn es nicht explizit konfiguriert ist - und explizit konfigurieren tut man nur dann, wenn man genau weiß, dass sowohl Router als auch Internetanbieter IPv6 vollständig unterstützen. Sollte der Router IPv6 unterstützen, der Internetanbieter aber nicht, sollte auch ein "Network unreachable" zurückkommen (diesmal vom Router).

MDNS und Firewall

Im SUSE-Supportdatenbankartikel http://portal.suse.com/sdb/de/2003/10/90_mozilla_ipv6.html wird beschrieben, dass IPv6 und/oder DNS von SuSEfirewall2 blockiert wird.

Der Artikel ist ziemlich zweideutig! -Anm.v.~~

Daher ein paar alternative Erklärungsversuche. Wenn in /etc/resolv.conf keine IPv6-Adressen stehen, wird auch kein IPv6 zur Kontaktierung des DNS-Servers verwendet. Selbst wenn laut Artikel IPv6 gesperrt ist, würde die Namensauflösung nicht ins leere laufen. Zwar werden in den DNS-Antworten auch generell IPv6-Adressen mit zurückgegeben, diese aber entsprechend der vorigen Sektion bei Fehlen einer Route nicht verwendet.

Allein Multicast DNS würde mir im Moment einfallen das zu Timeouts führen könnte, wenn es keinen MDNS-Server gibt, der antworten könnte. Hier kann man versuchen, die Zeroconf-Komponenten zu deaktivieren:

/etc/init.d/avahi-dnsconfd stop
/etc/init.d/avahi-daemon stop

Läuft danach der Internetzugriff mit gewohnten Tempo, sind diese Änderung evtl. permanent zu machen (mittels chkconfig oder insserv), sofern man nicht auf Zeroconf angewiesen ist.

(SUSE 9.x: Alternativ steht über das Online-Update mittlerweile eine modifizierte Version der SuSEfirewall2 zur Verfügung, die die nötigen Pakete auf dem lokalen Rechner nicht mehr blockiert.)

IPv6 deaktivieren

global (Kernelebene)

Möchte man dennoch IPv6 deaktivieren, so kann man dies über YaST bewerkstelligen, oder manuell in /etc/modprobe.d/ipv6 nachtragen. Dort steht meistens schon

#install ipv6 /bin/true

Um IPv6 zu deaktivieren, ist das # zu entfernen sodass nicht ipv6 geladen wird, sondern der Befehl /bin/true ausgeführt wird (der nichts tut).

Konqueror

wbast hat folgendes geschrieben: Ich habe jetzt heraus gekriegt woran das lag. Und zwar versuchte bei mir der Konqueror(und nur der) IPv6-Adressen aufzulösen. Das habe ich im abgewöhnt mit einem

export KDE_NO_IPV6=1

in der ~/.bashrc gelöst.

Firefox

geko hat folgendes geschrieben: Firefox aufrufen und in Adresszeile about:config eingeben. Folgenden Wert suchen:

network.dns.disableIPv6  Standard  boolean   false

Durch anklicken ändern in:

network.dns.disableIPv6  vom Ben..  boolean   true

Noch kurz Firefox neustarten!

MTU

ADSL verwendet hierzulande in der Regel das PPPoE-Protokoll. PPP dient zur Einwahl in TCP/IP-Netze und wird auch Einwahl über Analog-Modem oder ISDN verwendet. Bei PPPoE wird PPP lediglich über Ethernet statt der Telefonleitung gesendet.

Ethernetpakete haben eine maximale Nutzlast von 1500 Bytes, die für IP zur Verfügung stehen (alternativ 9000 Byte "Jumboframes" bei Gigabit); diesen Wert nennt man MTU, Maximal Transmission Unit. Kommt nun aber noch die zusätzliche PPP-Paketierung dazu, so reduziert sich dieser Wert um 8, lässt also 1492 nutzbare Bytes für IP. Siehe hierzu auch http://de.wikipedia.org/wiki/Maximum_Transmission_Unit .

Dies gilt nicht nur für PPP, sondern generell bei allen Verkapselungen, also auch OpenVPN, IPsec, GRE und IP-in-IP.

Die Path MTU wird generell automatisch gefunden, es muss aber sichergestellt sein, dass ICMP von Firewalls nicht blockiert wird. Auch wenn die eigene Firewall ICMP erlaubt, können falsch konfigurierte Firewalls der Seitenbetreiber auf der Gegenseite für Probleme sorgen.

Die Einstellung für die MTU befinden sich bei SuSE 9.1 tief versteckt im YaST in den Experteneinstellungen zur Netzwerkkarte:

YaST2 - Netzwerkgeräte - Netzwerkkarte - ändern - Karte auswählen - Erweitert - Besondere Einstellungen - MTU

Man kann auch als root die zugehörige Konfigurationsdatei in /etc/sysconfig/network/ifcfg-XXX selbst bearbeiten (XXX entsprechend ersetzen). Da drin kann man eine Zeile 'MTU=' anlegen oder bearbeiten. Hier ein Beispiel:

BOOTPROTO='static'
IPADDR='192.168.1.70/24'
MTU='1492'
STARTMODE='onboot'
UNIQUE='7EWs.weGuQ9ywYPF'
_nm_name='bus-pci-0000:00:11.0'

MSS

Wenn man einen eigenen Linux-basierten DSL-Router hat, dann besteht die Möglichkeit daß dieser via iptables die Datenpakete (nur TCP!) an die MTU des eingehenden und ausgehenden Interfaces anpaßt. Dazu muß das Firewallskript um folgende Zeile erweitert werden:

iptables -t mangle -A FORWARD -p tcp --syn -j TCPMSS --clamp-mss-to-pmtu

MSS, die Maximum Segment Size, beschreibt die maximale Nutzlast von TCP-Paketen, also in der Regel MTU minus IPv4-Header (20 Bytes) oder IPv6-Header (40 Bytes) minus TCP-Header (typischerweise 20 Bytes).

Weitere Infos zum Thema 'MTU' gibt es hier

Ermitteln des optimalen MTU Wertes:

• http://www.gschwarz.de/mtu-wert.htm

Internetverbindung: Manche Webseiten lassen sich nicht aufrufen: http://portal.suse.de/sdb/de/2001/11/cg_internet.html

MTU optimieren:

• http://gw.renner.bei.t-online.de/windowsxp/mtu.htm

MTU-Mini-FAQ (für xDSL-Zugänge über PPPoE)

• http://www.sauff.com/dsl-faq/mtu-mini-faq.html

Lexikonbeschreibung MTU

• http://de.wikipedia.org/wiki/Maximum_Transfer_Unit

DNS-Probleme bei Routern

Es hat sich gezeigt dass manche DSL-Router Probleme mit der DNS-Weiterleitung haben. Der DSL-Router bekommt in der Regel bei der Einwahl über PPP die Adresse eines oder mehrerer DNS-Servers des Providers mitgeteilt. Client-PCs wiederum verwenden dann als DNS-Server die IP-Adresse des DSL-Routers. Der DSL-Router soll DNS-Anfragen von Clients an den DNS-Server des Providers weiterleiten und ebenso die Antwort an den Client weiterreichen. Aus irgendwelchen, mir unbekannten Gründen hakt es dabei immer wieder. Die Symptome sind nicht eindeutig - mal gehts, mal nicht, mal gehen bestimmte Seiten, aber andere nicht. Es wurde auch schon mehrfach berichtet, dass es unter Windows funktioniert, unter Linux aber nicht. Ich habe schon mal mit einem Firmwareupdate des DSL-Routers Besserung erzielen können. Eine Alternative ist es das Problem einfach zu umgehen und die Adresse eines DNS-Servers des Providers direkt beim Client einzutragen. Das stellt dann ein Problem dar, wenn der Provider den DNS auf einen anderen Server umzieht oder bei mehreren DNS-Servern einer ausfällt. Da viele T-DSL über T-Online verwenden hier ein Link mit Adressen mehrerer DNS-Server von T-Online:

• http://atelier89.de/users/dirk/t-o/010.html

Bei meinem DSL-Router kann man im Webinterface nachsehen, welche DNS-Server er momentan benutzt. Der DNS-Server lässt sich auch so einstellen:

yast2 - Netzwerkdienste - DNS- und Hostname

nsswitch.conf

/etc/nsswitch.conf kann dazu führen, dass DNS zur Namensauflösung gar nicht verwendet wird. Deshalb sicherheitshalber die Zeile 'hosts:' überprüfen. Eine i.A. funktionierende Variante ist:

hosts: files dns

Hinweise von Usern

Dieses HOWTO zu Linux oder der Abschnitt davon braucht eine Überarbeitung. Weitere Informationen findest Du hier. Deine Hilfe ist gefragt, das HOWTO zu verbessern. Danach entsorge bitte diese Signierung.

Google dauert zu lange

ich schaute mir alle confs an die dafür zuständig sein könnten. am ende war ich in der /etc/sysconfig/network/config da gibt es ein eintrag der folgend heißt MODIFY_NAMED_CONF_DYNAMICALLY="no" war ganz erstaunt auf no

also habe ich den eintrag auf yes gestzt mein dns neugestarte und mich neu eingewählt und es funktioniert

Das dürfte der Eintrag sein der dafür zuständig ist bei Einwahl über DHCP auch den DNS-Server zu ändern.

upstream erhöhen

mir hat folgender Tip, den ich in einem anderen Forum gefunden Habe geholfen In der Datei /etc/sysconfig/SuSEfirewall folgende Zeile

FW_HTB_TUNE_DEV=""

ändern in

FW_HTB_TUNE_DEV="eth0,380"

Dadurch wird anscheinend der upstream erhöht. Seitdem rennt meine Internet Verbindung nur noch .

Hi,

bei mir bremste dieser Tip eher. ich bin mit einem analogen Modem unterwegs, weil wir kein DSL bekommen. (Ich wohne nicht am A..... der Welt, aber vom Balkon aus kann ich ihn sehen. )

Dieser Tip gilt für ein analoges " FaxModem V.92 56k" unter Suse 8.2. Mein Modem läuft unter "ppp0". Dann erhöht man die dort eingestellte Baudrate auf 115200.

Dann habe ich in der Datei /etc/sysconfig/SuSEfirewall2 folgende Zeile

FW_HTB_TUNE_DEV=""

geändert in:

FW_HTB_TUNE_DEV="ppp0,100"

In verschiedenen Beiträgen im Internet stand, man soll etwas unter der maximalen Baudrate bleiben. Also hier 100 und nicht 115(200). Mal schauen, was man noch mit anderen Tricks rausholen kann.

Manche Website erscheint nicht (insbesondere ebay)

ipv6 NICHT auf true setzten. Das sollte aus sein. Also FALSE.

• http://www.tecchannel.de/netzwerk/extra/402394/

Dort gibt es noch eine weiterführende Diskussion, die habe ich nicht eingearbeitet: http://www.linux-club.de/ftopic16677.html

---

zurück zum Netzwerk