DSM 7.0 Subdomains verlinken alle zu DSM

[ST-Solutions]

Guten Tag zusammen,

Ich habe gestern das DSM 7 Update auf meiner DS218+ gemacht.
Vor dem Update hatte ich verschiedene Subdomains via Reverse Proxy auf unterschiedliche Anwendungen verlinkt.

Beispiel:

dsm.XXX.ch als DynDNS Hostname (HTTPS Port: 38200)

plex.XXX.ch als verlinkung zu Plex (HTTPS Port: 32400)
drive.XXX.ch als verlinkung zu Synology Drive (HTTPS Port: 10003)
etc

Das hat vor dem Update auch alles Funktioniert und war mit Lets Encrypt Zertifikaten gesichert.

Seit dem Update auf DSM 7 geht gar nichts mehr. Die Subdomains verweisen nun alle auf dsm.XXX.ch. Wenn man den Anwendungsport mit in die Adresszeile eingiebt landet man bei der Anwendung aber die Verbindung wird als nicht sicher angezeigt, ausser man greift auf dsm.XXX.ch zu.
Eine Externe verbindung zum Plex Server konnte auch nur noch durch Zufall erstellt werden.

Ich habe auch schon versucht die Reverse Proxy Einstellungen in [Einstellungen -> Anmeldeportal -> Erweitert -> Reverse Proxy] anzupassen aber das half auch nicht.

Ist das ein Bekanntes Problem bei DSM7?
Im Internet findet man Beiträge zu ähnlichen Problemen mit früheren DSM Versionen welche aber mit den vorgeschlagenen Lösungen auch nicht funktionieren.

Ich bin auf eure Erfahrungen gespannt und hoffe das mir vieleicht sogar jemand einen Tipp hat um das zu Lösen.

Greetz ST

 

[Thonav]

Schau bitte mal nach ob die Zertifikate noch richtig zugeordnet sind.

 

[synfor]

Falsch zu geordnete Zertifikate sollten eigentlich nur zu Fehlermeldungen bezüglich der Zertifikate führen und nicht, dass man am falschen Ziel ankommt.

 

[ST-Solutions]

Die Zertifikate, sind korrekt eingerichtet, die haben auch bis zum Update problemlos funktioniert. Ich habe mal testweise ein Zertifikat einer nicht funktionierenden Subdomain gelöscht und neu erstellt, was alles Problemlos geklappt hat.

 

[Benares]

Wenn man den Anwendungsport mit in die Adresszeile eingiebt landet man bei der Anwendung aber die Verbindung wird als nicht sicher angezeigt, ausser man greift auf dsm.XXX.ch zu

Also beim richtigen Ziel landest du schon, oder nur, wenn du den Port mit angibst? Letzteres wäre ja nicht der Sinn der Reverse-Proxy.

Hast du ein Zertifikat für alle Subdomains (Wildcard-Zertifikat) oder hast du für jede ein eigenes?
Ich denke auch, dass es einfach nur an der Zuordnung der Zertifikate zu diversen Reverse-Proxies liegt.
Schau mal unter Systemsteuerung, Sicherheit, Zertifikat, Einstellungen, Konfigurieren und geh die ganze Liste durch.

 

[ST-Solutions]

Ja wenn ich den Port mit angebe dann komme ich dahin wo ich möchte, wenn ich den nicht angebe lande ich immer bei dsm.XXX.ch.
Bei den Zertifikaten ist es komisch. Es funktionieren alle noch ausser die für die Subdomains (Da habe ich für jede Subdomain ein eigenes Zertifikat.) Wenn ich z.B plex.XXX.ch:32400 aufrufe kommt die Warnung website nicht sicher obwohl ein Zertifikat für plex.XXX.ch ausgestellt ist. Reverse Proxys sind aktuell alle Deaktiviert da ich sonst gar keinen Zugriff auf die dienste hatte.

 

[Benares]

Wenn ich z.B plex.XXX.ch:32400 aufrufe kommt die Warnung website nicht sicher obwohl ein Zertifikat für plex.XXX.ch ausgestellt ist

Das ist normal. Ein Zertifikat, das für XXX.ch ausgestellt ist, gilt nicht automatisch auch für plex.XXX.ch, es sei denn, es wäre ein Wildcard-Zertifikat (also auch für *.XXX.ch gültig) oder es wurden auch alle anderen Namen explizit mit aufgenommen. Wichtig ist da die Liste der "Alternative Antragstellername" im Zertifikat.

Schau dir z.B. mal das Zertifikat hier vom Forum an

es gilt exakt für 2 Namen.

Du bräuchtest eines mit allen deinen Namen, oder eines für jeden Namen, oder eben ein Wildcard-Zertifikat.

 

[ST-Solutions]

Ich kann leider keine Wildcard Zertifikate von Lets Encrypt abrufen da die Subdomains nicht von Synology sind. Das mit den alternativen Antragsstellern habe ich (so glaube ich das zumindest) wie du das sagst konfiguriert.

 

[Benares]

Ja, Wildcard-Zertifikate gehen über die Oberfläche nicht, das geht nur per Script.
Deshalb hat man normalerweise dann ein Zertifikat für XXX.ch (als Common Name) mit all den anderen Namen als "Betreff Altervativer Name" - das reicht. Dieses weist man dann allen betroffenen Diensten zu.

Bei dir zeigt momentan nur das 1. Zertifikat auf "Systemstandard" (also default), das 2. wird gar nicht genutzt (ist also unnötig).
Die Liste unter Systemsteuerung, Sicherheit, Zertifikat, Einstellungen, Konfigurieren hat bestimmt mehr Einträge als nur "Systemstandard". Wo zeigt der Rest hin? Normalweise tauchen dort auch alle definierten Reverse-Proxies auf.

 

[Fusion]

Bei plex.example.com Zertifikat muss bei 'Für' in der Übersicht auch der Reverse Proxy Eintrag aufgeführt sein.
Aktuell hast du zwar ein plex.example.com Zertifikat, aber es ist keinem Dienst zugeordnet.

Dann noch zum Aufruf:
plex.example.com ruft den Proxy und dessen Zertifikat auf und dieser redet im Hintergrund mit Plex.
plex.example.com:32400 ruft hingegen direkt den Plex server Dienst an (der Proxy und Zertifikat ist nicht involviert). Der läuft normal mit einem *.plex.direct Zertifikat. Nur wenn du im Plex server selbst ein p12 Zertifikat einbindest benutzt er das.

Und wieso hast du bei den Zertifikaten die jeweiligen anderen Namen als SAN eingetragen?
Entweder alle in ein Zertifikat ,oder für jeden Namen ein eigenes.

 

[ST-Solutions]

Ich habe jetzt nochmal etwas romprobiert mit den Tips die ich von euch bekommen habe aber irgendwas mach ich wohl falsch oder ist verbuggt. Vor dem Update ist alles Reibungslos gelaufen.

Bei Plex tritt jetzt bei den Einstellungen eine neue Problematik auf. Wenn ich den Fernzugriff neu lade kommt kurz ca 5-10s die Meldung das alles klappt, danach wechselt es aber von alleine wieder auf den Fehler. Ich denke auch nicht dass das Problem mit Plex zutun hat aber langsam bin ich mit meinem Latein am Ende.

Hier noch die neuen Einstellungen

 

[Benares]

Sorry, bei Plex muss ich passen.
Der Sinn eines Reverse-Proxy ist doch eher, dass man alles von extern über https:443 schleust und intern, je nach Name, weiter verteilt.

 

[ST-Solutions]

Ja Plex dient hier nur als Beispiel, das Problem tritt auch bei anderen Anwendungen auf die ich so einstellen möchte. Leider bin ich nicht der Reverse Proxy unf Zertifikat Profi..

 

[Benares]

Das Prinzip ist eigentlich recht einfach, es sei denn man macht es kompliziert:

1. Du leitest nur https, Port 443 im Router auf deine DS weiter
2. Für jeden Dienst, den du nach außen anbieten willst, brauchst du im DNS zusätzlich zu deiner Domain (aktualisiert per DDNS) noch eine Subdomain (CNAME) mit entsprechendem Namen, der auch auf die aktuelle, öffentliche IP deines Routers auflöst (XXX.ch, plex.XXX.ch, dsm.XXX.ch, ...). "nslookup ..." sollte für alle Namen das gleiche liefern, deine aktuelle, öffentliche IP.
3. Passend dazu brauchst du auch ein Zertifikat, das alle diese Namen abdeckt.
4. Im letzten Schritt definierst du für jeden Dienst einen entsprechenden Reverse-Proxy, der z.B. auf plex.XXX.ch:443 reagiert und auf localhost:32400 weiterleitet und ordnest diesem dein Zertifikat zu. Für die Weiterleitung braucht es auch kein https mehr zu sein, die Umsetzung erledigt ja schon der Proxy. Das Ziel muss auch nicht unbedingt auf der DS liegen, ein Reverse-Proxy für fritzbox.XXX.ch:443 auf fritz.box:80 ginge auch.

Prinzip verstanden?

 

[Fusion]

Und das was dir Plex unter "nicht von außen erreichbar" anzeigt beim Reverse Proxy eher ignorieren. Die Erkennung funktioniert nicht einwandfrei.
Ich hab in Plex den Fernzugriff deaktiviert, komme aber über den Reverse Proxy trotzdem drauf.
Wichtig oder Empfehlenswert ist dann in den Plex Einstellungen unter Netzwerk deine plex.example.com als Custom Access URL / benutzerdefinierte Domain einzutragen. Dann hinterlegt der Plex Server diese Information auch in deinem plex.tv Konto für deinen anderen Geräte zum Zugriff.

 

[ST-Solutions]

Ich habe die Einstellungen jetzt mal so übernommen wie Benares das beschrieben hat. Leider ist das Ergebnis ein neuer Fehler, und zwar verlinkt die Subdomain nun auf garnichts mehr bzw. es kommt nur noch ein Seiten-Ladefehler. Egal ob man den Port angibt oder nicht. Mit nslookup erhalte ich auch unterschiedliche IPs der Subdomains. Ich habe beim DDNS Anbeiter die einstellungen überprüft und da scheint es zu stimmen.

@Benares: An sich in der Theorie klingt es nicht nicht kompliziert, es ist ja auch bis zum Update wunderbar gelaufen, nur jetzt klappts irgendwie nicht mehr.

 

[Benares]

Dein letzter Screenshot zeigt aber, dass plex auf .191 auflöst und nicht auf .242.

Machst du für jeden Namen ein eigenes DDNS-Update? Das ist eigentlich nicht nötig, wenn z.B. nur XXX.ch (also die Hauptdomäne) per DDNS aktualisiert wird und die anderen Namen nur CNAMES (also Aliase) dafür sind.

Bei mir sieht das dann z.B. so aus:

C:\>nslookup dsm.example.com
Server:  fritz.box
Address:  fd00::...

Nicht autorisierende Antwort:
Name:    example.com
Addresses:  2002:...
          83.135.x.x
Aliases:  dsm.example.com

 

[ST-Solutions]

Meine Hauptdomänen ist dsm.XXX.ch.
Welche auch in Synology als DDNS eingetragen ist. Ansonsten habe ich beim DDNS nur noch die synology ddns eingetragen. Die IP mit .242 am Ende wäre die richtige, aber anscheinend aktualisiert sich die plex Domain nicht mit. Ich frage mal beim DDNS Anbieter wieso das so ist.

 

[Fusion]

Beim Anbieter hat sie sich doch aktualisiert, nur bei deinen angefragten DNS Servern bzw. DNS Resolver nicht.

 

[ST-Solutions]

Jetzt hat sie sich plötzlich doch noch richtig aktualisiert. Mit nslookup löst die Subdomäne jetzt auf die richtige IP auf.
Jetzt bin ich aber wieder beim gleichen Problem wie am Anfang, alle Subdomains lösen zu DSM auf. Die Reverse Proxy Einstellungen sind wie oben in den Bildern und die Zertifikate sind zu den Proxys zugeordnet.