Pool de minería por VPN: manter a sesión no camiño correcto

O software de minería mantén un só socket aberto cara a unha soa dirección, e cada pregunta sobre o túnel, a ruta e o traballo acreditado colga dese socket. Ese socket é unha sesión de cliente de saída cara a un extremo do pool, non un escoitador que acepta pares. O percorrido de abaixo ségueo desde os catro valores que emitiu o pool ata unha parte que o pool rexistrou de verdade, e deixa os demais servizos do host en paz. Cada paso produce unha resposta que podes comparar, non unha impresión.

Comeza polo extremo que o pool emitiu de verdade

O pool dálle catro valores que forman todo o contrato: nome do host ou dirección, porto, variante de protocolo e cadea de conta. Tómaos do panel do pool ou da mensaxe de benvida, non dun titorial para outro pool. Existen fragmentos rexionais para o mesmo servizo, así que un nome de host copiado dunha guía antiga aínda pode conectar e aínda pode acreditar unha conta que nunca quixeches usar. Copia os catro valores literalmente na configuración do mineiro, porque unha cadea de conta reescrita perde un separador.

O fluxo que estás a encamiñar é o que a guía do desenvolvedor de Bitcoin chama sesión Stratum: unha conexión TCP persistente de dous sentidos na que o pool distribúe traballo e o mineiro devolve partes. Non é o mesmo fluxo que as conexións de par dun nodo completo ou a sincronización de cadea dunha carteira, e meter todos nunha única clase de tráfico é onde comeza a maior parte da confusión. Só o primeiro pertence a esta política.

Onde o pool ofrece TLS, mantén a verificación do servidor que esixe a súa documentación. Un túnel cifra o salto desde a túa máquina ata o servidor VPN e remata aí; non responde por quen conteste ao outro lado. Mantén as dúas comprobacións, unha en cada extremo, se queres que a sesión sobreviva a unha saída comprometida.

Fixar o túnel ao proceso, non ao fogar

Dous puntos de fixación funcionan: executa o cliente VPN dentro do espazo de nomes de rede que usa o mineiro, ou dálle a ese espazo de nomes unha pasarela que leva o seu tráfico ao túnel. Calquera das dúas disposicións pon a sesión no camiño antes de que o pool a vexa. O fallo habitual é un cliente no host, un mineiro nun contedor coa súa propia ponte e unha ruta do host que o contedor nunca consulta. A xanela do cliente parece san, mentres o pool rexistra o teu enderezo doméstico.

Comproba o transporte propio do túnel antes de delimitar nada. O cliente ten que chegar ao seu servidor pola capa inferior, así que unha política que captura cada paquete captura tamén os paquetes que construirían o túnel. Entón o túnel non pode arrincar e nada máis sae tampouco. Selecciona coa función de túnel dividido do cliente o que entra no túnel; editar rutas por defecto a man é como desaparece a capa inferior.

Coa política no seu sitio, le a táboa de sockets no espazo de nomes ao que pertence o mineiro. O fluxo cara ao porto do pool debería estar na interface do túnel, e dous comandos responden a esa pregunta. O porto de abaixo é un exemplo; substituíno polo que emitiu o 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

Le a ruta e o resolvedor desde o propio contexto do mineiro

O encamiñamento e a resolución de nomes son por espazo de nomes, así que unha comprobación executada nun shell normal describe a máquina equivocada sempre que o mineiro está contenerizado. Entra primeiro no espazo de nomes e logo pregunta que interface levaría un paquete cara á dirección do pool e que resolvedor respondería polo seu nome de host. As respostas do host non se trasladan, e a fenda entre elas é unha fonte común de culpa mal posta.

Nomea a interface que obtés: o túnel significa que a sesión está no camiño previsto, mentres que a ligazón física significa que unha regra coincidiu antes do que esperabas. A lonxitude do prefixo decide primeiro, logo a métrica, logo as regras de política, así que unha táboa con varias entradas por defecto non duplica paquetes, só perde.

Os resolvedores fallan por separado das rutas. Un túnel que reescribe /etc/resolv.conf pode deixar o espazo de nomes apuntando a un resolvedor alcanzable só desde dentro do túnel, o que falla antes de que ocorra calquera aperto de mans TCP. Resolve o nome de host do pool dentro do espazo de nomes e compárao coa dirección publicada. Se a consulta caduca ou devolve outra cousa, arranxa a resolución antes de tocar as rutas.

Manter separados o cliente do pool e o escoitador do nodo

O porto 8333 é o porto de par de Bitcoin Core, onde un nodo completo escoita conexións entrantes; un mineiro de pool nunca o necesita aberto, e abrilo non repara un fallo de saída. Os escoitadores entrantes e as sesións de saída son roles opostos con supostos de confianza opostos. Nada na configuración dun mineiro vincula ese porto, así que un porto pechado non pode explicar ningún erro que reporte. Un consello escrito para a alcanzabilidade dun nodo pode, por tanto, deixar un servizo público funcionando nun host que só debía enviar partes.

Se unha soa máquina fai de verdade ambas as cousas, trata cada rol como o seu propio servizo coa súa propia decisión de acceso. O escoitador do nodo pertence detrás da política que aplicas aos servizos públicos, e a sesión do mineiro pertence á política de saída que escolle o túnel. Anota que rol xoga o host e elimina as regras do outro rol cando iso cambie, porque unha regra de permiso esquecida sobrevive ao seu motivo.

Demostra que o pool recibiu o traballo

Un ventilador ocupado e un hashrate que sobe mostran que o mineiro calcula, non que algo chegou ao pool. A evidencia está nos contadores de envío do cliente ou no panel do pool: partes aceptadas, partes rexeitadas e o motivo asociado a cada rexeitamento. Esas cifras separan tres fallos que se ven idénticos desde fóra: ningunha sesión, unha sesión sen crédito e unha sesión que se reconecta sen parar. Léos antes de cambiar calquera configuración.

Observa un intento de conexión con rexistro detallado e anota a última etapa que tivo éxito. A etapa na que se detén a secuencia é máis útil que calquera mensaxe solta ao seu redor:

Logo deixa que o cliente funcione unha xanela fixa e conta ambos os desenlaces no seu rexistro. Un grep por contador abonda, e comparalos sobre a mesma xanela separa un pool lento dun camiño roto. Axusta o camiño a onde escribe o teu cliente, xa que as dúas contas non dependen da localización:

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

Se unha regra prohibe unha conexión directa ao pool cada vez que o túnel cae, exprésaa como un bloqueo explícito no extremo do pool. Un cliente que reintenta en silencio pola ligazón física seguirá minando e seguirá incumprindo esa regra, e a súa pantalla de estado non o mencionará. Proba a regra cortando o túnel a propósito e confirmando que o porto do pool non é alcanzable en absoluto.