Pool di mining su VPN: tenere la sessione sul percorso giusto

Il software di mining tiene un solo socket aperto verso un solo indirizzo, e ogni domanda su tunnel, rotta e lavoro accreditato pende da quel socket. Quel socket è una sessione client in uscita verso un endpoint del pool, non un listener che accetta peer. Il percorso qui sotto lo segue dai quattro valori emessi dal pool fino a una share che il pool ha davvero registrato, e lascia in pace gli altri servizi dell’host. Ogni passo produce una risposta che puoi confrontare, non un’impressione.

Partire dall’endpoint che il pool ha davvero emesso

Il pool ti consegna quattro valori che formano l’intero contratto: nome host o indirizzo, porta, variante di protocollo e stringa dell’account. Prendili dalla dashboard del pool o dal messaggio di onboarding, non da un tutorial per un altro pool. Esistono shard regionali per lo stesso servizio, quindi un nome host copiato da una guida vecchia può ancora connettersi e ancora accreditare un account che non volevi usare. Copia i quattro valori alla lettera nella configurazione del miner, perché una stringa dell’account ridigitata perde un separatore.

Il flusso che stai instradando è quello che la guida per sviluppatori di Bitcoin chiama una sessione Stratum: una connessione TCP persistente bidirezionale in cui il pool distribuisce lavoro e il miner restituisce share. Non è lo stesso flusso delle connessioni peer di un nodo completo o della sincronizzazione della catena di un wallet, e il punto in cui la maggior parte della confusione nasce è proprio nel fonderli in un’unica classe di traffico. Solo il primo appartiene a questa policy.

Dove il pool offre TLS, mantieni la verifica del server richiesta dalla sua documentazione. Un tunnel cifra il salto dalla tua macchina al server VPN e finisce lì; non garantisce per chi risponde dall’altro lato. Mantieni entrambi i controlli, uno a ciascuna estremità, se vuoi che la sessione sopravviva a un’uscita compromessa.

Agganciare il tunnel al processo, non alla casa

Due punti di aggancio funzionano: esegui il client VPN nel namespace di rete che usa il miner, oppure assegna a quel namespace un gateway che porta il suo traffico nel tunnel. Entrambe le sistemazioni mettono la sessione sul percorso prima che il pool la veda. Il guasto abituale è un client sull’host, un miner in un container con il proprio bridge e una rotta dell’host che il container non consulta mai. La finestra del client sembra sana mentre il pool registra il tuo indirizzo di casa.

Controlla il trasporto proprio del tunnel prima di delimitare qualsiasi cosa. Il client deve raggiungere il suo server attraverso l’underlay, quindi una policy che cattura ogni pacchetto cattura anche i pacchetti che costruirebbero il tunnel. Allora il tunnel non può partire e non esce nient’altro. Seleziona cosa entra nel tunnel con la funzione split tunneling del client; modificare a mano le rotte predefinite è il modo in cui l’underlay svanisce.

Con la policy in vigore, leggi la tabella dei socket nel namespace a cui appartiene il miner. Il flusso verso la porta del pool dovrebbe stare sull’interfaccia del tunnel, e due comandi rispondono a questa domanda. La porta qui sotto è un esempio; sostituisci quella emessa dal 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

Leggere rotta e resolver dal contesto del miner stesso

Instradamento e risoluzione dei nomi sono per namespace, quindi un controllo eseguito in una shell normale descrive la macchina sbagliata ogni volta che il miner è in un container. Entra prima nel namespace, poi chiedi quale interfaccia porterebbe un pacchetto all’indirizzo del pool e quale resolver risponderebbe per il suo nome host. Le risposte dell’host non si trasferiscono, e lo scarto tra le due è una fonte comune di colpe mal riposte.

Nomina l’interfaccia che ottieni: il tunnel significa che la sessione è sul percorso previsto, mentre il collegamento fisico significa che una regola ha corrisposto prima di quanto ti aspettassi. La lunghezza del prefisso decide per prima, poi la metrica, poi le regole di policy, quindi una tabella con diverse voci predefinite non duplica i pacchetti, perde e basta.

I resolver falliscono separatamente dalle rotte. Un tunnel che riscrive /etc/resolv.conf può lasciare il namespace puntato a un resolver raggiungibile solo dall’interno del tunnel, il che fallisce prima che avvenga qualsiasi handshake TCP. Risolvi il nome host del pool dentro il namespace e confrontalo con l’indirizzo pubblicato. Se la ricerca scade o restituisce altro, correggi la risoluzione prima di toccare le rotte.

Tenere separati il client in pool e il listener del nodo

La porta 8333 è la porta peer di Bitcoin Core, dove un nodo completo ascolta connessioni in entrata; un miner in pool non ha mai bisogno di aprirla, e aprirla non ripara un guasto in uscita. Listener in entrata e sessioni in uscita sono ruoli opposti con ipotesi di fiducia opposte. Nulla nella configurazione di un miner lega quella porta, quindi una porta chiusa non può spiegare nessun errore che riporta. Un consiglio scritto per la raggiungibilità di un nodo può quindi lasciare un servizio pubblico in esecuzione su un host che doveva solo inviare share.

Se una sola macchina fa davvero entrambe le cose, tratta ogni ruolo come servizio a sé con la propria decisione di accesso. Il listener del nodo appartiene alla policy che applichi ai servizi pubblici, e la sessione del miner appartiene alla policy di uscita che sceglie il tunnel. Annota quale ruolo ricopre l’host e rimuovi le regole dell’altro ruolo quando cambia, perché una regola di permesso rimasta in giro sopravvive alla sua ragione.

Dimostrare che il pool ha ricevuto il lavoro

Una ventola indaffarata e un hashrate in salita mostrano che il miner sta calcolando, non che qualcosa ha raggiunto il pool. Le prove stanno nei contatori di invio del client o nella dashboard del pool: share accettate, share rifiutate e il motivo allegato a ogni rifiuto. Quei numeri separano tre guasti che dall’esterno sembrano identici: nessuna sessione, una sessione senza credito e una sessione che si riconnette di continuo. Leggili prima di cambiare qualsiasi configurazione.

Osserva un tentativo di connessione con logging dettagliato e annota l’ultima fase riuscita. La fase in cui la sequenza si ferma è più utile di qualsiasi singolo messaggio intorno ad essa:

Poi lascia che il client giri per una finestra fissa e conta entrambi gli esiti dal suo log. Un grep per contatore basta, e confrontarli sulla stessa finestra separa un pool lento da un percorso rotto. Adatta il percorso a dove scrive il tuo client, dato che i due conteggi non dipendono dalla posizione:

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

Se una regola vieta una connessione diretta al pool ogni volta che il tunnel cade, esprimila come blocco esplicito sull’endpoint del pool. Un client che ritenta in silenzio sul collegamento fisico continuerà a fare mining e continuerà a violare quella regola, e il suo display di stato non lo menzionerà. Metti alla prova la regola abbattendo il tunnel di proposito e confermando che la porta del pool non è raggiungibile affatto.