Einer meiner Computer ist bei einem reinen IPv4-ISP, daher verwende ich Miredo, um eine IPv6-Adresse zu haben. Jetzt muss ich per IPv6 remote auf diesen Computer zugreifen. (Ich kann hier kein IPv4 verwenden, da es sich hinter einem NAT I befindet und keine neuen Portweiterleitungen hinzufügen kann.) Das Problem ist, dass ich keinen AAAA-DNS-Eintrag hinzufügen kann, da sich ein Teil der IP-Adresse bei jeder Verbindung des Computers mit dem Netzwerk zufällig ändert.
Meine Frage lautet also: Gibt es eine Möglichkeit, mit Teredo immer dieselbe IP-Adresse zu verwenden?
Antwort1
Teredo-IP-Adressen hängen von einigen Dingen abWikipedia.
Zunächst einmal hängt es von der IPv4-Adresse des Routers ab. Wenn sich diese ändert, liegt ein Problem vor.
Zweitens hängt es vom Quellport ab, der von Teredo verwendet wird, und der vom NAT-Gerät übersetzt und geändert werden kann. Wenn Ihr NAT-Gerät den von internen Anwendungen verwendeten Quellport beibehält,MaiSie können dies so einrichten, dass es unverändert bleibt. Wenn Sie Windows verwenden, kann die Option „Clientport“ für Teredo hilfreich sein.Siehe diesen Technet-Artikel.
Kurze Antwort: SieMaiSie können es die meiste Zeit gleich hinbekommen, aber Ihre Ergebnisse können erheblich variieren. Wahrscheinlich werden Sie es nicht zuverlässig hinbekommen, weil das NAT-Gerät Ihren Quellport verstümmeln könnte. Sie können das vielleicht verhindern, indem Sie Portweiterleitungen in Ihrer Firewall einrichten... aber das können Sie bereits nicht tun... also...
Eine bessere Option könnte darin bestehen, einen dynamischen DNS-Client einzurichten, vorausgesetzt, Sie finden einen, der eine IPv6-Adresse einer Teredo-Schnittstelle veröffentlicht.
Antwort2
Offenbar seitRFC 5991, einige Teile der IPv6-Adresse sind immer zufällig, um sie unvorhersehbar zu machen.
Daher war für mich die einfachste Lösung, einen dynamischen DNS-Dienst zu verwenden, der IPv6 unterstützt, wie z. B. dynv6.com.
Antwort3
Ja, das ist mit dem Teredo-Protokoll möglich. Dafür ist jedoch sowohl auf dem Teredo-Client als auch auf dem Teredo-Server ein geänderter Code erforderlich.
Um zu erklären, warum es immer noch als dasselbe Protokoll angesehen werden kann, nachdem sowohl Client als auch Server geändert wurden, muss ich zunächst erklären, welche anderen Komponenten an der Kommunikation beteiligt sind.
Teredo-Grundlagen
Die vier kritischen Netzwerkknoten in einer Kommunikation mit dem Teredo-Protokoll sind:
- Teredo-Client
- Teredo-Server (vom Client ausgewählt)
- Teredo-Relay (vom nativen IPv6-Knoten ausgewählt)
- Nativer IPv6-Knoten
Letztlich sind es der Teredo-Client und der native IPv6-Knoten, die IPv6-Pakete austauschen möchten. Die Teredo-Server und Teredo-Relays dienen dazu, diesen Datenverkehr zu ermöglichen.
Der Teredo-Server ist nur am anfänglichen Verbindungsaufbau beteiligt. Sobald die Verbindung hergestellt ist, durchläuft der Datenverkehr zwischen Teredo-Client und nativem IPv6-Knoten das Relay, ohne dass der Teredo-Server den Datenverkehr sieht.
Da der Client keinen Einfluss auf die Wahl des Teredo-Relays hat, würde jede Lösung, die Änderungen am Relay erfordern würde, nicht funktionieren. Glücklicherweise ist das auch nicht erforderlich. Die Verbindung zwischen Client und Relay, über die der Großteil des Datenverkehrs gesendet wird, besteht weiterhin vollständig aus standardmäßigem Teredo-Datenverkehr.
Da Client und Relay weiterhin über Standard-Teredo kommunizieren und der Client weiterhin eine IPv6-Adresse im 2001::/32Präfix hat, handelt es sich dennoch um Teredo.
Notwendige Änderungen
12 der Bits in der Teredo-Adresse werden vom Teredo-Client zufällig ausgewählt. Auf der Clientseite ist eine Änderung erforderlich, damit diese nicht zufällig sind.
48 der Bits in der Teredo-Adresse sind die IPv4-Adresse und die UDP-Portnummer des Teredo-Clients, wie sie vom Teredo-Server gesehen werden.
Dabei ist es sehr wichtig, dass diese 48 Bits die Portadresse sind, die der Server sieht. Aufgrund von NAT könnten Client und Relay denken, dass der UDP-Port eine völlig andere Adresse hat. Aber die IPv4-Adresse und Portnummer, die Client und Relay sehen, haben keinen Einfluss auf die endgültige IPv6-Adresse.
Normalerweise befindet sich das einzige beteiligte NAT in der Nähe des Teredo-Clients. Wenn Sie jedoch die endgültige IPv6-Adresse beeinflussen möchten, kann ein NAT auf derselben Maschine wie der Teredo-Server installiert werden. Wenn Sie möchten, können Sie NAT sogar direkt in den Teredo-Server einbauen.
Gibt es hierfür eine Implementierung?
Wahrscheinlich nicht.
Ich habe bereits implementiertam meisteneines Teredo-Servers, der dies tut. Aber der Client könnte nur die IPv4-Adresse und nicht die UDP-Portnummer auswählen. Ich brauchte die UDP-Portnummer, um die Clients unterscheiden zu können.
Ein Teredo-Server, der sowohl die IPv4-Adresse als auch den UDP-Port für einen bestimmten Benutzer statisch hält, bräuchte eine Möglichkeit, den Benutzer zu erkennen. Es gibt Felder im Protokoll, die möglicherweise dafür verwendet werden könnten. Mir ist jedoch keine Implementierung bekannt, die die Identifizierung von Teredo-Clients gegenüber Teredo-Servern unterstützt.
Darüber hinaus leidet Teredo unter einem erheblichen Zuverlässigkeitsproblem. Dieses Zuverlässigkeitsproblem betrifft den Teil des Teredo-Protokolls, der von den hier beschriebenen Änderungen nicht betroffen ist.
Das Problem mit Teredo
Das Problem besteht darin, wie der native IPv6-Knoten auswählt, welches Teredo-Relay verwendet werden soll. Idealerweise konfiguriert der Administrator des Netzwerks, in dem sich der native IPv6-Knoten befindet, ein Teredo-Relay für dieses Netzwerk (und platziert es außerhalb des NAT, wenn NAT für IPv4 verwendet wird).
Viele Administratoren entscheiden sich jedoch gegen die Bereitstellung eines Teredo-Relays. Normalerweise mit der Begründung, dass Teredo aufgrund seiner Unzuverlässigkeit nicht unterstützt werden muss (ohne zu erkennen, dass diese Begründung die Unzuverlässigkeit von Teredo zu einer sich selbst erfüllenden Prophezeiung macht).
Stattdessen wird der Datenverkehr vom nativen IPv6-Knoten über die Standardroute an den Upstream-Provider gesendet, der ihn wiederum an seinen Upstream-Provider weiterleiten kann. Schließlich landet der Datenverkehr möglicherweise auf einem öffentlichen Drittanbieter-Relay auf einem AS, das sich für eine Ankündigung entschieden hat 2001::/32.
Die Verwendung eines Drittanbieter-Relays bedeutet einen längeren Netzwerkpfad, was wiederum eine höhere Latenz bedeutet. Es bedeutet auch, dass es kein SLA gibt und das Teredo-Relay möglicherweise nicht über ausreichende Kapazität für den an es gesendeten Datenverkehr verfügt.
In den meisten Fällen, in denen eine statische IP-Adresse gewünscht wird, ist auch eine gewisse Zuverlässigkeit erwünscht. Und da Sie selten Kontrolle über alle Remote-Knoten haben, mit denen Sie kommunizieren, haben Sie auch keine Kontrolle darüber, welche Teredo-Relays verwendet werden.
Dies macht Teredo mit statischer IP-Adresse zu einem Nischenprodukt für die wenigen, die bereit sind, einen modifizierten Teredo-Client zu installieren, um eine statische IP-Adresse ohne Zuverlässigkeitsgarantie zu erhalten.
Antwort4
Mit einem Tunnel sind Sie vielleicht besser dran 6in4. Dieser verwendet Protokoll 41 und erfordert keine zusätzlichen NAT-Regeln. Es gibt Broker, die kostenlose Tunnel bereitstellen. Solange Sie der Einzige in Ihrem Netzwerk sind, der die Tunnelbroker-IP verwendet, sollte es keine Probleme geben.
Wenn die IP-Adresse Ihres Routers nicht statisch ist, müssen Sie zusätzliche Konfigurationsschritte durchführen, um das Netzwerk neu zu konfigurieren, wenn sich die IP-Adresse ändert. Dies ist ähnlich dem, was Sie bei DDNS tun müssten.
Verwenden Sie für Ihre Verbindung eine Firewall, da Sie sonst nicht über ein NAT verfügen, das Sie vor unerwünschtem Datenverkehr schützt.
Die Unterstützung für beides 6in4ist 6to4in Linux integriert. Ich habe ursprünglich mit 6to4 angefangen, was zwar funktionierte, aber nicht so stabil war, wie ich es mir gewünscht hätte. Mit 6in4hatte ich eine stabile Verbindung. Ich habe es für NTP-Verbindungen verwendet und erhalte stabile Zeitquellen über IPv6.