Pool de mineração por VPN: manter a sessão no caminho certo

O software de mineração mantém um único socket aberto para um único endereço, e toda pergunta sobre o túnel, a rota e o trabalho creditado depende desse socket. Esse socket é uma sessão de cliente de saída para um endpoint do pool, não um listener que aceita pares. O percurso abaixo o segue dos quatro valores que o pool emitiu até uma share que o pool realmente registrou, e deixa os outros serviços do host em paz. Cada passo produz uma resposta que você pode comparar, não uma impressão.

Começar pelo endpoint que o pool realmente emitiu

O pool entrega quatro valores que formam todo o contrato: nome de host ou endereço, porta, variante de protocolo e string de conta. Tire-os do painel do pool ou da mensagem de integração, não de um tutorial para outro pool. Existem shards regionais para o mesmo serviço, então um nome de host copiado de um guia antigo ainda pode conectar e ainda creditar uma conta que você nunca pretendeu usar. Copie os quatro valores literalmente na configuração do minerador, pois uma string de conta redigitada perde um separador.

O fluxo que você está roteando é o que o guia do desenvolvedor Bitcoin chama de sessão Stratum: uma conexão TCP persistente bidirecional em que o pool distribui trabalho e o minerador devolve shares. Esse não é o mesmo fluxo das conexões de par de um nó completo ou da sincronização de cadeia de uma carteira, e juntá-los em uma única classe de tráfego é onde a maior parte da confusão começa. Só o primeiro pertence a esta política.

Onde o pool oferece TLS, mantenha a verificação de servidor que a documentação dele exige. Um túnel criptografa o salto da sua máquina até o servidor VPN e termina ali; ele não garante quem responde do outro lado. Mantenha as duas verificações, uma em cada ponta, se quiser que a sessão sobreviva a uma saída comprometida.

Prender o túnel ao processo, não à casa

Dois pontos de fixação funcionam: execute o cliente VPN dentro do namespace de rede que o minerador usa, ou dê a esse namespace um gateway que leve o tráfego dele para o túnel. Qualquer das duas disposições coloca a sessão no caminho antes de o pool vê-la. A falha comum é um cliente no host, um minerador em um contêiner com a própria bridge e uma rota do host que o contêiner nunca consulta. A janela do cliente parece saudável enquanto o pool registra o seu endereço residencial.

Verifique o transporte próprio do túnel antes de delimitar qualquer coisa. O cliente precisa alcançar o servidor dele pelo underlay, então uma política que captura cada pacote também captura os pacotes que construiriam o túnel. Aí o túnel não inicia e nada mais sai também. Selecione o que entra no túnel com o recurso de túnel dividido do cliente; editar rotas padrão à mão é como o underlay some.

Com a política no lugar, leia a tabela de sockets no namespace a que o minerador pertence. O fluxo para a porta do pool deve estar na interface do túnel, e dois comandos respondem a essa pergunta. A porta abaixo é um exemplo; substitua pela que o pool emitiu.

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

Ler rota e resolvedor a partir do contexto do próprio minerador

Roteamento e resolução de nomes são por namespace, então uma verificação executada em um shell comum descreve a máquina errada sempre que o minerador está em contêiner. Entre primeiro no namespace e então pergunte qual interface levaria um pacote ao endereço do pool e qual resolvedor responderia pelo nome de host. As respostas do host não se transferem, e a diferença entre elas é uma fonte comum de culpa mal atribuída.

Nomeie a interface que você obtém: o túnel significa que a sessão está no caminho pretendido, enquanto o enlace físico significa que uma regra casou antes do que você esperava. O tamanho do prefixo decide primeiro, depois a métrica, depois as regras de política, então uma tabela com várias entradas padrão não duplica pacotes, apenas perde.

Resolvedores falham separadamente das rotas. Um túnel que reescreve /etc/resolv.conf pode deixar o namespace apontando para um resolvedor alcançável só de dentro do túnel, o que falha antes de qualquer handshake TCP acontecer. Resolva o nome de host do pool dentro do namespace e compare com o endereço publicado. Se a consulta expirar ou devolver outra coisa, conserte a resolução antes de mexer nas rotas.

Manter separados o cliente em pool e o listener do nó

A porta 8333 é a porta de par do Bitcoin Core, onde um nó completo escuta conexões de entrada; um minerador em pool nunca precisa dela aberta, e abri-la não conserta uma falha de saída. Listeners de entrada e sessões de saída são papéis opostos com premissas de confiança opostas. Nada na configuração de um minerador vincula essa porta, então uma porta fechada não pode explicar nenhum erro que ele relate. Um conselho escrito para a alcançabilidade de um nó pode, portanto, deixar um serviço público rodando em um host que só deveria enviar shares.

Se uma única máquina realmente faz as duas coisas, trate cada papel como serviço próprio com a própria decisão de acesso. O listener do nó pertence à política que você aplica a serviços públicos, e a sessão do minerador pertence à política de saída que escolhe o túnel. Registre qual papel o host cumpre e remova as regras do outro papel quando isso mudar, porque uma regra de permissão esquecida sobrevive ao motivo dela.

Provar que o pool recebeu o trabalho

Um ventilador ocupado e um hashrate subindo mostram que o minerador está calculando, não que algo chegou ao pool. A evidência está nos contadores de envio do cliente ou no painel do pool: shares aceitas, shares rejeitadas e o motivo anexado a cada rejeição. Esses números separam três falhas que parecem idênticas por fora: nenhuma sessão, uma sessão sem crédito e uma sessão que reconecta sem parar. Leia-os antes de mudar qualquer configuração.

Observe uma tentativa de conexão com log detalhado e anote o último estágio que teve sucesso. O estágio em que a sequência para é mais útil do que qualquer mensagem isolada em volta dele:

Depois deixe o cliente rodar uma janela fixa e conte os dois desfechos no log dele. Um grep por contador basta, e compará-los na mesma janela separa um pool lento de um caminho quebrado. Ajuste o caminho para onde o seu cliente escreve, já que as duas contagens não dependem do local:

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

Se uma regra proíbe uma conexão direta ao pool sempre que o túnel cai, expresse-a como um bloqueio explícito no endpoint do pool. Um cliente que tenta de novo em silêncio pelo enlace físico continuará minerando e continuará violando essa regra, e o display de status dele não vai mencionar isso. Teste a regra derrubando o túnel de propósito e confirmando que a porta do pool não é alcançável de jeito nenhum.