Paket-Zentrum / Verbindung fehlgeschlagen ...

[AR88]

Meine Vermutung liegt ebenfalls noch an der vergangenen AWS Störung.
Bis vor ein paar Tagen lief meine DS223j ohne Probleme. Heute hatte ich, mehr durch Zufall, festgestellt, dass kein Zugriff über QuickConnect mehr möglich war.

Nach vielen Testen komme ich zu dem Ergebnis, dass die DS223j keine Verbindung ins Internet aufbauen kann. Sowohl der Paketmanager auf der DiskStation als auch die Updatesuche in den Einstellungen liefert immer wieder "Verbindung fehlgeschlagen". Kurioserweise funktioniert jedoch der Abgleich der Zeit über NTP problemlos.

An meiner FritzBox bzw. an der DNS-Auflösung im Netzwerk sollte es nicht liegen, da ich direkt auf der DiskStation per SSH ein nslookup auf synology.com durchgeführt habe. Ergbenis: löst korrekt mit 3.99.72.136 und 15.157.251.244 auf. Auch ist der zu verwendende DNS-Server direkt auf der DiskStation mit 8.8.8.8/alternativ 8.8.4.4 fest eingestellt. Die nutzt also gar kein DNS-Server im Netzwerk bzw. von der FritzBox.

... und nun weiß ich auch nicht weiter was man da noch machen könnte.

 

[progs]

Hallo, hatte das gleiche Problem. Neustart, etc. nichts gebracht. Gerade ein manuelles Update auf die 7.3 gemacht und alles geht wieder wunderbar.

 

[Erich-maier]

Guten Morgen in dem anderen Post wurde evtl ein certificates Problem angesprochen. Durchaus denkbar und kann man ja mal probieren.

Die Eingabe:

curl -v https://account.synology.com

Ausgabe:

* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL: no alternative certificate subject name matches target host name 'account.synology.com'
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name 'account.synology.com'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Am Anfang steht was von von finished und zum Ende hin failed. Ich kann das nicht wirklich interpretieren, ob das jetzt gut ist, oder nicht.

Auch das Update:

sudo update-ca-certificates.sh

gab folgende Rückmeldung:

ehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
149 added, 0 removed; done.

Auch da wieder die Frage, ist das gut?

 

[Hagen2000]

Die erste Meldung besagt eigentlich, dass Du von dem angesprochenen Server ein Zertifikat erhalten hast, das nicht zu account.synology.com passt. Das könnte an einer falschen Auflösung im DNS liegen und das würde dann außerhalb deines Einflussbereichs liegen. Hier könntest Du mal die Ausgabe von nslookup account.synology.composten.

Was passiert denn, wenn Du mal testweise die URL https://account.synology.com im Browser aufrufst (da sollte eigentlich die Anmeldeseite des Synology-Kontos erscheinen, was bei mir auch der Fall ist)?

Die zweite Meldung ist nur eine Warnung und tritt nach meiner Einschätzung vermutlich konstruktionsbedingt auf.

 

[Erich-maier]

Danke für die Infos. Bei https://account.synology.com lande ich genau im Account-Bereich von Synology.

Eingabe:

nslookup account.synology.com

Ausgabe:

Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   account.synology.com
Address: 18.173.233.39
Name:   account.synology.com
Address: 18.173.233.129
Name:   account.synology.com
Address: 18.173.233.49
Name:   account.synology.com
Address: 18.173.233.66

Sieht aus meiner Sicht nicht ganz falsch aus, oder?

 

[Benares]

Ich habe "curl -v https://account.synology.com" eben mal hier probiert. Auf beiden DSen klappt es und es kommt irgendwann der html-Code.

Beispiel DS415+

root@DS415:~# curl -v https://account.synology.com
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
> GET / HTTP/2
> Host: account.synology.com
> user-agent: curl/7.79.1
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 302
< content-type: text/html; charset=utf-8
...

Auf der DS1522+ ist es ähnlich, nur sind es mehr Zeilen bis zu "accept"

Bei nslookup bekomme ich aber andere Adressen

root@DS415:~# nslookup account.synology.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   account.synology.com
Address: 18.245.46.14
Name:   account.synology.com
Address: 18.245.46.50
Name:   account.synology.com
Address: 18.245.46.69
Name:   account.synology.com
Address: 18.245.46.37

komisch

 

[Hagen2000]

Bei mir liefert der nslookup wieder andere IP-Adressen, aber das hängt offensichtlich vom Standort ab. Auf jeden Fall sind die alle bei Amazon gehostet.
@Erich-maier : Welche DSM-Version setzt Du ein? Schon mal hier gelesen?

 

[Erich-maier]

Ich habe 7.1.1 im Einsatz und daher den Knopf nicht (der kam erst mit 7.2) Auf 7.2 kann ich meine nicht aktualisieren. Ich habe auch ein Ticket bei Synology aufgemacht. Die haben mir genau den Tipp aus dem anderen Post gegeben. Es riecht aber nach DNS. Will mal eben die HOSTS anpassen, mal schauen.

 

[Benares]

das hängt offensichtlich vom Standort ab

Das könnte sein. Ein Reverse Lookup liefert z.B.

Name: server-18-245-46-50.fra56.r.cloudfront.net
Address: 18.245.46.50
bei meinen Adressen und
Name: server-18-173-233-39.dus51.r.cloudfront.net
Address: 18.173.233.39
bei denen von @Erich-maier

fra56 könnte Frankfurt sein, das würde bei mir passen. dus51 vielleicht Düsseldorf?

 

[Benares]

@Erich-maier, nimm mal testweise in der Datei /etc/resolv.conf die Zeile "domain fritz.box" raus. Genau das macht nämlich das bei dir fehlende Häkchen (eben auf der DS1522+ getestet)

 

[Erich-maier]

Das war die LÖSUNG!

 

[josch4711]

Ich habe 7.1.1 im Einsatz und daher den Knopf nicht (der kam erst mit 7.2) Auf 7.2 kann ich meine nicht aktualisieren. Ich habe auch ein Ticket bei Synology aufgemacht. Die haben mir genau den Tipp aus dem anderen Post gegeben. Es riecht aber nach DNS. Will mal eben die HOSTS anpassen, mal schauen.

Der Amazon Störfall war ja ein Problem mit dem DNS.
Durch DNS-Caching, verteilte Server usw. kann es eine Weile dauern, bis alle System wieder die richtigen Einträge haben.

 

[Hagen2000]

@Erich-maier @Benares Gehe ich richtig in der Annahme, dass Ihr jeweils nicht die FRITZ!Box als DNS-Server verwendet?

 

[Benares]

@josch4711, Ich denke das hat wohl eher damit zu tun, dass AVM Mist gebaut hat und es die Domain "fritz.box" im Internet wirklich gibt und die alles zu localhost auflöst. Befragt man also einen externen Nameserver nach irgendwas.fritz.box liefert der immer ::1 und 127.0.0.1

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

Non-authoritative answer:
Name:   irgendwas.fritz.box
Address: 127.0.0.1
Name:   irgendwas.fritz.box
Address: ::1

@Hagen2000 Nein, ich verwende meine Fritzbox als DNS, die macht es richtig. Ich war nur gestern zufällig auf dieses Problem gestoßen.

Edit: Die Domain "fritz.box" gehört seit letztem Jahr wieder AVM. Warum die diesen Unsinn machen, weiß ich nicht. Ich hab das gestern dem AVM-Support gemeldet, aber die haben es nicht verstanden.

 

[patrickn]

Verstehe auch nicht warum AVM sich nicht endlich des fritz.box entledigt.
Spätestens seit es .box gibt hätte man den DNS Suffix eigentlich ändern müssen.

 

[Erich-maier]

@Erich-maier @Benares Gehe ich richtig in der Annahme, dass Ihr jeweils nicht die FRITZ!Box als DNS-Server verwendet?

Nein, ich habe testweise die 8.8.8.8 als DNS auf der Diskstation eingetragen.
Ich betreibe noch im Netzwerk ein PiHole, den ich eigentlich überall als DNS verwende. aber der hat Quad9 (filtered, DNSSEC) als DNS aktiviert. Meine Internetverbindung hängt aber an einer Fritz!Box.

Mit dem ändern der /etc/resov.conf konnte ich den PiHole wieder als DNS verwenden. ... Es läuft tatsächlich alles wieder.

 

[Hagen2000]

Befragt man also einen externen Nameserver nach irgendwas.fritz.box liefert der immer ::1 und 127.0.0.1

In der Tat merkwürdig - aber warum sollte überhaupt auf irgendwas.fritz.box zugegriffen werden?
Das würde ja bedeuten, dass der curl bei Erich-maier beispielsweise versucht hat auf account.synology.com.fritz.box zuzugreifen. Klar hätte da der Fehler NXDOMAIN kommen sollen, was bei mir auch der Fall ist (die FRITZ!Box ist bei mir der DNS-Server).

 

[Erich-maier]

Kann ich das für dich irgendwie genauer austesten?

 

[ctrlaltdelete]

Schaut mal hier?
https://www.synology-forum.de/threads/synology-down.140248/post-1260732

 

[josch4711]

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

Nach dem Update auf DSM 7.3 funktioniert bei mir wieder alles und
curl -v https://account.synology.com
liefert nun auch den entsprechenden HTML-Code.

Synology nutz AWS:
subject=CN = account.synology.com
issuer=C = US, O = Amazon, CN = Amazon RSA 2048 M03

Meine Vermutung, und für mehr reicht meine Ahnung leider nicht;
Durch das DNS-Problem ist die Zertifikatskette kaputt gegangen (anderes Intermediate-CA). Durch das Update auf 7.3 wurden die Zertifikate aktualisiert bzw. vervollständigt.