Port Forwarding die 500.

In vielen Netzen von Unitymedia sind Internet und Telefonie bereits verfügbar.
Forumsregeln
  • Kunden aus Hessen und Nordrhein-Westfalen können über die Rufnummer 0221 / 466 191 00 Hilfe bei allen Problemen in Anspruch nehmen.
  • Kunden aus Baden-Württemberg können über die Rufnummer 0711 / 54 888 150 Hilfe bei allen Problemen in Anspruch nehmen.
Antworten
Benutzeravatar
phoenixx4000
Übergabepunkt
Beiträge: 480
Registriert: 30.03.2008, 22:36
Wohnort: Geldern

Re: Port Forwarding die 500.

Beitrag von phoenixx4000 » 06.11.2013, 18:35

grouper hat geschrieben:Voice over IP sowie P2P ist ja laut Unitymedia AGB eh nicht gestattet...

http://app.unitymedia.de/service/index. ... et-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:

Benutzeravatar
matchi
Kabelneuling
Beiträge: 12
Registriert: 07.11.2013, 11:21

Re: Port Forwarding die 500.

Beitrag von matchi » 07.11.2013, 11:34

*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
erfahrener Kabelkunde
Beiträge: 59
Registriert: 04.11.2013, 09:51

Re: Port Forwarding die 500.

Beitrag von grouper » 07.11.2013, 12:21

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

Benutzeravatar
matchi
Kabelneuling
Beiträge: 12
Registriert: 07.11.2013, 11:21

Re: Port Forwarding die 500.

Beitrag von matchi » 07.11.2013, 12:28

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.

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Port Forwarding die 500.

Beitrag von SpaceRat » 07.11.2013, 14:37

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:

Code: Alles auswählen

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.
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

feste-ip.net
Kabelneuling
Beiträge: 5
Registriert: 25.11.2013, 17:24

Re: Port Forwarding die 500.

Beitrag von feste-ip.net » 25.11.2013, 17:41

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

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Port Forwarding die 500.

Beitrag von SpaceRat » 25.11.2013, 19:09

feste-ip.net hat geschrieben:
SpaceRat hat geschrieben: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.
feste-ip.net hat geschrieben:
SpaceRat hat geschrieben: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.
feste-ip.net hat geschrieben: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.
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

Benutzeravatar
matchi
Kabelneuling
Beiträge: 12
Registriert: 07.11.2013, 11:21

Re: Port Forwarding die 500.

Beitrag von matchi » 25.11.2013, 22:00

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"

Bild

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

Code: Alles auswählen

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):

Code: Alles auswählen

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.

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Port Forwarding die 500.

Beitrag von SpaceRat » 26.11.2013, 09:41

matchi hat geschrieben: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.
matchi hat geschrieben: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 ...
matchi hat geschrieben: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ß ...

    Code: Alles auswählen

    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ß ...

    Code: Alles auswählen

    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) ...

    Code: Alles auswählen

    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.
Zuletzt geändert von SpaceRat am 26.11.2013, 19:12, insgesamt 1-mal geändert.
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

Benutzeravatar
matchi
Kabelneuling
Beiträge: 12
Registriert: 07.11.2013, 11:21

Re: Port Forwarding die 500.

Beitrag von matchi » 26.11.2013, 13:23

SpaceRat hat geschrieben: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
Kabelneuling
Beiträge: 5
Registriert: 25.11.2013, 17:24

Re: Port Forwarding die 500.

Beitrag von feste-ip.net » 06.01.2014, 16:27

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

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Port Forwarding die 500.

Beitrag von SpaceRat » 06.01.2014, 17:08

feste-ip.net hat geschrieben: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.
feste-ip.net hat geschrieben: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:

Code: Alles auswählen

listen customer-proxy-12345
   bind kundenserver.feste-ip.net:80
   server customer-server-12345 ipv6@webserver.abcdef123456.myfritz.net: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).

feste-ip.net hat geschrieben:(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.
feste-ip.net hat geschrieben:Aufgrund der Tatsache das wir dadurch keinen aktiven Boxzugang benötigen werden wir das überdenken.
Was kriege ich eigentlich dafür? :)
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

feste-ip.net
Kabelneuling
Beiträge: 5
Registriert: 25.11.2013, 17:24

Re: Port Forwarding die 500.

Beitrag von feste-ip.net » 16.01.2014, 08:31

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

Benutzeravatar
SpaceRat
Glasfaserstrecke
Beiträge: 2467
Registriert: 08.05.2010, 01:30
Wohnort: Kreis Aachen
Kontaktdaten:

Re: Port Forwarding die 500.

Beitrag von SpaceRat » 16.01.2014, 11:16

feste-ip.net hat geschrieben: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.

feste-ip.net hat geschrieben: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.
Receiver/TV:
  • Vu+ Duo² 4xS2+2xC / OpenATV 6.1@Samsung 50" Plasma
  • AX Quadbox HD2400 2xS2+2xC / OpenATV 6.1@Samsung 32" TFT
  • 2xVu+ Solo² / OpenATV 6.1
  • DVBSky S2-Twin PCIe@SyncMaster T240HD (PC)
  • TechniSat SkyStar HD2@17" (2.PC)
Pay-TV: Schwarzfunk, Redlight Elite Superchic, SCT 10, HD-, Sky
Fon: VF Komfort-Classic (ISDN), 2xFritz!Fon C4+Siedle DoorCom Analog@F!B 7390
Internet: UM 1play 100 / Cisco EPC3212+Linksys WRT1900ACS / IPv4 (UM) + IPv6 (HE)
Bild

feste-ip.net
Kabelneuling
Beiträge: 5
Registriert: 25.11.2013, 17:24

Re: Port Forwarding die 500.

Beitrag von feste-ip.net » 20.01.2014, 13:01

Hallo Spacerat,

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

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

Antworten

Wer ist online?

Mitglieder in diesem Forum: brisbone, MaXX, sch4kal und 8 Gäste