Unitymedia Port Forwarding die 500.

[Creevy]

Guten Tag allerseits,

ich bin auch einer Jener Vollidio...Enthusiasten, die sich dachten ein Internetanschluss über Kabel ist eine feine Sache.
Noch quietschvergnügt bestellt (natürlich mehr als 2 Wochen vor dem Schaltungstermin, bei KabelBW brauchts ja keinen Wiederruf...)
und der Techniker kam auch noch auf die Minute pünktlich. :smile:

Dann kam die Phase des Erwachens, mit 2 Wochen Krieg führen damit der Elektroschrott der jetzt hier an der Wand hängt aktiviert wird.
AMAGWAD heute ham ses angestellt und siehe da...KEIN PORT FORWARDING!? :wut: :wut: WTF...Tja und weil ich sowohl für Arbeit als auch Vergnügen
darauf angewießen bin gleich mal geschmöckert was da für Alternativen zu finden sind. hmmhmm...KEIN..wait..VPN Tunnel?
Nun habe ich zwar die Suchfunktion ausführlich und bis zum Erbrechen Genutzt, aber trotz allem nun meine Frage(n):

Was kann ich(kann ich etwas) tun um trotz allem Port Forwarding nutzen zu können?
(Außer dem oft erwähnten Business-Anschluss.. Nein Danke, das Geld liegt NOCH nicht auf der Straße.. :motz: )
Falls der besagte VPN Tunnel eine Möglichkeit ist, wie funktioniert das (bzw was muss ich tun ums zum laufen zu kriegen, für den Laien bitte kindsgerecht erklären :/)
Falls all diese Stricke reißen, nutzt mein Nachmieter momentan noch meinen alten DSL Vertrag von 1&1, wäre es einfacher/stressfreier/grundsätzlich technisch möglich
die Umzugsoption von 1&1 zu nutzen und die mächtige 16k Leitung (neben der 100k...) für die Tätigkeiten zu nutzen auf die ich angewiesen bin?
Falls auch dieser letzte Strick reißt (und ich nicht am Bluthochdruck krepiere :wut: ....), ist die Tatsache, dass das Inet ohne freie ports quasi völlig nutzlos für mich ist ein Sonderkündigungsgrund?

Mit freundlichen Grüßen
der Creevy

 

[Knifte]

Wenn du bei KBW bist und denen ggü. argumentierst, dass du beruflich auf einen IPv4-Anschluss angewiesen bist, dann stellen die die mit etwas Glück auch wieder auf IPv4 um.

Dann sollte das Portforwarding auch wieder funktionieren.

 

[Creevy]

"Können wir ihnen leider nicht weiterhelfen"...
"Ist nicht möglich"...
"Sicherheitsrisiko"...
...
Also hat niemand einen konkreten Weg um diese gelinde UNVERSCHÄMTHEIT dem Kunden gegenüber zu umgehen?
Dann werd ich wohl drauf pochen müssen, dass das ein Sonderkündigungsgrund ist.

 

[EVA-01]

TC7200?

Hol dir ne Fritz 6360. Dann haste zwar immer noch IPv6, aber mit dem Teil müsste das meiste funktionieren. SpaceRat hat ja ein paar gute Tutorials dazu geschrieben.

 

[SpaceRat]

"Können wir ihnen leider nicht weiterhelfen"...
"Ist nicht möglich"...
"Sicherheitsrisiko"...
...

Hast Du diese Aussagen von Kabel BW oder von Unitymedia bekommen?

Bei Unitymedia ist das normal, die stellen sich bei Neukunden stur, die bleiben auf IPv6.

Für KabelBW gilt aber bzw. galt zumindest bisher: Kabel-BW gewährt stillschweigend auch öffentliche IPv4-Adressen.
KabelBW verlangt dabei aber durchaus auch schon mal nach einer Begründung, z.B. daß man mit DS-lite nicht mehr auf das Firmen-VPN zugreifen kann, das man für die Arbeit braucht oder der Fernzugriff auf die eigene Heizungssteuerung damit nicht funktioniert.

Nichtsdestotrotz ist das DK7200 absolut unbrauchbar. Mit der Fritz!Box 6360 hat man definitiv mehr vom Leben

 

[Creevy]

Nun ich vermute wenn ich an den KabelBWKundendienst schreibe, wirds wohl auch KabelBW sein..
Herbe Enttäuschung ist das..

 

[hajodele]

Nun ich vermute wenn ich an den KabelBWKundendienst schreibe, wirds wohl auch KabelBW sein..
Herbe Enttäuschung ist das..

Wie oft hast du denn angerufen?
Bei dem Kundenservice muss man manchmal 2 oder 3 Anrufe tätigen bis man jemanden erwischt, der die Umstellung macht.
Ich habe es damals per Störungstiket gemacht.

Mir ist kein Fall bekannt, in dem IPv4 dauerhaft verweigert worden wäre.

 

[EVA-01]

Ist das TC7200 bei IPv4 überhaupt sooo viel besser bzw. brauchbar? Sonst hat er nach einer Umstellung immer noch dieselben Probleme...

 

[SpaceRat]

Ist das TC7200 bei IPv4 überhaupt sooo viel besser bzw. brauchbar?

Auf jeden Fall:

Zum einen hängen die richtigen Störungen von Internet und Telefon (Also der Verlust der IPv4-Konnektivität) mit dem verwendeten DS-lite-Verfahren zusammen, welches das DK7200 gar nicht beherrscht (Die Ironie: Vorgeblich will man wohl über den abgeschalteten Bridge-Modus vermeiden, daß die Kunden mit eigenen, IPv6-untauglichen Routern Probleme kriegen und die Hotline belasten, selber liefert man aber einen solchen als Zwangsrouter aus).
Will heißen: Der AFTR-Tunnel, der für IPv4 und damit auch für die VoIP-Telefonie zuständig ist, bricht zusammen und damit bleibt in dem Moment nur noch das, was auch per IPv6 erreichbar ist.
Dieser Effekt entfiele, wenn der Kunde natives IPv4 hätte.

Zweitens sind IPv4-Zugänge an sich eh schon limitiert, dieser Stand läßt sich daher weitgehend auch ohne Bridge-Modus nachkonfigurieren. Es ist dann einfach nur noch eine Zumutung, dem Kunden diesen unnötig hohen Konfigurationsaufwand abzuverlangen, aber man kommt bei IPv4 über eine Router-Kaskade fast zum selben Ergebnis wie bei einer Bridge.

 

[grouper]

Voice over IP sowie P2P ist ja laut Unitymedia AGB eh nicht gestattet...

http://app.unitymedia.de/service/index.html/faqs/6b3b3b42-4388-4f69-b66d-e2f8fe57da75?contact_link=&layout=&query=welche+internet-dienste+

 

[phoenixx4000]

Voice over IP sowie P2P ist ja laut Unitymedia AGB eh nicht gestattet...

http://app.unitymedia.de/service/index.html/faqs/6b3b3b42-4388-4f69-b66d-e2f8fe57da75?contact_link=&layout=&query=welche+internet-dienste+

Oh Schreck.....

Darf ich jetzt mit meiner 6360 nicht mehr telefonieren???
Darf ich vielleicht die mit der Firmware 5.50 erst freigeschaltete Voip-vom-Internet-erreichbar-Funktion womöglich garnicht nutzen????

:kratz:

 

[matchi]

*Bitte nicht als Werbung verstehen!*

Hallo,

ich habe soeben die NAT Hürde mit Hilfe eines kostenpflichtigen portmapping Dienstes überwunden.
Das Verfahren dazu steckt noch in den Kinderschuhen und verlangt etwas Konfigurationsaufwand sowie gehöriges Vertrauen in den provider...wer geschäftliche Daten übertragen will, sollte zweimal drüber schlafen bzw. wohl doch lieber auf die feste IPv4 bei unitymedia bestehen.

Über diese Schritt-für-Schritt Anleitung bin ich auf den Anbieter gestoßen: http://www.feste-ip.net/dslite-ipv6/

Das ganze kostet aktuell ca. 5€ im Jahr.

mfg
matchi

 

[grouper]

Das liest sich sehr interessant, aber scheint nur mit Fritzboxen zu funktionieren, nicht mit dem super TC7200, oder?

 

[matchi]

Hi,

ja, so wie man das liest haben sie bisher nur die Abfrage des IPv6 Präfix auf der fritz.box hinbekommen :traurig: . Du könntest Dich mit dem Betreiber in Verbindung setzen...auch wieder Rennerei.

 

[SpaceRat]

Schon etwas strange.

Also das hier ist das, was der Anbieter im Prinzip macht:

Unter Windows:
netsh interface portproxy add v4tov6 listenport=<IPv4-Port des Anbieters> <IPv6-Adresse des Kunden-Rechners> <IPv6-Port des Dienstes auf dem Kunden-Rechner>

Mittels 6tunnel:
[NT]6tunnel <IPv4-Port des Anbieters> <IPv6-Adresse des Kunden-Rechners> <IPv6-Port des Dienstes auf dem Kunden-Rechner>

Mittels HAproxy:
haproxy.cfg:

global
[...]
defaults
[..]
listen <kunden-proxy>	bind <Anbieter-IPv4>:<Anbieter-IPv4-Port>	server <kunden-proxy> <IPv6-Adresse des Kunden-Rechners>:<IPv6-Port des Dienstes auf dem Kunden-Rechner>

Kein echtes Hexenwerk, steht übrigens auch schon so oder so ähnlich in meinem TCP/IP-Workshop (und natürlich auch zig anderen Quellen im Netz).
Durch alle o.g. Aufrufparameter/Konfigurationen wird der (nur) per IPv6 erreichbare Dienst beim Kunden zusätzlich unter dem bei diesem Anbieter konfigurierten Port per IPv4 erreichbar gemacht.
Das könnte man somit letztlich auch einfach bei einem Bekannten machen, der noch IPv4 (und auch IPv6) hat.

Einen Haken hat die Sache aber so oder so:
Dieser Port-Proxy bringt nur dann etwas, wenn die Verbindung über den Proxy sozusagen für sich selber steht, also ein Client von vornherein den Server unter der Adresse dieses Anbieters anspricht:
Beide, also Client und Server meinen dann, mit dem Rechner des DS-lite-Proxy-Anbieters zu kommunizieren und der schaltet die beiden zusammen.

Aus einem Kontext heraus wird es aber nicht oder nur schwer gehen. So weiß z.B. ein Instant Messenger auf dem Kunden-Rechner ja nichts von dem Proxy. Wenn der IM auf der IPv6-Leitung eine Direktverbindung (Dateitransfer, Video-Konferenz, ...) aufbauen möchte, dann kommt die Aufforderung dazu bei der anderen Seite immer noch von der nicht von außen erreichbaren CGN-IPv4 an.
Oder anders:
Aus dem Kontext heraus erfolgt so ein Aufbau einer Direktverbindung i.d.R. über die Aufforderung "Kontaktiere mich über Port <port>", wobei "mich" die IPv4 des Rechners ist, die in dem Kontext schon bekannt ist, also die von CGN betroffene IPv4 des DS-lite Kunden. Im IRC kann man einem DCC Request zwar auch eine IP beifügen, welche dann die des Port-Proxy-Anbieters sein könnte, aber auch das muß man erst einmal konfigurieren.

Das liesse sich nur vermeiden, indem man den Kontext ebenfalls über den Port-Proxy-Anbieter herstellt, d.h. dieser müßte dann auch v4tov4 Proxies anbieten, über die sich der DS-lite-Kunde mit z.B. dem Instant-Messenger-Dienst verbindet, damit dieser davon ausgeht, daß die IP des Port-Proxy-Anbieters auch die des Nutzers sei.

Genau das gleiche gilt natürlich auch für Spielekonsolen, die für Online-Games von außen erreichbar sein möchten: Wenn diese die Verbindung zum Server selber herstellen, dann erwartet der Server die geöffneten Ports auch auf der IPv4, über die sie kontaktiert wurden und nicht auf irgendeiner völlig anderen. Auch hier bräuchte man also einen v4tov4-Proxy über den sich der Kunde via Proxy-Anbieter mit den Game-Servern verbindet ... und davon, das auch zu tun, muß man die Spielekonsole auch erst einmal überzeugen (Das geht am ehesten durch DNS-Spoofing im eigenen Router, den man dafür erst einmal modifizieren muß).

Was der Kunde auch noch selber leisten muß, ist die Bindung seines IPv4-only-Programms an IPv6, damit der Port-Proxy-Anbieter den Dienst beim Kunden überhaupt erreichen kann.

Wenn ich also z.B. einen "Remote Administrator" (Das Teil kann nur IPv4) an einem DS-lite-Anschluß erreichbar machen will, dann reicht es nicht, beim Port-Proxy-Anbieter einen Port-Forward
von <Adresse des Port-Proxy-Anbieters>:<Port beim Anbieter> auf <meine IPv6>:4899 anzulegen, denn der Port-Proxy-Anbieter versucht dann eben den Port 4899 per IPv6 zu erreichen.
Der Kunde muß immer noch einen eigenen Port-Proxy zur Vermittlung zwischen IPv4 und IPv6 einrichten, also in diesem Fall z.B.
netsh interface portproxy add v6tov4 listenport=4899

Und was ich schlußendlich richtig strange finde ist der Zwang, dem Anbieter einen Zugang zur Fritz!Box einzuräumen.
a.) Diese Daten werden ganz sicherlich nicht nur als Hash gespeichert, denn damit käme er nicht in die Fritz!Box, er muß die Daten zwangsläufig wirklich an die Fritz!Box senden.
b.) Das Ganze ist völlig unnötig, denn er könnte als Weiterleitungsziel auch einfach die MyFritz!-Adressen der Kunden-Geräte nutzen, die braucht er aber eben nicht selber aus der Fritz!Box auszulesen, die kann ihm der Kunde auch mitteilen.

 

[feste-ip.net]

Hallo,

wir möchten diesen Post nutzen um zwei Dinge aufzugreifen die sachlich nicht korrekt sind.

Und was ich schlußendlich richtig strange finde ist der Zwang, dem Anbieter einen Zugang zur Fritz!Box einzuräumen.

Das ist momentan die einzige Möglichkeit den internen Präfix zu ermitteln.

a.) Diese Daten werden ganz sicherlich nicht nur als Hash gespeichert, denn damit käme er nicht in die Fritz!Box, er muß die Daten zwangsläufig wirklich an die Fritz!Box senden.

Das ist falsch. Wir verwenden das Login welches die Fritzbox für das DDNS Update sendet. Nachdem das PW mit dem Hash der Datenbank verglichen wurde baut unser System rückwärts eine Verbindung zur Gegenstelle (Frotzbox) auf und es wird damit der aktuelle lokale Präfix der Fritzbox ermittelt. Somit müssen wir die Passwörter nicht im Klartext speichern.

b.) Das Ganze ist völlig unnötig, denn er könnte als Weiterleitungsziel auch einfach die MyFritz!-Adressen der Kunden-Geräte nutzen, die braucht er aber eben nicht selber aus der Fritz!Box auszulesen, die kann ihm der Kunde auch mitteilen.

Das stimmt leider auch nicht so ganz.
Über die Myfritzdaten bekommt man nur die externe Adresse der Fritzbox. Für die Subhosts bzw. das Portmapping benötigen wir aber den internen LAN Präfix.

MfG
Rene - Feste-IP.net Team

 

[SpaceRat]

Und was ich schlußendlich richtig strange finde ist der Zwang, dem Anbieter einen Zugang zur Fritz!Box einzuräumen.

Das ist momentan die einzige Möglichkeit den internen Präfix zu ermitteln.

Das ist nicht korrekt.

Und es gibt auch kein "internes Präfix":
Wie ja auch schon auf Ihrer Seite steht, entfällt bei IPv6 die Notwendigkeit von NAT und das liegt eben daran, daß die vergebenen IPv6s grundsätzlich öffentlich sind.

Was noch am nächsten an die Bedeutung von "internes Präfix" käme, wäre das für die ULA verwendete Präfix. Standardmäßig advertised die Fritz!Box aber kein ULA-Präfix mehr, sobald eine IPv6-Verbindung besteht und außerdem wären die ULAs auch nicht routingfähig, für diesen Dienst also irrelevant.

b.) Das Ganze ist völlig unnötig, denn er könnte als Weiterleitungsziel auch einfach die MyFritz!-Adressen der Kunden-Geräte nutzen, die braucht er aber eben nicht selber aus der Fritz!Box auszulesen, die kann ihm der Kunde auch mitteilen.

Das stimmt leider auch nicht so ganz.
Über die Myfritzdaten bekommt man nur die externe Adresse der Fritzbox.

Das ist Blödsinn, denn wenn man über die MyFritz!-Freigaben nicht an die kompletten und korrekten IPv6-Adressen der freigegebenen Geräte käme, dann könnte man sie auch per IPv6 nicht von außerhalb erreichen ohne deren IPv6 anderweitig zu ermitteln.

Für die Subhosts bzw. das Portmapping benötigen wir aber den internen LAN Präfix.

Was Sie benötigen sind die (öffentlichen) IPv6-Adressen der Geräte, die freigegeben werden sollen, soweit korrekt.
Dafür würde es aber genügen, wenn der Kunde dazu beim Einrichten der v4tov6-Weiterleitung den MyFritz!-Namen des jeweiligen Gerätes angibt.
Ein Vollzugang zur Fritz!Box des Kunden ist dafür nicht erforderlich.

Übrigens:
Ich weiß sogar, welchen Denkfehler Sie machen. Aber wer kommerzielle Dienste anbietet, muß selber drauf kommen.

 

[matchi]

Guten Abend,

der Hinweis bzgl. ULA hat mich nochmal zum Grübeln gebracht...ich bin relativ neu in der v6 Materie.

Was ich grade gelernt habe:
Anscheinend ist es nicht mehr notwendig, die IP Adressen im LAN über einen DHCP(v6) Server zu vergeben. Stattdessen kann ein Mechanismus / Protokoll SLAAC zum Einsatz kommen. Die fritz.box von UM bietet diese Einstellung unter

"Heimnetz" - Reiter "Netzwerkeinstellungen" - Knopf "IPv6 Adressen"



Dort führt folgende Einstellung dazu, dass der Präfix der IPv6 Internetverbindung ohne Umsetzung mittels ULA an die Endgeräte durchgereicht wird:

DHCPv6-Server im Heimnetz DHCPv6-Server in der FRITZ!Box deaktivieren: * Es sind keine anderen DHCPv6-Server im Heimnetz vorhanden. Geräte im Heimnetzwerk sollen ihre Autokonfiguration (SLAAC) benutzen, um die eigene IPv6-Adresse zu ermitteln.

Jetzt sieht es im IPv6 LAN wie folgt aus (Präfix verfälscht):

IPv6-Präfix: 2a02:908:e659:5870::/57 + Interface ID: ::208:9bff:fecb:7cee
=> IPv6: 2a02:908:e659:5870:208:9bff:fecb:7cee

Damit ist es, wie von spacerat beschrieben, über die myfritz Adresse in Kombination mit den Interface IDs möglich, ohne router Zugriff die Adressen zu ermitteln.

PS:
feste-ip.net funktioniert mit beiden Einstellungen (SLAAC oder fritz.box als stateful DHCPv6).

PPS:
Man sollte die Diskussion "IPv6 -> IPv4 Portforwarding via feste-ip.net" hier evtl. zu einem eigenen Thema auskoppeln, der Thread-Titel passt nicht mehr wirklich.

 

[SpaceRat]

Anscheinend ist es nicht mehr notwendig, die IP Adressen im LAN über einen DHCP(v6) Server zu vergeben. Stattdessen kann ein Mechanismus / Protokoll SLAAC zum Einsatz kommen. Die fritz.box von UM bietet diese Einstellung unter

"Heimnetz" - Reiter "Netzwerkeinstellungen" - Knopf "IPv6 Adressen"

Die Adresszuweisung über SLAAC ist Standard in der Fritz!Box und auch den meisten anderen Routern, die IPv6 können.

SLAAC steht für Stateless Address Autoconfiguration, was in der dt. Fachterminologie zu "zustandslose Adressenautokonfiguration" übersetzt würde und sprachlich richtig besser "verbindungslose Adressenautokonfiguration" hieße.
SL bzw. state-less wird immer mit "zustandslos" übersetzt, aber "keine Verbindung" ist nun einmal auch ein Zustand und somit ist "zustandslos" absolut sinnleer.

"zustandslose Adressenautokonfiguration" heißt es deshalb, weil jedes Gerät auch ohne aktive Verbindung in der Lage ist, seine (lokale) IPv6-Adresse selber zu bestimmen.
Wie das abläuft, habe ich hier im Abschnitt "Adressvergabe IPv6 - DHCP vs. DHCPv6" beschrieben.

In dem Moment, in dem nun ein (oder mehrere) Router hinzukommt/hinzukommen, welche(r) ein (oder mehrere) Präfix(e) ankündigen ("advertise"), kombinieren die Geräte diese(s) Präfix(e) mit den hinteren 4 Tupeln (Der "Interface-ID") der schon ermittelten lokalen IPv6-Adresse zu weiteren IPv6-Adressen.
I.d.R. wäre das dann das öffentliche Präfix (und ggf., sofern man im Router die dauerhafte Vergabe von ULA eingeschaltet hat, auch das ULA-Präfix) und somit ergeben sich die öffentlichen (und ggf. eben zusätzlich der ULA-) IPv6-Adressen.
In der Standardeinstellung kündigt die Fritz!Box ein ULA-Präfix an, solange keine IPv6-Verbindung besteht und sobald eine IPv6-Verbindung aufgebaut ist, wird stattdessen das öffentliche Präfix angekündigt.

Dort führt folgende Einstellung dazu, dass der Präfix der IPv6 Internetverbindung ohne Umsetzung mittels ULA an die Endgeräte durchgereicht wird:

Es handelt sich keineswegs um eine "Umsetzung". Es ist einfach nur eine zweite IPv6-Adresse, über die - nur lokal - auch geroutet werden kann.
Der Vorteil bei einer ULA ist der, daß sie auch dann zur Verfügung steht, wenn die Internet-Verbindung ausgefallen ist, und sich selbst dann nicht ändert, wenn der Internet Provider dynamische Präfixe vergibt.
Wenn man also auch im LAN mit IPv6 arbeiten möchte, bietet es sich an, ULA dauerhaft zu vergeben und im Heimnetz mit diesen zu arbeiten, damit die lokalen Verbindungen nicht davon abhängig sind, ob man gerade Internet hat ...

Damit ist es, wie von spacerat beschrieben, über die myfritz Adresse in Kombination mit den Interface IDs möglich, ohne router Zugriff die Adressen zu ermitteln.

Jain, in Bezug auf das fett Markierte.
Ich winke da nochmal mit dem ganzen Gartenzaun:
Jede MyFritz!-Adresse läßt sich - sofern vorhanden - auf die vollständige, öffentliche IPv6 des jeweiligen Gerätes auflösen, unabhängig davon, wie die IPv6 erzeugt wurde.

MyFritz! wird niemals die MyFritz!-Adresse mit der ULA (Beginnend mit fdxx oder der link-local Adress (Beginnend mit fe80 bestücken, denn die wären von außerhalb nicht erreichbar. Genauso wenig wird eine MyFritz!-Adresse auf die lokale IPv4 eines Gerätes verweisen, sondern immer auf die öffentliche IPv4 des ganzen Heimnetzes. Bei einem - von außen nicht erreichbaren - DS-lite-Tunnel, wird gar nicht auf eine IPv4-Adresse verwiesen.

Die MyFritz!-Adresse der Box selber zeigt dabei tatsächlich auf eine IPv6-Adresse außerhalb des verwendeten Präfixes (Sie ist aber tatsächlich auch unter dieser Adresse erreichbar!), die MyFritz!-Adressen aller anderen Geräte zeigen auf die vollständige IPv6-Adresse des Gerätes mit dem Präfix, denn eine andere öffentliche IPv6 haben sie - im Gegensatz zur Fritz!Box - nicht.

Daraus ergibt sich folgendes Bild:
In einem Heimnetz befinden sich zwei NAS, NAS1 und NAS2, welche über MyFritz! freigegeben werden.

Die MyFritz!-Namen werden aufgelöst zu ...

• ... an einem IPv4-only-Anschluß ...
  

  X:\>nslookup nas1.gvambdcfesxyisow.myfritz.net
  Name: nas1.gvambdcfesxyisow.myfritz.net
  Address: 123.45.67.89
  X:\>nslookup nas2.gvambdcfesxyisow.myfritz.net
  Name: nas1.gvambdcfesxyisow.myfritz.net
  Address: 123.45.67.89

  Beide zeigen auf dieselbe IPv4, da das ganze Heimnetz ja nur diese eine hat und auf keine IPv6, da nicht vorhanden.
  Um tatsächlich entweder das eine oder das andere NAS zu erreichen, müssen entsprechende unterschiedliche NAT-Port-Weiterleitungen von der öffentlichen IPv4 auf die lokale im LAN existieren.
  
  Beispiel:
  Existiert eine Port-Weiterleitung für Port 80 extern auf Port 80 von NAS1 intern und eine von Port 81 extern auf Port 80 von NAS2 intern, dann würde man unter http://nas1.gvambdcfesxyisow.myfritz.net:81 trotzdem NAS2 und unter http://nas2.gvambdcfesxyisow.myfritz.net:80 trotzdem NAS1 erreichen, denn effektiv wird nicht die Adresse sondern die IP kontaktiert. Das ist erstens beide Male dieselbe und zweitens auch nur die der Fritz!Box, die dann anhand des Ports und einer eventuellen Port-Weiterleitung entscheidet, welches Gerät im LAN das Paket erhalten soll ...
• ... an einem IPv6-only-Anschluß oder einem DS-lite-Anschluß ...
  

  X:\>nslookup nas1.gvambdcfesxyisow.myfritz.net
  Name: nas1.gvambdcfesxyisow.myfritz.net
  Address: 2a02:908:1234:1400:290:a9ff:fe45:5678
  X:\>nslookup nas2.gvambdcfesxyisow.myfritz.net
  Name: nas1.gvambdcfesxyisow.myfritz.net
  Address: 2a02:908:1234:1400:290:a9ff:fe45:6789

  Beide zeigen auf unterschiedliche IPv6-Adressen, denn jedes NAS - und jedes weitere Gerät im Heimnetz - hat eine eigene öffentliche IPv6 über die es direkt und ohne Umweg über NAT angesprochen werden kann.
  Eine IPv4 hingegen wird nicht mitgeteilt, denn es existiert für beide Geräte keine öffentliche erreichbare IPv4.
  
  Daraus folgt:
  Unter nas1.gvambdcfesxyisow.myfritz.net:81 erreiche ich immer nur NAS1 und unter nas2.gvambdcfesxyisow.myfritz.net immer nur NAS2, da die beiden Adressen direkt auf die jeweilige IPv6 der beiden unterschiedlichen Geräte zeigen.
  IPv4-Port-Weiterleitungen auf der Fritz!Box interessieren dabei nicht, weil diese gar nicht gefragt wird, sie leitet nur durch.
• ... an einem Dual Stack-Anschluß ... (inkl. IPv4-only-Anschlüsse, auf denen zusätzlich ein IPv6-Tunnel eingerichtet wurde) ...
  

  X:\>nslookup nas1.gvambdcfesxyisow.myfritz.net
  Name: nas1.gvambdcfesxyisow.myfritz.net
  Address: 2a02:908:1234:1400:290:a9ff:fe45:5678
  Address: 123.45.67.89
  X:\>nslookup nas2.gvambdcfesxyisow.myfritz.net
  Name: nas1.gvambdcfesxyisow.myfritz.net
  Address: 2a02:908:1234:1400:290:a9ff:fe45:6789
  Address: 123.45.67.89

  Beide zeigen auf unterschiedliche IPv6-Adressen, denn jedes NAS - und jedes weitere Gerät im Heimnetz - hat eine eigene öffentliche IPv6 über die es direkt und ohne Umweg über NAT angesprochen werden kann.
  
  Zusätzlich zeigen beide Einträge auch auf eine IPv4, allerdings beide Male dieselbe, da das ganze Heimnetz ja nur diese eine hat.
  Um tatsächlich entweder das eine oder das andere NAS per IPv4 zu erreichen, müssen entsprechende unterschiedliche NAT-Port-Weiterleitungen von der öffentlichen IPv4 auf die lokale im LAN existieren.
  
  Somit gilt hier für den Zugriff per IPv6 das für IPv6-only-Anschlüsse und für Zugriffe per IPv4 das für IPv4-only-Anschlüsse Gesagte.

Für den Dienst von feste-ip gilt nun:

Es gibt absolut keinen Grund, die IPv6 der Geräte im Heimnetz umständlich aus Interface ID und Präfix zusammen zu basteln und dafür auch noch einen administrativen Zugang zur Fritz!Box einzufordern, wenn es auch einfacher und - da kein Zugang vergeben werden muß - auch sicherer direkt über die MyFritz!-Adressen geht.

 

[matchi]

Für den Dienst von feste-ip gilt nun:

Es gibt absolut keinen Grund, die IPv6 der Geräte im Heimnetz umständlich aus Interface ID und Präfix zusammen zu basteln und dafür auch noch einen administrativen Zugang zur Fritz!Box einzufordern, wenn es auch einfacher und - da kein Zugang vergeben werden muß - auch sicherer direkt über die MyFritz!-Adressen geht.

Hallo,

danke für die ausführliche Antwort, Du scheinst echt Spaß an der Materie zu haben

feste-ip.net sollte sein Tutorial zur fritz!box dahingehend anpassen, und eventuell bieten auch die anderen Routermodelle von UM eine ähnliche Funktionalität wie von AVM mit myfritz?!
Der service hat in meinen Augen durchaus seine Daseinsberechtigung, solange nicht jedes iPhone und jedes Heimnetzwerk ipv6 sprechen können....

 

[feste-ip.net]

Hallo,

Ich möchte mich nochmal kurz zu dem geschrieben äußern.
Da wir selbst "geografisch" bedingt keine DS-Lite Anbindung haben wurden die Portmapper auf Kundenanfragen hin entwickelt und bereitgestellt.

"Mit internen Präfix" meine ich das Präfix welches von der FritzBox per Routeradvertising an die internen Geräte weitergegeben wird.
Dieses ist nicht gleich dem von der Fritzbox für die externe Kommuniktion verwendeten und läßt sich auch nicht errechnen oder "erraten".
Das Auslesen über den Zugriff auf die Box ist momentan der einzige Wege dieses zu ermitteln. (Aussage AVM)
Das diese Möglichkeit aus Datenschutzsicht nicht "schön" ist, ist und bekannt und wir weisen auf unserer Seite auch darauf hin.

Dass die MYFritz Adressen "bis auf das lokale" Gerät reichen war mir bis jetzt nicht bekannt. Daraus läßt sich tatsächlich das von spacerat beschriebene Scenario abbilden.
Allerdings haben wir dann wieder das Problem, dass wir einen Präfixwechsel nicht aktiv mitbekommen würden und so die Gerätenamen alle X Sekunden im DNS Abfragen müßten.
(oder kann man myfritz und ddns parallel fahren?)
Aufgrund der Tatsache das wir dadurch keinen aktiven Boxzugang benötigen werden wir das überdenken.

@SpaceRat. Damit sollten denke ich alle Missverständnisse behoben sein?!

MfG
Rene Marticke
Feste-Ip.net

 

[SpaceRat]

Dass die MYFritz Adressen "bis auf das lokale" Gerät reichen war mir bis jetzt nicht bekannt. Daraus läßt sich tatsächlich das von spacerat beschriebene Scenario abbilden.

Sag ich doch

Die "1." MyFritz-Adresse, also die der Box selber, zeigt in der Tat nur auf die IPv6-Adresse, welche die Fritz!Box selber extern benutzt und das ist wirklich in der Regel keine aus dem Präfix/Subnet, welches dann am Ende die angeschlossenen Geräte benutzen.
Die bei MyFritz!-Freigaben angelegten "Unteradressen", also <Gerätename>.<Blahlaber>.myfritz.net verweisen hingegen wirklich auf die öffentliche IPv6 des jeweiligen Gerätes.

Allerdings haben wir dann wieder das Problem, dass wir einen Präfixwechsel nicht aktiv mitbekommen würden und so die Gerätenamen alle X Sekunden im DNS Abfragen müßten.

... es sei denn, für die Proxy-Konfiguration würde nicht die IPv6 selber, sondern der o.g. MyFritz-Hostname verwendet, denn der zeigt ja immer auf die aktuelle IPv6-Adresse ...

Eine solche Proxy-Konfiguration sähe dann z.B. in HAproxy 1.5 und höher so aus:

listen customer-proxy-12345 bind kundenserver.feste-ip.net:80 server customer-server-12345 [email protected]:80

Dieser Proxy würde an Port 80 des Servers kundenserver.feste-ip.net anbinden (Per IPv4 und IPv6) und alle Anfragen per IPv6 an Port 80 von webserver.abcdef123456.myfritz.net weiterleiten. HAproxy 1.5 ist notwendig, da die gegenwärtige Version 1.4 die oben verwendete Syntax "ipv6@" nicht versteht. Zudem löst HAproxy 1.4 Hostnames nur in A-Records auf, niemals aber in AAAA-Records.

Sprich: Bei Verwendung von HAproxy 1.4 kommt man nicht drumherum, Hostnames vorab in IPv6-Adressen aufzulösen und in der Config vorzukauen, ab 1.5 kann das durch gezieltes Forcieren von IPv4 oder IPv6 entfallen.

Der Vorteil bei der Verwendung von Hostnames ist auch, daß es noch andere Dienste gibt. die (fast) genauso arbeiten wie MyFritz!, z.B. WD2go.
Dort zeigt <NAS-Name>.device<Kundennummer>.wd2go.com ebenfalls auf die IP-Adresse des NAS. Derzeit zwar nur für IPv4, das kann sich aber ja noch ändern ...

Möglich wäre, daß auch MyDLink ähnlich arbeitet (Ich kaufe mir jetzt nicht extra einen D-Link-Router, um das auszuprobieren).

(oder kann man myfritz und ddns parallel fahren?)

MyFritz! und der DynDNS-Dienst der Fritz!Box sind absolut unabhängig voneinander.
Durch Verwendung von DNS-o-Matic als DynDNS-Dienst kann man sogar unzählige DynDNS-Dienste und MyFritz! parallel nutzen.

Aufgrund der Tatsache das wir dadurch keinen aktiven Boxzugang benötigen werden wir das überdenken.

Was kriege ich eigentlich dafür?

 

[feste-ip.net]

Hallo SpaceRat,

Danke für die Hinweise.
Mit DNS-O-Matic würden die Daten ja auch bei 3. liegen.
Haproxy haben wir uns damals auch angesehen, dann aber einangepasstes 6tunnel eingesetzt da sich damit einzelne Instanzen starten lassen und eine Konfigänderung nicht alle aktivieren Tunnel mitreißt.

Ich werde das MyFritzthema mal weiter verfolgen.

Wenn das umgesetzt ist kann ich dir gern einen kostenfreien Account zur Verfügung stellen.

/LG Rene

 

[SpaceRat]

Mit DNS-O-Matic würden die Daten ja auch bei 3. liegen.

Jain.

Die Anmeldedaten für diverse DynDNS-Dienste ja (MyFritz! aber nicht, das kann nur die Fritz!Box selber), aber eben keine fernwartungsgeeignete Anmeldedaten für die Fritz!Box selber.

Und da sehe ich schon einen qualitativen Unterschied:
Mit diesen Anmeldedaten für DynDNS-Dienste könnte DNS-O-Matic mir meine DynDNS-Accounts kapern oder mir andere IPs als die tatsächlichen unter meinen DynDNS-Hostnames unterjubeln. Das bringt denen aber rein gar nichts, weil ich mich an meinen Rechnern wiederum nur über sichere Dienste (https, sftp, ssh, usw.) anmelde und da würde mir ein untergejubelter Fremdserver schon anhand der Zertifikatsfehler auffallen. Außerdem können die das einfacher haben, denn DNS-o-Matic ist vom gleichen Anbieter wie OpenDNS¹ ... d.h. die könnten sowieso schon Millionen Nutzern gefakte IPs unterjubeln.

Also für DNS-o-Matic/OpenDNS absolut unnützes Wissen, vor allem wenn man für seine DynDNS-Accounts ganz andere Passwörter nutzt als anderswo.

Gebe ich hingegen jemandem Vollzugriff auf die Fritz!Box, dann kann er sich natürlich auch meine Konfiguration extrahieren und mit dieser
- Internet-Zugangsdaten (Bei PPPoE/DSL)
- VoIP-Zugangsdaten
- E-Mail-Zugangsdaten (Wenn ich Fritz!Box-Push benutze oder mal eingetragen habe)
- u.v.m.

Insbesondere der Punkt "E-Mail-Zugangsdaten" ist hochbrisant, denn mit diesen Daten wiederum kann ich über "Passwort vergessen" auf diversen illustren Seiten - meines Wissens nach z.B. auch PayPal - neue Passwörter für diese anfordern.
Zu allem Überfluß kann man auf einer Fritz!Box, wenn man deren Zugangsdaten kennt, auch noch einen kompletten Paket-Mitschnitt durchführen, praktischer Weise direkt im Wireshark-Format.

Sorry, aber das geht gar nicht.

Haproxy haben wir uns damals auch angesehen, dann aber einangepasstes 6tunnel eingesetzt da sich damit einzelne Instanzen starten lassen und eine Konfigänderung nicht alle aktivieren Tunnel mitreißt.

haproxy -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)

Aber 6tunnel ist auch ok.


¹ DNS-o-Matic entstand ja aus der Misere heraus, daß Benutzer oft nur ein einziges benutzerdefinierbares DynDNS-Update im Router eintragen können und das auch brauchen, während auch OpenDNS für erweiterte Funktionalität wie personalisierte White- und Blacklists ebenfalls ein DynDNS-Update erfordert.

 

[feste-ip.net]

Hallo Spacerat,

Kritik verstanden, angenommen, umgesetzt.
http://www.feste-ip.net/dslite-ipv6/universelle-portmapper/

Zusätzlich haben wir noch die FIP-Box aus der Taufe gehoben um den Zugriff auf IPv4 only Geräte hinter einem DS-Lite zu realisieren.
Wer sowieso einen Server im LAN hat macht es eh darüber. Wer aber nur eine IPv4 Webcam oder einen Haussteuerung hat die nur IPv4 spricht kann Sie über die FIP-Box wieder erreichen.

/LG Rene