Paket-Zentrum / Verbindung fehlgeschlagen ...

[Benares]

Die AVM-Denke ist da folgende:
AVM nutzt schon immer "fritz.box" für die interne Domain. Der DHCP-Server der Fritte verteilt "fritz.box" als DNS-Suffix an die Clients. Ziel war es, dass auch die interne Namensauflösung ohne den Anhang "fritz.box", als mit Kurzname klappt. Was der Client damit macht, ist betriebssystemabhängig. Windows trägt "fritz.box" in die DNS-Suffix-Suchliste ein, bei jeder Namensauflösung wird also erstmal fritz.box angehängt. Mit der Fritte als DNS klappt das auch. Die schaut, ist das einer von meinen, wenn nicht löst sie extern auf. Bei Linux ist es anders, da kommt es darauf an, ob in der /etc/resolv.conf entweder "search ..." oder "domain ..." eingetragen wird. Mit "search" ist es so wie bei Windows, mit "domain" nicht. Deshalb klappt dort ein "nslookup synology.com 8.8.8.8" auch, bei Windows nicht (bzw. liefert localhost). Wie das bei Zertifikatsprüfungen ist, weiß ich nicht.

Ich denke, hier kam einfach beides zusammen. Die AWS-Störung und den Mist, den AVM gebaut hat.

 

[Hagen2000]

Kann ich das für dich irgendwie genauer austesten?

Nein, Danke, ist schon klar, was passiert ist.

Solange die FRITZ!Box der primär angesprochene DNS-Server ist, funktioniert alles richtig. Erst wenn man eigene DNS-Server konfiguriert oder PiHole / Adguard etc. aufsetzt, beginnen die Probleme mit der Domäne fritz.box. Ich bin der Meinung, dass hier ein Konfigurationsmangel vorliegt: Auf dem eigenen DNS-Server muss die Domäne fritz.box ausgesteuert werden und an die FRITZ!Box zur Namensauflösung weitergeleitet werden. Das ist im Tutorial von plang.pl auch irgendwo erwähnt. Fängt man die Domäne intern ab, dann kann einem auch völlig gleichgültig sein, wie und ob die Domäne extern aufgelöst wird.

 

[Benie]

Hat jemand das schon ausprobiert ?

https://kb.synology.com/de-de/DSM/tutorial/Why_cant_I_connect_to_Package_Center

 

[Hagen2000]

Ich verstehe nicht, wie das Zertifikats-Problem da mit reinspielt, welches Erich-maier ja auch hat(te).

Gar nicht, das Problem bestand nämlich nicht.

Durch das DNS-Problem ist die Zertifikatskette kaputt gegangen (anderes Intermediate-CA).

Nein, auch das ist m.E. nicht passiert.

Ich könnte mir folgenden Ablauf vorstellen:
Durch das DNS-Problem (bei Amazon ausgelöst), funktionierte der Zugriff auf account.synology.com nicht und daher wurde versucht auf account.synology.com.fritz.box zuzugreifen. Das wird aber zu "localhost" aufgelöst (127.0.0.1 bzw. ::1) und somit wird jetzt auf das eigene System zugegriffen. Dieses liefert natürlich - sofern vorhanden - ein Zertifikat für das eigene NAS und das passt nicht zu account.synology.com. Daher die entsprechende Fehlermeldung in #103 "no alternative certificate subject name matches target host name 'account.synology.com'".

 

[Erich-maier]

Auf dem eigenen DNS-Server muss die Domäne fritz.box ausgesteuert werden und an die FRITZ!Box zur Namensauflösung weitergeleitet werden. Das ist im Tutorial von plang.pl auch irgendwo erwähnt.

Ok, könntest du noch dein angesprochenes Tutorial (plant.pl) verlinken. Würde gerne dazulernen und solche Fehler zukünftig vermeiden.

 

[Erich-maier]

Hat jemand das schon ausprobiert ?

https://kb.synology.com/de-de/DSM/tutorial/Why_cant_I_connect_to_Package_Center

Ja, das war mein erster Anlauf. Hat keine Besserung gebracht.

 

[Hagen2000]

Findest Du unter "Empfohlene Inhalte": https://www.synology-forum.de/threads/best-practice-adguard-home-unbound-als-dns-server.127983/

 

[Erich-maier]

So ein bisschen ärgere ich mich über mich selbst. Das ist ein klarer Konfigurationsfehler.

Im PiHole sagt der mir das sogar, habe aber dem bisher keine Beachtung geschenkt. Unter Conditional Forwarding steht:

The following list contains all reverse servers you want to add. The expected format is one server per line in form of <enabled>,<ip-address>[/<prefix-len>],<server>[#<port>][,<domain>]. A valid config line could look like true,192.168.0.0/24,192.168.0.1,fritz.box

Wenn man den Eintrag für sich übernimmt (und evtl die IPs anpasst), dann kann man die Domain in der Diskstation stehen lassen und es funktioniert.

Danke für die zielführenden Infos.

 

[josch4711]

Gar nicht, das Problem bestand nämlich nicht.

Ah, mein Fehler. Ich habe die curl-Ausgabe nicht genau beachtet, nur, dass es nicht erfolgreich war in beiden Fällen.

Nein, auch das ist m.E. nicht passiert.

Ich könnte mir folgenden Ablauf vorstellen:
Durch das DNS-Problem (bei Amazon ausgelöst), funktionierte der Zugriff auf account.synology.com nicht und daher wurde versucht auf account.synology.com.fritz.box zuzugreifen. Das wird aber zu "localhost" aufgelöst (127.0.0.1 bzw. ::1) und somit wird jetzt auf das eigene System zugegriffen. Dieses liefert natürlich - sofern vorhanden - ein Zertifikat für das eigene NAS und das passt nicht zu account.synology.com. Daher die entsprechende Fehlermeldung in #103 "no alternative certificate subject name matches target host name 'account.synology.com'".

Das hätte man bei
openssl s_client -connect account.synology.com:443 -showcerts
erkennen können?

Bei meiner Syno mit DSM 7.2.2 lieferte das übrigens "Verify return code: 0 (ok)".

curl und openssl verwenden offensichtlich bei der DSM Version unterschiedliche CA-Zertifikate. Weshalb wohl auch einige Sachen noch funktionierten und andere eben nicht.

 

[Benares]

Ich hab das gestern dem AVM-Support gemeldet, aber die haben es nicht verstanden.

Oh, kann sein, dass AVM mich doch verstanden hat

root@DS1522:~# nslookup irgendwas.fritz.box 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

** server can't find irgendwas.fritz.box: NXDOMAIN

 

[Hagen2000]

Cool!
Deine Argumentation bzgl. der /etc/resolv.conf kann ich allerdings nicht ganz nachvollziehen. Nach dieser Quelle heißt es "The domain directive is an obsolete name for the search directive that handles one search list entry only".
Generell muss man natürlich aufpassen, dass einem die DNS-Caches bzw. deren Devalidierung bei den ganzen Analysen nicht dazwischen kommen.

 

[Hagen2000]

Das hätte man bei
openssl s_client -connect account.synology.com:443 -showcerts
erkennen können?

Glaube ich eigentlich nicht, denn curl und openssl stützen sich ja beide auf das selbe DNS ab. Aber inzwischen (siehe #130) wird ja wohl ein NXDOMAIN-Fehler statt "localhost" geliefert und man kann das nicht mehr testen.

 

[Benares]

Mag sein, trotzdem tragen die DSen den über DHCP vergebenen DNS-Suffix als "domain ..." in die /etc/resolv.conf ein.

 

[ctrlaltdelete]

Außer du nimmst den Haken hier raus oder?

 

[Benares]

Ja, gibt's aber noch nicht in der 7.1.1, m.W. erst ab der 7.2er

 

[powermaniaxx]

Bei mir geht wieder alles, hab nichts verändert.