Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

Teredo

6to4 bietet IPv6-Tunnel über das IPv4-Internet, hat jedoch den Nachteil, dass die 6to4-Router immer eine offizielle IPv4-Adresse benötigen. Liegen sie hinter einem NAT-Device, funktioniert 6to4 nicht. Hier setzt Teredo an. Dabei handelt es sich um eine Tunneltechnologie, die von Mircosoft entwickelt wurde und insbesondere dort zum Einsatz kommt. Es gibt jedoch auch eine Implementation für Linux [5]. Der Name leitet sich übrigens von "Teredo navalis" ab und ist die Bezeichnung für einen Schiffsbohrwurm.

Teredo ist in den RFCs 4380 und 5991 definiert und bietet IPv6-Tunnel für IPv6-Knoten an, die sich hinter NAT-Devices befinden, die keine 6to4-Router sind. Dazu tunnelt Teredo die IPv6-Pakete nicht nur in IPv4, sondern zusätzlich in UDP. Das bedeutet, dass das originale IPv6-Paket als Payload von UDP transportiert wird. Dies erhöht die Chance, durch NAT-Devices hindurchzukommen. Dabei kann das getunnelte Paket grundsätzlich auch problemlos mehrere NAT-Stufen durchqueren.

Dabei spielen die NAT-Typen eine wichtige Rolle. Nach RFC 3489 wird unterschieden in:

  • Cone-NAT: Es existiert eine 1-zu-1-Zuordnung zwischen internen und externen Adressen, die dementsprechend auch von extern angesprochen werden können.
  • Restricted-NAT: Die Kontaktaufnahme von außen kann nur dann geschehen, wenn von innen bereits eine Verbindung zuvor aufgebaut wurde.
  • Symmetric-NAT: Die interne Adresse kann verschiedenen externen Adressen zugewiesen werden und ist daher von außen nicht eindeutig identifizierbar.

In der Praxis ist diese Unterscheidung jedoch nur ein Anhaltspunkt, da viele NAT-Router Mischformen verwenden. Teredo funktioniert grundsätzlich mit Cone-NAT und Restricted-NAT. Teredo definert die folgenden Komponenten:

  • Teredo-Clients: Dies sind IPv6/IPv4-Knoten, die Teredo-Tunneling-Interfaces unterstützen (ab Windows XP SP1).
  • Teredo-Server: IPv6/IPv4-Knoten, die sowohl an das IPv4- als auch an das IPv6-Internet angeschlossen sind. Sie weisen Teredo-Präfixe zu und unterstützen die Teredo-Clients bei der Kontaktaufnahme zu anderen Teredo-Clients oder IPv6-Only-Knoten. Teredo-Server lauschen per Default auf Port 3544/udp.
  • Teredo-Relays: IPv6/IPv4-Router, die Pakete von Teredo-Clients aus dem IPv4-Internet in das IPv6-Internet weiterleiten. Sie arbeiten teilweise mit Teredo-Servern zusammen.
  • Host-spezifisches Teredo-Relay: Dieses Relay ist ebenfalls im IPv6- und IPv4-Internet angeschlossen. Ist ein IPv6-Knoten auch IPv4-fähig, kann er über ein Host-spezifisches Teredo-Relay direkt über IPv4 mit dem Teredo-Client kommunizieren. In diesem Fall ist kein Teredo-Relay notwendig und damit keine Kommunikation über das IPv6-Internet.

Die Teredo-Adresse besteht aus einem 32-Bit-Präfix (2001::/32), gefolgt von der hexadezimalen IPv4-Adresse des Teredo-Servers. Die hinteren 64-Bits teilen sich in drei Bestandteile auf. Die Flags (16 Bits) definieren insbesondere die Art des NAT. Der chiffrierte externe Port (16 Bits) gibt den Port an, über den der interne Teredo-Client durch das NAT-Device von außen erreichbar ist. Diesen bestimmt der Teredo-Server durch die Analyse des Source-Ports der Pakete, die vom Client bei ihm ankommen und nennt ihn dem Client im Antwortpaket. Da einige NAT-Geräte versuchen, eine im Payload enthaltende Port-Angabe auf die interne Portnummer zu übersetzen, wird dieser Wert mit XOR verschlüsselt. Die letzten 32 Bits enthalten die chiffrierte externe IPv4-Adresse, über die der Client erreichbar ist.

Abbildung 8: Eine Teredo-Adresse kodiert neben dem Teredo-Server die NAT-Flags, den Port und die externe Adresse. Der Verbindungsaufbau dauert aber seine Zeit.

IPv6-Blase

Teredo-Adressen dieser Art werden ausschließlich den Teredo-Clients zugewiesen. Teredo-Server und -Relays erhalten nur native IPv4- beziehungsweise IPv6-Adressen. Die Kommunikation wird nun von den Teredo-Clients über die Teredo-Server initiiert, die den Teredo-Clients mitteilen, über welche offiziellen IP-Adressen und Ports sie zu sehen sind. Mit diesen Informationen macht Teredo sich die NAT-Session-Einträge zunutze, um die internen Systeme auch von außen ansprechen zu können.

Um die NAT-Verbindungen aufrechtzuerhalten, senden Teredo-Clients in regelmäßigen Abständen sogenannte Bubble-Pakete an den Teredo-Server. Dabei handelt es sich um "leere" IPv6-Pakete, die in einem IPv4-UDP-Paket eingekapselt sind.Möchten zwei Teredo-Clients am selben Link miteinander kommunizieren, so nutzen sie Bubble-Pakete als Ersatz für den Neighbor Discovery-Prozess, um die Kommunikation zu initiieren. Möchte ein Teredo-Client mit einem anderen Teredo-Client einer Remote-Site sprechen, hängt die Kommunikation vom NAT-Typ ab.

Befinden sich beide Knoten hinter einem Cone-NAT, können die Systeme direkt miteinander in Verbindung treten, da die Verbindungsaufnahme nach der Definition von Cone-NAT von jeder Source-IP-Adresse aus möglich ist. Befinden sich die Knoten jedoch hinter Routern, die Restricted-NAT verwenden, so werden zunächst Bubble-Pakete zu den Remote-Sites und zum Teredo-Server gesendet, der die Verbindung initiiert. Die eigentliche Kommunikation geht nach der initialen Öffnung der Verbindung direkt zwischen den beiden Kommunikationspartnern, der Teredo-Server hilft hier nur beim Verbindungsaufbau.

Im Falle der Verbindung eines Teredo-Clients mit einem nativen IPv6-Knoten im IPv6-Internet dient der Teredo-Server jedoch auch als Router in das IPv6-Internet. Verbindungen, die vom IPv6-Internet zu einem Teredo-Client aufgebaut werden sollen, werden mithilfe des nächstgelegenen Teredo-Relays beziehungsweise Host-spezifischen Relays realisiert.

Durch diese komplexen Mechanismen ist Teredo zum einen sehr langsam beim Verbindungsaufbau (unter anderem wegen Timeouts) und zum anderen unzuverlässig, weil die Verbindungen nur unter bestimmten Bedingungen überhaupt aufgebaut werden können. Für einen produktiven Einsatz ist Teredo derzeit eher nicht geeignet.

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019