Quick connect: Wie funktionierts?

[mgutt]

@ das wurde erst vor 2 Monaten eingeführt. Davon wusste ich tatsächlich nichts. Allerdings ist das nur ein optionaler Weg die Daten zu senden und damit das überhaupt geht, müssen beide Router das TCP hole punching unterstützen und die Netze der Provider müssen auch mitspielen. Geht das in Deutschland überhaupt (also z.B. Telekom zu Kabel Deutschland)? Infos dazu findet man so gut wie gar nicht.

Was ich aber vorher gesagt habe gilt trotzdem. Steht ja auch im Blog. Siehe den Punkt Auto-Switch.

 

[Matthieu]

Na dann zitiere ich mal daraus:

Port Punching gibt es erst seit DSM 5.2 (ausgehend von einer Diskussion dazu auf der CeBIT hatte ich sogar erst deutlich später, in ein paar Monaten damit gerechnet). Diese Diskussion ist jedoch weitaus älter. Ob Port Punching funktioniert, hängt im wesentlichen auch vom Netzwerkequipment ab. Je besser die Firewall des Routers ist, desto unwahrscheinlicher ist es dass eine Verbindung zu stande kommt. Daher war seither das eigentliche Konzept hinter QC eine Verbindung über die Server von Synology, was auch nach wie vor mehr als nur "Fallback" ist. Falls du über die neuen Möglichkeiten mit Port Punching diskutieren möchtest, würde ich einen neuen Thread empfehlen.

MfG Matthieu

 

[horstepipe]

nur mal ne kurze Frage:
Wenn ich für die Video Station die Vorteile von Quick Connect nutzen möchte, aber nicht will, dass die Daten über deren Server laufen, welche Ports müssen dann alle freigegeben werden? Nur der HTTP(S) Port, oder auch UDP 1900?

lG

 

[heavy]

Quick Connect nutzen möchte

aber nicht will, dass die Daten über deren Server laufen

Also das widerspricht sich bedingt. Wenn eine direkte Verbindung prinzipiell möglich ist, dann gehen deine Video daten nicht über die Server von Synology sondern nur der Handshake. Nur wenn keine direkte Verbindung funktioniert läuft auch die Übertragung der Daten über Synology. Ports brauchst du ja wegen der verwendeten Technik nicht zu öffnen

 

[horstepipe]

genau, und ich will sicherstellen, dass wirklich nur der Handshake über die Server läuft.

 

[heavy]

das kannst du nicht, entweder quickconnect mit allem drum und dran. Oder dyndns Dienst mit den entsprechenden Portfreigaben.

 

[horstepipe]

hmm ok, danke dir

 

[FuXXz]

Ich verstehe die ganzen Quickconnect Diskussion immer noch nicht.
Gebe ich in meinem lokalen Netzwerk die QC ID an -> steht im Browser meine lokale DS IP. Was hat Synology damit zu tun? Das geht direkt über diese IP.
Gebe ich QC ID z.B. ausserhalb des Netzwerkes an, steht im Browser mein primärer DynDNS Anbieter. Da is nix mit Synology Server.
Ich habe jedoch DDNS und alle Ports eingerichtet und nutzen der Relay Server in den QC Optionen deaktivert.

Also für mich ist Quickconnect nichts anderes als ein schöner Alias, der immer die richtige Verbindung aufbaut, je nachdem wo ich mich gerade befinde. Wie macht ihr das sonst mit z.B. Android und der FilStation App?
Konfiguriert ihr die Adresse immer um, wenn ihr zuhause im WLAN seid?

 

[mgutt]

Wenn dein Router NAT Loopback beherrscht oder das NAS über eine öffentliche IPv6 erreichbar ist, dann reicht überall die DDNS.

Ein Speedport kann zum Beispiel kein Loopback, aber eine Fritz Box schon, die allerdings mit hohen Einbußen bei der Performance. Bei IPv6 ist dagegen alles super.

Ich spare mir die Wiederholung der Argumente, die gegen QC sprechen. Das sicherste ist sowieso ein VPN nach Hause und dann eben über die lokale IP ansprechen.

 

[FuXXz]

Mit der QC ID übertrage ich mit 90MB im lokalen Netz, eben weil er die lokale IP nutzt und nicht irgendwelche Server. Z.B. mit Cloud Client, das gleiche gilt für QNAP, die sowas ja auch haben.
Da geht nix über irgendwelche Server. Wo wäre da auch der Sinn, vom lokalen Netzt zu Synology und dann wieder in mein lokales Netz zurück?

 

[mgutt]

Korrekt, aber nur weil Syno bei QC erst eins nach dem anderen durchgeht, bevor der Proxy eingesetzt wird.

Also:
Verbindung über QC Proxy und Status abfragen. Antwort von NAS sind dann lokale IP und DDNS. Nun testet die gerade genutzte App, ob das NAS lokal erreichbar ist, wenn nein, dann testet es die DDNS und wenn das auch nicht geht, dann kommt der QC Proxy zum Einsatz.

Da muss ich mich fragen, warum das nicht auch bei DDNS so gemacht wird. Warum wird nicht dabei auch erst die lokale IP getestet?

Jedenfalls läuft der Traffic über den QC Proxy, sobald du keine Portfreigaben aktiv hast und von unterwegs zugreifst.

 

[Matthieu]

Da muss ich mich fragen, warum das nicht auch bei DDNS so gemacht wird. Warum wird nicht dabei auch erst die lokale IP getestet?

Sorry, aber für die Frage musst du die technischen Hintergründe kennen. DNS war für soetwas nie gedacht, außerdem hätte ein solches Vorgehen große Sicherheitsprobleme wenn im großen Stil angewendet.

MfG Matthieu

 

[mgutt]

Es geht ja nicht um die DNS Spezifikation, sondern um die Apps. Die müssen einfach nur per DDNS beim NAS nach der lokalen IP fragen. Das erfolgt natürlich erst nach Login, wie es auch bei QC der Fall ist. Eine API auf dem NAS antwortet dann mit der lokalen IP und die App testet dann ob sie das NAS darüber erreichen kann. Ist das der Fall, dann wechselt die App einfach von der DDNS zur IP und fertig. Es besteht als keine Gefahr für DNS-Rebind-Angriffe.

 

[Matthieu]

Schon mal Synology drauf angesprochen/angeschrieben?

MfG Matthieu

 

[FuXXz]

Trotzdem verstehe ich die ewigen uralten Diskussionen immer noch nicht
Gehen wir von dem normalen Fall aus, dass ddns und Portfreigaben laufen.
Dann mache ich das entweder alles über VPN oder über die QC ID.

In meiner Android App steht die QC ID, wie soll ich es auch anders machen? Und es läuft so perfekt.

Wenn jemand technisch Bedingt keine Freigaben machen kann, Irgendwelche öffentliche Netze hat, Proxy etc. ist das nen ganz anderes Thema.
Für den normalen User ist es zumindest toll und hat KEINE Nachteile. Also verteufelt nicht immer das QC

 

[Matthieu]

Deine Haltung in allen Ehren, aber auch QC hat eine lange Entwicklung hinter sich. Nicht alle dieser Features waren von Anfang an vorhanden. Außerdem sind viele privat mit dem Thema konfrontiert, weil mehrere Anbieter keine öffentlichen Adressen rausgeben. Das heißt auch, dass es viele trifft die nicht die Mittel oder das Wissen haben sich alternativen zu schaffen und gleichzeitig nicht möchten dass ihre Daten woanders lang fließen als beabsichtigt.

MfG Matthieu

 

[mgutt]

Schon mal Synology drauf angesprochen/angeschrieben?

Syno hat noch nie was von meinen Vorschlägen umgesetzt. Selbst Fehlermeldungen wurden bisher gekonnt mit "wird weitergeleitet" und darauf folgender Untätigkeit ignoriert. Der deutsche Support ist zwar nett und bemüht, aber ich habe das Gefühl, dass Syno einfach macht was sie wollen.

Durch die Ausbreitung von IPv6 und der Möglichkeit QC nutzen zu können, wird es wohl eher unten in der Prio-Liste stehen

Aber ich versuche es gerne noch mal. Von nichts kommt bekanntlich nichts.

 

[soerenwagneremden]

Wo wäre da auch der Sinn, vom lokalen Netzt zu Synology und dann wieder in mein lokales Netz zurück?

Das sehe ich ein bisschen anders.

QC ist tatsächlich eine einfache Möglichkeit, damit das per Quickconnect angebundene Gerät die schnellste Verbindung automatisch nimmt. In meinem Fall z.B: habe ich die Cloudstation Ports in der Fritzbox entsprechend auf meine DS weitergeleitet. An meinem Notebook verbindet sich die Cloudstation über Quickconnect mit meiner DS. Befinde ich mich im LAN verbindet sich Cloudstation über LAN - befinde ich mich außerhalb, geht der Weg über meinen DDNS Hostnamen wieder direkt durch die Fritzbox zum NAS. Über die Quickconnect-Server wird hier lediglich abgefragt "Bin ich im gleichen Netz oder nicht?" --> Die Daten laufen bei beiden Varianten (über verschlüsselte SSL-Verbindungen) direkt zum NAS - ob im LAN oder aus dem WAN...