IPv6/Windows/Teredo
Microsofts Tunnelmechanismus Teredo
Tunnelbroker oder den Provider wechseln? Ein IPv6-Zugang einzurichten, erscheint schwierig. Aktuelle Betriebssystem haben jedoch die Tunneltechnik Teredo an Bord, die sie ins IPv6-Netz bringt und die nur noch in Gang geklickt werden muss.
IPv6 nutzt Adressen mit 128 Bit, räumt durch seinen enormen Vorrat mit der Knappheit an Adressen bei IPv4 auf und entsorgt lästige IPv4-Netzwerktricks wie Network Address Translation [1].
Mit IPv6 [2] müsste niemand mehr den DSL-Router aufwendig eine Portweiterleitung beibringen, wenn LAN-Rechner Dateien ins Internet stellen sollen oder man auf Vaters Rechner Treiber-Probleme beheben muss. Doch der Traum von der globalen Erreichbarkeit endet jäh am eigenen DSL-Anschluss, der hierzulande in den meisten Fällen ausschließlich IPv4 spricht und zumeist bei jeder Einwahl die Adresse wechselt.
Die IPv6-freie Zone zwischen dem eigenen Rechner und Servern im Internet lässt sich jedoch mit Hilfe von Netzwerktunneln überbrücken. Vista und Windows XP seit Servicepack 1 haben einen solchen Tunnelmechanismus an Bord, den Microsoft den Namen des Schiffsbohrwurms Teredo navalis [3] verpasste und der im RFC 4380 [4] veröffentlicht wurde.
Teredo [5] nimmt dem Benutzer die Konfiguration weitgehend aus der Hand, in vielen Fällen funktioniert es ohne weitere Eingriffe. Es benötigt lediglich eine per IPv4 erreichbare Server-Adresse – den Rest der Arbeit übernimmt die Software. Andere Tunnelverfahren wie 6to4 funktionieren nur mit einer global-gültigen IPv4-Adresse und arbeiten daher nur im LAN-Router selbst, der per DSL direkt mit dem Internet verbunden ist. Einige Hersteller wie Apple und AVM haben diese Technik bereits in ihre Geräte eingebaut oder bieten diese Funktion über ein Firmware-Update [6] an.
Wie auch andere IPv6-Tunnelverfahren verpackt Teredo die IPv6-Daten in UDP [7]-Pakete und sendet sie per IPv4 an einen Server, der sowohl im IPv4- als auch im IPv6-Netz steht. Teredo tunnelt IPv6-Pakete jedoch aus einem per Network Address Translation (NAT) geschützten IPv4-Netz heraus, was sonst nur zusätzliche Client-Software wie Aiccu [8] oder Hexagos Gateway6 [9] beherrschen.
Trotz oder gar wegen aller Automatiken tauchen bei der Einrichtung und beim Betrieb von Teredo einige Probleme auf, die dem angehenden IPv6-Surfer im Wege stehen können. So argwöhnt mancher Windows-Benutzer Böses, wenn er in der Eingabeaufforderung den Teredo-Adapter sieht.
Derartige Netzwerktunnel setzen sich zudem über die Sicherheitsvorgaben des Netzwerkadministrators hinweg, da sie Daten am NAT-Router und der IPv4-Firewall [10] vorbei ins IPv4-Netzwerk schleusen können. IPv6 hebelt damit das Konzept des per NAT abgeschotteten lokalen Netze aus: IPv6-Rechner sind immer direkt erreichbar, wenn nicht die Firewall den Verbindungsaufbau blockiert.
Als IPv6-Tunnelmechanismus soll Teredo den Übergang von IPv4 auf das Nachfolgeprotokoll IPv6 vereinfachen. Ziel des Protokolls ist es ausdrücklich, Rechnern in lokalen (IPv4-)Netzen eine global gültige IPv6-Adresse zu verpassen.
Einrichtung unter Windows XP
Auf einen Windows XP seit Servicepack 2 benötigt Teredo lediglich den IPv6-Stack, der sich in den Netzwerkeinstellungen über die Eigenschaften der Netzwerkkarte oder als Administrator mit dem Netsh-Kommando netsh interface ipv6 install installieren lässt.
Anschließend sollte der Befehl netsh interface ipv6 show addresses an der Netzwerkkarte link-lokale IPv6-Adresse anzeigen, die sich am Präfix fe80:: erkennen lässt.
Der Teredo-Client hat eine Verbindung aufgebaut und kann IPv6-Adressen aufrufen. Anschließend zeigt das Kommando netsh interface ipv6 show teredo unter XP (und Vista) den Teredo-Status an: Meldet der Befehl beim Punkt "Status:" den Wert "qualified", steht der Teredo-Tunnel und der Heise-IPv6-Versuchsserver www.six.heise.de sollte auf ICMPv6-Pakete antworten, die das Kommando ping -6 www.six.heise.de anfordert. Endet das Ping-Kommando mit Fehlermeldungen, kann es sein, dass der Client den Tunnel noch nicht aufgebaut hat.
Rufen Sie das Kommando einfach ein zweites Mal auf, denn das unten beschriebene Auffinden des Teredo-Relays dauert oft etwas länger. Sollte Teredo ein verwaltetes Netzwerk erkennen und sich daher deaktivieren, hilft in einigen Netzen der Teredo-Enterpriseclient, der sich über Netsh anschalten lässt:
netsh interface ipv6 set teredo enterpriseclient
Wenn auch diese Einstellung nicht hilft, steht der Rechner in einem Netz, das wahrschienlich für Teredo nicht taugt. Das Verfahren versagt nämlich in LANs, deren Routern symmetrisches NAT einsetzen oder von einer Firewall geschützt werden, die UDP-Verkehr blockiert.
Auskunft über den Status oder den aktiven Tunnel liefert wiederum der Befehl netsh interface ipv6 show teredo.
Teredo-Parameter
Typ : client Servername : default Clientaktual.-intervall : default Clientport : default Status : dormant Typ : Teredo client Netzwerk : managed NAT : none (global connectivity)
Diese Ausgabe zeigt eine "schlafenden" Teredo-Client, der mit hoher Wahrscheinlich keine Tunnel aufbauen kann, denn er erkennt den NAT-Typ nicht und deklariert das LAN als verwaltetes Netz.
Steht jedoch der Teredo-Tunnel, liefern die Kommandos ipconfig /all oder netsh interface ipv6 show address die global gültige Adresse des Teredo-Tunneladapters. Diese Adresse startet immer mit 2001:0:, die mit fe80:: beginnende (link-lokale) Adresse des Adapters gilt nur im aktuellen Netzwerksegment.
Windows XP benötigt keine weiteren Einstellungen, wenn der Rechner über Programme wie Firefox 3, Internet Explorer 7 oder den SSH [11]-Client Putty [12] Internet-Adressen per IPv6 abruft.
Vista Spezial
Microsoft aktiviert Teredo in seiner aktuellen Windows-Version Vista, schaltet es aber automatisch ab, wenn das Betriebssystem merkt, dass das lokale Netz IPv6 spricht, die Vista-Firewall abgeschaltet ist oder das LAN verwaltet wird, was Teredo an einem Active Directory [13] bemerkt.
Besitzt der Vista-Rechner nur link-lokale oder Teredo-IPv6-Adressen [14] an seinen Netzwerkadaptern, erfragt das Betriebssystem die für IPv6 nötigen AAAA-Record nur dann, wenn ein Anwendungsprogramm wie ping sie ausdrücklich anfordert. So ermittelt unter Vista der Befehl ping -6 www.six.heise.de die korrekte IPv6-Adresse zum Heise-IPv6-Testserver, ein Aufruf der Website scheitert hingegen mit einer Fehlermeldung des DNS [15]-Resolvers.
Dieses Manko behebt eine IPv6-Adresse für die Netzwerkkarte, die mit der Zifferfolge 2001: beginnt und den Präfix /48 besitzt. In unseren Versuchen funktionierten beispielsweise die Adressen aus dem für Dokumentationszwecke reservierten IPv6-Bereich [16] 2001:db8, die sich über die Eigenschaften der Netzwerkverbindung in der Systemsteuerung oder per Netsh setzen lassen.
netsh interface ipv6 set address "LAN-Verbindung" 2001:db8::1/48
Besitzt der Rechner mehrere Netzwerkkarten, müssen Sie eventuell die Zeichenfolge "LAN-Verbindung" anpassen: Der Aufruf von ipconfig /all oder route -6 print gibt unter Windows die Namen aller Netzwerkadapter aus.
Dabei zeigt es auch die Nummer des Adapters, die für den letzten Schritt ist – das Setzen einer Route. Hat das Teredo-Interface beispielsweise die Nummer 9, setzt der Befehl
netsh interface ipv6 add route ::/0 9
die nötige Route. Weitere Details zum Routing und zu Teredo finden sich in dem Microsoft-Dokument IPv6 Transsition Technologies [17].
Teredo mit Linux, BSD und OS X
Dank der Veröffentlichung des Teredo-Protokolls im RFC 4380 [18] und der Arbeit des Linux-Kernelentwicklers Rémi Denis-Courmont steht mitterweile die quelloffene Teredo-Implementierung Miredo bereit, die unter Linux und BSD-Unixen läuft und sich als fertiges Paket beispielsweise in den Distributionen Debian, Opensuse und FreeBSD findet.
Für Mac OS X steht unter www.deepdarc.com/miredo-osx [19] ein fertiges Softwarepaket einer Miredo-Testversion bereit, die allerdings bereits gut zwei Jahre alt ist. In einem Subversion-Repository [20] finden sich die passenden Quelltexte.
Unter Linux verbindet das Paket Miredo den Rechner per Teredo-Tunnel mit dem IPv6-Internet Unter Debian oder Ubuntu startet Miredo nach der Installtion als Dienst. Der Eintrag "START_MIREDO" in der Datei /etc/default/miredo steuert, ob Miredo während des Systemstart den Tunnel aufbaut.
Details zum Verbindungsaufbau hinterlegt Miredo in der Datei /etc/miredo/miredo.conf:
# Please refer to the miredo.conf(5) man page for details. InterfaceName teredo # Pick a Teredo server: # ServerAddress teredo.ipv6.microsoft.com ServerAddress teredo-debian.remlab.net
ServerAddress legt fest, welchen Teredo-Server der Client anfragen soll – im Beispiel den Teredo-Server des Miredo-Entwicklers. Wie auch der Microsoft-Teredo-Server verrichtet dieser ohne zusätzliche Anmeldung seine Dienste. Mit InterfaceName vergibt die Software den Namen für das Tunnel-Interface. Weitere Einstellungen benötigt der Tunnel nicht und auch die Namensauflösung funktioniert unter Linux klaglos.
Letzte Ausfahrt
Microsoft bezeichnet seine Tunneltechnik selbst als letzten Ausweg: Sie soll nur dort zum Einsatz kommen, wo andere IPv6-Verbindungswege verschlossen sind. Teredo-Verbindungen verursachen im Netzwerk viel Aufwand, sind vergleichsweise uneffektiv und nicht besonders stabil. Der hohe Aufwand kommt besonders dadurch zustande, das Teredo Tunnel-Verbindungen durch NAT-Router bohrt, deren Eigenheiten es beim Tunnelaufbau ermittelt.
Im Allgemeinen unterscheidet man die vier NAT-Varianten [21] Full Cone, Restricted Cone, Port Restricted Cone und Symmetric, die sich allerdings miteinander mischen lassen. Teredo kann mit allen NAT-Arten umgehen. Teredo-Clients unter Windows XP verstehen sich jedoch nicht mit jedem symmetrischen NAT. Für neuere Windows-Versionen steht eine Teredo-Erweiterung [22] bereit, die dieses Problem für viele symmetrische NAT-Router beseitigt. Seit Version 1.1.0 beherrscht die Open-Source-Variante Miredo grundsätzlich diese NAT-Technik.
Teredo nutzt eine eigenes Adressformat: Die ersten 64 Bit einer Teredo-Adresse enthalten den Präfix 2001:0 und die hexadezimale Form der IPv4-Adresse der Teredo-Server. Es folgt ein 16-Bit-Block für Flags, dessen erste vier Bit den NAT-Typ kennzeichnen (Cone-Flag) und der eine 12-Bit lange Zufallszahl enthält, die zur Verbindungssicherung dient.
In den folgenden 16 Bit steht die externe Port-Nummer des NAT-Routers. Die letzten 32 Bit enthalten die externe Adresse des NAT-Routers. Damit ein Router den Port und die Routeradresse nicht versehentlich umschreibt, invertiert Teredo die Angaben zum Router-Port und zur Router-Adresse per XOR-Verfahren.
Das Protokoll baut den IPv6-Tunnel über ein mehrstufiges Verfahren auf: Der Client kontaktiert im ersten Schritt über den UDP-Port 3544 einen Rechner im IPv4-Internet, den Teredo-Server. Die Adresse des Teredo-Servers ist beim Windows-Client mit teredo.ipv6.microsoft.com vorbelegt. Mittels Netsh lässt sie sich jedoch anpassen:
netsh interface ipv6 set teredo client teredo.example.com
Dieser Befehl setzt noch weitere Teredo-Parameter, eine Liste gibt das Kommando netsh interface ipv6 set teredo help aus.
Teredo nutzt für den Tunnelaufbau einen Internet-Server, der beim Ausmessen der Verbindung und des NAT-Routers hilft. Der eigentliche IPv6-Verkehr läuft anschließend über einen weiteren Rechner, das Teredo-Relay. Beim ersten Aufruf versucht Teredo herauszufinden, welchen NAT-Typ das lokale Netz nutzt, wie die externe Adresse des Routers lautet und welchen Port es für den Transport der eigentlichen IPv6-Daten nutzen kann.
Dazu sendet der Client eine Router-Solication-Nachricht (RS), deren Cone-Flag besetzt ist. Der Teredo-Server antwortet über eine zweite IPv4-Adresse mit einer Router-Advertisment-Nachricht. Erhält der Client diese Nachricht, arbeitet der Teredo-Client in einem LAN, das per Cone-NAT mit dem Internet verbunden ist.
Kommt nichts zurück, sendet der Client ein zweite RS-Nachricht ohne gesetztes Cone-Flag, die der Server von seiner primären, vom Client als Zieladresse benutzten IP-Adresse beantwortet. Abschließend überprüfen Client und Server, ob das LAN des Clients symmetriches NAT nutzt.
Haben Client und Server diese Parameter ermittelt, sendet der Client in regelmäßigen Abständen Pakete an den Server, sodass der NAT-Router die Einträge in seiner NAT-Tabelle nicht löscht.
Sitzt der Client in einem LAN mit Port-restricted NAT, muss der Router erst die Adresse des Relay lernen. Will der Teredo-Client eine IPv6-Rechner ansprechen, erfragt er über den Server für jede IPv6-Gegenstelle einen Relay, der den eigentlichen IPv-Verkehr an den Client transportiert.
Die jeweils passende Relay-Adresse ermittelt der Client über ICMPv6-Anfragen: Er schickt eine ICMP [23]-Echo-Nachricht an die IPv6-Gegenstelle, die er in UDP-Pakete verpackt und an den Teredo-Server sendet.
Der Server packt die Nachricht aus und leitet sie per IPv6 an die Gegenstelle weiter. Der IPv6-Zielrechner antwortet mit einer Echo-Reply-Nachricht, die durch das IPv6-Routing zum nächstliegenden Relay gelangt, denn dieses zeigt sich gegenüber seinen Nachbarn für das Routing zu Teredo-Adressen zuständig. Der Relay verpackt die IPv6-Nachricht in IPv4-UDP-Paket und sendet sie dank der in der Teredo-Adresse gespeichertern Client-Adresse dem Client direkt zu.
Benutzt der Router des Client-LANs eine Port Restricted NAT, ist an dieser Stelle ein zusätzlicher Schritt (Bubble-to-open-Procedure) notwendig:
Der NAT-Router kennt die Adresse des Relay bislang nicht. Ihm fehlt ein entsprechender Eintrag in seiner NAT-Tabelle und somit blockiert er dessen Netzwerkpakete.
Der Relay sendet daher ein IPv6-Paket über den Teredo-Server an den Client, der nun Kontakt mit dem Relay aufnimmt und damit einen Eintrag in der NAT-Tabelle des Routers erzeugt. Anschließend läuft sämtlicher IPv6-Verkehr für dieses Ziel über das ermittelte Relay.
Vor die Wand
Rechner mit aktiven Teredo-Tunneln sind wie alle IPv6-Rechner weltweit erreichbar. IPv6 benötigt schlicht keine Netwerk Address Translation, die im IPv4-Netzwerken eine gewissen Schutz für Angriffen bietet. Teredo umgeht jedoch diese vermeintliche Schutzfunktion [24].
Allerdings bringt beispielweise ein Windows XP von Hause aus keine IPv6-tauglichen Server-Dienste mit und ist von dieser Seite relativ sicher vor Angreifern. Vistas Firewall berücksichtigt auch den eingehenden IPv6-Verkehr, den sie in der Standardeinstellung blockiert.
Läuft die Vista-Firewall nicht, stoppt das Betriebssystem automatisch den Teredo-Tunnel. Betriebssysteme wie Linux benötigen hingegen einen zusätzlichen Paketfilter (ip6tables [25]), der Serverdienste auf dem Rechner schützt oder den Verkehr ins LAN kontrolliert.
Teredo lässt sich unter Windows zudem mit dem Befehl netsh interface ipv6 set teredo disable deaktivieren. Vistas grundsätzliche IPv6-Tauglichkeit bleibt dabei erhalten. Misstrauische Naturen können jedoch IPv6 und damit auch Teredo über die Eigenschaften der Netzwerkkarte vollständig deaktivieren.
Teredo sperren in der Fritz!Box
Teredo auf dem Router zu sperren, ist ganz einfach: Man blockiert den Datenverkehr auf UDP-Port 3544 und unterbindet so die Kommunikation mit dem Teredo-Server. Bei professionellen Firewalls ist das kein Problem, und auch die meisten Heim-Router bieten einen Paketfilter, in dem sich der UDP-Port blockieren lässt. Nicht so die Fritz!Box, die zwar einen Paketfilter enthält, dessen Konfiguration aber nicht über die Web-Oberfläche im Browser anbietet.
Daher ist etwas Fummelei per telnet [26] nötig. Wer sich mit Kommandozeilen und dem Editor vi [27] gar nicht auskennt, sollte unbedingt die Finger davon lassen. Um bei einem Fehler die funktionierende Konfiguration wiederherstellen zu können, sichert man sie zuerst über das Web-Interface in eine Datei (Einstellungen -> System -> Einstellungen sichern).
Dann schaltet man den Telnetserver frei, indem man auf einem an der Fritzbox angeschlossenen Telefon die magische Kombination #96*7* wählt. Die Box quittiert das bei Erfolg mit einem einsekündigen Dauertuten. Auf den freigeschalteten Server greift man dann mit dem Befehl telnet fritz.box zu. Unter Windows Vista muss dazu das telnet-Programm nachinstalliert [28] werden, die anderen Systeme bringen es ohne Weiteres mit.
Auf der Kommanozeile lädt der Befehl nvi /var/flash/ar7.cgf die zentrale Konfigurationsdatei in den vi-ähnlichen Editor. Dort sucht man nach dem Wort "dslifaces". In diesem Bereich gibt es nach ungefähr 30 Zeilen zwei Einträge "accesslist", einen unter "lowinput" und einen unter "highoutput". In beide fügt man als vorletzte Zeile "reject udp any any eq 3544", ein.
Das bedeutet, dass Pakete verworfen werden, und zwar UDP-Pakete von allen Adressen an alle Adressen sofern der Zeilport gleich 3544 ist. Der Sender erhält per ICMP eine Fehlermeldung. Nach dem Speichern der Datei gilt es nun, mit dem Befehl ar7cfgchanged die Konfiguration neu zu laden. Einzelne Meldungen wie "websrv: not found" oder "checkempty: No such file" sind dabei normal. Eine wesentlich längere Liste deutet jedoch auf einen Fehler beim Editieren der Datei hin.
Nun sollte ein Check des Teredo-Status auf einem PC im LAN (netsh interface ipv6 show teredo) zur Meldung
Status : offline Fehler : Sekundäre Serveradresse ist nicht erreichbar
führen. Wenn alles geklappt hat, schaltet man den Telnet-Server mit der Wahl #96*8* wieder ab.