Freigabe über Drive ohne DSM über quickconnect

[Hagen2000]

Betreibst du eine FRITZ!Box? Dann musst du beim Rebind-Schutz für deinen DDNS-Namen eine Ausnahme erstellen.

 

[Jo92]

Das war es! Vielen Dank! Mensch meine Lernkurve ist steil aktuell! Ich probiere morgen weiter rum, da kommt sicher noch die ein oder andere Frage auf...

 

[Jo92]

So um einmal die Ergebnisse zusammen zu fassen:

• Wenn man von einem Dienst wie Drive oder Photos über Quickconnect (QC) Dateien/Ordner freigeben möchte, muss man auch DSM über Quickconnect freigeben. Macht man das nicht, kann man nicht auf die Links zugreifen.
• Möchte man nicht, dass DSM über QC erreichbar ist, muss man über einen DDNS gehen. In meinem Beispiel habe ich es einfach mit synology.me gemacht. Das geht auch wenn man DS-Lite hat. Dann darf man eben nur über IPv6 den DDNS erstellen.

Heute habe ich mich selbst noch etwas weiter damit beschäftigt. Weil meine DDNS bei Synology einfach eine Anzahl x an zufälligen Zeichen ist, wollte ich noch eine Domain dahin linken. Ich hatte noch eine Domain bei Ionos. Dort habe ich einfach eine Subdomain angelegt und per CNAME auf die synology.me zeigen lassen. Musste noch ein neues Let's Encrypt Zertifikat in der Synology für die neue Subdomain generieren aber nun läuft es.

Ich glaube ich habe noch eine letzte abschließende Frage. Kann ich der Synology noch irgendwie beibringen, dass der Zugriff eigentlich über die Subdomain läuft und er die Freigabelinks direkt mit der Subdomain bauen soll?

 

[Benares]

Bei mir werden die Links so "gebaut" bzw. angezeigt, wie ich grade selbst angemeldet bin.
Edit: Quatsch, stimmt nicht ganz. Er nimmt wohl den Namen, der im Anmeldeportal als Domain bei Drive angegeben ist. Nur wenn dort nichts steht, nimmt er den aus der aktuellen URL.

 

[Jo92]

Ach das hatten wir doch schon Mal. Ok, das teste ich gleich nochmal! Baue gerade noch ein paar Dinge um.

Aber ich frage mich gerade: Erhöht es wirklich die Sicherheit, dass ich beim ddns 24 zufällige Zeichen habe und nicht einfach irgendeinen Namen. Ich dachte mir, dann kann niemand einfach die synology.me Adressen durchprobieren. Also er kommt zumindest schwieriger auf meine. Oder ist das Quatsch und eher pseudo Sicherheit?

 

[Benie]

Ausschlaggebend ist in meinen Augen das Passwort, wie das gewählt wurde. Wie dies generiert wird, kann man gut dem Passwortmanager überlassen, insofern man hierfür entsprechen gute Einstellungen gewählt hat. Denn was nutzt es jemanden vor der Haustüre zu stehen, den Namen am Türschild lesen zu können, wenn er doch den Schlüssel nicht hat.

 

[Hagen2000]

Wollte man gezielt Synology-User angreifen, könnte man natürlich eine Wörterbuchattacke mit synology.me als Domäne durchführen, oder man nimmt beispielsweise die Mitgliedsnamen dieses Forums. Da bekommt man bestimmt ein paar Treffer und erhält dann auch gleich die passenden (dynamischen) IP-Adressen frei Haus. Aus der Sicht: Ja, myfritz macht es ja auch so.

Andererseits laufen die meisten Angriffe wohl doch eher über das Scannen von IP-Adressen. Ich schließe mich meinem Vorredner an - wichtig ist die Verwendung sicherer Passwörter.

Eine Anmerkung noch zu IPv6 „only“: Befindest Du dich mit deinem Smartphone in einem WLAN (beispielsweise bei Freunden oder in einem Hotel), das nur IPv4 unterstützt, bräuchtest Du einen externen Dienst, der eine entsprechende Umsetzung IPv4 -> Ipv6 anbietet. Oder man muss dann ins Mobilfunknetz wechseln. Den Fall hatten wir kürzlich hier im Forum.

 

[Jo92]

Andererseits laufen die meisten Angriffe wohl doch eher über das Scannen von IP-Adressen. Ich schließe mich meinem Vorredner an - wichtig ist die Verwendung sicherer Passwörter.

Ich glaube ihr habt beide recht. Ich wähle nun auch einen Ansatz der sprechbarer/merkbarer ist. Alle User haben sichere Passwörter und 2FA, zusätzlich habe ich mich noch mit der Firewall beschäftigt und die recht dicht gemacht (hoffe ich). Danke für eure Meinungen, dass hat mir sehr geholfen.

Eine Anmerkung noch zu IPv6 „only“: Befindest Du dich mit deinem Smartphone in einem WLAN (beispielsweise bei Freunden oder in einem Hotel), das nur IPv4 unterstützt, bräuchtest Du einen externen Dienst, der eine entsprechende Umsetzung IPv4 -> Ipv6 anbietet. Oder man muss dann ins Mobilfunknetz wechseln. Den Fall hatten wir kürzlich hier im Forum.

Danke, leider geht es wegen DS-Lite nicht anders. Ich muss aber zeitnah Mal ein Paket da umstellen, vielleicht versuche ich sie danach Mal zu überreden mir einen Dualstack zu geben. Ich hatte das Problem auch aus dem Ausland vor kurzem, da kam ich auch nicht dran, weil nur IPv4 only... Grausam, dass das noch erlaubt ist also das only

 

[Jo92]

N'Abend zusammen,
so habe nun alles beisammen. Nur das mit den Links bei der Freigabe läuft irgendwie noch nicht richtig. Ich habe ja jetzt eine subdomain eingerichtet, die per CNAME auf meine synology.me Adresse zeigt. Für die Subdomain auf der Syno Let's Encrypt Zertifikate generiert. Als reverse Proxy ist die Subdomain eingerichtet. Das läuft alles.

@Benares schrieb ja, dass wenn man im Anmeldeportal nichts eingetragen hat die Zugriffs-URL genommen wird. Ich habe dort nichts, außer einem individuellen Port für https eingerichtet. Trotzdem generiert er die Links über die synology.me Adresse, was natürlich nicht funktioniert, weil die nicht als reverse proxy eingerichtet ist. Wahrscheinlich, weil der CNAME ja nur im Adressfenster die URL "faked" und der Zugriff eigentlich über die synology.me erfolgt, oder?

 

[Benares]

Lies mal hier. Da ist etwas genauer beschrieben, wie die Generierung der Links bei Drive abläuft.
Da ist die Logik etwas komplizierter als bei anderen Apps und es spielt wohl auch das Vorhandensein von aktivierten DDNS-Updates eine Rolle.

Edit: Grad gesehen, man kann auch in der Drive Admin Konsole unter Einstellungen, Freigabe eine Domain fest eintragen, wenn man die Logik umgehen will.

 

[Jo92]

Danke, ich hatte schon begonnen den Link von dir zu lesen und sah jetzt gerade nach einem Refresh, dass du noch einen Edit gemacht hast. Die Logik ist für mich in dem Fall perfekt. Habe nun den Link auf meine Subdomain angepasst, ist so wie ich es haben will.

Schade, dass die Photostation keine gleiche Logik hat. Aber da ist es mir nicht so wichtig. Dort steht in der Anleitung explizit drin:

Wenn Sie QuickConnect oder DDNS für andere DSM-Dienste nutzen und Ihre Fotos und Alben mit einer anderen Domain freigeben möchten, müssen Sie die Komponente der Netzwerkadresse im Freigabe-Link manuell ersetzen.

 

[Benares]

Schade, dass die Photostation keine gleiche Logik hat

Du meinst Synology Photos oder wirklich die alte Photostation? Und wenn du deine Wunsch-Domain dafür im Anmeldeportal einträgst?

 

[Jo92]

Sorry, bin noch am alten Begriff kleben geblieben. Ich meine Synology Photos. Wenn ich im Anmeldeportal die URL reinpacke, erhalte ich einen Fehler der Domainname wird bereits verwendet (wahrscheinlich auf Grund des reverse proxy).

Edit: Habe es jetzt Mal aus dem reverse proxy rausgenommen, dann klappt es. Aber jetzt verstehe ich nicht wie das überhaupt funktioniert mit dem Zugriff (oder liegt es daran, dass im DNS Cache noch die richtigen Daten hängen?

 

[Benares]

Brauchst keinen Reverse Proxy zusätzlich. Wenn du eine Domain im Anmeldeportal bei Synology Photos einträgst, entsteht intern sowas ähnliches wie ein Reverse Proxy.
Einen expliziten Reverse-Proxy brauchst du nur für Apps, die dort halt nicht unter Anwendungen auftauchen. Daher die Fehlermeldung.

 

[Jo92]

Alles klar, ich dachte das wäre notwendig. Ok, dann kann ich das natürlich auch bei Drive anpassen, dann müsste ich es gar nicht in der Admin Konsole anpassen und habe es für beide gleich (habe ich ansonsten in 2 Jahren wieder vergessen und suche mich dumm und dusselig). Danke!

 

[Jo92]

Habe nochmal eine Frage. Habe wie gesagt die URL jetzt im Anmeldeportal eingetragen, eigenes Let's Encrypt Zertifikat für die Subdomain eingerichtet, usw.

Über den Browser passt alles, Zertifikat auch gültig. Wenn ich jetzt im Drive Desktop Client von Quickconnect auf die Subdomain (die per CNAME auf den DDNS zeigt) umstelle, erhalte ich folgende Meldung:



Hier klicke ich "Nicht jetzt", macht ja Sinn. Aber dann kommt diese Meldung und die verwirrt mich:



Leider kann ich an der Stelle überhaupt nicht sehen, warum oder mir das Zertifikat anzeigen lassen, etc. Hat jemand eine Idee, wie ich das Debuggen könnte, was hier das Problem ist?

PS: Einrichtung am Handy in der Drive App (mit der Subdomain und SSL Ja) funktioniert ohne Zertifikatsfehler.


Edit: Und das scheint irgendwie überhaupt nicht richtig zu laufen vom Desktop-Client. Habe mich wohl davon leiten lassen, dass ich bisher im Heimnetz war. Habe meinen Laptop nun Mal per Smartphone Hotspot verbunden. Zugriff per Webbrowser läuft perfekt, in der Drive App erhalte ich die Meldung: Verbindung fehlgeschlagen. Prüfen Sie Ihre Netzwerkeinstellungen und versuchen Sie es erneut.

 

[Benares]

Wenn ich jetzt im Drive Desktop Client von Quickconnect auf die Subdomain (die per CNAME auf den DDNS zeigt) umstelle, erhalte ich folgende Meldung

Den Satz verstehe ich nicht. Was hat das mit Quickconnect zu tun?

 

[Jo92]

Die Verbindung des Drive Clients auf meinem PC ist bisher über Quickconnect gelaufen (was ich nun loswerden möchte, weil ich ja über den anderen Weg gehen will). Sorry war etwas missverständlich geschrieben.

Ich glaube ich habe des Fehler aber gerade selbst gefunden. Muss es nur noch verifizieren. Dadurch, dass ich die Domain im Anmeldeportal eingetragen haben, muss ich für den Drive Client den Port 6690 im Router freigeben. Sonst läuft es zwar aus dem Webbrowser und am Handy aber irgendwie nicht vom aus der Drive Client Software unter Windows.

 

[Jo92]

Ok, meine Lernkurve ist weiterhin steil. Ich habe aber eine Frage.

Der Zertifikatsfehler oben ist aufgetreten, weil ich bei den Zertifikaten unter "Synology Drive Server" ein falsches Zertifikat eingestellt hatte. Ok, verstanden. Das ich mich aus fremden Netzen nicht verbinden konnte, lag daran, dass ich in der Fritzbox den Port 6690 nicht geöffnet habe. Das verstehe ich nicht.

Wenn ich im Webbrowser auf meine Subdomain zugreife, funktioniert der Zugriff auf Drive ohne Probleme. Gleiches mit der App vom Handy. Warum muss ich für den Drive Client unter Windows den Port 6690 auf dem Router öffnen, wenn ich eine Verbindung haben möchte? Warum löst der die Subdomain nicht genauso über den DDNS und Reverse Proxy auf und erhält Zugriff?

 

[Benares]

Wenn du im Anmeldeportal bei Drive eine Domain und auch Ports für http und https einträgst, entstehen im Hintergrund sowas wie Reverse Proxies dafür.
Du kannst dann remote über z.B. https://drive.example.com (also Port 443) zugreifen, 443 muss natürlich freigegeben sein.
Weitere Portfreigaben brauchst du nur, wenn du eben nicht über den Reverse Proxy gehst.
Prinzip verstanden?