Pool de minage via VPN : garder la session sur le bon chemin

Le logiciel de minage garde une seule socket ouverte vers une seule adresse, et toutes les questions sur le tunnel, la route et le travail crédité dépendent de cette socket. Cette socket est une session cliente sortante vers un point de terminaison de pool, pas un écouteur qui accepte des pairs. La marche ci-dessous la suit depuis les quatre valeurs que le pool a émises jusqu’à une part que le pool a réellement enregistrée, et elle laisse les autres services de l’hôte tranquilles. Chaque étape produit une réponse que vous pouvez comparer, pas une impression.

Partir du point de terminaison que le pool a réellement émis

Le pool vous remet quatre valeurs qui forment tout le contrat : nom d’hôte ou adresse, port, variante de protocole et chaîne de compte. Prenez-les sur le tableau de bord du pool ou dans son message d’accueil, pas dans un tutoriel destiné à un autre pool. Des shards régionaux existent pour le même service, donc un nom d’hôte copié depuis un vieux guide peut encore se connecter et encore créditer un compte que vous ne vouliez pas utiliser. Copiez les quatre valeurs mot pour mot dans la configuration du mineur, car une chaîne de compte retapée perd un séparateur.

Le flux que vous routez est celui que le guide du développeur Bitcoin appelle une session Stratum : une connexion TCP persistante à double sens où le pool distribue le travail et le mineur renvoie des parts. Ce n’est pas le même flux que les connexions pair d’un nœud complet ou la synchronisation de chaîne d’un portefeuille, et les fondre dans une seule classe de trafic est là où commence la plupart de la confusion. Seul le premier relève de cette politique.

Là où le pool propose TLS, conservez la vérification du serveur exigée par sa documentation. Un tunnel chiffre le saut de votre machine au serveur VPN et s’arrête là ; il ne se porte pas garant de qui répond de l’autre côté. Gardez les deux contrôles, un à chaque extrémité, si vous voulez que la session survive à une sortie compromise.

Rattacher le tunnel au processus, pas au foyer

Deux points d’attache fonctionnent : exécutez le client VPN dans l’espace de noms réseau qu’utilise le mineur, ou donnez à cet espace de noms une passerelle qui porte son trafic dans le tunnel. L’une ou l’autre disposition place la session sur le chemin avant que le pool ne la voie. L’échec habituel est un client sur l’hôte, un mineur dans un conteneur avec son propre pont, et une route d’hôte que le conteneur ne consulte jamais. La fenêtre du client semble saine pendant que le pool enregistre votre adresse domicile.

Vérifiez le transport propre du tunnel avant de délimiter quoi que ce soit. Le client doit atteindre son serveur via le sous-jacent, donc une politique qui capture chaque paquet capture aussi les paquets qui construiraient le tunnel. Alors le tunnel ne peut pas démarrer et rien d’autre ne sort non plus. Sélectionnez ce qui entre dans le tunnel avec la fonction de tunneling divisé du client ; modifier les routes par défaut à la main, c’est ainsi que le sous-jacent disparaît.

Une fois la politique en place, lisez la table des sockets dans l’espace de noms qui possède le mineur. Le flux vers le port du pool doit se trouver sur l’interface du tunnel, et deux commandes répondent à cette question. Le port ci-dessous est un exemple ; remplacez-le par celui que le pool a émis.

sudo nsenter -t "$(pidof cgminer)" -n ss -tnp state established 'dport = :3333'
sudo nsenter -t "$(pidof cgminer)" -n ip route get 203.0.113.10

Lire la route et le résolveur depuis le contexte propre du mineur

Le routage et la résolution de noms sont par espace de noms, donc une vérification lancée dans un shell ordinaire décrit la mauvaise machine dès que le mineur est conteneurisé. Entrez d’abord dans l’espace de noms, puis demandez quelle interface porterait un paquet vers l’adresse du pool et quel résolveur répondrait pour son nom d’hôte. Les réponses de l’hôte ne se transposent pas, et l’écart entre elles est une source fréquente de reproches mal placés.

Nommez l’interface obtenue : le tunnel signifie que la session est sur le chemin prévu, tandis que le lien physique signifie qu’une règle a correspondu plus tôt que prévu. La longueur de préfixe décide d’abord, puis la métrique, puis les règles de politique, donc une table avec plusieurs entrées par défaut ne duplique pas les paquets, elle perd.

Les résolveurs échouent séparément des routes. Un tunnel qui réécrit /etc/resolv.conf peut laisser l’espace de noms pointer vers un résolveur joignable uniquement depuis l’intérieur du tunnel, ce qui échoue avant tout handshake TCP. Résolvez le nom d’hôte du pool dans l’espace de noms et comparez-le à l’adresse publiée. Si la recherche expire ou renvoie autre chose, corrigez la résolution avant de toucher aux routes.

Garder séparés le client mutualisé et l’écouteur du nœud

Le port 8333 est le port pair de Bitcoin Core, où un nœud complet écoute les connexions entrantes ; un mineur mutualisé n’a jamais besoin de l’ouvrir, et l’ouvrir ne répare pas une panne sortante. Les écouteurs entrants et les sessions sortantes sont des rôles opposés avec des hypothèses de confiance opposées. Rien dans la configuration d’un mineur ne lie ce port, donc un port fermé ne peut expliquer aucune erreur qu’il signale. Un conseil écrit pour la joignabilité d’un nœud peut donc laisser un service public tourner sur un hôte qui ne devait que soumettre des parts.

Si une seule machine fait réellement les deux, traitez chaque rôle comme son propre service avec sa propre décision d’accès. L’écouteur du nœud appartient à la politique que vous appliquez aux services publics, et la session du mineur appartient à la politique de sortie qui choisit le tunnel. Notez quel rôle l’hôte joue et supprimez les règles de l’autre rôle quand cela change, car une règle d’autorisation laissée derrière survit à sa raison.

Prouver que le pool a reçu le travail

Un ventilateur bruyant et un hashrate qui monte montrent que le mineur calcule, pas que quoi que ce soit a atteint le pool. La preuve se trouve dans les compteurs de soumission du client ou sur le tableau de bord du pool : parts acceptées, parts rejetées et la raison attachée à chaque rejet. Ces chiffres séparent trois pannes qui se ressemblent de l’extérieur : aucune session, une session sans crédit et une session qui se reconnecte sans fin. Lisez-les avant de changer une configuration.

Observez une tentative de connexion avec une journalisation détaillée et notez la dernière étape qui a réussi. L’étape où la séquence s’arrête est plus utile que n’importe quel message isolé autour d’elle :

Laissez ensuite le client tourner une fenêtre fixe et comptez les deux issues dans son journal. Un grep par compteur suffit, et les comparer sur la même fenêtre sépare un pool lent d’un chemin cassé. Adaptez le chemin à l’endroit où votre client écrit, car les deux comptages ne dépendent pas de l’emplacement :

grep -c Accepted /var/log/miner.log
grep -c Rejected /var/log/miner.log

Si une règle interdit une connexion directe au pool chaque fois que le tunnel tombe, exprimez-la comme un blocage explicite sur le point de terminaison du pool. Un client qui réessaie discrètement par le lien physique continuera de miner et continuera d’enfreindre cette règle, et son affichage d’état ne le mentionnera pas. Testez la règle en coupant le tunnel exprès et en confirmant que le port du pool est totalement injoignable.