Storj - Speicher vermieten

[thomas01]

Danke, dann war ich dort auch schon und habe keine Fehler drin stehen.

 

[Heidi]

Hallo Luddi,

auch ich habe diesen Fehler noch nicht bekommen. Ich habe aber nach all den Problemen, die wir bzgl. der Firewall besprochen hatten, meine Firewall wieder auf gemacht. Wahrscheinlich liegts daran.

Ich hatte das im Storj Forum gefragt https://forum.storj.io/t/firewall-rules-for-synology-dsm/5899 , aber da kam keine wirkliche Antwort. Wahrscheinlich sind dort zu wenige Leute vertraut mit den Firewall Regeln der Synology.

 

[Heidi]

Hallo deion und thomas01, habe grade erst den Eintrag gelesen mit der Fragen nach dem Diagramm. Wurde das schon beantwortet oder habt ihr das inzwischen selbst enträtselt??

Das Diagramm zeigt den "Verlauf des Füllgrades" eures Knotens an. Die Einheit sind GB*h (bzw TB*h bzw. PB*h). Also Speichermenge mal Zeit. wenn ihr also 1 TB an Daten habt und der erste Tag verstrichen ist, dann habe ihr 1TB*24h=24TB*h. Bei gleicher Datenmenge sind das nach dem 2. Tag dan 48TB*h usw. Am Ende des Monats wird man bezahlt nicht nur nach dem Egress (download von eurem Server runter) sondern auch nach dem Lagern der Daten auf euren Platten (die ja Geld gekostet haben und Strom fressen). Dabei wird 1,5$/TBm (also TB*Monat) bezahlt. Liegen als 1TB ein Monat auf dem NAS rum, gibts 1,50$. Ganz ohne Upload irgendwelcher Daten.

Nach meiner vormaligen Rechnung sieht das mit der Rentabilität so aus: Es gibt pro Monat und TB 1.50$, also 1,38€. Das TB kostet grade 29,5€ (Ironwolf 4TB). Da ist die Platte nach 21 Monaten (ohne Stromkosten und Steuerabgaben) bezahlt. Ganz ohne Upload!

 

[luddi]

Danke euch für eure Antworten.

auch ich habe diesen Fehler noch nicht bekommen. Ich habe aber nach all den Problemen, die wir bzgl. der Firewall besprochen hatten, meine Firewall wieder auf gemacht. Wahrscheinlich liegts daran.

Danke auch für deine Rückmeldung. Bevor ich meine Frage hierzu gestellt hatte, habe ich natürlich die Firewall deaktiviert und den log verfolgt. Sogar mit deaktivierter Firewall kamen nach ca. 1 Stunde diese "ping satellite failed" Errors.
Ich habe aktuell keine Ahnung was diesen Fehler verursacht.

Ich hatte das im Storj Forum gefragt https://forum.storj.io/t/firewall-rules-for-synology-dsm/5899 , aber da kam keine wirkliche Antwort. Wahrscheinlich sind dort zu wenige Leute vertraut mit den Firewall Regeln der Synology.

Dort findet man die Antwort dass lediglich nur Port 26967 im NAT geöffnet sein muss. Dies kann nach unserem Verständnis und Erfahrungen in Zusammenhang mit der Firewall nicht sein.
Ich suche immer noch nach eine log der Firewall, aber unter /var/log finde ich nichts diesbezüglich. Wenn uns die Firewall wenigstens verraten würde welcher eingehende traffic blockiert wurde könnte dies helfen.

Ich habe die Firewall wieder einmal deaktiviert und den Knoten neu gestartet. Jetzt werde ich weiterhin verfolgen ob der Fehler wieder auftritt.

--luddi

 

[faxxe]

Dort findet man die Antwort dass lediglich nur Port 26967 im NAT geöffnet sein muss.

--luddi

Ich hab auf meinem Mikrotik Router mal 10 Minuten den ein/ausgehenden Verkehr vom Storj Knoten aufgezeichnet und keinen UDP Traffic gesehen.
Die Sat gehen ausschliesslich auf TCP/28967 rein. Der Mikrotik, dessen Firwall auf IPTables passiert, routet nur was ich ihm sage und UDP wird nicht geforwardet.
Ich verstehe die Syno Firewall Logik in diesem Zusammenhang auch nicht.

-faxxe

 

[luddi]

Hallo @all,

an alle die die Firewall weiterhin nutzen möchten! Ich denke ich habe die Lösung des Problems gefunden.
Es ist nicht wie viele glauben, nicht zu verstehen wie die Firewall der Diskstation funktioniert. Sie funktioniert ganz nach dem Schema der iptables, und dies auch sorgfältig und zuverlässig. Die Regeln werden von oben nach unten abgearbeitet. Gibt es einen Match zu einem Eintrag, so werden die Pakete entweder angenommen bzw. weitergereicht oder eben abgelehnt.

Kommen wir zu dem Punkt, dass der Storj Knoten ausschließlich auf den Port 28967 lauscht. Dies hat zur Folge dass die eingehende Kommunikation der Satelliten ausschließlich über diesen Port initiiert wird und deshalb auch im NAT des Routers dieser Port offen bzw. zum jeweiligen Client im Netzwerk weitergereicht werden muss. Dies leuchtet bestimmt allen ein und ist somit gängige Praxis.

Die Listening Ports können wir uns anzeigen lassen:

netstat -tlpn | grep docker

tcp6       0      0 :::28967                :::*                    LISTEN      1692/docker-proxy   
tcp6       0      0 :::14002                :::*                    LISTEN      1712/docker-proxy

Soweit so gut. Nun kommen wir zu dem Punkt dass wir die Firewall der Diskstation näher betrachten. Wir möchten definitiv alle Verbindungen die über den Port 28967 ankommen auch zulassen.
Die Firewall Regeln werden auf das jeweilige interface angewandt welches man oben rechts auswählen kann. Hat man mehrere physikalische LAN Adapter so werden diese als Auswahlmöglichkeit angezeigt.
Man kann also somit folgendes Interfaces wählen: "Alle Schnittstellen" / "LAN1" / "LAN2" / "LANx" ... / "PPPoE" / "VPN".

Dies hat zur Folge, dass die Ethernetadapter somit auch eine IP Adresse aus dem internen Netzwerk haben.
Nehmen wir an wir beifinden uns in einem Netzwerk 192.168.0.0/24.
Unser Router hat die IP Adresse 192.168.0.1 und unsere Diskstation besitzt die Adresse 192.168.0.2

Damit wir uns in unserem lokalen Netzwerk nicht selbst aussperren und weiterhin auf die Diskstation zugreifen können definiert man gewöhnlich den ersten Eintrag in der Firewall wie folgt.
Das gesamte lokale Netzwerk darf auf die Dsikstation zugreifen. Somit lautet die Regel:

Ports: Alle    Protokoll: Alle    Quell-IP: 192.168.0.0/255.255.255.0    Aktion: Zulassen

Als zweite Regel können wir uns nun um den Port kümmern auf welchem unser Docker Storj Knoten lauscht. Dies ist insofern wichtig damit die Pakete den Container erreichen.

Ports: 28967    Protokoll: TCP    Quell-IP: Alle    Aktion: Zulassen

Und zu guter letzt definiert man noch die Regel am Ende der Kette mit einem sog. "Block All" die wie folgt aussieht.

Ports: Alle    Protokoll: Alle    Quell-IP: Alle    Aktion: Verweigern

In diesem Moment gehen wir davon aus, dass wir alle notwendigen Regeln für den erfolgreichen Betrieb des Knoten definiert haben. Dem ist aber nicht so und wir bekommen sofort nach dem Starten des Knotens ein FATAL error weil die Zeitsynchronisation zwischen dem Knoten und den Satelliten nicht stattfinden kann.
Nun stellen wir uns die Frage, warum denn eigentlich nicht. Der einzige Port über den kommuniziert wird ist sowohl in der NAT (Router) geöffnet als auch in der Firewall der Diskstation erlaubt.
Zusätzlich ist auch die Kommunikation des gesamten internen Netzwerks durch unsere erste Regel erlaubt.
Was fehlt also noch?

Des Rätsels Lösung ist Docker selbst.
Wer sich an meinen Beitrag #390 erinnert, der weiß dass ich hier zusätzlich zu den IP Adressen der Satelliten folgende Adresse hinzugenommen habe. Es ging hierbei um die Adresse 172.17.0.2 worüber ich mich selbst gewundert habe, dass es sich hierbei um eine IP Adresse aus dem reservierten Adressraum für private IP Adressen handelt.
Zu diesem Zeitpunkt war ich selbst verwundert weshalb über diese IP Adresse ein einkommender Traffic stattfindet. Jedoch entschloss ich mich diese genau wie auch die Satelliten zu behandeln und legte eine Regel in der Firewall an. Dies half nicht für lange Zeit, denn es folgten ständig weitere Fehler wie auch teils von euch berichtet wurde.

Lange Rede kurzer Sinn...
Ursache für das Scheitern der eingehenden Verbindungen durch die Firewall ist, dass docker eine Bridge anlegt über die zum lokalen Netzwerk der Diskstation (über eth0) kommuniziert. Die Bridge kann man als virtuallen Hub betrachten und alle angeschlossenen Schnittstellen sehen auch alle Ethernetpakete.
Die Bridge heißt standardmäßig "docker0" und besitzt per default die IP-Adresse 172.17.0.1

Um dies zu verifizieren können wir uns die Bridge auf unserem System anzeigen lassen:

brctl show

bridge name     bridge id             STP enabled       interfaces
docker0         8000.0242141aa0a1     no                docker843113a

Um anschließend noch die IP Adresse zu verifizieren führen wir folgenden Befehl aus:

ifconfig docker0

docker0   Link encap:Ethernet HWaddr 02:42:14:1A:A0:A1  
          inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0

Somit ist klar, dass Docker versucht mit der Netzwerkbridge "docker0" Pakete an den physikalischen Adapter z.B. eth0 zu schicken. Diese wiederum werden aber in der Firewall blockiert aufgrund dessen, dass Pakete nur aus dem Netzwerk 192.168.0.0/24 angenommen werden.
Also müssen wir dafür sorgen damit der gesamte docker Traffic auch zugelassen wird.
Wir erstellen also eine neue Regel in der Firewall und setzen diese z.B. direkt an die zweite Position.

Ports: Alle    Protokoll: Alle    Quell-IP: 172.17.0.0/255.255.0.0    Aktion: Zulassen

et voilà...
Nun können wir den Knoten sauber starten, die Systemzeiten werden abgeglichen und der Knoten läuft ohne erkennbare Errors im Log.

Zum Abschluss noch ein Screenshot welcher meine Eintellungen zum Test zeigt. Nur die farbig markierten Regeln sind die relevanten für eine saubere Kommunikation mit eurem Storagenode.



Ihr müsst entsprechend die erste farbig markierte Regel eurem Netzwerk anpassen. In meinem Fall befinde ich mich in dem lokalen Netzwerk 10.0.0.0/8
Bei den meisten von euch vermutlich eher 192.168.0.0/24 oder auch Fritzbox typisch 192.168.178.0/24

Viele Grüße
luddi

 

[faxxe]

@luddi: super erklärt. Dann ist natürlich auch klar warum man es an einer der Syno vorgeschaltenen FW nicht sieht, da die Bridge in der Syno sitzt. Sehrwohl aber für die interne Firewall "sichtbar"
-faxxe

 

[Heidi]

Update auf v1.3.3 kommt irgendwie nicht....

Seltsam, seit 5 Tagen bekomme ich die Aufforderung auf v1.3.3 ein update zu machen. Aber weder der watchtower macht was, noch bekomme ich eine passende email und wenn ich manuell ein pull machen, kommt wieder die alte v1.1.1 reingeschneit. Übersehe ich was, oder ist das normal, dass die notification solange im Vorfeld aufploppt?

 

[thomas01]

Ist bei mir auch so.

 

[m0useP4d]

Die Notification ist noch verbuggt bzw. noch nicht auf Docker abgestimmt.
Solange Docker storagenode:beta hier noch nicht aktualisiert wurde, kann watchtower auch nichts machen.

PS: Die neuesten Updates kommen zuerst immer auf die Windows Clients, später dann die Docker, damit nicht alle User auf einmal updaten und evtl. alles zusammenbricht

 

[Heidi]

Hallo Luddi,

super Anleitung für die Firewall. Da kommt ein Laie ja niemals drauf!

Kleine Anmerkung noch: Tatsächlich hat Synology oder Storj in den Anwendungen speziel für den Storj-Container einen vorgefertigten Eintrag.



Der Eintrag ist aber weg, wenn man Docker deinstalliert, ist also mit Vorsicht zu genießen, diese Methode.

 

[luddi]

Sehr gerne doch! Schön zu hören dass es funktioniert und auch danke fürs Feedback dass es verständlich ist.

Kleine Anmerkung noch: Tatsächlich hat Synology oder Storj in den Anwendungen speziel für den Storj-Container einen vorgefertigten Eintrag.
[...]
Der Eintrag ist aber weg, wenn man Docker deinstalliert, ist also mit Vorsicht zu genießen, diese Methode.

Exakt... es gibt solch einen vordefinierten Eintrag sobald der Container erstellt wurde. Aber wie du selbst bemerkt hast verschwindet der Eintrag sobald der Container deinstalliert wird.
Dies geschieht ja spätestens mit dem Befehl "docker rm storagenode" immer genau dann, wenn man ein Update des Knotens durchführt. Und auch selbstverständlich bei denen wo ein watchtower das automatisierte Update übernimmt.

Und genau aus diesem Grund habe ich euch diese Methode nicht vorgeschlagen. Es ist hier definitiv besser den Port in der Firewall explizit einzutragen.

Zudem reicht hier auch vollkommen ganz allein Port 28967 weil der 14002 ohnehin nur für die WebGui des "Storage Node Stats" vorgesehen ist und ihr diese vermutlich (und auch hoffentlich) ausschließlich im lokalen Netzwerk verwendet. Für diesen Zugriff sorgt ja allein schon der erste Eintrag in eurer Firewall der den eingehenden Traffic des gesamten lokalen Netzwerk freigibt.

--luddi

 

[Frieseba]

Kann man eigentlich einen zweiten Knoten auf der Synology installieren? Wenn ja, wie? Einfach nochmal einen storj-docker laufen lassen und einen anderen Port als beim ersten Docker angeben? Würde gerne noch eine externe HDD laufen lassen, die hier ungenutzt in der Ecke liegt

 

[luddi]

Technisch ist es möglich mehrere Knoten an einem ISP Anschluss zu betreiben. Ob mehrere Knoten auf einem Device (via Docker) oder auch auf mehreren Clients im Netzwerk ist möglich.
Jedoch soll nur ein Knoten an einem physikalischen Anschluss betrieben werden.

Dazu einaml dies hier lesen: https://support.storj.io/hc/en-us/a...w-can-I-set-up-to-run-multiple-storage-nodes-

"You can run multiple storage nodes but preferably, you should make sure each will be run in a different physical location and IP."

--luddi

 

[Frieseba]

Wäre mit 2 Lananschlüssen der DS ja möglich?!

 

[luddi]

Nein, hier ist aus meiner Sicht die öffentliche IP deines Internet Service Providers (ISP) gemeint. Also an einem DSL/Kabel Anschluss hast du nach außen eine einzige öffentliche IP Adresse.

--luddi

 

[Frieseba]

Na, das Problem habe ich bereits behoben. Hier läuft neben der bereits volllen DS noch ein Raspberry pi . Beide sind nun allerdings voll. Daher würde ich gerne, statt einem weiteren Stromfresser, an die DS gerne eine externe hdd anhängen. Mehrere Knoten hinter einer IP sind dabei kein Problem. Sehe auch keinen Einbruch beim Traffic. Frage ist halt nur, wie ich es auf der Synology umsetzen kann

 

[luddi]

Technisch ist dies ja möglich wie ich bereits erwähnt habe. Aber aus den Storj FAQ's bin ich davon ausgegangen dass eben dies vermieden werden soll.
Aber wenn du da bereits gute Erfahrungen gemacht hast ist das prima.

Also ich hatte auch mal daran gespielt und auf dem Raspberry zwei Knoten angelegt, zusätzlich zu dem Knoten auf der Diskstation. In Summe hatte ich dann an einem ISP Anschluss 3 Knoten laufen. Ich hatte aber das Gefühl dass sich die Knoten beeinträchtigen. Wie auch immer, ich hatte es dann verworfen...

Wenn du das selbst probieren möchtest dann geht das wie folgt.
Man muss einfach zwei Container mit eindeutigen Namen anlegen bzw. starten und jeweils einen anderen Port für die Kommunikation verwenden.

z.B. gibt man dem einen den Namen "storagenode-no1" und dem anderen "storagenode-no2".
Der Knoten 1 kommuniziert auf dem Port 28967 und sein Interface für die Statistik läuft auf 14002.
Beim Knoten 2 wird der Port 28968 für die Kommunikation verwendet und für die WebGui Statistik dann eben 14003.

Daran denken auch den jeweiligen Port 28968 für den zweiten Knoten natürlich auch im Router (NAT) öffnen bzw. forwarden.

Knoten 1:

docker run -d --restart unless-stopped \
    -p 28967:28967 \
    -p 14002:14002 \
    [...]
    -e ADDRESS="<your-domain>:28967" \
    --name storagenode-no1 storjlabs/storagenode:beta

Knoten 2:

docker run -d --restart unless-stopped \
    -p 28968:28967 \
    -p 14003:14002 \
    [...]
    -e ADDRESS="<your-domain>:28968" \
    --name storagenode-no2 storjlabs/storagenode:beta

--luddi

 

[Frieseba]

Super.Danke

 

[luddi]

Gerne.

Ich denke ich kann das Thema auch nochmals angehen um einen weiteren Knoten auf dem Raspberry im gleichen Netzwerk anzulegen und dann nochmals alle Log files zu analysieren.

Mich würde allerdings interessieren ob in deinen jeweiligen Log files von jedem Knoten auch einige Errors bzw. eine hohe Anzahl an Abbrüchen von Up-/Donwloads zu verzeichnen ist.

--luddi