Anpassung an russische Vorschriften

Das Problem

Ein erheblicher Teil der Maschinen auf CLORE.AI befindet sich in Russland, hauptsächlich aufgrund der Verfügbarkeit günstiger Energie.

Verschiedene Dienste, sogar Verbindungen zu allgemeiner Virtual-/Dedizierter-Server in anderen Ländern, können von einigen russischen ISP blockiert werden. CLORE.AI ist ein verteiltes, erlaubnisfreies Netzwerk mit vielen Hosts, die in Russland residential-/geschäftliche Internetanschlüsse nutzen, welche je nach Internetanbieter den Zugriff auf nicht standardisierte Protokolle wie

• stratum+tcp / stratum+ssl

• WebSockets

• oder sogar jede TCP/UDP-Verbindung von einigen Hosting-Anbietern einschränken können

Hauptsächlich aufgrund automatischer Firewalls, die versuchen, Verbindungen zu VPN-Diensten zu verhindern; nicht standardisierte Protokolle/allgemeine Server können als solche markiert werden

In einigen Fällen kann sogar die Domain bei HTTPS-Verkehr eine Rolle spielen, wie zum Beispiel gezeigt in Post wahrscheinlich wegen des SNI-Headers, der in der Anfrage eine Nicht-RU-Domain erwähnt (bei TLS-Versionen unter v1.3)

Die Realität ist sehr spezifisch und hängt von vielen Faktoren ab, die nicht vollständig öffentlich bekannt sind. Dieser Artikel kann Ihnen helfen, Fehlalarme beim Blockieren Ihrer Verbindungen zu mindern

Gut zu wissen

In GigaSPOT-Snapshots wird der Ländercode gemäß ISO 3166-1 alpha-2 angegeben

Lösungen

Verbindungen zu öffentlichen Mining-Pools

Bei Nutzung öffentlicher Mining-Pools versuchen Sie, für Verbindungen von Maschinen in Russland Stratum-Server in Russland zu verwenden, was anhand des Ländercodes ermittelt werden kann, der für jede Maschine im GigaSPOT-Markt angezeigt wird in ISO 3166-1 alpha-2 Format. Wichtig zu sagen: Einige Maschinen in Russland haben in letzter Zeit kasachische "KZ"-IP-Adressen, daher werden sie als KZ gemeldet. Es ist im Allgemeinen sicher, alle KZ als RU anzusehen und dieselbe Konfiguration für beide zu verwenden

Verbindungen zu meinem WebSocket / HTTP / HTTPS-Dienst

Zum Beispiel könnten Sie einen eigenen Host haben, um Skripte und Dateien für Deployments auf GigaSPOT bereitzustellen, besonders nützlich für Ausführung von Workloads aus dem Ubuntu-Base-Image

In solchen Fällen empfehle ich, Ihren Host unter dem Cloudflare-Proxy zu betreiben, der allgemein zugänglich ist. Wir haben Fälle gesehen, in denen die WebSocket-API beispielsweise unter Cloudflare von einigen russischen Internetanbietern eingeschränkt wurde. Das ist nicht sehr wahrscheinlich, aber die Beschaffung einer .ru-Domain hat geholfen

Außerdem können Sie versuchen, den Host in Russland einzurichten; eine gute Option könnte sein https://pq.hosting/ welches Kryptowährungszahlungen akzeptiert.

Prüfungen innerhalb des Containers

Sie können Prüfungen einrichten und separate Endpunkte für Maschinen in Russland und außerhalb haben und Ihre Workload entsprechend starten, je nachdem, welchen Endpunkt sie erreichen kann. Hier ist es unmöglich, eine Anleitung zu geben, da die Implementierung für verschiedene Workloads sehr unterschiedlich sein kann.

Regeln beim Deployen

Sie können Ihren Bot zwei Varianten Ihrer Workload deployen lassen, die vielleicht durch ENV, ein anderes Image, Entrypoint ... angepasst werden können, um Russland und die Außenwelt zu unterscheiden. Wie bereits erwähnt erscheinen einige russische Maschinen als Kasachstan "KZ"; für diesen Zweck ist es sicher, Kasachstan als Russland anzusehen.

Abschließendes Wort

Auch wenn derzeit die Mehrheit der Maschinen in Russland keine derartigen Verbindungsbeschränkungen hat, kommt es nicht selten vor, und es ist besser, vorbereitet zu sein, um finanzielle Verluste zu vermeiden.

Idealerweise nutzen Sie einige der genannten Tricks oder Sie versuchen, eine Sperrliste von Maschinen/Hosts zu pflegen, die nicht richtig funktionieren, was durch diese Beschränkungen verursacht sein kann