Synology Drive Client hinter Reverse Proxy

BavarianMan

Benutzer
Mitglied seit
27. Dez 2020
Beiträge
10
Punkte für Reaktionen
0
Punkte
7
Hallo zusammen,

ich versuche seit zwei Tagen nun von ausserhalb meines Heimnetzwerks den Drive Client am Desktop zu nutzen. Es funktionieren sämtliche Dienste und auch der Drive Zugriff via Smartphone App funktioniert. Aber der Desktop Client mag nicht wie er soll. Ich konnte der Synology Homepage entnehmen dass für den Drive Client der Port 6690 TCP freigegeben sein muss. Diesen Port habe ich in der FritzBox auf mein Nginx Reverse Proxy weitergeleitet und dort folgende Config eingerichtet:

NGINX:
server {
  listen 80;
  listen [::]:80;
  server_name sync.example.de;

  return 301 https://$server_name$request_uri;
}
server {
  listen 443 ssl;
  listen [::]:443 ssl;
  server_name sync.example.de;

  ssl_certificate /etc/letsencrypt/live/www.example.de/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/www.example.de/privkey.pem;

  include /etc/nginx/conf.d/includes/site-defaults.conf;
  include /etc/nginx/conf.d/includes/cert_bot.conf;
  include /etc/nginx/conf.d/includes/sec_headers.conf;

  expires $expires;

  location / {
      proxy_pass http://<IP>/;
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
  }
}
server {
    listen 6690;
    server_name sync.example.de;
    
    location / {
      proxy_pass http://<IP>:6690/;
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Leider meckert mit der Desktop Client an dass er keine Verbindung aufbauen kann :-(

Hat jemand eine Idee oder sieht einen Fehler in der Config?

Ach und Nein ich möchte kein QuickConnect nutzen ;-)

Beste Grüße
Markus
 
Zuletzt bearbeitet:

blurrrr

Benutzer
Sehr erfahren
Mitglied seit
23. Jan 2012
Beiträge
6.204
Punkte für Reaktionen
1.105
Punkte
248
https://www.synology.com/de-de/know...t_network_ports_are_used_by_Synology_services
dass für den Drive Client der Port 6690 TCP freigegeben sein muss. Das habe ich in der Fritzbox und in meinem Nginx auch alles freigegeben bzw. weitergeleitet.
Bei Aussagen wie "Jaja, hab ich gemacht"... sorry, einfach nur "nö". Ich bin bei weitem kein Nginx-Experte und hab mit dem ganzen Web-Geraffel auch eher weniger an der Mütze, aber irgendwas passt da nicht zusammen (vllt ist es das "jaja, hab ich alles gemacht" und das "geht nicht" ? ). Es wäre vielleicht sinnvoll, wenn Du einfach mal beschreiben würdest WAS GENAU Du getan hast und WAS in Deiner nginx-Config dazu drin steht ??

EDIT: Damit Dir jemand anders weiterhelfen kann ?
 

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.164
Punkte für Reaktionen
915
Punkte
424
Kannst ja unter Systemsteuerung > Anwendungsportal > Anwendungen > Drive eine benutzerdefinierte Domain setzen.

Dann gehst auf die Konsole und schaust dir die configs durch und findest vielleicht den Unterschied zwischen dem von Synology hier eingebauten Reverse Proxy und deiner config.

Der erste Verdächtige wäre, dass Synology eventuell über 6690 kein http(s) Transfer laufen hat sondern TCP Streams oder andere Protokolle.
Und dann ist halt erst mal Asche mit einem reinen http proxy wie er oben aufgeführt ist.

Mit der Mobil-App greift er halt nur per https/443 drauf zu für online / on-demand Zugriff.
Die Mobil-App hat ja keine Sync-Komponente.

Halt uns auf dem Laufenden, würde mich auch interessieren.
Hab mich nicht damit beschäftigt, weil die Desktop Clients hier nur im LAN / VPN unterwegs sind und direkt mit 6690 auf der Syno kommunizieren können.

Im White Paper wird nichts erwähnt und die nginx Syno config dazu habe ich mir noch nicht angesehen.
 
  • Like
Reaktionen: ra.la72

blurrrr

Benutzer
Sehr erfahren
Mitglied seit
23. Jan 2012
Beiträge
6.204
Punkte für Reaktionen
1.105
Punkte
248
Najo, man könnte ja schon TCP-Klamotten vom nginx weiterleiten, so isses nicht... aber dann halt definitiv nicht mit irgendwelchem "http"-Kram. Im Zweifel einfach mal bei https://docs.nginx.com nachschauen ??

EDIT: Alternativ - da Du (Beitrag wieder gelöscht?) von Docker sprachst - wäre vllt noch haproxy mit "mode tcp" eine Alternative.
mode

The mode setting defines whether HAProxy operates as a simple TCP proxy or if it’s able to inspect incoming traffic’s higher-level HTTP messages. The alternative to specifying mode http is to use mode tcp, which operates at the faster, but less-aware, level. If most of your frontend and backend sections would use the same mode, it makes sense to specify it in the defaults section to avoid repetition.
 
Zuletzt bearbeitet:

BavarianMan

Benutzer
Mitglied seit
27. Dez 2020
Beiträge
10
Punkte für Reaktionen
0
Punkte
7
Der erste Verdächtige wäre, dass Synology eventuell über 6690 kein http(s) Transfer laufen hat sondern TCP Streams oder andere Protokolle.
Und dann ist halt erst mal Asche mit einem reinen http proxy wie er oben aufgeführt ist.

Dem Gedanken gehe ich auch gerade nach und versuche einen (evtl. zweiten) NginxProxy in meiner Docker Umgebung aufzusetzen, welche ich mit einem TCP Proxy Modul neu baue. Damit würde ich folgendes versuchen: https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/

Ist natürlich aufwendig, aber wenn Synology hier keine andere Möglichkeit bietet die wahrscheinlich einzige Chance.

Ausser der Nginx kann auf eine mir nicht bekannte Weise bereits in Version 1.19.x mit Streams umgehen
 
Zuletzt bearbeitet:

Arnie99

Benutzer
Mitglied seit
12. Apr 2016
Beiträge
228
Punkte für Reaktionen
8
Punkte
18
Bei mir funktioniert es so:
  • TCP Port 6690 extern auf 6690 interne IP der DS weitergeleitet (Router)
  • Im Anwendungsportal benutzerdefinierten https-Port 10003 für Drive definiert
  • Im Reverse-Proxy drive.externeIP:443 umgelenkt zu https interneIP:10003
Läuft einwandfrei mit AndroidApp und Desktop. Ohne die 6690-Freigabe verliert die Desktop-App die Verbindung.
 

blurrrr

Benutzer
Sehr erfahren
Mitglied seit
23. Jan 2012
Beiträge
6.204
Punkte für Reaktionen
1.105
Punkte
248
@Arnie99 Danke für den Hinweis, so geht es sicher. Glaube aber, dass die Anforderung hier ist, dass "alles" über den Reverse-Proxy läuft :)
 

BavarianMan

Benutzer
Mitglied seit
27. Dez 2020
Beiträge
10
Punkte für Reaktionen
0
Punkte
7
Bei mir funktioniert es so:
  • TCP Port 6690 extern auf 6690 interne IP der DS weitergeleitet (Router)
  • Im Anwendungsportal benutzerdefinierten https-Port 10003 für Drive definiert
  • Im Reverse-Proxy drive.externeIP:443 umgelenkt zu https interneIP:10003
Läuft einwandfrei mit AndroidApp und Desktop. Ohne die 6690-Freigabe verliert die Desktop-App die Verbindung.

Hast du dein Let's Encrypt Zertifikat auf der DS und am Reverse Proxy? Ich hatte bei dem Ansatz nämlich einen Hinweis vom Client bekommen dass das Zertifikat nicht passt. Vermutlich das von der DS, da das Zertifikat für die Domain am Reverse Proxy liegt.

@Arnie99 Danke für den Hinweis, so geht es sicher. Glaube aber, dass die Anforderung hier ist, dass "alles" über den Reverse-Proxy läuft :)

Genau, ich hätte es gerne zentral und mit dem selben Zertifikat gelöst
 

Arnie99

Benutzer
Mitglied seit
12. Apr 2016
Beiträge
228
Punkte für Reaktionen
8
Punkte
18
Hast du dein Let's Encrypt Zertifikat auf der DS und am Reverse Proxy? Ich hatte bei dem Ansatz nämlich einen Hinweis vom Client bekommen dass das Zertifikat nicht passt. Vermutlich das von der DS, da das Zertifikat für die Domain am Reverse Proxy liegt.
Ja, der Client meckert tatsächlich wegen des Zertifikats. Habe ein eigenes Zertifikat für drive.externerZugriff, aber das scheint er hier nicht zu nutzen. Wenn ich meine Haupt-Proxy-Adresse https://haupt.externerZugriff im Desktop-Client für die Verbindung verwende, meckert er nicht und die Verbindung läuft ebenfalls sauber.
 

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.503
Punkte für Reaktionen
1.093
Punkte
194
Ich werde nicht müde und empfehle NGINX über Docker. In meinem Fall verwende ich SWAG inkl. Authelia - hier funktioniert Lets Encrypt auch mit *.Wildcards. Da findet dann auch das Gemauschel mit x Zertifikaten sein Ende. Zur Ersteinrichtung steckt ein wenig mehr Arbeit hinter - wenn man damit aber durch ist, dann ist man um einiges an Erfahrungen und Möglichkeiten reicher.
 

KGBist2000

Benutzer
Mitglied seit
10. Jan 2016
Beiträge
163
Punkte für Reaktionen
27
Punkte
28
Ich werde nicht müde und empfehle NGINX über Docker. In meinem Fall verwende ich SWAG inkl. Authelia - hier funktioniert Lets Encrypt auch mit *.Wildcards. Da findet dann auch das Gemauschel mit x Zertifikaten sein Ende. Zur Ersteinrichtung steckt ein wenig mehr Arbeit hinter - wenn man damit aber durch ist, dann ist man um einiges an Erfahrungen und Möglichkeiten reicher.
Hi,
kannst du mal deine nginix config teilen ?
 

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.503
Punkte für Reaktionen
1.093
Punkte
194
@KGBist2000 Die von SWAG bereitgestellte nginx.conf findest du unter Github. Diese ist allerdings auch customized - ein stumpfes copy & paste wird nicht zum Erfolg führen. Wenn du dich damit ernsthaft beschäftigten willst, musst du schon die Instruktionen lesen.
 

KGBist2000

Benutzer
Mitglied seit
10. Jan 2016
Beiträge
163
Punkte für Reaktionen
27
Punkte
28
Hi,
Danke dir für die schnelle Antwort. Leider hilft mir der Link nicht weiter.

Der ReverseProxy, RasPi läuft bei mir schon lange. Ich habe nur wie die anderen hier das Problem mit der Weiterleitung an den Port 6690 für den DesktopClient.
Ich habe zwar eine Lösung mir gebaut, jedoch ist diese sehr gefummelt und wird sicher mit dem nächste Update von DAM nicht funktionieren.

1. Läuft bei dir die Weiterleitung zum Drive-Server Port 6690 über den ReverseProxy?
2. Wenn ja, kannst du bitte deine Config teilen? Oder min. fragmente die zeigen, wie die tcp-streams aufgebaut sind und wie die SSL Zertifikate gemanaged werden?

Danke!
 

muxelmann

Benutzer
Mitglied seit
23. Jan 2022
Beiträge
1
Punkte für Reaktionen
1
Punkte
1
Hallo,

es ist zwar schon etwas her, dass hier eine Antwort geschrieben wurde. Aber ich meine es geschafft zu haben, Synology Drive ausschließlich über den Reverse Proxy (nginx) zu erreichen. Meine Ports werden in der FRITZ!Box wie folgt weitergeleitet:

Code:
www -> 6690 -> FRITZ!Box -> 6690 -> nginx
www -> 80 -> FRITZ!Box -> 80 -> nginx
www -> 443 -> FRITZ!Box -> 443 -> nginx

Synology Drive ist (standardmäßig) mit Port 6690 (TCP) und (über Systemeinstellungen -> Anmeldeportal -> Anwendungen) die 10003 (HTTPS über TCP). Die HTTP Einstellung bzgl. Port 10002 habe ich nicht konfiguriert, da ich ausschließlich einen externen SSL Zugang haben mag.

Die entsprechende nginx Seite ist wie folgt konfiguriert:

Code:
# z.B. in: /etc/nginx/config.d/synology-drive.conf

server {
    listen 80;
    listen 443 ssl;
    server_name <DOMAIN>;
    location / {
        proxy_set_header    Host $host;
        proxy_set_header    X-Real_IP $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;

       # Der HTTPS-Port für Synology Drive ist als 10003 konfiguriert
        proxy_pass          https://<SYNOLOGY-IP>:10003;
        proxy_read_timeout  90;
    }
    ssl_certificate         /etc/letsencrypt/live/<DOMAIN>/fullchain.pem;
    ssl_certificate_key     /etc/letsencrypt/live/<DOMAIN>/privkey.pem;

    include /etc/letsencrypt/options-ssl-nginx.conf;
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
}

Dann habe ich in der Datei unter /etc/nginx/nginx.conf noch folgende Zeile hinzugefügt:

Code:
...
http {
    ....
}

# Definieren des Stream-Proxy
include /etc/nginx/fallthrough.conf;

Und dann in der Datei unter /etc/nginx/fallthrough.conf folgende Einstellungen:

Code:
stream {
    upstream synology_drive {
         server <SYNOLOGY-IP>:6690;
    }
    server {
        listen     6690;
        proxy_pass synology_drive;
    }
}

Leider wird immer noch das (selbst signierte) Zertifikat benutzt, dass auf dem Synology NAS gespeichert ist. Mein Let's Encrypt Zertifikat auf dem Reverse Proxy bleibt unbenutzt. Das erkennt man daran, dass sich der Synology Drive Client beim Einrichten über ein "nicht vertrauenswürdiges Zertifikat" beschwert.

Geht nicht 1:

Ich habe versucht, den Stream-Proxy mit SSL einzurichten:

Code:
stream {
    upstream synology_drive {
         server <SYNOLOGY-IP>:6690;
    }
    server {
        listen     6690 ssl;
        proxy_pass synology_drive;
        ssl_certificate         /etc/letsencrypt/live/<DOMAIN>/fullchain.pem;
        ssl_certificate_key     /etc/letsencrypt/live/<DOMAIN>/privkey.pem;
    }
}

Denn das soll laut der Nginx Dokumentation (link) funktionieren. Nur funktioniert das überhaupt nicht, das so noch nicht einmal der Synology NAS erreich wird.

Fehlerquelle?

Ich habe mal mit Wireshark in die Pakete geschaut, die beim Einrichten des Synology Drive Clients mit und ohne SSL übertragen werden. Mir scheint, dass immer TCP und später erst verschlüsselte Pakete übertragen werden (siehe Screenshots unten). Vielleicht hat das was mit dem Handshake zu tun, aber im Vergleich zum Aufruf einer Webseite, werden mit reichlich viele unverschlüsselte TCP-Pakete vor dem ersten TLS-Paket übertragen.
KnORRkQ.png

yvgbkeY.png

Daher nehme ich an, dass eine standardmäßige SSL-Weiterleitung mit nginx als Stream-Proxy einfach nicht funktionieren kann, bis der Synology Drive Client aktualisiert wurde.

...dennoch versuche ich mein Glück weiter und gebe hier Bescheid, falls ich was herausfinde.

LG
Max
 
  • Like
Reaktionen: myjackal

KGBist2000

Benutzer
Mitglied seit
10. Jan 2016
Beiträge
163
Punkte für Reaktionen
27
Punkte
28
Hallo Max,
sehr cool deine Untersuchung. Ich hatte zwar nicht mit Wireshark alles durchgesnifft, jedoch die Erkenntnise waren die gleichen.

Es muss per TCP Stream gehen, dass es nicht geht liegt an Synology. Die haben da irgendein Mist implementiert was nicht Fleisch und nicht Fisch ist.

Hoffen wir dass es mit DSM 7.1 besser wird, die Drive App für iOS und Android wird ja offline Sync bringen. Hoffe die stellen das auf 443 um mit SSL und nehmen nicht den 6690 Port mit ihrer Eigenkreation von Implementierung. Ich werde sicherlich enttäuscht, aber das wird mir hoffentlich den letzten Tritt geben auf eigenen nextcloud umzusteigen.

Halt uns auf dem laufenden!

Vg
 

ctrlaltdelete

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
30. Dez 2012
Beiträge
14.040
Punkte für Reaktionen
6.049
Punkte
569
Es gibt noch keine Lösung für Synology Drive Client über Reverse Proxy ohne Portforwarding 6690 am Router?
Sehe ich das richtig, habe jetzt gefühlte 2 Tage das Web durchsucht?
 

herrtim

Benutzer
Mitglied seit
15. Mrz 2016
Beiträge
44
Punkte für Reaktionen
0
Punkte
6
Hi,
gibt es dafür inzwischen eine Lösung?
Ich suche bereits seit einigen Tagen, aber nichts funktioniert :(
 

KGBist2000

Benutzer
Mitglied seit
10. Jan 2016
Beiträge
163
Punkte für Reaktionen
27
Punkte
28
Der Status ist unverändert leider. Für die Desktop Drive App (Windows/MacOS) wird weiterhin der Port 6690 benötigt.

Die Smartphone-Apps laufen auch mit offline Sync über 443.
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Mitglied seit
28. Okt 2020
Beiträge
15.028
Punkte für Reaktionen
5.401
Punkte
564

herrtim

Benutzer
Mitglied seit
15. Mrz 2016
Beiträge
44
Punkte für Reaktionen
0
Punkte
6
Danke für eure Antwort. Sorry das ich so blöd nachfragen muss, hard gecoded ist ein Problem, weil man es nicht auf 443 umstellen kann, wie für die Mobile Apps? Also d.h. weiterhin nur den internen Reverse Proxy nutzen, Mist...
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat