Pool de mineria per VPN: mantenir la sessió al camí correcte

El programari de mineria manté un sol socket obert cap a una sola adreça, i cada pregunta sobre el túnel, la ruta i la feina acreditada penja d’aquest socket. Aquest socket és una sessió de client de sortida cap a un extrem del pool, no un oïdor que accepta parells. El recorregut de sota el segueix des dels quatre valors que va emetre el pool fins a una part que el pool va registrar de debò, i deixa la resta de serveis de l’host en pau. Cada pas produeix una resposta que pots comparar, no una impressió.

Comença per l’extrem que el pool va emetre de debò

El pool et dona quatre valors que formen tot el contracte: nom d’host o adreça, port, variant de protocol i cadena de compte. Pren-los del tauler del pool o del missatge de benvinguda, no d’un tutorial per a un altre pool. Hi ha fragments regionals per al mateix servei, així que un nom d’host copiat d’una guia antiga encara es pot connectar i encara pot acreditar un compte que no volies fer servir mai. Copia els quatre valors literalment a la configuració del miner, perquè una cadena de compte reescrita perd un separador.

El flux que estàs encaminant és el que la guia del desenvolupador de Bitcoin anomena sessió Stratum: una connexió TCP persistent de dos sentits on el pool distribueix feina i el miner retorna parts. No és el mateix flux que les connexions de parell d’un node complet o la sincronització de cadena d’una cartera, i ficar-los tots en una única classe de trànsit és on comença la major part de la confusió. Només el primer pertany a aquesta política.

On el pool ofereix TLS, mantén la verificació del servidor que exigeix la seva documentació. Un túnel xifra el salt des de la teva màquina fins al servidor VPN i s’acaba allà; no respon per qui contesti a l’altre costat. Mantén les dues comprovacions, una a cada extrem, si vols que la sessió sobrevisqui a una sortida compromesa.

Fixar el túnel al procés, no a la llar

Dos punts de fixació funcionen: executa el client VPN dins de l’espai de noms de xarxa que fa servir el miner, o dona a aquest espai de noms una passarel·la que porta el seu trànsit al túnel. Qualsevol de les dues disposicions posa la sessió al camí abans que el pool la vegi. La fallada habitual és un client a l’host, un miner en un contenidor amb el seu propi pont i una ruta de l’host que el contenidor no consulta mai. La finestra del client sembla sana mentre el pool registra la teva adreça domèstica.

Comprova el transport propi del túnel abans de delimitar res. El client ha d’arribar al seu servidor per la capa inferior, així que una política que captura cada paquet captura també els paquets que construirien el túnel. Llavors el túnel no pot arrencar i res més no surt tampoc. Selecciona amb la funció de túnel dividit del client què entra al túnel; editar rutes per defecte a mà és com desapareix la capa inferior.

Amb la política al seu lloc, llegeix la taula de sockets a l’espai de noms al qual pertany el miner. El flux cap al port del pool hauria de seure a la interfície del túnel, i dues ordres responen a aquesta pregunta. El port de sota és un exemple; substitueix-lo pel que va emetre el pool.

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

Llegeix la ruta i el resolutor des del context propi del miner

L’encaminament i la resolució de noms són per espai de noms, així que una comprovació executada en un shell normal descriu la màquina equivocada sempre que el miner és en un contenidor. Entra primer a l’espai de noms i després pregunta quina interfície portaria un paquet cap a l’adreça del pool i quin resolutor respondria pel seu nom d’host. Les respostes de l’host no es traslladen, i la bretxa entre elles és una font comuna de culpa mal posada.

Anomena la interfície que obtens: el túnel significa que la sessió és al camí previst, mentre que l’enllaç físic significa que una regla va coincidir abans del que esperaves. La longitud del prefix decideix primer, després la mètrica, després les regles de política, així que una taula amb diverses entrades per defecte no duplica paquets, només perd.

Els resolutors fallen per separat de les rutes. Un túnel que reescriu /etc/resolv.conf pot deixar l’espai de noms apuntant a un resolutor abastable només des de dins del túnel, cosa que falla abans que passi cap encaixada de mans TCP. Resol el nom d’host del pool dins de l’espai de noms i compara’l amb l’adreça publicada. Si la consulta caduca o retorna una altra cosa, arregla la resolució abans de tocar les rutes.

Mantenir separats el client del pool i l’oïdor del node

El port 8333 és el port de parell de Bitcoin Core, on un node complet escolta connexions entrants; un miner de pool no el necessita mai obert, i obrir-lo no repara una fallada de sortida. Els oïdors entrants i les sessions de sortida són rols oposats amb supòsits de confiança oposats. Res a la configuració d’un miner no vincula aquest port, així que un port tancat no pot explicar cap error que reporti. Un consell escrit per a l’abastabilitat d’un node pot, per tant, deixar un servei públic funcionant en un host que només havia d’enviar parts.

Si una sola màquina fa de debò les dues coses, tracta cada rol com el seu propi servei amb la seva pròpia decisió d’accés. L’oïdor del node pertany darrere de la política que apliques als serveis públics, i la sessió del miner pertany a la política de sortida que tria el túnel. Anota quin rol fa l’host i elimina les regles de l’altre rol quan això canviï, perquè una regla de permís oblidada sobreviu al seu motiu.

Demostra que el pool va rebre la feina

Un ventilador ocupat i un hashrate que puja mostren que el miner calcula, no que alguna cosa hagi arribat al pool. L’evidència és als comptadors d’enviament del client o al tauler del pool: parts acceptades, parts rebutjades i el motiu associat a cada rebuig. Aquestes xifres separen tres fallades que es veuen idèntiques des de fora: cap sessió, una sessió sense crèdit i una sessió que es reconnecta sense parar. Llegeix-les abans de canviar qualsevol configuració.

Observa un intent de connexió amb registre detallat i anota l’última etapa que va tenir èxit. L’etapa on s’atura la seqüència és més útil que qualsevol missatge solt al seu voltant:

Després deixa que el client funcioni una finestra fixa i compta els dos desenllaços al seu registre. Un grep per comptador n’hi ha prou, i comparar-los sobre la mateixa finestra separa un pool lent d’un camí trencat. Ajusta el camí a on escriu el teu client, ja que els dos comptes no depenen de la ubicació:

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

Si una regla prohibeix una connexió directa al pool cada cop que el túnel cau, expressa-la com un bloqueig explícit a l’extrem del pool. Un client que reintenta en silenci per l’enllaç físic continuarà minant i continuarà incomplint aquesta regla, i la seva pantalla d’estat no ho esmentarà. Prova la regla tallant el túnel a propòsit i confirmant que el port del pool no és abastable de cap manera.