Miningpool över VPN: håll sessionen på rätt väg

Miningprogramvara håller en enda socket öppen mot en enda adress, och varje fråga om tunneln, rutten och det krediterade arbetet hänger på den socketen. Den socketen är en utgående klientsession till en pool-endpoint, inte en lyssnare som tar emot peers. Genomgången nedan följer den från de fyra värden poolen utfärdade till en share som poolen faktiskt bokförde, och den lämnar värdens övriga tjänster i fred. Varje steg ger ett svar du kan jämföra, inte ett intryck.

Börja vid den endpoint poolen faktiskt utfärdade

Poolen ger dig fyra värden som utgör hela kontraktet: värdnamn eller adress, port, protokollvariant och kontosträng. Ta dem från poolens instrumentpanel eller introduktionsmeddelande, inte från en guide för en annan pool. Det finns regionala shards för samma tjänst, så ett värdnamn kopierat från en gammal guide kan fortfarande ansluta och fortfarande kreditera ett konto du aldrig tänkt använda. Kopiera de fyra värdena ordagrant in i minerarens konfiguration, eftersom en omtangenterad kontosträng tappar en separator.

Det flöde du routar är det som Bitcoins utvecklarguide kallar en Stratum-session: en beständig dubbelriktad TCP-anslutning där poolen distribuerar arbete och mineraren returnerar shares. Det är inte samma flöde som en fullständig nods peer-anslutningar eller en plånboks kedjesynkronisering, och att vika ihop dem till en enda trafikklass är där det mesta av förvirringen börjar. Bara det första hör under den här policyn.

Där poolen erbjuder TLS, behåll den serververifiering som dess dokumentation kräver. En tunnel krypterar hoppet från din maskin till VPN-servern och slutar där; den går inte i god för den som svarar på andra sidan. Behåll båda kontrollerna, en i varje ände, om du vill att sessionen ska överleva en komprometterad utgång.

Fäst tunneln vid processen, inte vid hushållet

Två fästpunkter fungerar: kör VPN-klienten inuti det nätverksnamespace som mineraren använder, eller ge det namespacet en gateway som bär dess trafik in i tunneln. Båda arrangemangen sätter sessionen på vägen innan poolen ser den. Det vanliga felet är en klient på värden, en minerare i en container med egen bridge och en värdrutt som containern aldrig rådfrågar. Klientfönstret ser friskt ut medan poolen registrerar din hemadress.

Kontrollera tunnelns egen transport innan du avgränsar något. Klienten måste nå sin server genom underliggande nätet, så en policy som fångar varje paket fångar också paketen som skulle bygga tunneln. Då kan tunneln inte starta och inget annat lämnar heller. Välj med klientens split-tunneling-funktion vad som går in i tunneln; att redigera standardrutter för hand är hur underliggande nätet försvinner.

Med policyn på plats, läs sockettabellen i det namespace som äger mineraren. Flödet till poolporten bör ligga på tunnelgränssnittet, och två kommandon besvarar den frågan. Porten nedan är ett exempel; ersätt den med den poolen utfärdade.

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

Läs rutt och resolver från minerarens egen kontext

Routing och namnutslagning gäller per namespace, så en kontroll som körs i ett vanligt skal beskriver fel maskin när mineraren är containeriserad. Gå in i namespacet först och fråga sedan vilket gränssnitt som skulle bära ett paket till pooladressen och vilken resolver som skulle svara för dess värdnamn. Värdens svar överförs inte, och gapet mellan dem är en vanlig källa till felplacerad skuld.

Namnge gränssnittet du får: tunneln betyder att sessionen är på den avsedda vägen, medan den fysiska länken betyder att en regel matchade tidigare än du förväntade dig. Prefixlängden avgör först, sedan metric, sedan policyregler, så en tabell med flera standardposter duplicerar inte paket, den förlorar bara.

Resolvers misslyckas separat från rutter. En tunnel som skriver om /etc/resolv.conf kan lämna namespacet pekande på en resolver som bara nås inifrån tunneln, vilket misslyckas innan någon TCP-handskakning sker. Slå upp poolens värdnamn inne i namespacet och jämför det med den publicerade adressen. Om uppslaget tar timeout eller ger något annat, åtgärda uppslagningen innan du rör rutterna.

Håll poolklienten och nodlyssnaren åtskilda

Port 8333 är Bitcoin Cores peer-port, där en fullständig nod lyssnar efter inkommande anslutningar; en poolminerare behöver den aldrig öppen, och att öppna den reparerar inte ett utgående fel. Inkommande lyssnare och utgående sessioner är motsatta roller med motsatta förtroendeantaganden. Inget i en minerares konfiguration binder den porten, så en stängd port kan inte förklara något fel den rapporterar. Råd skrivna för en nods nåbarhet kan därför lämna en offentlig tjänst körande på en värd som bara skulle skicka in shares.

Om en maskin verkligen gör båda, behandla varje roll som en egen tjänst med ett eget åtkomstbeslut. Nodens lyssnare hör bakom den policy du tillämpar på offentliga tjänster, och minerarens session hör till den egress-policy som väljer tunneln. Anteckna vilken roll värden spelar och ta bort den andra rollens regler när det ändras, eftersom en kvarlämnad allow-regel överlever sin anledning.

Bevisa att poolen tog emot arbetet

En flitig fläkt och en stigande hashrate visar att mineraren räknar, inte att något nådde poolen. Beviset finns i klientens insändningstäljare eller på poolens instrumentpanel: accepterade shares, avvisade shares och orsaken som hör till varje avvisning. De siffrorna skiljer tre fel som ser identiska ut utifrån: ingen session, en session utan kredit och en session som fortsätter återansluta. Läs dem innan du ändrar någon konfiguration.

Titta på ett anslutningsförsök med utförlig loggning och notera det sista steget som lyckades. Steget där sekvensen stannar är mer användbart än något enskilt meddelande runt det:

Låt sedan klienten köra ett fast fönster och räkna båda utfallen i dess logg. En grep per räknare räcker, och att jämföra dem över samma fönster skiljer en långsam pool från en trasig väg. Anpassa sökvägen till där din klient skriver, eftersom de två räkningarna inte beror på platsen:

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

Om en regel förbjuder en direkt poolanslutning när tunneln faller, uttryck den som en explicit blockering på pool-endpointen. En klient som tyst försöker igen över den fysiska länken fortsätter mina och fortsätter bryta mot regeln, och dess statusdisplay nämner det inte. Testa regeln genom att släppa tunneln med avsikt och bekräfta att poolporten inte går att nå alls.