Internetverbindungsprobleme - IPv6 MTU DNS: Unterschied zwischen den Versionen

Aus Linupedia.org
Wechseln zu: Navigation, Suche
(Anmerkung)
K (interne Verlinkung)
 
(3 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt)
Zeile 5: Zeile 5:
 
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?
 
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):
+
Es gibt drei Standardursachen für dieses "Problem" (nicht notwendigerweise in dieser Reihenfolge):
  
# TCP/IP v6 (abschalten)
+
* ungewollte Verwendung von IPv6
# bei DSL ist die MTU zu groß
+
* Multicast DNS/Zeroconf
# Probleme mit dem DNS
+
* 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.
+
Ihr solltet keineswegs einfach mal alles so abändern wie hier beschrieben. Es geht hier darum, einen Fehler einzukreisen und zu umgehen. Dazu werden verschiedene Ansätze beschrieben, welche man ausprobieren kann (idealerweise in der Reihenfolge wie sie gleich erscheinen).
  
Der Reihe nach:
+
Ein 'korrekt' arbeitendes System wird hierdurch nicht schneller.
  
 +
== IPv6 ==
  
== IPv6 abschalten ==
+
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.
  
TCP/IP verwendet vier Bytes zur Adressierung von Rechnern. Durch das rasante Anwachsen des Internets besteht das Problem, dass so langsam die Adressen ausgehen.
+
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 (<code>fe80::...</code> wenn man <code>/sbin/ip a</code> eingibt) und <code>fe80::</code>-Routen. Es fehlen 'normale' Routen und Standardgateway, sodass jeder Versuch, sich mit einer für das Internet zugewiesenen IPv6-Adresse zu verbinden (z.B. <code>2001::1</code>), sofort scheitert und IPv6 somit eigentlich keine Ursache für einen langsamen Verbindungsaufbau sein kann.
  
Deswegen hat man einen Nachfolger definiert, der 16 statt 4 Bytes für die Adressierung verwendet.
+
Um dies zu überprüfen, kann man folgendes in einer Konsole eingeben:
  
Details: http://de.wikipedia.org/wiki/Ipv6
+
ip r g 2001::1
  
Wenn ipv6 aktiviert ist, passiert es, dass Linux zuerst versucht, ipv6 und dann das 'gute alte' ipv4 (([[TCP/IP-Referenzmodell|TCP/IP]])) zu benutzen. Da ipv6 momentan im Internet noch nicht flächendeckend benutzt wird, kann man es auf dem Client abschalten.
+
Erhält man
  
Wie man ipv6 abschaltet, steht in diesem Artikel der SuSE Supportdatenbank:
+
'''unreachable''' 2001::1 from :: dev lo  table unspec  proto none  src ::1  metric -1  '''error -101''' hoplimit 255
  
http://portal.suse.com/sdb/de/2003/10/90_mozilla_ipv6.html
+
Error 101 steht für "Network unreachable", d.h. das Zielnetzwerk in dem sich 2001::1 befindet, ist nicht erreichbar. Die meisten Programme&nbsp;- bzw. wird es sogar die zentrale glibc-Bibliothek sein, die das intern behandelt&nbsp;- versuchen somit gar nicht erst, sich mit IPv6 zu verbinden, oder machen es zumindest ohne es dem Benutzer zu sagen, wie der folgende Test zeigt:
  
Zitat:
+
$ '''telnet netfilter.org 80'''
Symptom
+
Trying 213.95.27.115...
 +
Connected to netfilter.org.
 +
Escape character is '^]'.
 +
''^]''
 +
telnet> Connection closed.
  
Sobald sie irgendetwas in die Mozilla URL-Leiste eingeben friert Mozilla ein.
+
(''^]'' ist <code>Strg</code>-<code>]</code>.) <code>netfilter.org</code> hat sowohl eine IPv4- als auch eine IPv6-Adresse. Gibt es eine passende IPv6-Route, sähe die Ausgabe wie folgt aus:
  
Ursache:
+
$ '''telnet netfilter.org 80'''
 +
Trying 2001:780:45:1d:20d:93ff:fe9b:e443...
  
Mozilla versucht Namensauflösung zuerst über IPv6. Wenn Sie SuSEfirewall2 benutzen, ist IPv6 allerdings komplett gesperrt. Deswegen läuft die Abfrage ins Leere und wartet auf einen Timeout von ca. 60 Sekunden.
+
und bleibt dort für weniger als 10 Sekunden stehen, da mein Router nicht auf IPv6 reagiert. Wenn der Zielrechner nicht antwortet, kommt dann
  
Lösung:
+
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 '^]'.
  
Sie können, wenn Sie ihn nicht benötigen, den IPv6 Support komplett abschalten.
+
Wie aber oben beschrieben sollte man eigentlich keine IPv6-Route ins Internet haben, wenn es nicht explizit konfiguriert ist&nbsp;- 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).
  
Für SUSE Linux 9.0 können Sie dies tun Sie, indem Sie folgende Zeilen in der Datei /etc/modules.conf ändern.
+
== MDNS und Firewall ==
  
<nowiki>alias net-pf-10 ipv6
+
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.
#alias net-pf-10 off</nowiki>
 
  
nach
+
(''Der Artikel ist ziemlich zweideutig! -Anm.v.[[Benutzer:Jengelh|j.engelh]]'')
  
<nowiki>#alias net-pf-10 ipv6
+
Daher ein paar alternative Erklärungsversuche. Wenn in <code>/etc/resolv.conf</code> 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.
alias net-pf-10 off</nowiki>
 
  
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.
+
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:
  
Unter SUSE Linux 9.1 (genauer: mit Kernel 2.6.x) gibt es statt der Datei /etc/modules.conf jetzt die Datei /etc/modprobe.conf.
+
/etc/init.d/avahi-dnsconfd stop
 +
/etc/init.d/avahi-daemon stop
  
Wenn Sie unter SUSE Linux 9.1 IPv6 grundsätzlich deaktivieren möchten, müssen Sie in der Datei /etc/modprobe.conf die folgende Änderung vornehmen:
+
Läuft danach der Internetzugriff mit gewohnten Tempo, sind diese Änderung evtl. permanent zu machen (mittels <code>chkconfig</code> oder <code>insserv</code>), sofern man nicht auf Zeroconf angewiesen ist.
  
alias net-pf-10 ipv6
+
(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.)
  
nach
+
== IPv6 deaktivieren ==
  
alias net-pf-10 ipv6
+
Möchte man dennoch IPv6 global auf Kernelebene deaktivieren, so kann man dies über YaST bewerkstelligen, oder manuell in <code>/etc/modprobe.d/ipv6</code> nachtragen. Dort steht meistens schon
install ipv6 /bin/true
 
  
 +
#install ipv6 /bin/true
  
Weiter unten gibt es noch Hinweise wie man IPv6 für Konqueror und Firefox abschalten kann.
+
Um IPv6 zu deaktivieren, ist das Kommentarzeichen <code>#</code> zu entfernen, sodass beim Versuch, <code>ipv6</code> zu laden stattdessen der Befehl <code>/bin/true</code> ausgeführt wird (der nichts tut).
  
Noch ein Artikel zu dem Thema:
+
Sollte auch dies keine Abhilfe schaffen, so kann man zusätzlich noch spezifisch auf Anwendungsebene Änderungen vornehmen, wie folgend beschrieben.
  
http://support.novell.com/cgi-bin/search/searchtid.cgi?10098152.htm
+
=== Konqueror ===
  
Zitat:
+
User wbast schreibt:
The following steps should be followed to disable IPV6 on SuSE Linux Enterprise Server 9:
+
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 i[h]m [mit einem]
  
1- Modify /etc/modprobe.conf.local by adding the following:
+
export KDE_NO_IPV6=1
  
<nowiki>#
+
in der <code>~/.bashrc</code> [abgewöhnt].
# please add local extensions to this file
 
#
 
install ipv6 /bin/true</nowiki>
 
  
2- reboot
+
=== Firefox ===
  
*** In some circumstances, it is also necessary to modify the /etc/modprobe.conf and change the following:
+
User geko schreibt:
 +
Firefox aufrufen und in Adresszeile <code>about:config</code> eingeben. Folgenden Wert suchen:
  
  alias net-pf-10 ipv6
+
  network.dns.disableIPv6  Standard  boolean  false
  
to
+
Durch anklicken ändern in:
  
  alias net-pf-10 off
+
  network.dns.disableIPv6  vom Ben..  boolean  true
  
{{Box Hinweis||
+
Noch kurz [[Firefox]] neustarten!
Das hier für SLES9 beschriebene Verfahren funktioniert auch für SuSE Pro 10 (jedefalls bei mir).
 
}}
 
 
 
== MTU zu gross ==
 
 
 
 
 
MTU und DNS sind Hauptverdächtige wenn sich bestimmte Webseiten nicht aufrufen lassen. Allerdings sind hier die Seitenbetreiber schuld[http://www.phildev.net/mss/].
 
 
 
MTU = Maximum Transfer Unit
 
PPP = Point-to-Point Protocol
 
PPPoE = PPP over Ethernet
 
 
 
DSL verwendet hierzulande in der Regel das PPPoE Protokoll. PPP ist ein Protokoll zur Einwahl in TCP/IP-Netze das z.B. bei der Einwahl über Analog-Modem oder ISDN verwendet wird. PPPoE verwendet das PPP-Protokoll, nur eben über Ethernet und nicht Telefonleitung.
 
  
Das Problem besteht nun darin, dass Ethernet-Pakete eine maximale Paketgröße haben. Wenn man nun ein Ethernet-Paket in ein PPP-Paket verpackt und das wiederum in ein Ethernet-Paket steckt (so wie das bei PPPoE geschieht) dann wird der maximal nutzbare Teil des Paketes kleiner. Und dieser ist die MTU.
+
== MTU ==
  
Eigentlich sollte das automatisch umgesetzt werden und ein zu großes Paket gesplittet werden. Da das nicht immer so funktioniert kann man das Problem umgehen indem man auf dem Client die MTU kleiner macht.
+
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.
  
Ein guter Wert für T-DSL ist 1492 bytes.
+
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 .
  
Die Einstellung für die MTU befinden sich bei SuSE 9.1 tief versteckt im Yast2 in den Experteneinstellungen zur Netzwerkkarte:
+
Dies gilt nicht nur für PPP, sondern generell auch bei allen Verkapselungen, also OpenVPN, IPsec, GRE, IP-in-IP, usw.
  
yast2- Netzwerkgeraete - Netzwerkkarte - ändern - Karte auswählen - Erweitert - Besondere Einstellungen - MTU
+
Die Path MTU wird üblicherweise automatisch gefunden ("PMTU Discovery"), es muss aber sichergestellt sein, dass ICMP von Firewalls '''nicht''' blockiert wird. Damit ist nicht ICMP "ping" gemeint, sondern ICMP mit "fragmentation-needed" als Code. Auch wenn die eigene Firewall ICMP erlaubt, können falsch konfigurierte Firewalls der Seitenbetreiber für Probleme sorgen.
  
Man kann aber auch (als root) die zugehörige Konfigurationsdatei in <code>/etc/sysconfig/network</code> selbst bearbeiten.
+
Die Einstellung für die MTU befinden sich bei SuSE 9.1 tief versteckt im YaST in den Experteneinstellungen zur Netzwerkkarte:
  
Unter SuSE 9.0 heißen diese <code>/etc/sysconfig/network/ifcfg-ethX</code>, wobei <code>ethX</code> hier als Platzhalter für <code>eth0</code>, <code>eth1</code> und so weiter steht.
+
YaST2 - Netzwerkgeräte - Netzwerkkarte - ändern - Karte auswählen - Erweitert - Besondere Einstellungen - MTU
 
 
Unter SuSE 9.1 heißen die Dateien etwas anders, <code>/etc/sysconfig/network/ifcfg-eth-id-00:00:39:c8:91:88</code> oder ähnlich. Hier wird die MAC-Adresse der Netzwerkkarte zur Identifikation verwendet.
 
 
 
Da drin gibt es eine Zeile 'MTU='.
 
 
 
Hier ein Beispiel:
 
  
 +
Man kann auch als root die zugehörige Konfigurationsdatei in <code>/etc/sysconfig/network/ifcfg-''XXX''</code> selbst bearbeiten (''<code>XXX</code>'' entsprechend ersetzen). Da drin kann man eine Zeile '<code>MTU=</code>' anlegen oder bearbeiten. Hier ein Beispiel:
  
 
  BOOTPROTO='static'
 
  BOOTPROTO='static'
BROADCAST='192.168.1.255'
+
  IPADDR='192.168.1.70/24'
  IPADDR='192.168.1.70'
 
 
  MTU='1492'
 
  MTU='1492'
NETMASK='255.255.255.0'
 
NETWORK='192.168.1.0'
 
REMOTE_IPADDR=''
 
 
  STARTMODE='onboot'
 
  STARTMODE='onboot'
 
  UNIQUE='7EWs.weGuQ9ywYPF'
 
  UNIQUE='7EWs.weGuQ9ywYPF'
 
  _nm_name='bus-pci-0000:00:11.0'
 
  _nm_name='bus-pci-0000:00:11.0'
  
 +
== MSS (Maximum Segment Size) ==
  
 +
Wenn man einen eigenen Linux-basierten DSL-Router hat, dann besteht die Möglichkeit, dass dieser via [[iptables]] die Datenpakete (nur TCP!) an die MTU des eingehenden und ausgehenden Interfaces anpasst. Dazu muss das Firewallskript um folgende Zeile erweitert werden:
  
Wenn man einen eigenen linuxbasierten DSL-Router hat dann besteht die Möglichkeit daß dieser via iptables die Datenpakete an die MTU anpaßt. Dazu muß das Firewallskript erweitert werden um folgende Zeile:
+
  iptables -t mangle -A FORWARD -p tcp --syn -j TCPMSS --clamp-mss-to-pmtu
 
 
 
 
  iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
 
 
 
 
 
 
 
 
 
=== Weitere Infos zum Thema 'MTU' gibt es hier ===
 
  
 +
== Weitere Infos zum Thema 'MTU' gibt es hier ==
  
 
Ermitteln des optimalen MTU Wertes:
 
Ermitteln des optimalen MTU Wertes:
Zeile 169: Zeile 150:
 
* http://de.wikipedia.org/wiki/Maximum_Transfer_Unit
 
* http://de.wikipedia.org/wiki/Maximum_Transfer_Unit
  
== DNS-Probleme ==
+
== 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:
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 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
 
* 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:
 
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
 
  
 +
yast2 - Netzwerkdienste - DNS- und Hostname
  
== Ein Fehler in der Datei ==
+
== nsswitch.conf ==
<code>/etc/nsswitch.conf</code> 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:
+
 
 +
<code>/etc/nsswitch.conf</code> 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
 
  hosts: files dns
  
== IPv6 für Konqueror abschalten ==
+
== Hinweise von Usern ==
 
 
 
 
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
 
 
 
== IPv6 für Firefox abschalten ==
 
 
 
 
 
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!
 
  
== Anmerkung ==
 
 
{{Überarbeiten}}
 
{{Überarbeiten}}
  
== Google dauert zu lange ==
+
=== Google dauert zu lange ===
  
 
ich schaute mir alle confs an die dafür zuständig sein könnten.  
 
ich schaute mir alle confs an die dafür zuständig sein könnten.  
Zeile 239: Zeile 183:
  
  
== upstream erhöhen ==
+
=== upstream erhöhen ===
  
 
mir hat folgender Tip, den ich in einem anderen Forum gefunden Habe geholfen  
 
mir hat folgender Tip, den ich in einem anderen Forum gefunden Habe geholfen  
Zeile 272: Zeile 216:
  
  
== Manche Website erscheint nicht (insbesondere ebay) ==
+
=== Manche Website erscheint nicht (insbesondere ebay) ===
  
 
ipv6 NICHT auf true setzten. Das sollte aus sein. Also FALSE.
 
ipv6 NICHT auf true setzten. Das sollte aus sein. Also FALSE.

Aktuelle Version vom 23. November 2013, 15:56 Uhr

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. Dazu werden verschiedene Ansätze beschrieben, welche man ausprobieren kann (idealerweise in der Reihenfolge wie sie gleich erscheinen).

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 für das 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 der folgende Test zeigt:

$ 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 nicht auf IPv6 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.j.engelh)

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

Möchte man dennoch IPv6 global auf Kernelebene 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 Kommentarzeichen # zu entfernen, sodass beim Versuch, ipv6 zu laden stattdessen der Befehl /bin/true ausgeführt wird (der nichts tut).

Sollte auch dies keine Abhilfe schaffen, so kann man zusätzlich noch spezifisch auf Anwendungsebene Änderungen vornehmen, wie folgend beschrieben.

Konqueror

User wbast schreibt: 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 i[h]m [mit einem]

export KDE_NO_IPV6=1

in der ~/.bashrc [abgewöhnt].

Firefox

User geko schreibt: 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 auch bei allen Verkapselungen, also OpenVPN, IPsec, GRE, IP-in-IP, usw.

Die Path MTU wird üblicherweise automatisch gefunden ("PMTU Discovery"), es muss aber sichergestellt sein, dass ICMP von Firewalls nicht blockiert wird. Damit ist nicht ICMP "ping" gemeint, sondern ICMP mit "fragmentation-needed" als Code. Auch wenn die eigene Firewall ICMP erlaubt, können falsch konfigurierte Firewalls der Seitenbetreiber 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 (Maximum Segment Size)

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

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

Weitere Infos zum Thema 'MTU' gibt es hier

Ermitteln des optimalen MTU Wertes:

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

MTU optimieren:

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

Lexikonbeschreibung MTU

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:

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

Höhe=24px
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.

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


zurück zum Netzwerk