Storj - Speicher vermieten

[faxxe]

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

-faxxe

 

[kev.lin]

Vielleicht wissen die Schöpfer der Software näheres
...
https://documentation.storj.io/resources/faq/migrate-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!

 

[Heidi]

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.




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?

 

[luddi]

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

 

[Heidi]

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



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.

 

[luddi]

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.

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




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

 

[Heidi]

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?

 

[luddi]

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:

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 ???

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.

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:

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.

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.

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

 

[thomas01]

Hallo Zusammen,

könntet Ihr mir vielleicht einmal behilflich sein?

Wenn ich folgendes Script für die Docker-Config ausführe (natürlich von mir abgeändert) erhalte ich immer die Meldung, dass der Mount-Pfad invalid wäre und man den absoluten Pfad verwenden solle.
Der Ordner "storj" ist bei mir ein Gemeinsamer Ordner und in diesem Ordner liegen die Ordner "identity-dir" und "storage-dir"

docker run -d --restart unless-stopped --stop-timeout 300 \
    -p 28967:28967 \
    -p 127.0.0.1:14002:14002 \
    -e WALLET="0xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" \
    -e EMAIL="user@example.com" \
    -e ADDRESS="domain.ddns.net:28967" \
    -e STORAGE="2TB" \
    --mount type=bind,source="</volume1/storj/identity-dir>",destination=/app/identity \
    --mount type=bind,source="</volume1/storj/storage-dir>",destination=/app/config \
    --name storagenode storjlabs/storagenode:beta

Was mache ich falsch?

Vielen Dank schon Mal im Voraus!

Grüße, Thomas

 

[maalik]

Moin Thomas

ändere

</volume1/storj/identity-dir>
</volume1/storj/storage-dir>

zu

/volume1/storj/identity-dir
/volume1/storj/storage-dir

 

[faxxe]

Irgendwas an der Schreibweise faul?

--mount type=bind,source=„/volume4/nas/Identity/storagenode",destination=/app/identity
--mount type=bind,source="/volume1/storj",destination=/app/config

So sehen die Zeilen bei mir aus.

-faxxe

 

[thomas01]

Au Mann....., das habe ich ja völlig übersehen.

Vielen, vielen Dank, nun läuft es!

Grüße, Thomas

 

[thomas01]

Ich hätte da noch ein kleines Problemchen...

Irgendwie komme ich nicht auf mein Webinterface.

In der Docker-Konfiguration habe ich folgendes angegeben:

    -p 127.0.0.1:14002:14002 \

Gebe ich nun die IP-Adresse meiner Synology gefolgt von :14002 ein, bekomme ich die Ansage: Die Website ist nicht erreichbar.

Laut

docker exec -it storagenode /app/dashboard.sh

läuft die Geschichte aber.

Hätte vielleicht jemand eine Idee?

 

[maalik]

Die 127.0.01 beim Port weglassen, also nur

-p 14002:14002 \

 

[thomas01]

Wie kann ich das dem Docker Container nachträglich noch beibringen?
Ich habe ihn in der Gui gerade gestoppt und mal geschaut, aber dort kann ich die 127.0.0.1 nirgens sehen.

 

[maalik]

docker stop -t 300 storagenode
docker rm storagenode

docker run ... (und die ganzen anderen Paramter hinterher)

 

[thomas01]

Danke Dir, zumindest komme ich jetzt über DDNS an das Dashboard.
Aber warum lässt er nicht zu, wenn ich die NAS-IP 192.168.0.XXX:14002 verwende?

 

[maalik]

Bei mir funktioniert das...

 

[luddi]

Aber warum lässt er nicht zu, wenn ich die NAS-IP 192.168.0.XXX:14002 verwende?

Hast du es schon mit einen anderen Browser probiert? Bzw. mal den Cache/Verlauf des Browsers löschen...

--luddi

 

[thomas01]

Hallo Luddi,

ich habe es gerade mit dem Opera getestet, aber auch darüber komme ich lokal nicht auf das Dashboard.

So ganz schlimm finde ich das nicht, davon ab, dass ich nicht weis woran es liegt.
Wäre es vielleicht möglich, dass offene im Internet stehende Interface, durch eine .htaccess zu schützen?