Pool de minería a través de VPN: mantener la sesión en el camino correcto

El software de minería mantiene un solo socket abierto hacia una sola dirección, y toda pregunta sobre el túnel, la ruta y el trabajo acreditado cuelga de ese socket. Ese socket es una sesión de cliente saliente hacia un extremo del pool, no un escucha que acepta pares. El recorrido siguiente lo sigue desde los cuatro valores que emitió el pool hasta una parte que el pool realmente registró, y deja intactos los demás servicios del host. Cada paso produce una respuesta que puede comparar, no una impresión.

Empezar por el extremo que el pool emitió realmente

El pool le entrega cuatro valores que forman todo el contrato: nombre de host o dirección, puerto, variante de protocolo y cadena de cuenta. Tómeles del panel del pool o de su mensaje de incorporación, no de un tutorial para otro pool. Existen fragmentos regionales para el mismo servicio, así que un nombre de host copiado de una guía antigua todavía puede conectar y todavía puede acreditar una cuenta que usted nunca quiso usar. Copie los cuatro valores literalmente en la configuración del minero, porque una cadena de cuenta reescrita pierde un separador.

El flujo que está enrutando es el que la guía del desarrollador de Bitcoin llama una sesión Stratum: una conexión TCP persistente de dos sentidos en la que el pool distribuye trabajo y el minero devuelve partes. No es el mismo flujo que las conexiones de par de un nodo completo o la sincronización de cadena de una cartera, y meterlos en una sola clase de tráfico es donde empieza la mayor parte de la confusión. Solo el primero pertenece a esta política.

Donde el pool ofrece TLS, mantenga la verificación del servidor que exige su documentación. Un túnel cifra el salto desde su máquina hasta el servidor VPN y termina ahí; no responde por quien conteste al otro lado. Mantenga ambas comprobaciones, una en cada extremo, si quiere que la sesión sobreviva a una salida comprometida.

Fijar el túnel al proceso, no al hogar

Dos puntos de fijación funcionan: ejecute el cliente VPN dentro del espacio de nombres de red que usa el minero, o dé a ese espacio de nombres una puerta de enlace que lleve su tráfico al túnel. Cualquiera de las dos disposiciones pone la sesión en el camino antes de que el pool la vea. El fallo habitual es un cliente en el host, un minero en un contenedor con su propio puente y una ruta del host que el contenedor nunca consulta. La ventana del cliente parece sana mientras el pool registra su dirección doméstica.

Compruebe el transporte propio del túnel antes de delimitar nada. El cliente tiene que llegar a su servidor a través de la capa inferior, así que una política que captura cada paquete captura también los paquetes que construirían el túnel. Entonces el túnel no puede arrancar y nada más sale tampoco. Seleccione qué entra en el túnel con la función de túnel dividido del cliente; editar rutas por defecto a mano es como desaparece la capa inferior.

Con la política en su sitio, lea la tabla de sockets en el espacio de nombres al que pertenece el minero. El flujo hacia el puerto del pool debería estar en la interfaz del túnel, y dos comandos responden a esa pregunta. El puerto de abajo es un ejemplo; sustituya el que emitió 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

Leer la ruta y el resolutor desde el propio contexto del minero

El enrutamiento y la resolución de nombres son por espacio de nombres, así que una comprobación ejecutada en un shell normal describe la máquina equivocada siempre que el minero esté contenerizado. Entre primero en el espacio de nombres y luego pregunte qué interfaz llevaría un paquete a la dirección del pool y qué resolutor respondería por su nombre de host. Las respuestas del host no se transfieren, y la brecha entre ambas es una fuente común de culpas mal puestas.

Nombre la interfaz que obtiene: el túnel significa que la sesión está en el camino previsto, mientras que el enlace físico significa que una regla coincidió antes de lo que esperaba. La longitud de prefijo decide primero, luego la métrica, luego las reglas de política, así que una tabla con varias entradas por defecto no duplica paquetes, solo pierde.

Los resolutores fallan por separado de las rutas. Un túnel que reescribe /etc/resolv.conf puede dejar el espacio de nombres apuntando a un resolutor alcanzable solo desde dentro del túnel, lo que falla antes de que ocurra ningún handshake TCP. Resuelva el nombre de host del pool dentro del espacio de nombres y compárelo con la dirección publicada. Si la consulta expira o devuelve otra cosa, arregle la resolución antes de tocar las rutas.

Mantener separados el cliente agrupado y el escucha del nodo

El puerto 8333 es el puerto de par de Bitcoin Core, donde un nodo completo escucha conexiones entrantes; un minero agrupado nunca necesita abrirlo, y abrirlo no repara un fallo saliente. Los escuchas entrantes y las sesiones salientes son roles opuestos con supuestos de confianza opuestos. Nada en la configuración de un minero vincula ese puerto, así que un puerto cerrado no puede explicar ningún error que reporte. Un consejo escrito para la alcanzabilidad de un nodo puede por tanto dejar un servicio público funcionando en un host que solo debía enviar partes.

Si una sola máquina hace de verdad ambas cosas, trate cada rol como su propio servicio con su propia decisión de acceso. El escucha del nodo pertenece a la política que aplique a los servicios públicos, y la sesión del minero pertenece a la política de salida que elige el túnel. Anote qué rol cumple el host y elimine las reglas del otro rol cuando eso cambie, porque una regla de permiso olvidada sobrevive a su motivo.

Demostrar que el pool recibió el trabajo

Un ventilador ocupado y un hashrate que sube muestran que el minero calcula, no que algo llegó al pool. La evidencia está en los contadores de envío del cliente o en el panel del pool: partes aceptadas, partes rechazadas y el motivo asociado a cada rechazo. Esos números separan tres fallos que se ven idénticos desde fuera: ninguna sesión, una sesión sin crédito y una sesión que se reconecta sin parar. Léalos antes de cambiar cualquier configuración.

Observe un intento de conexión con registro detallado y anote la última etapa que tuvo éxito. La etapa en la que se detiene la secuencia es más útil que cualquier mensaje suelto a su alrededor:

Luego deje que el cliente funcione una ventana fija y cuente ambos desenlaces en su registro. Un grep por contador basta, y compararlos sobre la misma ventana separa un pool lento de un camino roto. Ajuste el camino a donde escribe su cliente, ya que los dos recuentos no dependen de la ubicación:

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

Si una regla prohíbe una conexión directa al pool cada vez que el túnel se cae, exprésela como un bloqueo explícito en el extremo del pool. Un cliente que reintenta en silencio por el enlace físico seguirá minando y seguirá incumpliendo esa regla, y su pantalla de estado no lo mencionará. Pruebe la regla cortando el túnel a propósito y confirmando que el puerto del pool no es alcanzable en absoluto.