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 allgemeinen virtuellen/dedizierten Servern in anderen Ländern, könnten von einigen russischen ISPs blockiert werden. CLORE.AI ist ein verteiltes, genehmigungsfreies Netzwerk mit vielen Hosts, die in Russland Wohn-/Geschäfts-Internetverbindungen nutzen, welche je nach Internetanbieter den Zugriff auf nicht standardmäßige Protokolle einschränken können wie

• stratum+tcp / stratum+ssl

• WebSockets

• oder sogar jegliche TCP/UDP-Verbindungen von einigen Hosting-Anbietern

Hauptsächlich wegen automatisierter Firewalls, die versuchen, Verbindungen zu VPN-Diensten zu verhindern, und nicht standardmäßige Protokolle/allgemeine Server als solche markiert werden können

In manchen Fällen kann sogar die Domain für HTTPS-Verkehr eine Rolle spielen, wie beispielsweise gezeigt in Beitrag wahrscheinlich wegen des SNI-Headers, der in der Anfrage eine Nicht‑.ru‑Domain erwähnt (bei TLS unter Version 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 dabei helfen, Fehlalarme bei der Blockierung Ihrer Verbindungen zu mindern

Gut zu wissen

In GigaSPOT-Snapshots wird der Ländercode im ISO 3166-1 alpha-2-Format angegeben

Lösungen

Verbindungen zu öffentlichen Mining-Pools

Bei der Nutzung öffentlicher Mining-Pools versuchen Sie, Stratum-Server zu verwenden, die in Russland gehostet werden, für Verbindungen von Maschinen in Russland. Dies lässt sich anhand des Ländercodes für jede Maschine im GigaSPOT-Markt bestimmen in ISO 3166-1 alpha-2 Format. Wichtig ist zu sagen, dass einige Maschinen in Russland zuletzt kasachische "KZ"-IP-Adressen hatten, sodass sie als KZ gemeldet werden. Es ist allgemein sicher, alle KZ als RU zu betrachten 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ühren von Workloads aus einem Ubuntu-Basis-Image

In solchen Fällen kann ich empfehlen, Ihren Host hinter dem Cloudflare-Proxy zu betreiben, der allgemein zugänglich ist. Wir haben Fälle gesehen, in denen zum Beispiel die WebSocket-API unter Cloudflare von einigen russischen Internetanbietern eingeschränkt wurde. Es ist nicht sehr wahrscheinlich, aber das Erlangen einer .ru-Domain hat geholfen

Außerdem können Sie versuchen, den Host in Russland einzurichten. Eine großartige Option könnte sein https://pq.hosting/ die 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 einrichten und Ihre Workloads entsprechend starten, abhängig davon, welchen Endpunkt sie erreichen können. Hier ist es unmöglich, eine Anleitung zu geben, da die Implementierung je nach Workload sehr unterschiedlich sein kann.

Regeln bei Deployments

Sie können Ihren Bot so konfigurieren, dass er zwei Varianten Ihres Workloads bereitstellt, die möglicherweise per ENV, anderem Image, Entrypoint usw. angepasst werden können, um Russland und die Außenwelt zu unterscheiden. Wie bereits erwähnt, erscheinen einige russische Maschinen als Kasachstan "KZ"; es ist für diesen Zweck sicher, Kasachstan als Russland zu behandeln.

Abschließendes Wort

Auch wenn momentan 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 verwenden Sie einige der genannten Tricks oder Sie versuchen, eine Blacklist von Maschinen/Hosts zu pflegen, die nicht richtig funktionieren, was durch diese Beschränkungen verursacht werden kann.