Quick connect: Wie funktionierts?

[Hobbyuser]

Hallo zusammen,

für das NAS gibt es ja die Quick Connect Funktion, die es laut Doku ermöglichen soll auf das Nas vom Inet zuzugreifen ohne dazu Ports im Router zu forwarden.

Wie funktioniert dies?

Meinem Wissen nach geht das nur mit zwei Möglichkeiten:
1. Der Router wird vom NAS per UPNP konfiguriert
2. oder das Nas baut von INNEN eine dauerhafte Verbindung zu einem Server auf, der dann auf Zugriffe von Clients wartet und dies ans NAS weiterleitet....

Irgendwie ist mir noch nicht so ganz klar, wie das realisiert wird.

Ich danke euch für eure Antworten.

Grüße.

 

[rauppe31]

Da stimmt 2.
Deine NAS baut eine (sehr langsame) Verbindung zum Synology-Server auf. Deine NAS überträgt deine Daten also zuerst zum Synology-Server und dieser leitet die Daten dann an den PC weiter.

 

[Matthieu]

Es gibt ez-Internet um mit ein paar Dialogen und UPnP die Ports freizugeben (kann man später auch von Hand im DSM machen) und ezCloud/QuickConnect wo die von dir als 2. beschriebene Methode angewandt wird. Kann man mit Wireshark schön verfolgen.
Die Beschreibung von rauppe kann ich aber nicht so ganz teilen, da die DS den Client nur "abholt", die Daten selbst also direkt gehen sollten. Wenn die Verbindung einmal steht sollte das problemlos möglich sein. Würde auch sonst extreme Anforderungen an die Server stellen was gar nicht zu Synology passt.

MfG Matthieu

 

[rauppe31]

Es gibt ez-Internet um mit ein paar Dialogen und UPnP die Ports freizugeben (kann man später auch von Hand im DSM machen) und ezCloud/QuickConnect wo die von dir als 2. beschriebene Methode angewandt wird. Kann man mit Wireshark schön verfolgen.
Die Beschreibung von rauppe kann ich aber nicht so ganz teilen, da die DS den Client nur "abholt", die Daten selbst also direkt gehen sollten. Wenn die Verbindung einmal steht sollte das problemlos möglich sein. Würde auch sonst extreme Anforderungen an die Server stellen was gar nicht zu Synology passt.

MfG Matthieu

Und wieder was gelernt.

 

[itari]

es funktoniert ein wenig so, wie auch Schadprogramme ihren Server auf einem PC hinter einem nicht-durchlässigen Router freischiessen ... er verhält sich im ersten Schritt wie ein Client und bombt die Ports im Router frei (und das wird ja bei uns auch so gemacht, in dem eine Verbindung zum Synology-Server aufgebaut wird)

Itari

 

[Hobbyuser]

Danke für eure Antworten, hat jemand vielleicht noch einen deraillierteren Link zur Hand, was es mit der ezcloud und dem ezinternet auf sich hat? Was bedeutet das ez überhaupt.....

Danke euch recht herzlich.

Grüße

 

[itari]

u2 => you too

cu => see you

ez => easy (einfach, simpel)

Itari

 

[amarthius]

ezCloud

ezInternet

 

[Hobbyuser]

Hallo,

nochmals vielen Dank. Ich habe mir die beiden Links mal genauer angeschaut.

Zu ezinternet (zur Routerfreigabe) habe ich noch eine Frage: Es scheint ja mehrere Möglichkeiten zu geben, die Routerports über die DS freizuschalten (Automatisch, manuell, Router ist in der Liste etc).

Funktioniert dies bei allen diesen Methoden über UPNP? Oder gibt es noch andere Protokolle, Schnitstellen etc. mit denen Router und DS kommunizieren können?

UPNP ist bei mir im Router deaktiviert, das kann die DS doch in diesem Fall auch nicht einfach aktivieren?!

Grüße

 

[Matthieu]

Ich weiß zwar nicht ganz worauf du hinaus willst, aber sämtliche dieser Konfigurationsoberflächen greifen auf einen Kern zurück der über UPnP auf den Router zugreift. Wenn sich UPnP bei diesem von "außerhalb" einschalten ließe, würde ich das als Bug werten.
Auch dieses "Router in der Liste" ist UPnP, nur weiß die DS da genau wie sie vorgehen muss. Es gibt wie so oft zwischen den Herstellern leichte Unterschiede und daher kann bei den Routern aus der Liste garantiert werden dass es funktioniert indem Synology dazu Infos hinterlegt hat. Bei allen anderen geht es dann nach dem "Try & Error"-Prinzip. Entweder es geht oder eben nicht.

Ports sollte man aber eigentlich direkt im Router freigeben. Da weiß man meist besser was dann passiert.

MfG Matthieu

 

[_PP_]

Hab jetzt so auf die Schnelle nichts im Web dazu gefunden, daher die Frage hier:

Wie sieht es mit der Sicherheit und der Korrumpierbarkeit von Quick-Connect aus? Kann da jemand (belegbare) Aussagen dazu machen?

Gruß
Peter

 

[Village Hero]

@_PP_ QuickConnect ist ein reiner Relay-Service - d.h. deine DS meldet ihre IP (bzw. die deines Routers) an den Synology-Server. Greifst du auf diesen zu, leitet er dich dann an deine DS weiter. Hier musst du dich vermutlich (hab's selbst nicht am laufen - Erklärung unten) ganz normal an... Korrumpierbar ist das nur, wenn jemand jemand sich als Synology-Server ausgibt und den (hoffentlich verschlüsselten) Verkehr auch noch fälschen kann (sog. Man-in-the-Middle). Das ist möglich, aber sehr sehr unwahrscheinlich.

Ansonsten seh ich als großen Nachteil von QuickConnect, daß deine DS ja dann ständig laufen muss um die IP weiterzumelden.

Energiesparender ist die IP-Weitermeldung aber einfach deinen Router übernehmen zu lassen. Das nennt sich dann offiziell DynDNS und kann eigentlich jeder Router. Wenn du dann noch deine DS auf Wake-On-Lan konfiguriert hast, hast du die maximale Energieersparnis. Funktioniert bei mir tadellos. Als Dienst nehm ich selfhost.bz.

 

[goetz]

Hallo,

Ansonsten seh ich als großen Nachteil von QuickConnect, daß deine DS ja dann ständig laufen muss um die IP weiterzumelden.

meine DS legt sich trotz Quickconnect ganz brav schlafen.

Gruß Götz

 

[soerenwagneremden]

Ein weiterer Vorteil von quickconnect:

Befindet man sich im LAN, connected z.B. Die cloudstation (wenn über quickconnect konfiguriert) ebenfalls über LAN. Bin ich nicht im LAN geht's übers inet. Das ist sehr praktisch wenn man häufig den Standort wechselt.

 

[soerenwagneremden]

Ich habe auf drei unterschiedlichen Systemen an drei Standorten einen netzwerkfehler bei quickconnect. Geht's euch auch so?

 

[matze_de]

Sorry, dass ich mich jetzt auch noch mit max. gefährlichem Halbwissen einschalte.

Gibt es nun gravierende Nachteile bei der Nutzung von Quickconnect im Vergleich zu EZConnect mit Portforwardings oder nicht? Quickconnect ist ja viel einfacher einzurichten und auf die DSM muss ich von außen ohnehin eigentlich nicht...

Danke für die Aufklärung ;-)

 

[mgutt]

In meinen Augen gibt es vier Argumente gegen Quickconnect

1.) Privatsphäre. Will man dass die eigenen Daten über einen dritten Server geroutet werden oder nicht. Auch die Frage ob man Synology ständig die eigene IP mitteilen möchte. Dazu zählt auch, dass Synology keine Dokumentation bereitstellt wie Quickconnect genau funktioniert.

2.) Ausfallsicherheit. Sobald die Quickconnect-Server offline gehen, kann man den Service nicht mehr nutzen. Allerdings gilt das auch für den DynDNS Server, der allerdings nur 1x in 24 Stunden (beim Wechsel der IP) erreichbar sein muss.

3.) Geschwindigkeitkeit. Wenn mein Anschluss einen höheren Upload bietet als Quickconnect, dann ist der im Vorteil.

4.) (unbestätigt) Funktioniert nicht in eingeschränkten Netzen. Wobei ich das nicht mit DynDNS testen konnte, weil mein Router kein separates Port-Forwarding für DynDNS beherrscht. Und zwar wenn man in der DS Cloud App als Ziel diskstation.example.org:443 angeben kann, dann ist der Service im Vorteil, weil er auch in Gast-WLANs funktioniert, die nur 80 und 443 erlauben. Hier verstehe ich das allerdings so, dass es nicht geht:
http://forum.synology.com/enu/viewtopic.php?f=194&t=48204

In dem Fall könnte der empfangende Router diesen Port auf den internen 6690 weiterleiten.

Befindet man sich im LAN, connected z.B. Die cloudstation (wenn über quickconnect konfiguriert) ebenfalls über LAN.

Das ist korrekt und im Grunde ein Mangel der App, weshalb ich Synology mehrere Adressen als Verbindungspunkt vorgeschlagen habe. Also statt "diskstation.example.org" auch "192.168.1.10,diskstation.example.org" erlauben, so dass jeder Punkt durchgearbeitet wird.

Alternativ hätte Synology das auch so machen können, dass man seine HEIM-WLAN-SSID hinterlegen kann und immer dann lokal verbunden wird, sobald das Smartphone damit verbunden ist. Mir wird der Fokus eindeutig zu stark auf das Quickconnect gelegt.

Übrigens lässt sich das lösen, aber nur wenn der Router Loopback beherrscht. D.h. wenn er selbst eine DNS Anfrage zu diskstation.example.org bekommt, dann löst er die nicht auf die öffentliche, sondern auf die lokale IP auf. Leider kann die Fritz!Box das nicht (mehr).

 

[Matthieu]

1.) Privatsphäre. Will man dass die eigenen Daten über einen dritten Server geroutet werden oder nicht. Auch die Frage ob man Synology ständig die eigene IP mitteilen möchte. Dazu zählt auch, dass Synology keine Dokumentation bereitstellt wie Quickconnect genau funktioniert.

Zumindest der erste Teil dieser Aussage ist nach meinem aktuellen Kenntnisstand falsch. Synology hat kein Interesse daran den Traffic zu routen, weil das für eine riesige Server- und Bandbreitenauslastung der QuickConnect-Server sorgen würde. Stattdessen bringt QuickConnect die beiden Seiten lediglich "zusammen", ist aber ab diesem Handover nicht weiter beteiligt.
Ansonsten gilt wie immer: Es ist ein proprietäres System und damit eine Black Box. Man kann vieles etwa durch Netzwerkmitschnitte nachvollziehen, aber die Funktionsweise selbst werden sie wohl kaum rausrücken, sonst könnten sie es auch gleich unter Open Source stellen.
Die eigene IP muss man auch immer rausrücken wenn man von außen zugreifen möchte. Da kommt man nun mal nicht dran vorbei.
Entsprechend erledigt sich IMHO auch Punkt 3.

2.) Ausfallsicherheit. Sobald die Quickconnect-Server offline gehen, kann man den Service nicht mehr nutzen. Allerdings gilt das auch für den DynDNS Server, der allerdings nur 1x in 24 Stunden (beim Wechsel der IP) erreichbar sein muss.

Bei DNS muss man keineswegs nur ein Mal in 24h verbinden, schließlich muss ja jeder Besucher nach der IP fragen. Sind die öffentlichen DNS-Server des Anbieters ausgefallen, ist die eigene DS nicht mehr erreichbar. Dass QuickConnect ab und an ausfällt dürfte viel eher daran liegen, dass Synology gerade in der Anfangszeit Probleme hatte den Service angemessen zu skalieren und die Software auch nicht so stabil ist wie man das von DNS erwarten kann.

PS: Ich möchte QuickConnect nicht verteidigen; bin selbst auch kein großer Freund davon. Aber fachlich falsche/fragwürdige Punkte möchte ich auch nicht hier stehen lassen.

MfG Matthieu

 

[mgutt]

1.) Das Wort "Zusammenbringen" klingt zwar ganz nett, ändert aber nichts daran, dass der Traffic komplett über die Synology Server läuft. Das siehst Du einmal daran, dass es langsam ist, egal mit welchem Speed man selbst angebunden ist und zweitens kannst Du auf beiden Seiten alle eingehenden Ports sperren und es funktioniert trotzdem, was belegt, dass beide Seiten mit einem Knoten im Internet verbunden sind und nicht direkt miteinander. Wie die Technik genau funktioniert, keine Ahnung, aber ich kann ja auch nur das wiedergeben was man nachvollziehen kann.

Vielleicht ist es sicher, weil das Paket mit dem Schlüssel der DS verschlüsselt wird, aber kennt der Synology Server den Schlüssel? Ich vermute mal schon, weil der ist ja Middle-Man.

Quickconnect OpenSource? Hat bestimmt keiner was dagegen und ist sicherlich keine neue Technologie.

Wenn ich von außen auf mein NAS zugreife, woher willst Du dann meine IP kennen? Und selbst wenn Du sie kennst, weil Du z.B. einen Deeplink auf einen Download von mir bekommen hast, so heißt das noch lange nicht, dass Synology 24 Stunden am Tag ebenfalls diese Kenntnis besitzt. Das ist ja aktuell der Fall. Und warum erledigt sich dadurch Punkt 3?!

Es ist auch völlig egal ob nun alles ganz toll verschlüsselt ist. Synology weiß wie viele Endgeräte man benutzt, welches NAS man besitzt, wie lange es eingeschaltet ist, wie viele Daten von und zu welchem Endgerät übertragen werden, wo ich gerade mit meinem Endgerät bin, usw. Solche Daten sind nicht nur wertvoll für Synology.

Und wenn der Server von Synology gehackt wird, was dann? Vielleicht ist er das schon oder vielleicht steht die NSA schon mit einem Mitarbeiter daneben. Die NSA interessiert mich wirklich überhaupt nicht. Aber ich glaube kaum, dass die NSA die Einzigen sind sowas zu machen. Ich hinterfrage also mein Nutzerverhalten und das sollte jeder machen. Fakt ist, dass keiner weiß wie die Technik funktioniert, wie sicher sie ist und wer sie einsehen kann. Und Vertrauen ist zwar gut, aber selber machen ist besser.

2.) Das schöne am DNS ist, dass man immer eine Secondary-IP eintragen kann. Trägt man beispielsweise den von der Telekom und den von Google ein dürfte die Wahrscheinlichkeit gleich Null sein, dass beide ausfallen. Und 99,99999% Ausfallwahrscheinlichkeit sind mir immer noch lieber als 99% und ich habe ja auch nicht behauptet, dass das nun das einzige oder gar das Hauptargument gegen Quickconnect sei.

 

[fpo4711]

@mgutt

ich wäre mit deinen fachlichen Aussagen etwas vorsichtiger. In deinen Beiträgen sind soviele fachliche Fehler das ich das gar nicht erst kommentieren will. Ohne das jetzt gerade aktuell überprüft zu haben, bin ich mir sicher das dir das Matthieu richtig beschrieben hat.

Vieleicht solltest Du ja mal einen Netzwerk-Sniffer bemühen und dann damit dein Halbwissen ein wenig auf Vordermann bringen. Hier mal ein Begriff der für ein mögliches Verfahren gebräuchlich wäre womit der Inhalt nicht über den Synology-Server geroutet würde.

UDP hole punching

Das Für und Wider bezüglich QuickConnect möchte ich nicht weiter eingehen. Aber welche Daten von wo nach wo gehen kann man doch auch prüfen und dann eine qualifizierte Aussage treffen.

Und NSA - Ich kann es nicht mehr hören.

Gruß Frank