Seite 31 von 31 ErsteErste ... 21293031
Ergebnis 301 bis 308 von 308
  1. #301
    Anwender
    Registriert seit
    22.11.2007
    Beiträge
    73

    Standard

    Bei mir siehts gleich aus und läuft als Docker.
    Vielleicht brauchen wir bald mal das aktuelle Update auf 0.35.3

    -faxxe

  2. #302
    Anwender
    Registriert seit
    17.07.2007
    Beiträge
    418

    Standard

    Zitat Zitat von faxxe Beitrag anzeigen
    Vielleicht wissen die Schöpfer der Software näheres
    ...
    https://documentation.storj.io/resou...igrate-my-node
    Der Linkt hat geholfen! Ich hatte im ersten Versuch die Daten per FileStation von der alten auf die neue DiskStation kopiert. Das hatte nicht geklappt. Nach der Anleitung habe ich es dann per RSync gemacht. Nun rennt storj auf der neuen DiskStation wieder! Danke faxxe!
    Produktivsystem: DS416play (8GB Upgrade) || Backupsystem: DS215j
    Zufriedener Nutzer von Ultimate Backup

  3. #303
    Anwender
    Registriert seit
    05.08.2019
    Beiträge
    58

    Standard

    Ich hatte die Tage ja das Problem, dass mein Knoten aprupt nicht mehr richtig läuft. Und ein anderer auf anderer IP ebenso. Deshalb dachte ich, es liegt nicht an mir. Aber ich hatte die NAS Firewall umkonfiguriert, also nicht die in meinem Router, sondern die direkt in meiner DSM.


    Anmerkung 2020-03-27 210032.png

    Meine Frage an die Community (auch wenn das ggf. in einen anderen thread gehört). Wie macht ihr das?
    Die Firewall Regeln werden von oben nach unten abgearbeitet laut Synology und sobald eine zutrifft, wird die Firewall passiert und nicht weiter abgearbeitet.

    Ich möchte
    1) von lokal stets einloggen können
    2) von allen IPs aus Deutschland einloggbar sein (ich bewege mich ja mit meinem Handy hier meist)
    3) den Docker Port für den Storage Knoten frei haben
    4) Alle anderen IPs aus der Welt nicht durchlassen

    solange 4) aktiviert war, ist meine Storage Knoten nicht mehr erreichbar gewesen. Deshalb habe ich 4) nun deaktiviert. Jetzt läuft wieder alle wie geschmiert!! Zum Glück. Früher hatte ich die Länderregeln einzeln drin. Also: China, verweigern, Russland verweigern, etc. Nur hierfür ist die Eingabemaske beschränkt auf 15 Länder gleichzeitig. Das ist dann nervig, dann man 20 (x15) Regeln aufsetzen muss um die Länder auszusperren. Hatte aber funktioniert. Plötzlich waren die ganzen Hack-Versuche von den Russischen IPs weg.

    Deshalb mein Vorgehen: Wenn es ich bin, dann komm rein, wenn du aus Dtld bist, komm rein, Storageknoten von weltweit, komm rein, alles andere kommsch hier net rein. Den Rest regelt ja meine Routerfirewall.

    Wer hat einen Tipp?
    DS1819+ / FB7590 / Pi-Hole (Rasp3B)

  4. #304
    Anwender Avatar von luddi
    Registriert seit
    05.09.2012
    Beiträge
    1.214

    Standard

    Zitat Zitat von Heidi Beitrag anzeigen
    solange 4) aktiviert war, ist meine Storage Knoten nicht mehr erreichbar gewesen. Deshalb habe ich 4) nun deaktiviert. Jetzt läuft wieder alle wie geschmiert!! Zum Glück. Früher hatte ich die Länderregeln einzeln drin. Also: China, verweigern, Russland verweigern, etc. Nur hierfür ist die Eingabemaske beschränkt auf 15 Länder gleichzeitig. Das ist dann nervig, dann man 20 (x15) Regeln aufsetzen muss um die Länder auszusperren. Hatte aber funktioniert. Plötzlich waren die ganzen Hack-Versuche von den Russischen IPs weg.

    Deshalb mein Vorgehen: Wenn es ich bin, dann komm rein, wenn du aus Dtld bist, komm rein, Storageknoten von weltweit, komm rein, alles andere kommsch hier net rein.

    Wer hat einen Tipp?
    Hast du zu diesem Thema Firewall und storagenode meinen Beitrag #291 bereits gesehen?

    Das könnte Abhilfe schaffen.

    --luddi
    DS1817+ | DSM 6.2.2-Update4 | 4x 8TB WD80EFZX (Raid 5) | 4x 3TB WD30EFRX (Raid 5) | 2x M.2 SSD 256 GB R/W Cache | 16 GB RAM

  5. #305
    Anwender
    Registriert seit
    05.08.2019
    Beiträge
    58

    Standard

    Tach Luddi,
    ich habe das von dir jetzt mal ausprobiert und parallel immer das Docker-Terminal mit dem upload/download Protokoll von Storage node im Auge behalten.

    Siehe hierzu meine Firewall

    Unbenannt.png

    Also:
    1) lokal offen
    2) Deutschland-Ausnahme mal deaktiviert
    3) den Dockerport offen
    4) Dein UDP Vorschlag offen
    5) restl. Welt zu

    Läuft. Wenn ich nun den 28967 Docker Port zumache, dann läuft der storagenode nicht mehr. Trotz deiner UDP-Vorschläge. Wenn ich zusätzlich hingegen deine UDPs zumache (Kontrollversuch), ändert sich garnichts. Wenn ich dann (trotz deiner zugemachten UDPs) den 28967 wieder öffne, dann rennt die Kiste wieder.

    Ich schließe daraus, dass der 28967er der Schlüssel ist. Und weiterhin dass deine UDPs nichts bringen. Oder haben sich die IPs der Satelliten geändert??

    Jetzt habe ich damals ja nicht einfach meine Firewall konfiguriert und bin dann heimgegangen. Ich hatte schon das Docker Terminal beobachtet und mich versichert, dass die Kiste noch läuft. Habe dann leider einen Tage später gestaunt, dass kein Traffic mehr passiuert, aber mich geistesungegenwärtig nicht gleich an die Firewall erinnert.
    DS1819+ / FB7590 / Pi-Hole (Rasp3B)

  6. #306
    Anwender Avatar von luddi
    Registriert seit
    05.09.2012
    Beiträge
    1.214

    Standard

    Hallo Heidi,

    vielleicht war es aus meiner Sicht nicht ganz im Detail erläutert gewesen mit der Firewall. Mein ursprüngliches Problem startete mit Post #290 wo ich den Knoten nicht zum Laufen brachte und im Terminal window ständig Fehler ausgegeben bekommen hatte.

    Zitat Zitat von luddi Beitrag anzeigen
    a.) WARN trust Failed to fetch URLs from source
    b.) ERROR preflight:localtime unable to get satellite system time
    In der Firewall hatte ich bereits von Anfang an den Port 28967 geöffnet. Dies ist ohnehin unerlässlich laut Doku und erfordert ja auch ein Forwarding im Router. Nichts desto trotz startete der Knoten nicht korrekt weil die Satelliten die Systemzeit nicht abgleichen konnten. Erst daraufhin habe ich die UDP Port Freigaben für alle verfügbaren Satelliten hinzugefügt.

    Das Bild aus Post #291 ist lediglich nur der Auszug der nur die UDP Settings für die Satelliten zeigen soll.
    Hier liegt ein Missverständnis vor, dass ich nur diese für storj geöffnet habe. Zwingend notwendig ist definitv der Port 28967.

    Meine Firewall Settings sind wie folgt:

    1.) Gesamtes lokales Netzwerk, eine bestimmte feste IP Adresse, und alle IP´s aus DE sind erlaubt
    2.) alle benötigten Ports und IP´s für den Storj Knoten sind erlaubt
    3.) Die allgemeine "Block ALL" ganz am Ende in der Kette

    syno-firewall.png


    Warum deine beiden Knoten nicht mehr sauber gelaufen sind, ist für mich unerklärlich. Aber eins ist sicher. Der Port auf dem alle Anfragen hinein kommen (28967) muss definitv geöffnet sein im System.
    Die anderen UDP Portfreigaben in der Firewall sind aus meiner Sicht nur notwendig sobald die Satelliten eine Zeitsynchronisation vorhnehmen. Dies tun sie definitv am Anfang beim Aufstarten.
    Zur Gegenprobe kannst du folgendes ausprobieren.

    1.) stoppe den storagenode
    2.) deaktivere die UDP Freigaben in der Firewall (ABER: Port 28967 weiterhin erlaubt)
    3.) Firewall "Block ALL" weiterhin am Ende aktiviert lassen
    4.) starte storagenode neu und verfolge das Log bzw. die Terminal Ausgabe.

    Du solltest somit nun auch feststellen dass der Knoten nicht startet und auch die gleichen Fehlermeldungen bekommen wie auch ich aus Post #290

    --luddi
    DS1817+ | DSM 6.2.2-Update4 | 4x 8TB WD80EFZX (Raid 5) | 4x 3TB WD30EFRX (Raid 5) | 2x M.2 SSD 256 GB R/W Cache | 16 GB RAM

  7. #307
    Anwender
    Registriert seit
    05.08.2019
    Beiträge
    58

    Standard

    Hallo Luddi,

    eine Nacht ist nun vergangen, in der ist wieder viel erhellendes passiert. Nachdem ich hier gestern geschrieben hatte, dass aus meiner Sicht die UDP Ports irrelevant für den Betrieb sind, muss ich meine Meinung heute morgen ändern und revidieren!

    Ich betreibe 2 Knoten. Der eine hat Firewalleinstellungen (dank des Experiments gestern) exakt wie deine. Beim anderen hatte ich diese UDP Ports nicht definiert. Beide Knoten liefen (auch ohne UDP Portöffnung) gestern nach Abschluss meines Experiments tadellos. Wie alle sicher bemerkt haben, hat der Watchtower grade das update auf v0.35.3 durchgeführt. Mein erster Knoten mit UDP Portdefinition war dabei schon auf 0.35.3 gewesen, der andere noch auf dem alten 0.34.6.
    Dieser hatte heute Nacht sein update bekommen. Und -siehe da- heute morgen lief er nicht mehr!

    Meine Vermutung (bevor ich deinen Post grade gelesen habe) ist gewesen, dass die ingress/egress-Anfragen von den Clients direkt kommen und nur die Verteilung/Administration der Storage-Knoten vom Satelite vorgenommen werden und der dieses eben nur alle Nase lang evaluiert (so wie die audits). Und nachdem dieses einmal gescheitert war, hat er den Betrieb meines Knotens eingestellt. Und da dies nicht direkt passiert ist, hatte ich das beim ersten Mal Firewall umstellen eben auch nicht gleich bemerkt. Wie vormals geschireben, ich ändere ja nicht einfach die Firewall und geh dann Heim ohne Kontrolle.

    Soviel zu meine Vermutung. Aber nachdem ich nun deinen Post lese, klingt das für mich vernünftiger. Die Satelliten werden wohl jede Clientanfrage entgegennehmen und dann on-the-fly die Anfrage an den Knoten weiterleiten, sind also ständig im Eingriff. Und das über das TCP Protokoll (Port 28967?). Nur eben die Zeitstempelabfrage läuft über UDP. Dein vorgeschlagener Test hat sich quasi gestern dank Watchtower von alleine ausgeführt. Damit ist für mich klar. Die Firewallregeln müssen so sein, wie du schreibst. 1e3 Dank dafür! Ohne das wäre ich sicher jetzt noch verzweifelt im Wald gestanden.

    Jetzt stellt sich mir die Frage: Werden sich die Satelite IPs mal ändern? Muss ich das immer im Auge behalten, wenn neue Satellites dazukommen? Wo finde ich eine immer aktuelle Liste derselben? Eigentlich will man den Koten ja garnicht mehr betreuen müssen. Man bekommt ja auch keine email Benachrichtigung über irgendwelche Satelite Kontakt Fehler...

    Wäre es Firewall-technisch fahrlässig, wenn ich einfach die UDP für alle IPs aufmache? Kommen die "Angriffe" meist über TCP oder doch auch über UDP?
    DS1819+ / FB7590 / Pi-Hole (Rasp3B)

  8. #308
    Anwender Avatar von luddi
    Registriert seit
    05.09.2012
    Beiträge
    1.214

    Standard

    Zitat Zitat von Heidi Beitrag anzeigen
    Dein vorgeschlagener Test hat sich quasi gestern dank Watchtower von alleine ausgeführt. Damit ist für mich klar. Die Firewallregeln müssen so sein, wie du schreibst. 1e3 Dank dafür! Ohne das wäre ich sicher jetzt noch verzweifelt im Wald gestanden.
    Ah prima, du hast also den Test quasi implizit ausgeführt Das ist genau die Erkenntnis die ich nämlich zu Beginn mit meinem Knoten daraus gewonnen habe. Ich werde das ganze noch ein wenig im Log verfolgen welche weiteren Errors zu erkennen sind die auf eine Firewall Einstellung zurückzuführen ist.

    Aktuell bekomme ich gelegentlich mit den gegenwärtigen Firewall Einstellungen folgende Fehler angezeigt:
    Code:
    ERROR	nodestats:cache	Get disk space usage query failed	{"error": "node stats service error: unable to connect to the satellite 118UWpMCHzs6CvSgWd9BfFVjw5K9pZbJjkfZJexMtSkmKxvvAW: rpccompat: dial tcp: lookup satellite.stefan-benten.de on 10.88.66.1:53:
    read udp 172.17.0.2:35382->10.88.66.1:53: i/o timeout;
    Das Problem was ich hier sehe ist, dass die IP Adresse 172.17.0.2 keine öffentliche IP Adresse ist. Sie gehört zu dem privaten IP Adressbereich 172.16.0.0 bis 172.31.255.255 eines Klasse B Netzwerk. Dies ist ja keine öffentliche IP und somit wüsste ich auch nicht ob es Sinn macht eine solche IP Adresse in der Firewall explizit einzutragen ???

    Zitat Zitat von Heidi Beitrag anzeigen
    Jetzt stellt sich mir die Frage: Werden sich die Satelite IPs mal ändern? Muss ich das immer im Auge behalten, wenn neue Satellites dazukommen?
    Diese Frage habe ich mir selbstverständlich auch bereits gestellt. Klar können sich die IP Adressen der Knoten ändern oder gar neue Knoten hinzukommen bzw. vorhandene Knoten wegfallen. Eine Garantie hat man somit nicht. Eine Domain in der Firewall eintragen geht natürlich auch nicht und macht aus meiner Sicht auch keinen Sinn.

    Zitat Zitat von Heidi Beitrag anzeigen
    Wo finde ich eine immer aktuelle Liste derselben? Eigentlich will man den Koten ja garnicht mehr betreuen müssen. Man bekommt ja auch keine email Benachrichtigung über irgendwelche Satelite Kontakt Fehler...
    Die IP Adressen musst du am besten selbst über eine DNS Anfrage herausfinden. Da gibt es sicher viele Wege die nach Rom führen...
    Ich mache das am liebsten über die Kommandozeile. Hier mal ein paar Beispiele:
    Code:
    1.) getent hosts <DOMAIN.TLD> | awk '{ print $1 }'
    
    2.) dig +short <DOMAIN.TLD>
    
    3.) nslookup <DOMAIN.TLD> | awk '/^Address: / { print $2 }'
    Aber gerade hier kommt mir eine Idee... Die Firewall Settings müssten doch eigentlich in einem human readable file auf der Diskstation liegen. Wenn ich das gefunden habe, dann schreibe ich ein bash Script was diese Arbeit erledigt um die IP Adressen aktuell zu halten. Also wenn jemand weiß wo die Firewall Settings liegen wäre ich schon einmal Dankbar für Unterstützung. Bis dahin gehe ich selbst einmal auf die Suche.
    Update: Es wird auch auf der Diskstation mit iptables gearbeitet. Eigentlich nicht anders zu erwarten von einem Linux Unterbau.
    Nun werde ich mich damit einmal vertraut machen. Wenn man nur die Eingehenden Regeln betrachten möchte also diejeninigen aus der INPUT Chain dann kann man sich die Einträge mit folgendem Befehl auflisten.

    Code:
    iptables -L INPUT_FIREWALL -v -n --line-numbers
    Die Input Chain der Synology Firewall heißt "INPUT_FIREWALL". Wenn man den gesamten Inhalt der iptables sehen möchte, so lässt man den Chain Identifier einfach weg.


    Zitat Zitat von Heidi Beitrag anzeigen
    Wäre es Firewall-technisch fahrlässig, wenn ich einfach die UDP für alle IPs aufmache? Kommen die "Angriffe" meist über TCP oder doch auch über UDP?
    Ich persönlich versuche jeglichen Datenverkehr so weit wie möglich einzuschränken. Ob jetzt UDP ungefährlicher sei als TCP kann ich dir nicht beantworten. Dazu kenne ich keine Statistiken zu Angriffen.

    --luddi
    Geändert von luddi (Gestern um 12:33 Uhr)
    DS1817+ | DSM 6.2.2-Update4 | 4x 8TB WD80EFZX (Raid 5) | 4x 3TB WD30EFRX (Raid 5) | 2x M.2 SSD 256 GB R/W Cache | 16 GB RAM

Seite 31 von 31 ErsteErste ... 21293031

Ähnliche Themen

  1. Speicher für Offsite-Backup vermieten
    Von rednag im Forum Backup / Restore / Data Replicator Allgemein
    Antworten: 16
    Letzter Beitrag: 14.11.2019, 19:02
  2. Speicher
    Von southpole im Forum Sonstiges
    Antworten: 6
    Letzter Beitrag: 08.05.2016, 10:59
  3. Speicher Manager und Speicher Analysator nicht gleiche werte
    Von novski im Forum Disk Station Manager
    Antworten: 3
    Letzter Beitrag: 03.10.2015, 08:25
  4. USB-Speicher
    Von itari im Forum Off-Topic
    Antworten: 9
    Letzter Beitrag: 27.07.2013, 07:24
  5. Kaufentscheidung Speicher
    Von spitfire4all im Forum Kaufberatung - Fragen vor dem Kauf
    Antworten: 4
    Letzter Beitrag: 28.02.2011, 14:39

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •