Troubleshooting IPv6

Kommentieren Drucken
Teil 5 von 6 aus der Serie "IPv6 Blog"

Die Troubleshooter frohlocken: die Zeiten trister Anwendungsanalysen sind vorbei, endlich wieder echte Protokollanalyse dank IPv6. Gut, das ist jetzt etwas überspitzt, trifft jedoch den Kern. Heute geht man davon aus, dass auch die letzten Fehler aus Treibern und Netzwerkkomponenten verschwunden sind. Ethernet und IP funktionieren auch systemübergreifend zuverlässig. IPv6 jedoch hat diesen Reifegrad noch lange nicht erreicht. Wer das Protokoll einführen will, wird immer wieder auf Probleme stoßen, die einen Protokollanalysator notwendig machen. Beispiele gefällig?


Merkwürdiges Prefix
Ein besonderes Highlight meiner ersten Tests war ein Fehler in der Firmware meines DSL-Routers. Zu der Zeit hatte ich noch keinen IPv6 fähigen Internetzugang und wollte erste Tests auch lieber Inhaus machen. Also generierte ich mir auf der SixXS.net Seite ein ULA-Prefix (fdea:f4b4:58f5::/48) und wollte davon ein /64 Prefix nutzen. Dazu trug ich auf dem DSL-Router ein: fdea:f4b4:58f5::/64. Als ich den Erfolg kontrollieren wollte, sah ich jedoch anderes:

inet6 fd00::bae8:56ff:fe40:9dbe prefixlen 64 autoconf

Also zurück auf die Konfigurationsoberfläche des Routers. Dort stand immer noch das SixXS Prefix. Damit blieb nur der Griff zum Protokollanalysator um heraus zu bekommen, wer spinnt: der Router oder der Rechner. Was ich dort zu sehen bekam, verblüffte mich dann schon ein wenig (vgl. Bild 1).

Im Router Advertisement stand allen ernstes „fd00::“ mit einer Prefix-Länge von /64 als Netzwerkprefix! Nicht nur, dass der Router meinen Eintrag komplett ignorierte, er nahm – zumindest optisch – auch gleich das gesamte ULA-Netz in Beschlag. Den manuell vorgenommenen Eintrag auf meinem NAS System musste ich im Anschluss natürlich auch gleich ändern. Abhilfe brachte erst ein Update der Firmware einige Monate später.

Falscher DHCP Server
Wer mit IPv6 auch ins Internet will, braucht eine Firewall. Viele Anbieter behaupten von sich IPv6 fähig zu sein. Dabei sollte man aber auch lesen können, was nicht geschrieben wird. So lautet der Marketingsatz „wir routen jetzt auch IPv6“ vollständig: „… können es aber noch nicht filtern“. Wenn man dann nach der aufmerksamen Lektüre die Auswahl auf einige Produkte reduziert hat, sollte man auf jeden Fall eigene Tests machen, bevor man sich für ein Produkt entscheidet. In unserem Fall passierte beispielsweise Folgendes:
Zunächst machten wir eine Liste, was die Firewall leisten muss. Ein für uns als Kleinstunternehmen entscheidender Punkt war: sie muss nicht nur Perimeter-Firewall, sondern auch default Gateway sein. Damit kommt ihr die Aufgabe zu, Router Advertisements zu senden. Da wir ein Active Directory betreiben, entschieden wir uns ferner für Stateful DHCP. D.h. die Firewall muss im Router Advertisement das M- und das O-bit auf 1 setzen, damit die Clients ihre IP-Konfiguration vom DHCP Server des AD beziehen. So weit so gut, das machte die Firewall auch. Merkwürdig war allerdings, dass einige Endgeräte auf dem DHCP Server auftauchten, andere hingegen nicht. IPv6 Adressen hatten alle.

Auch hier stellte sich die Frage, wer spinnt: DHCP Server, Firewall oder Endgerät. Letzteres ließ sich eigentlich ausschließen, da identische Betriebssysteme unterschiedliches Verhalten aufwiesen. Also ein Fehler in der Anzeige des DHCP Servers? Nein, mitnichten. Der Sniffer brachte die Wahrheit an den Tag: nicht nur der DHCP Server, sondern auch die Firewall sendete DHCP Advertisements.
Sicher, die Konfiguration dafür hatte ich beim Aufsetzen des Gerätes gesehen, und auch ignoriert. Was ich nicht ahnte war, dass beim Einschalten der RA-Funktion das Gerät automatisch die eigene DHCP Funktion aktivierte, die sich über die Web-Oberfläche auch nicht ausschalten ließ. Zwar konnte man per CLI die Funktion „killen“, jedoch aktivierte sie sich jedes Mal, wenn man auf der Weboberfläche die Seite mit den Router Advertisments auch nur ansah.

In der Road-Map des Herstellers tauchte die Möglichkeit beide Funktionen voneinander zu entkoppeln nicht auf. Es gab lediglich einen Eintrag in der Liste „gewünschter Funktionen“ der Nutzer, die aber kaum Unterstützer hatte. Die Konsequenz für uns war, das Gerät wieder einzupacken und zurück zu schicken.

Falscher Router
In unseren Server-Log-Files tauchten irgendwann Warnmeldungen der Backup-Software auf, mit dem Hinweis, dass es zwischen den Servern keine IPv6 Verbindung gäbe. Genervt von den vielen „sinnlosen“ Meldungen machte sich unser Administrator viel Arbeit, indem er teilweise mittels netsh Befehlen auf den Servern frei erfundene IPv6 Adressen verteilte und den DHCP Server sogar Router Advertisements verteilen ließ. Er war glücklich, weil danach die Warnungen weg und die Log-Files kürzer waren.

Nichts davon ahnend, bemerkte ich, dass es einige wenige Web-Seiten gab, die sich nur sehr langsam bei mir aufbauten. Und mit sehr langsam meine ich, dass sie mehrere Minuten brauchten. Zunächst dachte ich mir nichts dabei: da es nur wenige Seiten waren, vermutete ich den Fehler auf Seiten der Server. Irgendwann aber konnte ich einfach nicht mehr daran glauben, dass Heise so lange braucht, um ihre Serverprobleme zu lösen. Außerdem war ich der einzige Mac User im Unternehmen und der einzige, der dieses Problem hatte. Das legte den Verdacht nahe, dass das Problem bei mir lag. Ich griff zum Wireshark und siehe da: mein Mac bombadierte unseren DHCP Server mit HTTP-Requests.

Was war passiert? Der Mac nahm an, dass unser DHCP Server ein Router sei, schließlich sendete er ja Router Advertisements. Für IPv6 fähige Seiten bekam mein Rechner auch per DNS die IPv6 Adressen genannt, also versuchte er ordnungsgemäß die Verbindung zunächst über IPv6 aufzubauen und erst später über IPv4, wie in Bild 2 dargestellt. Und das versuchte er für jede einzelne TCP Session. Bei Webseiten sind das ziemlich viele (Text, CSS, Bilder…).

Die Windowsrechner hatten dieses Problem nicht, da sie die Router Advertisements nur teilweise aktzeptieren. Sie werteten zwar die Informationen darin aus, wie Prefix-Advertisement, M-/O-Bit etc. Jedoch erkannten sie auch, dass der Server eben kein Router war. Der Mac hingegen ging davon aus, dass jeder, der RA-Pakete sendet, auch ein Router ist, egal, was im Paket selbst steht.

Die Lösung damals war, IPv6 auf Link-Local zu stellen. Das Problem ist allerdings seit geraumer Zeit von Apple gelöst worden und die entsprechenden Infos in den Router Advertisements sollten nun korrekt ausgewertet werden.

Keine Verbindung über GRE
Ein weiteres Beispiel findet sich im Artikel IPv6: Auf die Plätze, fertig, los im Absatz zu DS-Lite. Dieses Beispiel zeigt schön, dass es manchmal nicht möglich ist mit einem Protokollanalysator den Fehler zu finden und auch das Studium der Standards nicht weiterhilft. Nur wenn man die richtige Idee hat, kommt man der Ursache auf die Spur. In diesem Fall war es das Handbuch des NAT-Gateways des Providers.

Fazit

Was lehren diese drei Beispiele:

  1. Es gibt wieder IP-basierte Probleme beim Troubleshooting.
  2. Für die Problemlösung muss man
    • die Grundlagen des Protokolles beherrschen,
    • die Grundlagen der Protokollanalyse beherrschen,
    • wissen, wie man die Standards liest und
    • das Glück haben, auf die richtige Idee zu kommen.

« Teil 4: IPv6 Privacy Extensions bei Ubuntu 12.04 LTSTeil 6: IPv6 – welche Interface-Adresse wird genutzt? »


zugeordnete Kategorien: Data Center, IP und IPv6, IT-Sicherheit, LAN
zugeordnete Tags: , , ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.