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 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é et sans permission 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 tels que

• stratum+tcp / stratum+ssl

• websockets

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

Principalement à cause de pare-feux automatisés qui tentent d'empêcher les connexions aux services VPN et où un serveur à usage général ou des protocoles non standard peuvent être signalés comme tels

Dans certains cas, même le domaine peut jouer un rôle pour le trafic HTTPS, comme illustré par exemple dans un post probablement à cause 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 lors du 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 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 format ISO 3166-1 alpha-2 Il est important de noter 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 d'une image de base Ubuntu

Dans de tels cas, je pourrais 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 derrière Cloudflare, voyait son accès restreint par certains fournisseurs d'accès Internet russes ; cela est peu probable, mais l'obtention d'un domaine .ru a aidé

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

Contrôles à l'intérieur du conteneur

Vous pouvez configurer des contrôles et avoir des points de terminaison séparés pour les machines en Russie et pour le reste du monde et lancer votre charge de travail en fonction de l'endroit qu'elles peuvent atteindre ; ici il est impossible de fournir 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, ajustables peut-être par variable d'environnement, image différente, point d'entrée... 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

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 certaines 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