Miningpool over VPN: hold økten på riktig sti

Miningsprogramvare holder én socket åpen mot én adresse, og hvert spørsmål om tunnelen, ruten og det krediterte arbeidet henger på den socketen. Den socketen er en utgående klientøkt til et pool-endepunkt, ikke en lytter som tar imot peers. Gjennomgangen nedenfor følger den fra de fire verdiene poolen utstedte til en share poolen faktisk bokførte, og den lar vertens andre tjenester være i fred. Hvert trinn gir et svar du kan sammenligne, ikke et inntrykk.

Start ved endepunktet poolen faktisk utstedte

Poolen gir deg fire verdier som utgjør hele kontrakten: vertsnavn eller adresse, port, protokollvariant og kontostreng. Ta dem fra poolens dashbord eller onboardingmelding, ikke fra en veiledning for en annen pool. Det finnes regionale shards for samme tjeneste, så et vertsnavn kopiert fra en gammel guide kan fortsatt koble til og fortsatt kreditere en konto du aldri mente å bruke. Kopier de fire verdiene ordrett inn i minerens konfigurasjon, for en kontostreng som skrives på nytt mister et skilletegn.

Strømmen du ruter, er den Bitcoins utviklerveiledning kaller en Stratum-økt: en vedvarende toveis TCP-forbindelse der poolen fordeler arbeid og mineren returnerer shares. Det er ikke samme strøm som en full nodes peer-forbindelser eller en lommeboks kjedessynkronisering, og å folde dem sammen i én trafikkklasse er der det meste av forvirringen starter. Bare den første hører under denne policyen.

Der poolen tilbyr TLS, behold serververifiseringen dokumentasjonen krever. En tunnel krypterer hoppet fra maskinen din til VPN-serveren og slutter der; den garanterer ikke for den som svarer på andre siden. Behold begge kontrollene, én i hver ende, hvis du vil at økten skal overleve en kompromittert utgang.

Fest tunnelen til prosessen, ikke til husstanden

To festepunkter fungerer: kjør VPN-klienten inne i navnerommet mineren bruker, eller gi det navnerommet en gateway som bærer trafikken inn i tunnelen. Begge oppsettene setter økten på stien før poolen ser den. Den vanlige feilen er en klient på verten, en miner i en container med egen bro og en vertsrute containeren aldri spør. Klientvinduet ser friskt ut mens poolen registrerer hjemadressen din.

Kontroller tunnelens egen transport før du avgrenser noe. Klienten må nå serveren sin gjennom underlaget, så en policy som fanger hver pakke fanger også pakkene som ville bygge tunnelen. Da kan ikke tunnelen starte, og ingenting annet slipper ut heller. Velg med klientens split-tunneling-funksjon hva som går inn i tunnelen; å redigere standardruter for hånd er hvordan underlaget forsvinner.

Med policyen på plass, les socket-tabellen i navnerommet som eier mineren. Strømmen til poolporten bør ligge på tunnegrensesnittet, og to kommandoer svarer på det spørsmålet. Porten nedenfor er et eksempel; bytt inn den poolen utstedte.

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

Les rute og resolver fra minerens egen kontekst

Ruting og navneoppslag gjelder per navnerom, så en kontroll kjørt i et vanlig skall beskriver feil maskin når mineren er containerisert. Gå inn i navnerommet først og spør deretter hvilket grensesnitt som ville bære en pakke til pooladressen og hvilken resolver som ville svare for vertsnavnet. Vertens svar overføres ikke, og gapet mellom dem er en vanlig kilde til feilplassert skyld.

Navngi grensesnittet du får: tunnelen betyr at økten er på den tiltenkte stien, mens den fysiske lenken betyr at en regel traff tidligere enn du forventet. Prefikslengden avgjør først, deretter metric, deretter policyregler, så en tabell med flere standardoppføringer dupliserer ikke pakker, den taper bare.

Resolvere feiler atskilt fra ruter. En tunnel som skriver om /etc/resolv.conf, kan la navnerommet peke på en resolver som bare er nåbar innenfra tunnelen, noe som feiler før noen TCP-håndtrykk skjer. Slå opp poolens vertsnavn inne i navnerommet og sammenlign det med den publiserte adressen. Hvis oppslaget timer ut eller gir noe annet, fiks oppslaget før du rører rutene.

Hold poolklienten og nodelytteren fra hverandre

Port 8333 er Bitcoin Cores peer-port, der en full node lytter etter innkommende forbindelser; en poolminer trenger den aldri åpen, og å åpne den reparerer ikke en utgående feil. Innkommende lyttere og utgående økter er motsatte roller med motsatte tillitsantakelser. Ingenting i en miners konfigurasjon binder den porten, så en lukket port kan ikke forklare noen feil den rapporterer. Råd skrevet for en nodes tilgjengelighet kan derfor la en offentlig tjeneste kjøre på en vert som bare skulle sende inn shares.

Hvis én maskin virkelig gjør begge deler, behandle hver rolle som sin egen tjeneste med sin egen tilgangsbeslutning. Nodens lytter hører til bak policyen du bruker på offentlige tjenester, og minerens økt hører til egress-policyen som velger tunnelen. Noter hvilken rolle verten spiller og fjern den andre rollens regler når det endrer seg, for en gjenglemt allow-regel overlever begrunnelsen sin.

Bevis at poolen mottok arbeidet

En travel vifte og en stigende hashrate viser at mineren regner, ikke at noe nådde poolen. Beviset ligger i klientens innsendelsestellere eller på poolens dashbord: aksepterte shares, avviste shares og årsaken knyttet til hver avvisning. Tallene skiller tre feil som ser identiske ut utenfra: ingen økt, en økt uten kreditt og en økt som fortsetter å koble til på nytt. Les dem før du endrer noen konfigurasjon.

Se på ett tilkoblingsforsøk med utførlig logging og noter det siste trinnet som lyktes. Trinnet der sekvensen stopper, er mer nyttig enn noen enkelt melding rundt det:

La deretter klienten kjøre et fast vindu og tell begge utfallene i loggen. Én grep per teller er nok, og å sammenligne dem over samme vindu skiller en treg pool fra en ødelagt sti. Tilpass stien til der klienten skriver, siden de to tellingene ikke avhenger av plasseringen:

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

Hvis en regel forbyr direkte pooltilkobling når tunnelen faller, uttrykk det som en eksplisitt blokkering på pool-endepunktet. En klient som stille prøver på nytt over den fysiske lenken, fortsetter å mine og fortsetter å bryte regelen, og statusvisningen nevner det ikke. Test regelen ved å slippe tunnelen med vilje og bekrefte at poolporten ikke kan nås i det hele tatt.