DDNS mit SSL und URL Cloaking

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

mf_2

Benutzer
Registriert
31. Aug. 2008
Beiträge
203
Reaktionspunkte
8
Punkte
18
Hi,

(contoso ist ein Dummy-Name)

ich weiß nicht so recht, wo ich anfangen soll, aber ich versuche es mal.
Ich habe ein paar Server in meinem LAN, nennen wir sie contoso01 und contoso02.
Auf beiden läuft ein IIS.
Meine Syno ist per contoso.synology.me DDNS von außen erreichbar.
Des Weiteren habe ich eine Domain: www.contoso.de bei HostEurope.

Mein Ziel ist nun:
Ich möchte server01.contoso.de auf meinen Server contoso01 zeigen lassen.
Analog soll server02.contoso.de auf contoso02 zeigen.

Wenn der Anwender server01.contoso.de eingibt, soll er diese URL im Browser sehen, er soll dann nicht server01.contoso.synology.me oä. sehen.
Des Weiteren möchte ich ein SSL-Zerifikat nutzen können. Dies würde ich dann gerne via HostEurope kaufen (mache ich heute schon für www.contoso.de).

Wenn ich bei HostEurope eine Subdomain anlege, so ist es zum Einen http und nicht https und zum anderen sieht der Anwender dann die synology.me URL.
Wenn ich dort den CNAME Record pflege, so kann ich nur auf die DDNS-Domain an sich zeigen, bekomme aber die Server nicht unterschieden.

Geht mein Vorhaben überhaupt und wenn ja, wie stelle ich das an?

Viele Grüße
mf_2
 
Wenn ich dort den CNAME Record pflege, so kann ich nur auf die DDNS-Domain an sich zeigen, bekomme aber die Server nicht unterschieden.
Das müsstest Du mit einem Reverse Proxy auf dem NAS lösen können. Mal so als Idee:

CNAME-Eintrag server01.contoso.de auf contoso01.contoso.synology.me und einen weiteren CNAME-Eintrag für den zweiten Server anlegen.
Auf dem NAS den Reverse Proxy als "Verteiler" benutzen - anhand der jeweiligen Subdomain kann der Reverse Proxy die Zugriffe an den jeweiligen Server weitergeben.
Vorteile: Nach außen hin tritt nur der Reverse Proxy auf, für die beiden IIS werden keine Zertifikate benötigt (hausintern kannst Du mit HTTP arbeiten). Du kannst mit Standard-Portnummern arbeiten und das Konstrukt sollte sowohl für IPv4 als auch für IPv6 funktionieren.
Nachteil: Wenn Du dir bei HostEurope ein Zertifikat besorgst, muss dies beide Servernamen enthalten (oder ein Wildcard-Zertifikat sein) und Du musst es manuell regelmäßig auf dein NAS kopieren. Außerdem musst Du vermutlich künftig auch dein NAS über eine Subdomain ansprechen (z. B. als nas.contoso.synology.me).

Warum willst Du die Synology-Domain eigentlich "dazwischen" schalten - kannst Du DDNS nicht direkt bei HostEurope einrichten?

Wenn ich bei HostEurope eine Subdomain anlege, so ist es zum Einen http und nicht https und zum anderen sieht der Anwender dann die synology.me URL.
Das verstehe ich jetzt nicht - DNS hat ja nichts mit Protokollen (SSH, FTP, HTTP, HTTPS) zu tun, sondern dient zur Adressauflösung. Und die synology.me-URL sollte der Anwender im Browser eigentlich nicht sehen. Im DNS kann er das natürlich nachsehen, ist ja öffentlich.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Benie
Ich denke, ich habe verstanden, was du suchst. Ich kann dir ja mal einfach schreiben, wie ich das mache (IPv6 lasse ich mal außen vor):

1. Ich habe eine Domain bei Netcup, nennen wir sie mal meinedomain.de.
2. DDNS mache ich über ipv64.net (kostenlos), dort habe ich eine Domain meinedomain.ipv64.net angelegt. Das Update das wird von einem meiner NASe, der DS1522+ erledigt. Kannst aber auch einfach synology.me nehmen.
3. Auf dem Router existiert nur eine Portfreigabe/-weiterleitung von Port 443 auf die DS1522+. Des weiteren existiert auf der DS1522+ auch ein Zertifikat für meinedomai.de. Wichtig ist, dass dies ein Wildcard-Zertifikat ist, also nicht nur für meinedomein.de gilt, sondern auch für *.meinedomain.de. Ich mache die Aktualisierung über Lets Encrypt und einen Updater in Docker/ContainerManager (neilpang-acme.sh1)
4. Bei Netcup gibt es einen gibt es einen ganzen Sack CNAMEs für die verschiedenen internen Dienste (z.B. photo.meinedomain.de) usw.

Damit sind alle Voraussetzungen geschaffen um externe Zugriffe über den Reverse Proxy der DS1522+ abhängig vom verwendeten Namen intern zu verteilen.
Bsp:
https://immich.meinedomain.de[:443] -> http://dxp4800plus:8080
https://ds415.meinedomain.de[:443] -> http://ds415:5000
https://ds1522.meinedomain.de[:443] -> http://localhost:5000
usw.usw.

Ich sehe gerade, dass @Hagen2000 grad was dazu geschrieben hat. Aber jetzt hab ich das hier schon geschrieben, dann schick ich's halt trotzdem ab.
 
  • Like
Reaktionen: Benie
@Benares es gibt auch ddns updater wie https://github.com/qdm12/ddns-updater
Damit kannst du direkt die DNS API von Netcup bedienen und z.b. einen A record setzen.

In Summe könnte die Ip64 Lösung trotzdem besser sein, weil netcup recht träge beim DNS ist, und du dort ja keine Änderungen vornehmen musst.
Hab jetzt noch kein Test gemacht, aber alleine bei letsencrypt muss man ja teilweise 15-30min warten bis TXT records aktualisiert sind zur Abfrage durch die LE server. Bei Hetzner flutscht das in 20 Sekunden, weshalb ich die dafür bevorzuge.
 
  • Like
Reaktionen: Benie und Benares
Die TTL kann man in den Domain DNS Einstellungen bei netcup doch verändern?
 
Ja, Netcup ist sehr träge, darüber bin ich auch schon gestolpert. Nach einen Update dauert es mindestens 5-10 Minuten, bis das auf deren DNS-Servern ankommt. Die TTL kommt noch oben drauf. Da haben sich CNAMEs woanders hin als besser erwiesen.
Bei den ACME-Updates arbeite ich momentan mit einem Delay von 600s, was m.W. auch das Maximum ist und auch meist klappt.

Edit: @patrickn, bei Netcup scheinen Updates erstmal in einer Datenbank zu landen, die dann zyklisch mit einem deutlichen Versatz auf den DNS-Servern ankommt. Da nützt auch eine reduzierte TTL nichts/wenig.
 
Zuletzt bearbeitet:
Die IPv64-Domain ist nur die Basis für CNAMEs für die Netcup-Domain. Bei IPv64-DDNS geht halt wesentlich mehr, z.B. auch reine IPv6-Prefix-Updates mit fest hinterlegten IPv6-Interface-Identifierern, wenn man auch Namen für die internen IPv6-Adressen braucht.

So lassen sich die Namen auch rein intern ohne Portfreigabe für https nutzen.

Hier mal als Beispiel:
1773740385740.png
 
Hast Recht, kommt wohl drauf an, worauf ds415.meinedomain.de bei Netcup per CNAME zeigt, entweder auf ds415.meinedomain.ipv64.net oder auf ds1522.meinedomain.ipv64.net.
Im 1. Fall lauft es direkt, im 2. Fall über den Reverse-Proxy der DS1522+
Das kommt davon, wenn man die Namen oft nur ohne Portfreigabe von intern nutzt :rolleyes:.
Ich scheue Portfreigaben, dann lieber Wireguard-VPN.
 

Additional post fields

 

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