Port Weiterleitung für Drive Server

NASzypern

Benutzer
Mitglied seit
19. Apr 2022
Beiträge
1
Punkte für Reaktionen
0
Punkte
1
Welche Port Freigaben brauche ich für zwei NAS920 (Home & Office) bei Nutzung von Drive Server/DriveShareSync ?
siehe https://www.youtube.com/watch?v=01n5gi8s-LM
Beiden Router haben eine feste IP und die Verbindung sollte mit maximaler Geschwindigkeit erfolgen (kein Relay Service!)
Sollte ich die fixen IPs in den NASs eintragen?
Würdet ihr noch quickconnect nutzen?
 

franko77

Benutzer
Mitglied seit
07. Dez 2017
Beiträge
27
Punkte für Reaktionen
3
Punkte
3
Drive verwedet für den Sync den Port 6690.
viele Grüße aus Dortmund
Frank
 

ctrlaltdelete

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
30. Dez 2012
Beiträge
14.040
Punkte für Reaktionen
6.050
Punkte
569
Und ist neben 443 der einzig offene bei mir, da sich Drive nicht über Reverse Proxy routen lässt. grrrrrrrrrr
 
  • Like
Reaktionen: Fusion

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.164
Punkte für Reaktionen
915
Punkte
424
6281 Hyper Backup noch dazu. Der lässt sich ja auch nicht ändern. Und ich nehme identische Ports bei ipv4/ipv6, deshalb keine NAT Verbiegung.
 
  • Like
Reaktionen: ctrlaltdelete

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.503
Punkte für Reaktionen
1.093
Punkte
194
@ctrlaltdelete also bei mir läuft Drive über einen Reverse Proxy... :unsure:
Allerdings nicht über den Proxy der Diskstation.
 

ctrlaltdelete

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
30. Dez 2012
Beiträge
14.040
Punkte für Reaktionen
6.050
Punkte
569
Da nehme ich webdav über Reverse Proxy.
 

ctrlaltdelete

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
30. Dez 2012
Beiträge
14.040
Punkte für Reaktionen
6.050
Punkte
569

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.503
Punkte für Reaktionen
1.093
Punkte
194
@ctrlaltdelete hatte ich hier und dort schon mal erwähnt: Ich verwende SWAG. Das ist im Kern ein Nginx mit zusätzlicher 2FA-Anbindung, Fail2ban, Certbot und anderer Spielereien.


Mal exemplarisch wie ich vorgegangen bin, wenn ich das noch so zusammenbekomme...
1. Subdomain im Anwendungsportal für Drive registriert (share.domain.tld)
2. Zertifikat erstellt und Drive zugewiesen
3. Zertifikat von der DS exportiert und im Nginx unter keys abgelegt
4. Im Nginx unter proxy-confs eine File share.subdomain.conf erstellt.
5. Im Nginx eine INDIVIDUELLE.conf erstellt. (# Certificates berücksichtigen)


Beispiele:
share.subdomain.conf
## Version 2022/01/06 # make sure that your dns has a cname set for share server { listen 80; listen 443 ssl; listen [::]:443 ssl; server_name share.*; include /config/nginx/INDIVIDUELLE.conf; client_max_body_size 0; # enable for ldap auth, fill in ldap details in ldap.conf #include /config/nginx/ldap.conf; # enable for Authelia #include /config/nginx/authelia-server.conf; location / { # enable the next two lines for http auth #auth_basic "Restricted"; #auth_basic_user_file /config/nginx/.htpasswd; # enable the next two lines for ldap auth #auth_request /auth; #error_page 401 =200 /ldaplogin; # enable for Authelia #include /config/nginx/authelia-location.conf; include /config/nginx/proxy.conf; resolver 127.0.0.11 valid=30s; proxy_pass https://192.168.1.21:5001; } }

INDIVIDUELLE.conf
## Version 2020/10/29 - Changelog: https://github.com/linuxserver/docker-swag/commits/master/root/defaults/ssl.conf ### Mozilla Recommendations # generated 2020-06-17, Mozilla Guideline v5.4, nginx 1.18.0-r0, OpenSSL 1.1.1g-r0, intermediate configuration # https://ssl-config.mozilla.org/#server=nginx&version=1.18.0-r0&config=intermediate&openssl=1.1.1g-r0&guideline=5.4 ssl_session_timeout 1d; ssl_session_cache shared:MozSSL:10m; # about 40000 sessions ssl_session_tickets off; # intermediate configuration ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; # OCSP stapling ssl_stapling off; ssl_stapling_verify off; ### Linuxserver.io Defaults # Certificates ssl_certificate /config/keys/DEIN-ZERTIFIKAT.crt; ssl_certificate_key /config/keys/DEIN-SCHLUESSEL.key; # verify chain of trust of OCSP response using Root CA and Intermediate certs #ssl_trusted_certificate /config/keys/letsencrypt/fullchain.pem; # Diffie-Hellman Parameters ssl_dhparam /config/nginx/dhparams.pem; # Resolver resolver 127.0.0.11 valid=30s; # Docker DNS Server # Enable TLS 1.3 early data ssl_early_data on; # HSTS, remove # from the line below to enable HSTS #add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; # Optional additional headers #add_header Cache-Control "no-transform" always; #add_header Content-Security-Policy "upgrade-insecure-requests; frame-ancestors 'self'"; #add_header Referrer-Policy "same-origin" always; #add_header X-Content-Type-Options "nosniff" always; #add_header X-Frame-Options "SAMEORIGIN" always; #add_header X-UA-Compatible "IE=Edge" always; #add_header X-XSS-Protection "1; mode=block" always;


Vielleicht hilft es dir.
 
  • Like
Reaktionen: ctrlaltdelete

ctrlaltdelete

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
30. Dez 2012
Beiträge
14.040
Punkte für Reaktionen
6.050
Punkte
569
@Ulfhednir Danke, werde ich mir anschauen, stimmt hattest du schon mal geschrieben, war ich aber zu faul es zu testen :cool:
 

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.503
Punkte für Reaktionen
1.093
Punkte
194
Der Reverse Proxy der Syno ist ja auch nur ein Nginx. Den könntest du theoretisch genauso missbrauchen. Allerdings sind mir Operationen am offenen Herzen im bestehenden System doch eher unheilig. Ersatzweise kannst du dir auch einfach einen anderen Nginx per Docker raufklatschen... Der https://nginxproxymanager.com/ wird z.B. auch gerne aufgrund seiner GUI verwendet.

*Ding-Ding-Ding*
Mein 2000er Beitrag
 

ctrlaltdelete

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
30. Dez 2012
Beiträge
14.040
Punkte für Reaktionen
6.050
Punkte
569
Glückwunsch zum 2.000 Beitrag. Hast echt schon vielen geholfen.
 

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.503
Punkte für Reaktionen
1.093
Punkte
194
Ich kann nur für den Desktop Client Sync sprechen, welcher bei zwei Vereinsmitgliedern eingerichtet ist.
 

KGBist2000

Benutzer
Mitglied seit
10. Jan 2016
Beiträge
163
Punkte für Reaktionen
27
Punkte
28
Ich kann nur für den Desktop Client Sync sprechen, welcher bei zwei Vereinsmitgliedern eingerichtet ist.
Interessant, habe mit die nginx-config angeschaut, finde nix zum Port 6690. hier wird nur der Port 80 und 443 weitergeleitet. Oder bin ich blind?

Der Desktop Client ist doch so doof und Quatsch auf Port 6690. in der von dir geteilten Config hört der Reverse Proxy nicht auf diesen.

Kannst ggf. den Inhalt der Proxy.Conf Posten?

Wie sehen deine Portweiterleitungen im Router aus?

Kannst du bitte für die Ports 80,443 und 6690 es auflisten?
 
Zuletzt bearbeitet:

Fusion

Benutzer
Sehr erfahren
Mitglied seit
06. Apr 2013
Beiträge
14.164
Punkte für Reaktionen
915
Punkte
424
OK, muss ich bei Gelegenheit nochmal schauen.
Mit dem eingebauten (benutzerdefinierte Domains) oder einem vorgeschalteten (nginx, Linux server) musste ich immer 443 (web) +6690 (sync) nehmen.

Sehe da jetzt keine besondere Streambehandlung oder ähnliches. Und Header ebenfalls.

Aber vielleicht hab ich ja irgendwas verpasst.
 

Ulfhednir

Benutzer
Sehr erfahren
Mitglied seit
26. Aug 2013
Beiträge
3.503
Punkte für Reaktionen
1.093
Punkte
194
@KGBist2000 du hast vollkommen Recht. Ich habe gerade nochmal geschaut. Die 6690 wird trotzdem für die Synchronisierung benötigt. Mein Forwarding hatte den Vermerk "CloudSync" - also nicht im Kontext mit Drive. Hier wird also der scheinbar der selbe Port verwendet.
siehe auch: https://kb.synology.com/de-de/DSM/tutorial/What_network_ports_are_used_by_Synology_services

Daher habe ich mir eingebildet, dass ich nur 443 benötigen würde. So langsam dämmert es auch bei mir wieder, weswegen ich diese Sonderkonfiguration hatte. Bezog sich im Kontext darauf, dass der Drive-Client nicht in der Lage war das korrekte (selbst signierte Zertifikat) zu verwenden und ich wenig Lust hatte, quartalsweise den alten Herren zu erklären, dass das sie sich im Drive-Client neu einloggen müssen.

Ich duck mich jetzt weg und wünsche einen angenehmen Start in den Tag.
 
  • Like
Reaktionen: KGBist2000 und Fusion


 

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