Möglichst einfache Erreichbarkeit über DynDNS und FritzBox-Freigabe

[deadbabylon]

Nabend zusammen,

ich würde gerne meine aktuelle Erreichbarkeit der Diskstation etwas vereinfachen, damit es etwas einfacher wird.
Allerdings weiß ich nicht, ob das, was ich vorhaben, überhaupt funktioniert und frage hier daher einmal nach Hilfe:

Was wären meine Kriterien:
1. Erreichbarkeit aus dem Internet über dyndns bzw. no-ip.org, wobei allerdings nur ein Port in der Fritzbox weitergeleitet werden soll (no-ip.org ist Ansich kein Problem, zu der Portproblematik siehe unten), z.B. <meine_adresse>.no-ip.org:23456
2. Erreichbarkeit von verschiedenen *station-Apps und Webseiten über eine Subdomain, z.B.

• <meine_adresse>.no-ip.org:23456/notes für NoteStation

• <meine_adresse>.no-ip.org:23456/downloads für DownloadStation

• <meine_adresse>.no-ip.org:23456/webdav für WebDAV

• <meine_adresse>.no-ip.org:23456/files für FileStation

• etc.

3. Eigenes Zertifikat, damit diesen Seiten auch in HTTPS über Chrome funktionieren, welches oftmals rumzickt.
4. Das Zertifikat sollte aber auch im lokalen LAN nicht ungültig sein, damit Chrome z.B. bei <diskstation_ip>/notes nicht dennoch rumzickt
5. In der Firtzbox sollte möglichst nur ein Port weitergeleitet werden (hier z.B. 23456), um es möglichst einfach zu halten
6. Verschiedene Android-Apps sollten natürlich dennoch funktionieren mit diesen Subdomains

Ich bin mir nicht ganz sicher, ob mein Anliegen verständlich ist, daher beschreibe ich einmal mein momentanes Setup:
1. Die verschiedenen *stations haben in der Systemsteuerung->Anwendungsportal jeweils einen eigenen Port für HTTPS (entfernter Zugriff) und HTTP (lokaler Zugriff)
2. In meiner Fritzbox sind entsprechende Portweiterleitungen (Mehrzahl) eingerichtet auf die jeweiligen HTTPS-Ports der einzelnen Anwendungen
3. Für den einfachen Zugriff habe ich damit pro Anwendung mir zwei Lesezeichen angelegt, einmal lokal (HTTP), einmal entfernt (HTTPS)
4. Ich habe mir ein Zertifikat erstellt für den externen Zugriff (also auf die Domain <meine_adresse>.no-ip.org.
5. Im lokalen LAN nutze ich die normalen HTTP-Lesezeichen, weil Chrome sonzt rumzickt, dass die im Zertifikat angegebene Domain nicht mit der lokalen übereinstimmt.

Da ich inzwischen verschiedene *Stations nutze, verliere ich langsam die Übersicht über die verschiedenen notwendigen Portfreigaben, wobei mich aber auch Chrome nervt, da es scheinbar unterscheidet zwischen lokalem und entfernten Zugriff (da die URL anders ist). Vielleicht habe ich bei der Erstellung des Zertifikats auch einen Fehler begangen, aber momentan traue ich mich nicht daran, das ohne Hilfe zu ändern.
Quickconnect möchte ich dabei übrigens explizit nicht nutzen, da es mir zum einen gerade bei entferntem Zugriff etwas langsam vorkommt, ich aber auch die Verbindung über einen fremden Server vermeiden möchte.

War das so verständlich?
Gibt es hierfür überhaupt eine Lösung?
Würde mich über Input freuen.

 

[frankyst72]

4. Das Zertifikat sollte aber auch im lokalen LAN nicht ungültig sein, damit Chrome z.B. bei <diskstation_ip>/notes nicht dennoch rumzickt

lokalen DNS einrichten, der <meine_adresse>.no-ip.org in die lokale IP umwandelt. Dann kannst Du von extern und von intern mit der gleichen Adresse arbeiten <meine_adresse>.no-ip.org
Ich verwende z.B. Pi-hole auf einem Raspberry Pi 3. Das ist zwar kein DNS Server im eigentlichen Sinne, aber ich kann die Auflösung hinterlegen und habe noch die Vorteile von Pi-hole.

 

[mb01]

... naja, Wünsche kann man viele haben.

Zuerst: Die "Subdomains" von dem du redest sind keine Subdomains. Bei No-IP bekommst du als DynDNS-Nutzer keine eigene Domain, d.h. das <meine_adresse> ist bereits eine Subdomain zur Domain "no-ip" unter der Top-Level-Domain "org".

Ohne mich genau mit dem Thema beschäftigt zu haben: Für die Weboberflächen der Dienste lassen sich Aliasnamen einrichten: https://www.synology.com/de-de/knowledgebase/DSM/help/DSM/AdminCenter/application_appportalias ... wobei das schwierig werden wird, wenn man selbst bereits nur eine Subdomain nutzen kann. Die Pfadangaben mit den Slashes hinter der Domain dürften hier uninteressant sein.

Für native Anwendungen, die über spezifische Ports mit DSM kommunizieren, hilft das vermutlich nicht, d.h. da wirst du um Portfreigaben nicht herumkommen.