Adaptation à la réglementation russe

Le Problème

Une partie importante des machines sur CLORE.AI se trouve en Russie, principalement en raison de la disponibilité d'une énergie bon marché.

Différents services, voire les connexions à des serveurs virtuels/dédiés à usage général dans d'autres pays, peuvent être bloqués par certains FAI russes. CLORE.AI est un réseau distribué sans autorisation comportant de nombreux hôtes qui utilisent des connexions Internet résidentielles/entreprises en Russie, lesquelles, selon le fournisseur d'accès, peuvent restreindre l'accès à des protocoles non standard comme

• stratum+tcp / stratum+ssl

• websockets

• ou même toute connexion TCP/UDP depuis certains fournisseurs d'hébergement

Principalement à cause d'un pare-feu automatisé qui tente d'empêcher les connexions aux services VPN et les protocoles non standard/serveurs à usage général peuvent être signalés comme tels

Dans certains cas, même le domaine peut jouer un rôle pour le trafic HTTPS, comme montré par exemple dans publication probablement à cause de l'en-tête SNI mentionnant un domaine non .ru dans la requête (en TLS en dessous de la version v1.3)

La réalité est très spécifique et dépend de nombreux facteurs qui ne sont pas entièrement publics ; cet article peut vous aider à atténuer les faux positifs lors du blocage de vos connexions

Bon à savoir

Dans les instantanés GigaSPOT, le code pays est spécifié en ISO 3166-1 alpha-2

Solutions

Connexions aux pools de minage publics

Lors de l'utilisation de pools de minage publics, essayez d'utiliser un stratum hébergé en Russie pour les connexions depuis des machines situées en Russie, ce qui peut être déterminé par le code pays affiché pour chaque machine sur le marché GigaSPOT dans ISO 3166-1 alpha-2 format. Il est important de préciser que certaines machines en Russie ont récemment des adresses IP du Kazakhstan « KZ », elles sont donc signalées comme KZ ; il est généralement sûr de considérer tous les KZ comme RU et d'utiliser la même configuration pour les deux

Connexions à mon service websocket / http / https

Par exemple, vous pouvez avoir votre propre hôte pour servir des scripts et des fichiers pour des déploiements sur GigaSPOT, particulièrement utile pour exécuter des charges de travail à partir de l'image de base Ubuntu

Dans de tels cas, je peux recommander de mettre votre hôte derrière le proxy Cloudflare, qui est généralement accessible. Nous avons vu des cas où l'API websocket, par exemple sous Cloudflare, a été restreinte par certains fournisseurs d'accès russes ; cela est peu probable, mais l'obtention d'un domaine .ru a aidé

Vous pouvez aussi essayer d'installer l'hôte en Russie; une excellente option pourrait être https://pq.hosting/ qui accepte les paiements en cryptomonnaies.

Vérifications à l'intérieur du conteneur

Vous pouvez configurer des vérifications et avoir des points de terminaison séparés pour les machines en Russie et pour le reste du monde et démarrer votre charge de travail en conséquence selon l'endpoint qu'elle peut atteindre ; ici il est impossible de donner un guide, car l'implémentation peut être très différente selon les charges de travail.

Règles lors du déploiement

Vous pouvez faire en sorte que votre bot déploie 2 variantes de votre charge de travail, qui peuvent être ajustées peut-être par ENV, image différente, entrypoint... Pour différencier la Russie et le reste du monde. Comme mentionné précédemment, certaines machines russes apparaissent comme Kazakhstan « KZ » ; il est sûr de considérer le Kazakhstan comme la Russie à cette fin.

Mot de la fin

Alors qu'à l'heure actuelle la majorité des machines en Russie n'ont pas de tels problèmes de connexions restreintes, ce n'est pas rare et il est préférable d'être préparé pour prévenir des pertes financières.

Idéalement, utilisez quelques-unes des astuces mentionnées ou vous pouvez essayer de maintenir une liste noire de machines/hôtes qui ne fonctionnent pas correctement, ce qui peut être causé par ces restrictions