Pool de minerit prin VPN: păstrează sesiunea pe calea corectă

Software-ul de minerit ține un singur socket deschis către o singură adresă, iar fiecare întrebare despre tunel, rută și munca creditată atârnă de acel socket. Acel socket este o sesiune de client de ieșire către un endpoint al pool-ului, nu un listener care acceptă peeri. Parcursul de mai jos îl urmărește de la cele patru valori emise de pool până la un share pe care pool-ul l-a înregistrat efectiv, și lasă celelalte servicii ale gazdei în pace. Fiecare pas produce un răspuns pe care îl poți compara, nu o impresie.

Începe de la endpointul pe care pool-ul l-a emis efectiv

Pool-ul îți dă patru valori care formează tot contractul: nume de gazdă sau adresă, port, variantă de protocol și șir de cont. Ia-le din panoul pool-ului sau din mesajul de onboarding, nu dintr-un tutorial pentru alt pool. Există sharduri regionale pentru același serviciu, așa că un nume de gazdă copiat dintr-un ghid vechi se poate conecta în continuare și poate credita în continuare un cont pe care nu ai vrut niciodată să îl folosești. Copiază cele patru valori întocmai în configurația minerului, fiindcă un șir de cont rescris pierde un separator.

Fluxul pe care îl rutezi este cel pe care ghidul dezvoltatorului Bitcoin îl numește sesiune Stratum: o conexiune TCP persistentă bidirecțională în care pool-ul distribuie muncă, iar minerul returnează share-uri. Nu este același flux ca conexiunile peer ale unui nod complet sau sincronizarea lanțului a unui portofel, iar plierea lor într-o singură clasă de trafic este locul unde începe cea mai mare parte a confuziei. Doar primul aparține acestei politici.

Acolo unde pool-ul oferă TLS, păstrează verificarea serverului cerută de documentația lui. Un tunel criptează saltul de la mașina ta la serverul VPN și se termină acolo; nu garantează pentru cine răspunde la celălalt capăt. Păstrează ambele verificări, una la fiecare capăt, dacă vrei ca sesiunea să supraviețuiască unei ieșiri compromise.

Atașează tunelul la proces, nu la gospodărie

Două puncte de atașare funcționează: rulează clientul VPN în spațiul de nume de rețea folosit de miner, sau dă acelui spațiu de nume o poartă care îi duce traficul în tunel. Ambele aranjamente pun sesiunea pe cale înainte ca pool-ul să o vadă. Eșecul obișnuit este un client pe gazdă, un miner într-un container cu puntea lui și o rută de gazdă pe care containerul nu o consultă niciodată. Fereastra clientului arată sănătos în timp ce pool-ul înregistrează adresa ta de acasă.

Verifică transportul propriu al tunelului înainte de a delimita ceva. Clientul trebuie să ajungă la serverul lui prin stratul de dedesubt, așa că o politică ce capturează fiecare pachet capturează și pachetele care ar construi tunelul. Atunci tunelul nu poate porni și nici altceva nu mai iese. Selectează cu funcția de tunel divizat a clientului ce intră în tunel; editarea manuală a rutelor implicite este felul în care stratul de dedesubt dispare.

Cu politica în vigoare, citește tabela de socketuri din spațiul de nume căruia îi aparține minerul. Fluxul către portul pool-ului ar trebui să stea pe interfața tunelului, iar două comenzi răspund la această întrebare. Portul de mai jos este un exemplu; înlocuiește-l cu cel emis de 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

Citește ruta și resolverul din contextul propriu al minerului

Rutarea și rezolvarea numelor sunt per spațiu de nume, așa că o verificare rulată într-un shell obișnuit descrie mașina greșită ori de câte ori minerul rulează într-un container. Intră mai întâi în spațiul de nume și apoi întreabă ce interfață ar duce un pachet către adresa pool-ului și ce resolver ar răspunde pentru numele lui de gazdă. Răspunsurile gazdei nu se transferă, iar diferența dintre ele este o sursă comună de vină prost plasată.

Numește interfața pe care o obții: tunelul înseamnă că sesiunea este pe calea dorită, în timp ce legătura fizică înseamnă că o regulă s-a potrivit mai devreme decât te așteptai. Lungimea prefixului decide prima, apoi metrica, apoi regulile de politică, așa că un tabel cu mai multe intrări implicite nu duplică pachetele, doar pierde.

Resolverele eșuează separat de rute. Un tunel care rescrie /etc/resolv.conf poate lăsa spațiul de nume să indice un resolver accesibil doar din interiorul tunelului, ceea ce eșuează înainte de orice handshake TCP. Rezolvă numele de gazdă al pool-ului în interiorul spațiului de nume și compară-l cu adresa publicată. Dacă interogarea expiră sau returnează altceva, repară rezolvarea înainte de a atinge rutele.

Ține separat clientul din pool și listenerul nodului

Portul 8333 este portul de peer al Bitcoin Core, unde un nod complet ascultă conexiuni de intrare; un miner din pool nu are niciodată nevoie de el deschis, iar deschiderea lui nu repară o defecțiune de ieșire. Listenerii de intrare și sesiunile de ieșire sunt roluri opuse cu ipoteze de încredere opuse. Nimic din configurația unui miner nu leagă acel port, așa că un port închis nu poate explica nicio eroare pe care o raportează. Un sfat scris pentru accesibilitatea unui nod poate deci lăsa un serviciu public să ruleze pe o gazdă care trebuia doar să trimită share-uri.

Dacă o singură mașină face într-adevăr ambele, tratează fiecare rol ca serviciu propriu cu propria decizie de acces. Listenerul nodului aparține politicii pe care o aplici serviciilor publice, iar sesiunea minerului aparține politicii de ieșire care alege tunelul. Notează ce rol joacă gazda și elimină regulile celuilalt rol când asta se schimbă, fiindcă o regulă de permisiune rămasă în urmă supraviețuiește motivului ei.

Dovedește că pool-ul a primit munca

Un ventilator ocupat și un hashrate în creștere arată că minerul calculează, nu că ceva a ajuns la pool. Dovada stă în contoarele de trimitere ale clientului sau în panoul pool-ului: share-uri acceptate, share-uri respinse și motivul atașat fiecărei respingeri. Acele numere separă trei defecțiuni care arată identic din exterior: nicio sesiune, o sesiune fără credit și o sesiune care se reconectează continuu. Citește-le înainte de a schimba orice configurație.

Urmărește o încercare de conexiune cu logare detaliată și notează ultima etapă care a reușit. Etapa în care secvența se oprește este mai utilă decât orice mesaj individual din jurul ei:

Apoi lasă clientul să ruleze o fereastră fixă și numără ambele rezultate din logul lui. Un grep pe contor este suficient, iar compararea lor pe aceeași fereastră separă un pool lent de o cale ruptă. Ajustează calea la locul unde scrie clientul tău, fiindcă cele două numărări nu depind de locație:

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

Dacă o regulă interzice o conexiune directă la pool ori de câte ori tunelul cade, exprimă-o ca blocare explicită pe endpointul pool-ului. Un client care reîncearcă în tăcere prin legătura fizică va continua să mineze și va continua să încalce acea regulă, iar afișajul lui de stare nu va menționa asta. Testează regula lăsând tunelul să cadă intenționat și confirmând că portul pool-ului nu este deloc accesibil.