connection refused

Mal geprüft ob die IP noch richtig ist?

Lu schrieb:

Mal geprüft ob die IP noch richtig ist?

Dann würde eine Zeitüberschreitung kommen. Bei "refused" ist der Host erreichbar, aber auf den angesprochenen Port "hört" kein Dienst (ssh, http oder smb?).

Peter N. schrieb:

Es kommt immer die Meldung "Error: connection refused".

Bei welcher Aktion genau?

Wie kann ich das beheben?

Mehr Informationen darüber geben, was mit welchem Ergebnis versucht wurde.

Z. B. Handbuch Seite 53 und 54. https://www.bedienungsanleitu.ng/qnap/ts-1673u/anleitung?p=53

Im Nutzerforum gefragt?

Rolf schrieb:

Mehr Informationen darüber geben, was mit welchem Ergebnis versucht wurde.

Die Meldung kommt, wenn ich die IP im Edge eingebe. Sowohl auf dem 1G-, als auch auf dem 10G-Anschluß, auch schon mit SSH probiert (da weiß ich aber nicht, ob das im NAS läuft).

Intern lief das NAS, es hat mir ständig Status-E-Mails geschickt.

Weitere Versuche: Start ohne HDs. Dann geht das NAS in den Installisierungsmodus. Da hatte ich Zugriff. HDs eingeschoben und "auf Werkseinstellungen setzen". Dann versucht das NAS das RAID wieder herzustellen. Nachdem es damit fertig war wieder "connection refused".

3-Sekunden-Reset: IP wurde dann über DHCP zugewiesen. sonst keine Änderung.

10s-Reset: Keine Änderung.

Rolf schrieb:

Im Nutzerforum gefragt?

In einem. Keine funktionierenden Antworten.

Ingo W. schrieb:

Bei "refused" ist der Host erreichbar, aber auf den angesprochenen Port "hört" kein Dienst (ssh, http oder smb?).

HTTP ist für die Weboberfläche und SMB für Dateizugriff?

Ich habe Dateizugriff über IP mit Explorer versucht. Rückfrage nach User und Paßwort, aber nichts wurde akzeptiert.

Peter N. schrieb:

Ich habe Dateizugriff über IP mit Explorer versucht. Rückfrage nach User und Paßwort, aber nichts wurde akzeptiert.

Das ist dann schon eine Schicht höher (SMB ist dann offen). Wohl ein Problem mit der Nutzerdatenbank im NAS.

Ingo W. schrieb:

Das ist dann schon eine Schicht höher (SMB ist dann offen). Wohl ein Problem mit der Nutzerdatenbank im NAS.

Nein, da wäre die Antwort permission denied. Ich denke auch es ist der Port

noch ein Tip: hol Dir nmap und schaue, was am NAS noch offen ist

Peter N. schrieb:

Intern lief das NAS, es hat mir ständig Status-E-Mails geschickt.

Findet sich in den Status emails irgend ein Hinweis daß was nicht funktioniert?

Peter N. schrieb:

Wie kann ich das beheben?

Frag mal beim Service der Kiste nach. Wo ist denn sonst noch überall der Strom ausgefallen, und wie lange, ist ja kein Trivial-Ding? Je nach Vorfall müsste man vielleicht auch Bios-Einstellungen überprüfen.

Rbx schrieb:

Wo ist denn sonst noch überall der Strom ausgefallen, und wie lange, ist ja kein Trivial-Ding?

Der Strom war mehrere Straßen weg, wie lange weiß ich nicht, aber etliche Minuten.

PC und Fritzbox sind dann wieder normal hochgefahren. Einige NAS auch,

Ein NAS ist zwar hochgefahren, lies sich aber nicht ansprechen. Nach einem Neustart ging es.

Ein weiteres NAS wollte nicht hochfahren, nach einigem guten Zureden fuhr es dann hoch, aber die Netzwerkadapter sind seitden vertauscht.

Der SAT-Receiver hat sich beim Hochfahren auch verhaspelt, danach kannte er kein Internet mehr und zum Schluß funktionierte NTP auch nicht.

Und am Schlimmsten hat es den TS-1673U getroffen, da ich da nicht mehr reinkomme.

Insgesamt ein Stromausfall mit merkwürdigen Auswirkungen auf mein Heimnetz...

Der Klinken-Anschluss auf der Rückseite ist wohl eine serielle Schnittstelle, schliess da mal einen Rechner an (ggf mit Pegelkonverter a la MAX232 etc) und starte ein Konsolen-Programm, beim Hochfahren sind da sicher interessante Sachen zu lesen

Stephan S. schrieb:

Der Klinken-Anschluss auf der Rückseite ist wohl eine serielle Schnittstelle, schliess da mal einen Rechner an (ggf mit Pegelkonverter a la MAX232 etc)

Im NAS ist ein Pegelwanler.

Ich habe ein USB-Serialkabel, aber was bedeutet der Anschlußname im Gerätemanager "THIS IS NOT PROFILIC PL2303, PLEASE CONTACT YOUR SUPPLIER."

Win hat einen Profilic-Treiber installiert, dieser hat sich auf COM7 eingestellt. PuTTY meint, kein Adapter vorhanden...

Kann ich dieses Kabel aktivieren?

Steve van de Grens schrieb:

Du verwendest entweder einen gefälschten oder einen alten USB-UART Adapter von Prolific.

Es ist ein altes Teil. die Dinger haben wir vor mehreren Gerätegenerationen in der Firma benutzt. Es akzeptiert den Treiber 3.3.2.105.

Leider tut sich mit PuTTY nichts. Wo sind da eigentlich die Serialparameter Datenbits, Parität, Stopbits?

Das NAS soll 115200 Baud haben.

Ich habe es auch am Konsolenport eines Switch angeschlossen und mit 9600 und 115200 Baud probiert, ebenfalls nichts.

Der dem NAS zugrunde liegende Rechner scheint ja noch zu funktionieren, da Du Emails bekommst. Dass am COM-Port nichts rauskommt, ist schon merkwürdig.

Ich habe noch das hier https://www.qnap.com/de-de/how-to/faq/article/how-do-i-enter-the-console-and-bios-on-the-qnap-nas-only-with-3-5mm-console-port gefunden, damit kommt man angeblich noch ins BIOS (ist allerdings ein anderes Modell) und das hier https://forum.qnapclub.de/thread/42855-qnap-consolen-port-zugang-und-belegung/

Edit: hats Du es mal mit ssh über das Netzwerk probiert? ssh <user> <ip-nr> als <user> würde ich mal root oder admin probieren

Vielleicht hilft sniffen auf dem LAN mit etherape oder ähnlicher Anwendung weiter um herauszufinden was schief läuft.

Peter N. schrieb:

Leider tut sich mit PuTTY nichts. Wo sind da eigentlich die Serialparameter Datenbits, Parität, Stopbits?

Im linken Auswahlbaum: Connection - Serial

9600 Baud 8N1 ist bei mir als default eingestellt.

Peter N. schrieb:

Ich habe es auch am Konsolenport eines Switch angeschlossen und mit 9600 und 115200 Baud probiert, ebenfalls nichts.

Rx und Tx vertauscht vielleicht?

Vielleicht einfach mal ohne Netzwerk-Kabel neustarten.. Kabel nach dem hochfahren einstecken.

Feste IP oder DHCP? Vielleicht haben die untereinander die IPs getauscht.

Alle anderen runterfahren, nur den betroffenen hochfahren.

Sind Hostnames vergeben?

Im E-Mail Header der E-Mails Hostname und IP überprüfen. (Edit: macht wahrscheinlich keinen Sinn, die Mail wird bestimmt in der Cloud verschickt.)

Hast du den Weblink mit https://<IP-Adresse> geöffnet? (mit http:// gehts nicht mehr automatisch)

Ansonsten den Qfinder Pro als Software herunterladen und dort prüfen ob du auf die Konfiguration kommst? https://www.qnap.com/de-de/software/qfinder-pro

Peter N. schrieb:

Der Strom war mehrere Straßen weg, wie lange weiß ich nicht, aber etliche Minuten.

Ein NAS ist zwar hochgefahren, lies sich aber nicht ansprechen. Nach einem Neustart ging es.

Schon mal alle Spannungen vom Netzteil oszillografiert? Elkodefekte machen sich gerne erst nach einem Stromausfall bemerkbar.

Philippe B. schrieb:

Hast du den Weblink mit https://<IP-Adresse>; geöffnet? (mit http:// gehts nicht mehr automatisch)

Ich gebe im Browser nur die IP ein (ohne http...) davor. Bei https://IP wird auf http://IP zurückgeschaltet (mit diversen Warnmeldungen). Die Weboberflächen aller meinen Heimnetzgeräte sind auf http:

Der aktuelle Stand beim NAS: Ich habe es neu installiert (damit ist das RAID zwar futsch, aber da war noch nichts wichtiges drauf).

Dabei ist mir etwas seltsames aufgefallen: Normalerweise muß ich bei der IP den Port 8080 nicht angeben. Die Fritzbox verzichtet ganz drauf, bei anderen Geräten wird er automatisch angehängt (auch bei neuen Geräten mit noch nicht benutzter IP).

Beim TS-1673U-RP muß ich den Port 8080 aber extra angeben. Wieso?

Laut qnaps (erster googler) ist der Webdienst 8080 http und SSL 443.

Kann man vielleicht auf immer auf HTTPS umleiten aktivieren, dann klappt das durch die automatische Weiterleitung im Browser.

Bei vielen Geräten muss man die automatische Weiterleitung in der Konfiguration auf ssl explizit aktivieren.

Die Browser versuchen auch meist zuerst den 443 Port zu erreichen, habe damit beim testen von Webseiten andauernd Probleme, sogar ein http wird ab und zu ignoriert wenn HTTPS vorhanden ist.

Fazit: SSL für das Webinterface aktivieren. Sollte es auch bei qnap gehen.

Philipp K. schrieb:

Die Browser versuchen auch meist zuerst den 443 Port zu erreichen,

Das sollte eigentlich auch funktionieren. HTTPS mit Port 443 ist auch aktiviert.

SSL habe ich auf die Schnelle nichtbgefunden.

Peter N. schrieb:

SSL habe ich auf die Schnelle nichtbgefunden.

Ich kann bei meinen Routern und Nas das Webinterface über HTTPS (SSL,443, "sichere Verbindung", wie auch immer) aktivieren.

Die Idee war das es nicht eingeschaltet ist und somit kann man nur über 8080 zugreifen. Wenn das aktiviert wäre, würde der Browser kurz mal auf 443 anklopfen und automatisch HTTPS nutzen. So würde einem nie auffallen das es auch über 8080 funktioniert.

Philipp K. schrieb:

Die Idee war das es nicht eingeschaltet ist und somit kann man nur über 8080 zugreifen.

Daß 8080 nicht der Standardport für http ist, ist Dir bekannt?

Es gibt NASe, die, wenn sie über Port 80 (http) angesprochen, einen Redirect auf sich selbst mit einer anderne Portnummer ausliefern.

So sieht das beispielsweise bei Synology aus:

1

<!DOCTYPE html>

2

<html>

3

    <body>

4

        <input type="hidden" id="http" name="http" value="5000">

5

        <input type="hidden" id="https" name="https" value="5001">

6

        <input type="hidden" id="prefer_https" name="prefer_https" value="false">

7

    </body>

8

    <script type="text/javascript">

9

        var protocol=location.protocol;

10

        var port=location.protocol === "https:" ? 5001 : 5000;

11

        var URL=protocol+"//"+location.hostname+":"+port+location.pathname+location.search;

12

        location.replace(URL);

13

    </script>

14

</html>

Philipp K. schrieb:

Die Browser versuchen auch meist zuerst den 443 Port zu erreichen, habe damit beim testen von Webseiten andauernd Probleme, sogar ein http wird ab und zu ignoriert wenn HTTPS vorhanden ist.

Verschärft lassen sich Browser auch so einstellen, dass sie http 80 überhaupt nicht mehr versuchen. Was bei welchem Browser seit wann Standardeinstellung ist...

Harald K. schrieb:

Es gibt NASe, die, wenn sie über Port 80 (http) angesprochen, einen Redirect auf sich selbst mit einer anderne Portnummer ausliefern.

Automatischer Redirect von http:80 auf https:443 ist heute bei Webseiten aller Art sehr verbreitet. Sieht man nur, wenn man darauf achtet.

(prx) A. K. schrieb:

Automatischer Redirect von http:80 auf https:443

Das macht oft der Browser, nicht der Webserver. Aber darum geht es hier nicht, sondern um den -merkwürdigen- Port 8080, den der Threadstarter erwähnt.

Harald K. schrieb:

Aber darum geht es hier nicht, sondern um den -merkwürdigen- Port 8080, den der Threadstarter erwähnt.

Verstehe ich nicht... http Port 80 wird doch aus Sicherheitsgründen, oder was weiß ich, nicht mehr verwendet? Stattdessen wird für http Port 8080 verwendet. Zumindest ist bei allen meinen Heimnetzgeräten dieser Port per default eingestellt.

Peter N. schrieb:

http Port 80 wird doch aus Sicherheitsgründen, oder was weiß ich, nicht mehr verwendet?

Nein, 8080 ist so eine Art nicht standardisierter Default Port für Webinterfaces auf Hosts bei denen auf Port 80 der http Dienst läuft. (Kann natürlich jeder X beliebige Port sein)

Zum Beispiel auf einer Webseite, dort wird auf Port 80 die Webseite geliefert, über 8080 kommt man auf das Verwaltungspanel des Hosters.

Also im Prinzip ist das eine noch heute gängige Praxis.

Das vor allem lokale Anwendungen wie ein NAS/Router garkein https sondern grundsätzlich auf Port 80 laufen weil man ja lokal und sicher ist, ist auch gängige Praxis. Da https die übertragenen Daten auf dem weg durch das Internet zur Sicherheit verschlüsselt.

(prx) A. K. schrieb:

Verschärft lassen sich Browser auch so einstellen, dass sie http 80 überhaupt nicht mehr versuchen. Was bei welchem Browser seit wann Standardeinstellung ist...

Ja klar, das wird aber nur für Internetzugriff benötigt, mein Mozilla und Chrome bevorzugen diese, versuchen das aber auch meist http.

Ich habe halt keinen Qnap, konnte aber gerade lesen das dieser den Port 80 nur bereitstellt wenn man den Webserver im Webinterface aktiviert hat um von 80 auf 8080 weiterzuleiten.

Das wäre ja das richtige zum Thema.

Harald K. schrieb:

Das macht oft der Browser, nicht der Webserver.

Der Browser macht es auch, seit SSL so gut wie obligatorisch ist. Aber ich sitze auf Seiten der Webserver. :)

Harald K. schrieb:

sondern um den -merkwürdigen- Port 8080, den der Threadstarter erwähnt.

Das ist nicht weiter merkwürdig, wenn man weiss, dass eine eierlegende Wollmilchsau wie eine Qnap auch Webdienste bereitstellt, wenn man sie lässt. Was zu Folge hat, dass deren Konfigurationsport eben /nicht/ auf 80 lauscht, weil der 80er für den optionalen Webserver bereitsteht. 8080 ist ein typischer Ausweichport für solche Szenarien.

Die Browser kennen halt noch Port 80 und Port 443, wenn du eine http:// url defintiv im Browser eintippst und es keinen 443 Port gibt.. dann versucht der das auch.

Seit Internet Beginn ist Port 80 in den Browsern http, und seit einigen Jahren schiebt sich Port 443 Namens https zwingend davor.

Aber wie schon geschrieben wird Lokal kein https benötigt, weil https eigentlich nur dafür da ist, das auf dem Weg vom Rechner zum Server über alle HOPS (Internet-Knotenpunkte und Routings) keine der übertragenen Daten auszuspähen sind. (Man-in-the-Middle Attacke)

Ohne https könnte ein Fritzbox Besitzer ein offenes Netz machen und alle login Passwörter der Teilnehmer oder über seine fritzbox laufenden Texte mitlesen. (Selbst schon probiert)

Https ist halt ein "Vertrag" von deinem Browser bis zum Internetdienst.

Philipp K. schrieb:

eigentlich nur dafür da ist, das auf dem Weg vom Rechner zum Server über alle HOPS (Internet-Knotenpunkte und Routings) keine der übertragfenen Daten auszuspähen sind.

Und dafür, einigermassen sicher zu sein, den richtigen Server am Haken zu haben. Und keinen, der sich nur dafür ausgibt. Man in the middle geht mehr in /diese/ Richtung.

Philipp K. schrieb:

Aber wie schon geschrieben wird Lokal kein https benötigt

Jedenfalls nicht unbedingt im typischen Home-Szenario. Schaden tut es jedoch nicht, etwa wenn man ein Freund nur schwach geschützter WLANs ist, und unter den Nachbarn nicht nur knapp-vor-Altersheimer wohnen.

(prx) A. K. schrieb:

Und dafür, einigermassen sicher zu sein, den richtigen Server am Haken zu haben.

Stimmt, da hast Du absolut Recht.

Oder halt z.B. Hotel-WLANs die irgendein Technik Freak eingerichtet hat und nebenbei schaut wer denn kein HTTPS benutzt :D

Wir gerade auffällt:

In der Fritzbox wird kein Link zur Weboberfläche des NAS angezeigt und das NAS heißt "NAS<Teil der IPV6-IP>". Wie kann ich dort erstmal dem NAS einen vernünftigen Namen geben?

in der Liste Netzwerkverbindungen sind rechts Symbole mit einem Stift, damit kannst Du den Rechner in der Fritzbox benennen

Stephan S. schrieb:

in der Liste Netzwerkverbindungen sind rechts Symbole mit einem Stift, damit kannst Du den Rechner in der Fritzbox benennen

Unter Heinnetz/Netzwerk komme ich zwar auf die Einstellungen, aber dort kann ich nur die IPs ändern. Der Gerätename ist nicht änderbar.

Peter N. schrieb:

Stephan S. schrieb:

in der Liste Netzwerkverbindungen sind rechts Symbole mit einem Stift, damit kannst Du den Rechner in der Fritzbox benennen

Unter Heinnetz/Netzwerk komme ich zwar auf die Einstellungen, aber dort kann ich nur die IPs ändern. Der Gerätename ist nicht änderbar.

Alte Fritzbox und alte Software? Bei meiner 7490 mit 7.57 geht es.

Stephan S. schrieb:

Alte Fritzbox und alte Software? Bei meiner 7490 mit 7.57 geht es.

FB 6490 Cable FritzOS 7.57

Die meisten Heimnetzgeräte haben den richtigen Namen. Also müßste man doch irgendwie über den Umweg -Gerät neu an die FB anlernen- den Namen korrigieren können?

Das der Link zur Weboberfläche fehlt, hängt wohl mit dem "connection refused"-Problem zusammen?

Den eigentlichen Hostnamen stellt man auch im Gerät um, bzw. erstellt diesen um keinen Random zu bekommen.

Außerdem kann es sein das der Webserver nur auf den eingestellten Hostnamen reagiert, wahrscheinlich auch die IP.

Durch den Gerätenamen in der Fritzbox wird auf die IP weitergeleitet.

Philipp K. schrieb:

Durch den Gerätenamen in der Fritzbox wird auf die IP weitergeleitet.

Ich vermute eher, dass die MAC das eigentliche Erkennungsmerkmal ist, mit der die Fritzbox Geräte erkennt. Ich hatte kurzfristig einen Windows-Rechner im Netz, den ich auf Ubuntu umgestellt habe. Er bekam vom DHCP der Fritzbox die gleiche IP zugeteilt.

Die MAC identifiziert das Gerät in der Box, und der Name wird vom DNS der Box zur IP aufgelöst.

Stephan S. schrieb:

Ich vermute eher, dass die MAC das eigentliche Erkennungsmerkmal ist

Das kannst du als gesicherten Fakt ansehen.

Diese ganze Geräte-Mimik der Fritzbox basiert auf der (etwas aufgeblasenen) Datenhaltung eines DHCP-Servers. Und der weiss anfangs über ein neues Gerät im Netz genau nur eins: seine MAC. Also ist das notwendigerweise auch der Primärschlüssel für diese ganze Datenhaltung.

Peter N. schrieb:

das NAS heißt "NAS<Teil der IPV6-IP>".

Wirklich ein Teil der IPV6?

Vielleicht läuft am NAS derzeit - warum auch immer - nur ein IPV6-Stack und deshalb kriegst du beim Versuch die V4-IP zu kontaktieren einen Fehler gemeldet.

Dann könnte ein Versuch das NAS über seine V6-IP anzusprechen zum Erfolg führen.

Philipp K. schrieb:

Fazit: SSL für das Webinterface aktivieren. Sollte es auch bei qnap gehen.

Das bedeutet dann allerdings, daß der Benutzer ein Transport Layer Security Zertifikat (TLS, früher Secure Socket Layer (SSL) genannt) benötigt. Also müßte unser Benutzer eine CA erstellen und sie als vertrauenswürdige CA auf allen Clients installieren, einen CSR erstellen, ihn mit der CA signieren, sowie das so entstandene signierte Zertifikat auf dem Server installieren. Ungeübte Anwender könnte das womöglich vor gewisse Schwierigkeiten stellen, zumal man einigen der beliebtesten Programme für diesen Zweck anmerkt, daß ihre Entwickler mehr von Kryptografie als von Usability verstehen.

Ein T. schrieb:

Das bedeutet dann allerdings, daß der Benutzer ein Transport Layer Security Zertifikat (TLS, früher Secure Socket Layer (SSL) genannt) benötigt. Also müßte unser Benutzer eine CA erstellen und sie als vertrauenswürdige CA auf allen Clients installieren, einen CSR erstellen, ihn mit der CA signieren, sowie das so entstandene signierte Zertifikat auf dem Server installieren.

Au Mann… Im LAN?

Der weltfremde „Superprofi“ mag sowas wollen. Was aber selbst für den bei einer simplen Home-Installation ohne eigene Domain schwierig würde.

Der ungeübte Benutzer klickt einfach die Warnung über das unbekannt, weil selbst signierte Zertifikat des NAS weg, und schon läufts.

Oliver

Oliver S. schrieb:

Ein T. schrieb:

Das bedeutet dann allerdings, daß der Benutzer ein Transport Layer Security Zertifikat (TLS, früher Secure Socket Layer (SSL) genannt) benötigt. Also müßte unser Benutzer eine CA erstellen und sie als vertrauenswürdige CA auf allen Clients installieren, einen CSR erstellen, ihn mit der CA signieren, sowie das so entstandene signierte Zertifikat auf dem Server installieren.

Au Mann… Im LAN?

Frag das jenen, der es vorgeschlagen hat. Tipp: ich war das nicht, ich habe nur auf die Konsequenzen hingewiesen.

Der ungeübte Benutzer klickt einfach die Warnung über das unbekannt, weil selbst signierte Zertifikat des NAS weg, und schon läufts.

Benutzer dazu erziehen, TLS-Warnungen wegzuklicken? Ganz miese Idee.

Selbst signiert ist ja nicht schlecht.. zur Verschlüsselung reicht es aus, da es von einem selbst signiert wurde, ist es Vertrauenswürdig. Das weiß ja nur der Browser nicht.

Philipp K. schrieb:

da es von einem selbst signiert wurde, ist es Vertrauenswürdig. Das weiß ja nur der Browser nicht.

Das Zertifikat des NAS wurde natürlich von dessen Hersteller signiert. Der Browser lehnt das allerdings auch ab.

Ein T. schrieb:

Benutzer dazu erziehen, TLS-Warnungen wegzuklicken? Ganz miese Idee.

Du bist immer noch im falschen Kontext. Hier geht's nicht um eine Hochsicherheitslösung eines internationalen Konzerns, hier geht's um das LAN des TO. Und da gibt's wenig Alternativen zum wegklicken der Warnung, egal, für wie mies du die Idee auch hältst.

Oliver

Das Zertifikat des NAS wurde natürlich von dessen Hersteller signiert. Der Browser lehnt das allerdings auch ab.

Abgelaufen, oder Hersteller-CA self signed?

Und da gibt's wenig Alternativen zum wegklicken der Warnung, egal, für wie mies du die Idee auch hältst.

Oder dem Browser (Firefox) oder System (Chrome) das Zertifikat oder die CA beibringen.

(prx) A. K. schrieb:

Das Zertifikat des NAS wurde natürlich von dessen Hersteller signiert. Der Browser lehnt das allerdings auch ab.

Abgelaufen, oder Hersteller-CA self signed?

All diese Geräte für home-Anwendung kommen doch immer mit einem Hersteller-signierten Zertifikat. Anders geht das doch gar nicht.

(prx) A. K. schrieb:

Oder dem Browser (Firefox) oder System (Chrome) das Zertifikat oder die CA beibringen.

Oder im Heimnetz einen eigenen ACME-Server laufen lassen, oder sich eine domain besorgen, und dafür dann Letsencrypt-Zertifikate ausstellen lassen, oder ... Das ist alles für nicht-unbedarfte Nutzer machbar. Um die geht es hier aber nicht.

Und wenn dann da eine Fritzbox steht, die sich bei jeder DSL-Neuverbindung eine neues Zertifikat ausdenkt, ist das trotzdem alles nutzlos.

Oliver

Ein T. schrieb:

Benutzer dazu erziehen, TLS-Warnungen wegzuklicken? Ganz miese Idee.

Und was soll man sonst machen, wenn man keine Ahrung hat, wie man das korrekt entfernt?

(prx) A. K. schrieb:

Das Zertifikat des NAS wurde natürlich von dessen Hersteller signiert. Der Browser lehnt das allerdings auch ab.

Abgelaufen, oder Hersteller-CA self signed?

Da der Name des NAS im Heimnetz nicht zu im Zertifikat hinterlegten Hostnamen passt, ist der Unterschied schon fast egal.

Oliver S. schrieb:

Ein T. schrieb:

Benutzer dazu erziehen, TLS-Warnungen wegzuklicken? Ganz miese Idee.

Du bist immer noch im falschen Kontext. Hier geht's nicht um eine Hochsicherheitslösung eines internationalen Konzerns, hier geht's um das LAN des TO. Und da gibt's wenig Alternativen zum wegklicken der Warnung, egal, für wie mies du die Idee auch hältst.

Die Idee des Wegklickens ist und bleibt jedenfalls der größte Mist von allen. Unabhängig davon, ob Du es wahrhaben willst, gibt es Alternativen. Nämlich, entweder komplett auf TLS zu verzichten oder eben, es korrekt aufzusetzen -- mit den entsprechenden Aufwänden, auf die ich hingewiesen habe. Wobei: wenn man schon TLS aufsetzt, kann man es auch gleich zur Authentifizierung nutzen und genießt dessen Komfort dann später.

Ein T. schrieb:

Nämlich, entweder komplett auf TLS zu verzichten oder eben, es korrekt aufzusetzen

Innerhalb eines LANs ohne eigene Domain hat man sehr wohl die Wahl, solche Zertifikate im Browser per Click anzuerkennen. Davon geht die Welt nicht unter.

Oliver

Zertifikatsfehlermeldungen wegzuklicken sollte man sich nicht angewöhnen.

Harald K. schrieb:

Zertifikatsfehlermeldungen wegzuklicken sollte man sich nicht angewöhnen.

Nee, man sollte sich vorher das Zertifikat anschauen, was man dann akzeptiert oder auch nicht. Macht man im Heimnetz beim Zugriff aufs NAS unter 192.168.1.17 aber eh nicht, weils völlig klar und auch egal ist, was da steht.

Oliver

Oliver S. schrieb:

Nee, man sollte sich vorher das Zertifikat anschauen, was man dann akzeptiert oder auch nicht.

Das magst vielleicht Du beherrschen und ich auch, aber bring das mal Tante Hiltrud oder Deinem Schwager bei.

Tante Hiltrud bekommt nicht mal gezeigt, wie sie auf die Managementoberfläche des NAS zugreifen könnte. Das ist für den Seelenfrieden aller Beteiligten einfach besser...

Oliver

Oliver S. schrieb:

Tante Hiltrud bekommt nicht mal gezeigt, wie sie auf die Managementoberfläche des NAS zugreifen könnte.

Tss, tss. Mit den zunehmenden Alter dieses Forums und seiner Insassen könnte so manche Tante Hiltrud mehr drauf haben, als ihr Neffe auf TikTok. :)

(prx) A. K. schrieb:

Oliver S. schrieb:

Tante Hiltrud bekommt nicht mal gezeigt, wie sie auf die Managementoberfläche des NAS zugreifen könnte.

Tss, tss. Mit den zunehmenden Alter dieses Forums und seiner Insassen könnte so manche Tante Hiltrud mehr drauf haben, als ihr Neffe auf TikTok. :)

Natürlich. Nur ginsg um die Tante Hiltrud, die nicht mal ein Zertifikat lesen können will, nicht um die andere, die bei google Rechenzentren administriert.

Oliver

Oliver S. schrieb:

Innerhalb eines LANs ohne eigene Domain hat man sehr wohl die Wahl, solche Zertifikate im Browser per Click anzuerkennen. Davon geht die Welt nicht unter.

Davon geht die Welt nicht unter, richtig. Aber Du erziehst Deine Benutzer zu einem schlechten Verhalten, und sowas ist Mist.

Ein T. schrieb:

Davon geht die Welt nicht unter, richtig. Aber Du erziehst Deine Benutzer zu einem schlechten Verhalten, und sowas ist Mist.

Ja, und nun? Die Lösung ist da, auf SSL im Lan zu verzichten, aber das erzieht die Benutzer auch zu einem schlechten Verhalten, und das ist dann Oberdoppelriesenmist.

Oliver

Oliver S. schrieb:

Innerhalb eines LANs ohne eigene Domain hat man sehr wohl die Wahl, solche Zertifikate im Browser per Click anzuerkennen. Davon geht die Welt nicht unter.

Sicher nicht. Wenn man viel Langeweile hat, kann man aber auch die Server mit den Zertifikaten einer eigenen CA ausstatten und den Clients beibringen, diese CA als solche zu akzeptieren.

Ist eben nur viel Arbeit mit begrenztem Nutzen. In einem privaten LAN steht das i.d.R. in keinem vernünftigen Verhältnis.

Aber z.B. im LAN einer Firma mit etlichen Servern und einer deutlich zweistelligen Zahl von Clients hingegen aber sehr wohl schon.

Hier hat man allerdings gelegentlich das Problem, dass es Client-Software gibt, die sich um's Verrecken nicht mit anderen CAs als den vom Issuer der Software vorgesehenen beglücken lassen will...

Und beim Rest ist es meistens üblicherweise zumindest nicht ganz einfach...

Dazu kommt dann noch, dass man in der Praxis oft noch mit Servern zu tun hat, die nicht mal aktuelle TLS-Versionen unterstützen. Siehe z.B. die Podukte der "großen" Anbieter (HP, DELL usw.) und ihr jeweiliges Admin-Interface. Tolle Acronyme wie "iDrac" oder "ILo", aber nach zehn Jahren (oder teilweise sogar weniger) alles Schrott? Das muss echt nicht sein, wenn der Server seine eigentlichen Aufgaben noch sehr gut erfüllen kann.

Das sehe ich echt nicht ein.

Sprich: die ganze Verschlüsselungs- und Zertifikats-Scheiße ist überwiegend wohl mehr so eine Gelddruckmaschine für alle etablierten Anbieter. Darüber können sie mehr oder weniger erzwingen, wann was neues gekauft werden muss.

Ob S. schrieb:

Hier hat man allerdings gelegentlich das Problem, dass es Client-Software gibt, die sich um's Verrecken nicht mit anderen CAs als den vom Issuer der Software vorgesehenen beglücken lassen will..

Jo, zum Beispiel seit Windows 10 in Excel..

Man kann keine URL über ein Excel Plugin abrufen die nicht von einem eingetragenem CA signiert wurde.

Sehr toll wenn der lokale API-Server zum Plugin von der Hersteller Firma selbst signiert wurde.

Aber mal ganz normal gedacht.. diese Diskutiererei macht keinen Sinn, in diesem hier zur Frage stehendem Anwendungsfall ist das doch "Wayne".

Das dümmste das einem passieren könnte, das man sich ein Rootkit einfängt, dieses das NAS speziell attackiert, alle Sicherheitsalgorithmen aushebelt und auf einen weit entfernten Server weiterleitet.

Im Prinzip ist dann so oder so schon alles zu spät.

Ob S. schrieb:

Sicher nicht. Wenn man viel Langeweile hat, kann man aber auch die Server mit den Zertifikaten einer eigenen CA ausstatten und den Clients beibringen, diese CA als solche zu akzeptieren.

Ist eben nur viel Arbeit mit begrenztem Nutzen. In einem privaten LAN steht das i.d.R. in keinem vernünftigen Verhältnis.

Das hängt IMHO im Wesentlichen von dem besagten LAN ab, also: welche Benutzer gibt es, was machen die im LAN, wie sensibel sind die vorhandenen Daten und ihre Verarbeitung, wer verwaltet die Veranstaltung, und so weiter. Aus meiner Sicht ist das eine Frage, die verschiedene Menschen sogar bei ansonsten ganz gleichen Voraussetzungen unterschiedlich beantworten können.

Ein T. schrieb:

Das hängt IMHO im Wesentlichen von dem besagten LAN ab

So langsam erweitert sich dein Weltbild…

Oliver

Oliver S. schrieb:

Ein T. schrieb:

Das hängt IMHO im Wesentlichen von dem besagten LAN ab

So langsam erweitert sich dein Weltbild…

Ich fürchte, die Weite meines Weltbildes übersteigt Deinen anscheinend etwas begrenzten Intellekt. Es war nämlich nicht mein Vorschlag, ein privates LAN über TLS abzusichern -- ich habe mir lediglich erlaubt, auf die Konsequenzen eines solchen Vorhabens hinzuweisen. :-)