VPN vs Dyndns vs Quickconnect

[low-rider]

Hallo Alle zuammen,

ich bin zwar neu hier, habe mich aber beim Einrichen meiner DS 215j durch das Forum gelesen.

Ich nutze zur Zeit die Verbindung über Qickconnenct, was auch wunderbar funktioniert.
Zum Testen habe ich mein iPhone über die Externe IP mit VPN verbunden, auch alles super.

Nun aber zu meiner eigenltichen Frage:
Ich habe vor, mir ein DynDns Account bei Synology einzurichten, den ich dann benutze um mich über VPN zu verbiden.
Was habe ich nun für Vorteile? Ich benötige ja immernoch diese Dyndns Adresse, um mich per VPN zu verbindin.
Also könnte ich doch bei den ganzen iPhone Apps diese Adresse angeben, statt mich erst per VPN zu verbinden und dann über die interne IP?

Also was spricht für VPN und was für Dyndns der sogar Quickconnect? Ports müssen ja in beiden Fällen geöffnet werden (wobei ich über Quickconnect keine geöffnet habe).
Bei der Handhabung von Extern (iPhone Apps) ist es über VPN ein wenig aufwediger. Gibt es ein Geschwindigkeitsvorteil?

Gruß Jan

 

[Tommes]

Hallo Jan und Willkommen im Forum.

Quickconnect mag ja durchaus seine Daseinsberechtigung haben, jedoch ist und bleibt mir die Funktion und Arbeitsweise ein wenig suspekt und würde es daher nur im Notfall einsetzen. Nicht zuletzt das automatische konfigurieren der Ports für das sogenannte "port punshing" des Routers mittels UPnP läßt es mich eiskalt den Rücken runterlaufen. Aber das ist nur meine bescheidene Meinung und daher solltest du dir lieber dein eigenes Bild von QC machen. http://blog.synology.com/?p=2283

Gegen die Bereitstellung eines DDNS-Service seitens Synology spricht erstmal nichts, bis auf die Tatsache das der DDNS-Service nur solange funktioniert wie die DS im Betrieb ist und/oder du damit ausschließlich die DS von extern erreichen möchtest und du von deinem ISP eine ständig wechselnde - dynamische IP erhältst. Daher gehört für mich ein DDNS-Dienst genau wie auch VPN eigentlich in der Routerkonfiguration verankert, um so auch andere Geräte des lokalen Netzwerkes ggfs. nach extern erreichbach zu machen und zu halten, aber auch hier gehen die Meinungen auseinander. Auch funktioniert der DDNS-Dienst von Synology meines Wissens auch nur auf Synology-Geräten.

VPN gehört für mich auch primär in die Routerkonfiguration, jedoch würde ich hier auch guten Gewissens ein Auge zudrücken und diesen Service z.B. über die DS steuern und zwar deswegen, da du hier gleich mehrere Verfahren (PPTP, IPSec, OpenVPN) angeboten bekommst. Entsprechende Ports mußt du dann natürlich im Router weiterleiten.

Von der Sicherheit her würde ich immer VPN den Vorzug geben, den DDNS-Service benötigst du i.d.R. sowieso um dein System im Internet überhaupt ausfindig zu machen, und Quickconnect würde ich... na ja... muß halt jeder selber wissen. Ach ja und Ports wirst du auch immer irgendwo öffnen müssen um dein System zugänglich zu machen. Und VPN ist naturgemäß auch langsamer, aber Quickconnect soll wohl vom Hörensagen noch langsamer sein.

Tommes

 

[radioshack]

...das der DDNS-Service nur solange funktioniert wie die DS im Betrieb ist und/oder du damit ausschließlich die DS von extern erreichen möchtest

danke für die gute Erläuterungen.

Ergänzen möchte ich, dass damit natürlich auch andere Geräte (bei entsprechender Portweiterleitung im Router) im lokalen Netzwerk erreichbar sind.

 

[Tommes]

Ist vielleicht etwas missverständlich rüberkommen. Da der DDNS-Dienst im Prinzip ja nur deine aktuell vom ISP (Internet Service Provider) zugewiesene IP mit dem DNS-Namen abgleicht, ist natürlich auch jedes andere Gerät aus dem lokalen Netzwerk - bei entsprechender Portweiterleitung erreichbar. Das funktioniert aber nur solange die DS im Betrieb und damit der DDNS-Dienst von Synology aktiv ist. Daher wäre der DDNS-Dienst eher im Router zu verankern, da dieser i.d.R. eh 24/7 läuft. Auch reden wir nur von IPv4.

Tommes

 

[low-rider]

Vielen Dank für das genaue Erklären der Funktionen.
Ich benutze jetzt kein Quickconnect mehr und lasse alles über den DDNS-Dienst laufen.
Bei bedarf aktiviere ich dann den VPN Server und kann ganz bequem mit meinem Mac drauf zugreifen.
Das ist wirklich eine beqeme Sache, wenn man nicht zu Hause ist.
Die Verbundung ist auch um einiges schneller mit dem DDNS-Dienst.

Grüße Jan

 

[franzbertbua]

ich benutze derzeit noch quickconnect...

ich überlege aber auf den synology-dns dienst zuzugreifen...

sollte ja laut diesem thema sicherer sein...
oder kann hier jemand auch einen kostenlosen ddns dienst empfehlen?

oder macht von mehr sinn?

weil monatlich zahlen wie bei dyndns ist es mir dann auch nicht wert muss ich zugeben...

 

[Fusion]

z.B. spdyn.de oder dynv6.com oder selfhost.eu ....

 

[FrAntje]

Quickconnect ist vielmehr wie ein Vermittler zu verstehen.
Wenn du zuhause bist wird die Verbindung über deinen Router geleitet, also die lokale IP.
Bist du unterwegs und hast deine DS und Router mit Ports konfiguriert, wird diese Verbindung genutzt. Identisch mit der Verbindung über deine externe IP, dem Synology DDNS Dienst oder sonst einen Dyn DNS Anbieter
Bist du weder zuhause, noch hast du Zugriff auf die Konfiguration deines Routers, dann kann der Relay Dienst genutzt werden. Dies muss aber explizit in den Einstellungen aktiviert sein.

Somit sparst du dir also ständig deine Mobile Apps umzukonfigurieren, einfach deine QC ID rein und fertig.

Wenn du ausschließlich DynDNS nutzt, laufen deine Zugriffe aber auch darüber, wenn du zuhause bist und sind somit deutlich langsamer.

DynDNS bzw. Domain Anbieter mit eigener Domain gibt es zwischen 2-10 €, dann hast du aber deine eigene TLD und nicht irgendeinen Zusatz wie selfhost, no-ip etc.
Zudem sind dann auch beliebige Anzahl von DDNS Adressen mit gleichen Namen möglich, über die subdomains.

Ansonsten ist selfhost.de ein kostenloser Anbieter, bei dem nach einer Brief Identifikation auch die lästige 30 Tage Bestätigung aufgehoben werden kann.

 

[Fusion]

@FrAntje - freut mich zu sehen, dass es Leute gibt die das Thema QC differenziert sehen können und verstanden haben, eventuell sogar das White-Paper gelesen.

Persönlich habe ich QC und Syno DDNS allerdings trotzdem deaktiviert.
Einerseits, weil ich im Durchschnitt bei den Syno-Diensten mehr Aussetzer/Ausfälle habe, was die Erreichbarkeit angeht, wo ich bei anderen Anbieter über Jahre keinerlei merkbare Beeinträchtigung durch Wartungsfenster oder ähnliches habe.
Andererseits, weil wenn QC oder DDNS aktiv sind die Freigabe-Links die die Syno-Automatik erzeugt auch mit diesen Domain-Namen erzeugt werden und ich keine Lust habe diese immer von Hand zu bearbeiten, weil ich überall mit benutzerdefinierten Domains arbeite.

 

[Kurt-oe1kyw]

wenn QC oder DDNS aktiv sind die Freigabe-Links die die Syno-Automatik erzeugt auch mit diesen Domain-Namen erzeugt werden und ich keine Lust habe diese immer von Hand zu bearbeiten,

hmmmmmmm, ich glaube das könntest du aber "reparieren".
Wenn ich dich richtig verstanden habe möchtest du die Links aus der Photostation an deine Wünsche anpassen?
Probier mal bitte folgendes:

Photostation > Einstellungen > Allgemein > da gibt es den Punkt Router-Port, wenn ich da in der Zeile "Hostname" einen anderen Namen eintrage dann erzeugt auch die Synotautomatik die Freigabelinks nach dieser "Vorgabe", bei Bedarf sogar mit Port (dabei wird in den automatischen Links der Eintrag : portnummer eingefügt.
Also der Freigabelink lautet dann https://dein_eingetragener_hosname:port_falls_eingetragen/der restliche sharelink.
NUR wenn du dort nichts definierst lautet der automatische Link immer DDNS oder QC-ID.

Probiers mal aus, nach meinen Verständnis müsste das funktionieren:



der Teil .12355 ist nur eine Portnummer, falls jemand Ports umleiten möchte.
Ich meine mich erinnern zu können, das jemand hier im Forum erst vor ein paar Tagen nach so etwas gesucht hat und man ihm erklärt hat es geht nich weil die Photostation immer fix auf :80 oder :443 läuft, aber ich bin der Meinung dass das nicht stimmt.
Mit meiner Erklärung oben müsste es gehen das die automatischen Links jede "Form" und Portnummer erhalten können:



Du müsstest jetzt nur deine gewünschte domain auf die öffentliche IP vom Router umleiten hinter welchem die DS mit dieser Photostation läuft.
Leider kann ich es nicht testen da ich keine domains habe.

 

[Puppetmaster]

Gleiches gilt auch für die Links, die im DSM erzeugt werden (FileStation etc.). Deren URL kannst du ebenfalls in den Optionen des DSM anpassen bzw. individualisieren.

 

[Andy14]

Quickconnect ist vielmehr wie ein Vermittler zu verstehen.
Wenn du zuhause bist wird die Verbindung über deinen Router geleitet, also die lokale IP.
Bist du unterwegs ...

Aber bei jedem Verbindungsaufbau wird der Synology Server angefragt und dort stehen auch Sachen über das lokale Netz.
Das mag ich schon nicht, da bleibe ich lieber bei einem DynDNS Anbieter.

LAN/WAN Detection
When a client attempts to reach a Synology NAS using the server’s QuickConnect ID, a request is sent to Synology QuickConnect Server for the registered information of the NAS.
This allows the client to obtain network information about the server to identify possible ways to connect it.
The information includes the public IP, LAN IP, and NAT type among others,
all of which are necessary for the link and do not compromise the security of the NAS.
With the given information, the client can identify whether a direct connection with the IP or domain address can be established in LAN or WAN

 

[Fusion]

@kurt-danke für die ausführliche Schilderung. Es geht allerdings nicht um die Photo Station (jedenfalls nicht exklusiv, ist eh ein Sonderfall) sondern um alle Dienste die auf der DS so laufen.

Szenario (ich gehe jetzt mal von Werkseinstellungen aus, alles was nicht explizit erwähnt ist ist also unverändert)
Port 80/443 auf die DS geleitet
Domains per A-Record oder CNAME und dynDNS auf den eigenen Anschluß geleitet

Systemsteuerung > Anwendungsportal > Anwendungen und reverse Proxies mehrere Dienste konfiguriert auf benutzerdefinierte Domains / Hostnamen
bsp.
audio.domain.de
file.domain.de
drive.domain.de
...

Logge ich mich jetzt z.B. per file.domain.de ein in die File Station und erzeuge einen Share-Link/Freigabe, dann lautet dieser auf
https://file.domain.de/sharing/io0wwHRva
Logge ich mich über die benutzerdefinierte Domain des DSM (Systemsteuerung > Netzwerk > DSM Einstellungen) ein lautet der generierte Link auf
https://dsm.domain.de/sharing/g1RuuLlrs
Die Domains sind hier vertauschbar, je nachdem ob ich mir die Links im Link Manager direkt in der File Station oder mit Login im DSM und dort in der File Station anzeigen lasse steht die jeweils andere Domain im Link.
So weit so gut.

Aktiviere ich jetzt QC und "File Sharing" ist dort aktiv gesetzt lauten die Links auf
https://gofile.me/2VpGI/oPDnCpbas
Die Domains sind nicht mehr austauschbar und der Aufruf schlägt zudem fehl.
Aus welchem Grund finde ich jetzt gerade nicht heraus.
Auch ein Eintrag unter Systemsteuerung > Externer Zugriif > Erweitert auf file.domain.de und port 443 hilft nicht.
Die Share Links werden dann weiter mit gofile.me angezeigt und zeigen irgendwo ins Leere.

Abgesehen davon, dass ich keine gofile Links verschicken will. dauert der Aufbau länger und schlägt hier fehl, weil die Automatik anscheinend in dieser Konstellation den Weg nicht findet.

Würde das gerne jetzt nochmal aufdröseln, ist mir aber gerade zu viel Arbeit / Zeit die ich nicht investieren will, weil die Tests ja doch recht umfangreich sind bei den Konstellation die in den Einstellungen alle möglich sind.

@Puppet - meinst du Externer Zugriff > Erweitert, oder welche Individualisierung?

 

[Puppetmaster]

Genau. Externer Zugriff -> Erweitert. Damit werden auch die Links (ob alle, weiß ich nicht) verändert, die der DSM erzeugt.

 

[Fusion]

Ja, das ist die Krux. Die Einstellung "überstimmt" zwar glaube ddns, aber anscheinend nicht Quickconnect.
Scheinbar auch nicht, wenn "File Sharing" in QuickConnect abgewählt ist (und benutzerdefinierte Domains für DSM und Apps definiert sind).

Hätte meine Versuche besser dokumentieren sollen mit DSM6 (welcher Link generiert wird, wenn welche Einstellungen (QC, DDNS, Anwendungsportal, Externer Zugriff) wie gesetzt oder nicht gesetzt waren, welche Ports, etc. pp und wie die sich gegenseitig beeinflussen). Ob die dann allerdings noch Gültigkeit hätten in vollem Unfang mit 6.1 oder 6.2 wieder ne andere Frage.
Es gibt zwar viele Möglichkeiten, aber alle Dienste die ich wünsche nach demselben Schema zu bedienen ist oft schwierig und manchmal unmöglich.
Wenn man sich also festlegt, nur mit benutzerdefinierten Domains/Reverse proxies (ala sub.domain.de) zu nutzen, oder nur mit /alias, oder nur mit Ports,.... irgendwo eckt man immer an.

Für mich müsst ihr jetzt auch keine Lösung finden.
Ich habe für mich entschieden mit benutzerdefinierten Domains / Reverse Proxies zu fahren. Was so nicht geht via 80/443 benutze ich nicht, oder suche mir eine Alternative die so funktioniert wie ich es will.
Meine aktuelle Baustelle liegt eher IPv4/v6 mit Domains und Reverse proxies und Diensten die auf verschiedenen Maschinen im Netz laufen.
So dass egal ob ein IPv4/v6 Client anfragt trotzdem mit LE-Zertifikat und Portweiterleitung (IPv4 läuft ja via DS)/Freigabe (IPv6 direkt ans Zielgerät) alles sauber ist und trotzdem am richtigen Ziel ankommt.

 

[Kurt-oe1kyw]

#13 und #15
vielen, vielen Dank Fusion deine Beiträge haben mich auch wieder ein Stück weitergebracht um das eine odere andere besser zu Verstehen und hinter die Zusammenhänge zu kommen.
Ich hatte gedacht ich kann einem alten Hasen eine neue Funktion zeigen

Aber ich lerne und komme jeden Tag ein Stück weiter, Dank eurer Beiträge hier.

 

[FrAntje]

Das hat QNAP unheimlich gut gelöst. Sobald ich dort eine Freigabe erstelle, bekomme ich eine DropDown Feld mit allen Adressen. Also lokale ip, VPN, Quickconnect, dyndns usw.
So kann ich bei jeder Freigabe individuell sagen worüber sie erreichbar sein soll

 

[TeXniXo]

DAS wäre wirklich eine nette Feature ... ^^

 

[FrAntje]

@Fusion
Bei mir ist es zumindest wie folgt:

Fall 1. Ich trage kein Quickconnect ein, kein DDNS, Externer Zugriff ist leer, kein reverse oder keine domains irgendwo eingetragen.
Die DS erstellt immer Links mit dem Hostnamen / IP, mit der ich gerade eingeloggt bin. In diesem Fall können es dann nur die interne IP oder die externe IP sein.
Beides natürlich nutzlos

Fall 2. Nun trage ich einen DDNS Namen ein, lasse alles andere genauso. Jetzt wird immer dieser DDNS Name genommen. Bei Photostation Filestation und im Anwendungsportal stehen auch die Links zu den Programmen jeweils mit der DDNS Adresse.Geteilte Links haben dann natürlich auch den DDNS NAmen.

Fall 3. Ich trage unter Externer Zugriff - Erweitert einen Hostnamen ein, dann hat dieser die höchste Priorität. Egal ob ich DDNS laufen habe oder nicht. Ob ich nun mit lokaler IP oder über DDNS Namen einen Link erstelle, es wird immer dieser Hostname genommen, den ich hier eingetragen habe.

Fall 4. Egal was ich tue, sobald Quick Connect an ist, werden Links mit gofile versehen. Dies kann man aber abschalten unter QuickConnect - Erweitert und dann den Haken bei Dateifreigabe raus.
Dann werden wieder Links in der Reihenfolge wie oben beschrieben, generiert.

Ich persönlich habe im QC alles aus, bis auf die Mobilen Anwendungen. Denn genau hier findei ch QC genial.

Oder wie macht ihr das sonst? Ich habe z.B ein Tablet mit DS CAM. Wenn dort meinen DDNS Namen eintrage, dann gehe ich über das langsame Internet, wenn ich zuhause bin.
Ich muss also täglich die Adresse in der App ändern. Ergo QC

 

[Fusion]

Wie gesagt, ich nutze nur benutzerdefinierte Domains, auch in den Apps.
Einziger Pferdefuß, man muss die App-interne Port-auswahl überstimmen, z.B. file.domain.de:443, damit er trotz file.domain.de und Haken bei https eben den korrekten Port 443 benutzt und nicht 5001 oder ähnlich.

DDNS geht nicht über das "lahme Internet". Wenn der Router das NAT-Loopback / Hairpin-NAT / DNS-Rebind Schutz unterstützt und der Aufruf von sub.domain.de im LAN/WLAN korrekt an die DS geht, dann verlässt auch der Traffic nicht das lokale Netz. Einzig wird am Router zweimal das NAT "überquert" (von der LAN zur WAN und zurück zur LAN Schnittstelle, alles innerhalb des Routers).
Das kostet zwar Performance, aber jede halbwegs moderne Router sollte das mit 700-1000 MBit/s schaffen.