+-Serie Über cname von meiner subdomain auf DynDNS weiterleiten

[jahlives]

nei das ist nicht möglich Ein Nameserver bekommt gar nicht mit ob du https oder http ansprechen willst. Er bekommt in beiden Fällen den Request eine IP für subdomain.meinedomain.tld zu liefern

 

[Tuvok42]

Und einen Schreibfehler im CNAME-Eintrag kannst Du definitiv ausschließen?

Ja, weil "http://subdomain.meinedomain.de" funktioniert, nur der HTTPS-Aufruf (mit dem zusätzlichen s und dem Port 5001) liefert kein Ergebnis.

 

[Frogman]

Und die Zugriffsversuche finden allesamt von einem Gerät außerhalb Deines LANs statt, dessen Cache Du auch einmal zwischendurch gelöscht hast?

 

[Tuvok42]

Und die Zugriffsversuche finden allesamt von einem Gerät außerhalb Deines LANs statt?

Ja. z.Zt. von Arbeit
Edith sagt: Auch die Cache-Löschung brachte keinen Erfolg.

 

[Fusion]

Kann es sein, dass hier eine Firmen-Firewall reinpfuscht? Ich kann z.B. auch keine beliebigen Ports aus dem Firmennetz erreichen.

 

[Frogman]

Nur damit ich das nicht falsch verstehe: Der Zugriff auf DDNS:5001 funktioniert aktuell auch von Deinem Arbeitsplatz, nur der über sub.meinedomain.de:5001 nicht?

 

[Tuvok42]

Kann es sein, dass hier eine Firmen-Firewall reinpfuscht? Ich kann z.B. auch keine beliebigen Ports aus dem Firmennetz erreichen.

Nein, weil ich die Zugriffe von meinem privatem Smartphone übers Mobilnetz mache. Die Firmen-Firewall schlägt bei den Zugriffsversuchen via "http://meineDS.DSCloud.me" und "http://meineFritzbox.myfritz.net" zu (dies wird mir aber im Browser auch mitgeteilt "Diese Domain wird durch Smartfilter gesperrt"). Auch bei den korrespondierenden HTTPS-Aufrufen. Auf "https://meineIP:5001" reagiert aber die Firmen-Firewall und der Smartfilter nicht. Auf "http://subdomain.meinedomain.de" kann ich jedoch zugreifen und beim HTTPS-Aufruf kriege ich nur den Time-Out und keine Browser-Mitteilung.

 

[Tuvok42]

Nur damit ich das nicht falsch verstehe: Der Zugriff auf DDNS:5001 funktioniert aktuell auch von Deinem Arbeitsplatz, nur der über sub.meinedomain.de:5001 nicht?

Ja; gestern

Der Aufruf "http://subdomain.meinedomain.de" führt mich auch direkt zur Webseite meiner DS. Der Aufruf "https://subdomain.meinedomain.de:5001" (wahlweise auch mit angehängtem "/webman/index.cgi") führt zur Fehlermeldung "Netzwerk-Zeitüberschreitung" ("Operation timed out"). Der Aufruf mit der (temporären) IP-Adresse meiner Fritzbox "https://meineIP:5001" (auch hier wahlweise mit angehängtem "/webman/index.cgi") führt mich jedoch direkt zur Anmeldemaske der DS (DSM 5; aktuelle Version).

und heute

Unter "https://meineDS.DSCloud.me:5001" erreiche ich meine Anmeldeseite auf der DS, bekomme aber die Zertifikatswarnung (weil ich kein Zertifikat für dscloud.me erstellen kann) und muss eine Ausnahme zulassen.
Unter "https://meineFritzbox.myfritz.net:5001" erreiche ich meine Anmeldeseite auf der DS, bekomme aber die Zertifikatswarnung (weil ich kein Zertifikat für myfritz.net erstellen kann) und muss eine Ausnahme zulassen.
...
Rufe ich nun "https://subdomain.meinedomain.de:5001" auf kriege ich gar keine Seite angezeigt, sondern nach einer Weile "Netzwerk-Zeitüberschreitung: Der Server antwortet nicht" ("Operation timed out"). Rufe ich jedoch "http://subdomain.meinedomain.de" auf, lande ich auf der Startseite des Webservers meiner DS.

 

[Fusion]

Von der Firmen-Firewall bekomme ich auch nur selten eine Meldung, meistens eben einen timeout.

Da liest sich irgendwie wie ein Problem auf dem Apache und eventuell den vHosts (wenn ich mal davon ausgehe, dass die ganzen DDNS Adressen alle auf ein und dieselbe IP auflösen).

 

[Tuvok42]

Da liest sich irgendwie wie ein Problem auf dem Apache und eventuell den vHosts (wenn ich mal davon ausgehe, dass die ganzen DDNS Adressen alle auf ein und dieselbe IP auflösen).

Ja, weil alle logischen Namen auf dieselbe IP-Adresse auflösen, vermute ich das Problem beim Nameserver meines Hosters:
"meineDS.DSCloud.me": Nameserver für DSCloud.me liefert "meineIP" => Zugriff funktioniert (HTTP und HTTPS)
"meineFritzbox.myfritz.net": Nameserver für myfritz.net liefert "meineIP" => Zugriff funktioniert (HTTP und HTTPS)
"meineIP": Zugriff funktioniert (HTTP und HTTPS)
"subdomain.meinedomain.de": Nameserver meines Hosters verweist via CNAME auf "meineDS.DSCloud.me" => HTTP-Zugriff funktioniert; HTTPS-Zugriff funktioniert nicht (Time-Out, Server antwortet nicht)
Inwieweit soll jetzt der Apache und/oder vHosts da involviert sein?
Es scheint irgendetwas mit meinem Hoster und dessen Nameserver zutun zu haben. Habe mal "https://www.meinedomain.de" eingegeben. Ergebnis: Firefox meldet "ssl_error_rx_record_too_long"; der IE behauptet "Die Webseite kann nicht angezeigt werden" und der Samsung-Browser spricht von einem "SSL-Verbindungsfehler". Werde also bei meinem Hoster nachfragen, was ich benötige, um HTTPS-Zugriffe über seinen Nameserver zuleiten. Wäre für Anregungen und Hintergrundinformationen (wie und warum filtert der Nameserver des Hoster HTTPS-Zugriffe bzw. liefert unsinnige Antworten) dankbar. Bin auf diesem Bereich ziemlich grün und schätze die Qualität der eingesetzten Servicemitarbeiter nicht sehr hoch ein (hatte bereits ein zweifelhaftes Vergnügen; aber das ist eine andere Geschichte).

 

[Fusion]

Achso, diese cname Konstruktion hatte ich ja ganz vergessen. Allgemein sollte aber die Zuweisung eines alternativen canonical names komplett unabhängig vom verwendeten Dienst sein (also dem "Port").

Führt denn ein nslookup und ping von sub.domain.tld am Ende auf die öffenltiche IP deines Anschlusses?

Der ssl error deutet auf eine fehlerhafte Konfiguration der Zertifikate auf der DS hin. Es könnte z.B. ein fehlendes oder fehlerhaftes Intermediate sein. Ohne reale Adressen kann ich da aber nur raten.

Über vHosts sagt man dem Webserver ja was er zu einer bestimmten angefragten URL für einen Inhalt liefern soll. Vielleicht ist da irgendwas "kaputt" gegangen und die Anfrage läuft ins Leere.

 

[Tuvok42]

Achso, diese cname Konstruktion hatte ich ja ganz vergessen. Allgemein sollte aber die Zuweisung eines alternativen canonical names komplett unabhängig vom verwendeten Dienst sein (also dem "Port").

Ja, so habe ich das in diesem und anderen Fäden in diesem Forum gelesen und gelernt.

Führt denn ein nslookup und ping von sub.domain.tld am Ende auf die öffenltiche IP deines Anschlusses?

Ja; und die HTTP-Zugriffe erreichen auch meine DS. Nur die HTTPS-Zugriffe scheinen meine DS nicht zu erreichen.

Der ssl error deutet auf eine fehlerhafte Konfiguration der Zertifikate auf der DS hin. Es könnte z.B. ein fehlendes oder fehlerhaftes Intermediate sein. Ohne reale Adressen kann ich da aber nur raten.

Über vHosts sagt man dem Webserver ja was er zu einer bestimmten angefragten URL für einen Inhalt liefern soll. Vielleicht ist da irgendwas "kaputt" gegangen und die Anfrage läuft ins Leere.

Wieso auf meiner DS? Der HTTPS-Zugriff auf meine DS funktioniert grundsätzlich via IP und DDNS von AVM und Synology; nur dass ich die Warnung erhalte, dass mein Zertifikat auf der DS nicht mit den eingegebenen Namen im Browser übereinstimmt und - weil es ein selbst erzeugtes Zertifikat ist - nicht vertrauenswürdig ist. Nach dem Abnicken der entsprechenden Warnungen und "sind sie sicher?"-Meldungen bekomme ich auch Zugriff.
Da jedoch auch der HTTPS-Zugriff auf meine Domain - die beim Hoster betrieben wird - nicht klappt (mit je nach Browser unterschiedlichen Meldungen) scheint meinem Paket beim Hoster noch irgendeine Einstellung (oder kostenpflichtigen Erweiterung) zu fehlen, damit ich HTTPS verwenden kann. Kann es sein, dass der Hoster HTTPS-Zugriffe irgendwie grundsätzlich sperrt und diese nur - ggf. Kostenpflichtig - individuell freischaltet?

 

[Fusion]

Das wäre mir jetzt neu, aber sag niemals nie. Welcher Hoster ist es denn?

Ich dachte halt, dass es eventuell mit dieser cname-Konstruktion und eventuell vHost Einträgen zu einer Unverträglichkeit kommt, die die Browser eben nicht nur mit einer "sind sie mit dem abweichenden Namen einverstanden" Meldung abnicken.
Hab jetzt mit solchen Problemen nicht gerade im Dutzend Routine, dass ich direkt sagen könnte was es ist.

 

[Tuvok42]

Das wäre mir jetzt neu, aber sag niemals nie. Welcher Hoster ist es denn?

1blu. Habe ebend im Frontend des Hosters die Möglichkeit gefunden, einen SSL-Proxy für meine subdomain "einzuschalten". Da die Einstellungen aber Zeit brauchen, bis sie wirken und ich jetzt mich anderen Themen widmen muss, melde ich morgen wieder.
Danke allen für die Denkanstöße und die tatkräftige Unterstützung. :thumbsup
Edith sagt: Bin für weitergehende Informationen z.B. was ist ein SSL-Proxy und was tut er? dankbar; gerne auch auf weitere Informationsquellen zum selber lesen.

 

[Fusion]

Ohne mich da nochmal rückversichert zu haben... ein ssl-proxy wird meist nur verwendet um z.B. für eine Web-Site ein SSL Zugriff zu bekommen ohne ein eigenes Zertifikat zu besitzen (also nur das des Providers). Müßte ich aber auch erstmal bei 1blue wieder schauen, was die darunter verstehen um eine belastbare Aussage zu treffen.

 

[Tuvok42]

Heute funktioniert es plötzlich wie erwartet. Was hat sich geändert: Ich habe meinen Hoster am Freitag nochmals beauftragt, den CNAME-Eintrag zu überprüfen, da nur die HTTP-Weiterleitung funktioniert. Als Reaktion bekam ich die obligatorische Antwortmail "Auftrag erledigt" und nun funktioniert es. Gleichzeitig hatte ich im Frontend die Möglichkeit gefunden einen "SSL-Proxy" für eine meiner Domänen einzuschalten (was auch immer das bedeuten soll). Dies habe ich getan und nachdem es keine Wirkung zeigte wieder rückgängig gemacht. Lange Rede kurzer Sinn: Keine Ahnung was jetzt die Ursache war, es funktioniert jetzt.
Vielen Dank für die Unterstützung.

 

[Fusion]

Danke für die Rückmeldung. Schade das 1Blue da so wortkarg ausfällt...