Adaptation à la réglementation russe

Le problème

Une portion significative des machines sur CLORE.AI est située en Russie, principalement en raison de la disponibilité d'une énergie bon marché.

Différents services, voire les connexions vers 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 permission comportant de nombreux hôtes qui utilisent des connexions Internet résidentielles/commerciales en Russie, lesquelles peuvent, selon le fournisseur d'accès, 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 en raison de l'en-tête SNI mentionnant un domaine non .ru dans la requête (en TLS sous la version v1.3)

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

Bon à savoir

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

Solutions

Connexions aux pools de minage publics

Lors de l'utilisation de pools de minage publics, essayez d'utiliser stratum hébergé en Russie pour les connexions sur les 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 dire que certaines machines en Russie ont récemment eu des adresses IP du Kazakhstan "KZ", donc elles sont 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 les déploiements sur GigaSPOT, particulièrement utile pour exécuter des charges de travail à partir d'une image de base Ubuntu

Dans de tels cas, je pourrais recommander de placer 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 derrière Cloudflare, a eu un accès restreint depuis certains fournisseurs d'accès russes, cela n'est pas 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 cryptomonnaie.

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 atteignable ; 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 final

Bien qu'à l'heure actuelle la majorité des machines en Russie n'aient pas de tels problèmes de connexions restreintes, il n'est pas rare que cela arrive et il est préférable d'être préparé pour éviter des pertes financières.

Idéalement, utilisez quelques-uns des trucs mentionnés 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