Internetverbindungsprobleme - IPv6 MTU DNS: Unterschied zwischen den Versionen
Yehudi (Diskussion | Beiträge) |
Gehrke (Diskussion | Beiträge) K (interne Verlinkung) |
||
| (17 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt) | |||
| Zeile 3: | Zeile 3: | ||
Zunächst einmal muss geklärt werden: | 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 ? | + | 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): |
| − | + | * 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 | + | 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 (<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. | |
| − | + | 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 <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: | |
| − | + | $ '''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.[[Benutzer:Jengelh|j.engelh]]'') | |
| − | + | 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. | |
| − | |||
| − | + | 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 <code>chkconfig</code> oder <code>insserv</code>), 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 <code>/etc/modprobe.d/ipv6</code> nachtragen. Dort steht meistens schon | |
| − | |||
| + | #install ipv6 /bin/true | ||
| − | + | 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). | |
| − | + | 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] | |
| − | 1 | + | export KDE_NO_IPV6=1 |
| − | + | in der <code>~/.bashrc</code> [abgewöhnt]. | |
| − | |||
| − | |||
| − | |||
| − | + | === Firefox === | |
| − | + | User geko schreibt: | |
| + | Firefox aufrufen und in Adresszeile <code>about:config</code> 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 <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' | ||
| − | + | IPADDR='192.168.1.70/24' | |
| − | IPADDR='192.168.1.70' | ||
MTU='1492' | MTU='1492' | ||
| − | |||
| − | |||
| − | |||
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: | ||
| − | + | iptables -t mangle -A FORWARD -p tcp --syn -j TCPMSS --clamp-mss-to-pmtu | |
| − | |||
| − | |||
| − | iptables -A FORWARD -p tcp -- | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | == Weitere Infos zum Thema 'MTU' gibt es hier == | ||
Ermitteln des optimalen MTU Wertes: | Ermitteln des optimalen MTU Wertes: | ||
| − | http://www.gschwarz.de/mtu-wert.htm | + | * http://www.gschwarz.de/mtu-wert.htm |
Internetverbindung: Manche Webseiten lassen sich nicht aufrufen: | Internetverbindung: Manche Webseiten lassen sich nicht aufrufen: | ||
| Zeile 168: | Zeile 142: | ||
MTU optimieren: | MTU optimieren: | ||
| − | http://gw.renner.bei.t-online.de/windowsxp/mtu.htm | + | * http://gw.renner.bei.t-online.de/windowsxp/mtu.htm |
MTU-Mini-FAQ (für xDSL-Zugänge über PPPoE) | MTU-Mini-FAQ (für xDSL-Zugänge über PPPoE) | ||
| − | http://www.sauff.com/dsl-faq/mtu-mini-faq.html | + | * http://www.sauff.com/dsl-faq/mtu-mini-faq.html |
Lexikonbeschreibung MTU | Lexikonbeschreibung MTU | ||
| − | http://de.wikipedia.org/wiki/Maximum_Transfer_Unit | + | * 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 == | |
| − | + | <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 | |
| − | + | == Hinweise von Usern == | |
| − | + | {{Überarbeiten}} | |
| − | + | === 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: | Dort gibt es noch eine weiterführende Diskussion, die habe ich nicht eingearbeitet: | ||
http://www.linux-club.de/ftopic16677.html | http://www.linux-club.de/ftopic16677.html | ||
| − | + | ---- | |
| − | + | ||
| + | [[Netzwerk|zurück zum Netzwerk]][[Category:TCP/IP]] | ||
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.
Inhaltsverzeichnis
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
 |
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
