Miningpool over VPN: hald økta på rett veg

Miningprogramvare held éin socket open mot éi adresse, og kvart spørsmål om tunnelen, ruta og det krediterte arbeidet heng på den socketen. Den socketen er ei utgåande klientøkt til eit pool-endepunkt, ikkje ein lyttar som tek imot peers. Gjennomgangen nedanfor følgjer han frå dei fire verdiane poolen sende ut til ein share poolen faktisk førte bok over, og han let dei andre tenestene til verten vera. Kvart steg gjev eit svar du kan samanlikne, ikkje eit inntrykk.

Start ved endepunktet poolen faktisk sende ut

Poolen gjev deg fire verdiar som utgjer heile kontrakten: vertsnamn eller adresse, port, protokollvariant og kontostreng. Ta dei frå dashbordet til poolen eller frå onboardingmeldinga, ikkje frå ei rettleia for ein annan pool. Det finst regionale shards for same tenesta, så eit vertsnamn kopiert frå ei gammal rettleia kan framleis kople til og framleis kreditere ein konto du aldri meinte å bruke. Kopier dei fire verdiane ordrett inn i konfigurasjonen til minaren, for ein kontostreng som blir skriven på nytt mistar eit skiljeteikn.

Straumen du rutar, er den Bitcoins utviklarrettleia kallar ei Stratum-økt: ei varig tovegs TCP-tilkopling der poolen fordeler arbeid og minaren returnerer shares. Det er ikkje same straumen som peer-tilkoplingane til ein full node eller kjedesynkroniseringa til ei lommebok, og å brette dei saman i éin trafikkklasse er der det meste av forvirringa byrjar. Berre den første høyrer under denne policyen.

Der poolen tilbyr TLS, hald på serververifiseringa som dokumentasjonen krev. Ein tunnel krypterer hoppet frå maskina di til VPN-serveren og sluttar der; han garanterer ikkje for den som svarar på andre sida. Hald på begge kontrollane, éin i kvar ende, om du vil at økta skal overleve ein kompromittert utgang.

Fest tunnelen til prosessen, ikkje til husstanden

To festepunkt fungerer: køyr VPN-klienten inne i namnerommet minaren brukar, eller gje det namnerommet ein gateway som ber trafikken inn i tunnelen. Begge oppsetta set økta på vegen før poolen ser ho. Den vanlege feilen er ein klient på verten, ein minar i ein container med eiga bru og ei vertsrute containeren aldri spør. Klientvindauget ser friskt ut medan poolen registrerer heimeadressa di.

Kontroller eigen transport i tunnelen før du avgrensar noko. Klienten må nå serveren sin gjennom underlaget, så ein policy som fangar kvar pakke fangar også pakkane som ville byggje tunnelen. Då kan ikkje tunnelen starte, og ingenting anna slepp ut heller. Vel med split-tunneling-funksjonen til klienten kva som går inn i tunnelen; å redigere standardruter for hand er korleis underlaget forsvinn.

Når policyen er på plass, les socket-tabellen i namnerommet som eig minaren. Straumen til poolporten bør liggje på tunnegrensesnittet, og to kommandoar svarar på det spørsmålet. Porten nedanfor er eit døme; byt inn den poolen sende ut.

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 frå den eigen konteksten til minaren

Ruting og namneoppslag gjeld per namnerom, så ein kontroll køyrd i eit vanleg skall skildrar feil maskin når minaren er containerisert. Gå inn i namnerommet først og spør deretter kva grensesnitt som ville bere ein pakke til pooladressa og kva resolver som ville svare for vertsnamnet. Svara til verten blir ikkje overførte, og gapet mellom dei er ei vanleg kjelde til feilplassert skuld.

Namngje grensesnittet du får: tunnelen tyder at økta er på den tiltenkte vegen, medan den fysiske lenkja tyder at ei regel trefte tidlegare enn du venta. Prefikslengda avgjer først, deretter metric, deretter policyreglar, så ein tabell med fleire standardoppføringar dupliserer ikkje pakkar, han taper berre.

Resolverar feilar åtskilt frå ruter. Ein tunnel som skriv om /etc/resolv.conf, kan la namnerommet peike på ein resolver som berre er nåbar innanfrå tunnelen, noko som feilar før nokon TCP-handshake skjer. Slå opp vertsnamnet til poolen inne i namnerommet og samanlikn det med den publiserte adressa. Viss oppslaget fell på tid eller gjev noko anna, fiks oppslaget før du rører rutene.

Hald poolklienten og nodelyttaren frå kvarandre

Port 8333 er peer-porten til Bitcoin Core, der ein full node lyttar etter innkommande tilkoplingar; ein poolminar treng han aldri open, og å opne han reparerer ikkje ein utgåande feil. Innkommande lyttarar og utgåande økter er motsette roller med motsette tillitsantakingar. Ingenting i konfigurasjonen til ein minar bind den porten, så ein lukka port kan ikkje forklare nokon feil han rapporterer. Råd skrivne for tilgjengelegheita til ein node kan difor la ei offentleg teneste køyre på ein vert som berre skulle sende inn shares.

Viss éin maskin verkeleg gjer begge delar, handsam kvar rolle som si eiga teneste med si eiga tilgangsavgjerd. Lyttaren til noden høyrer til bak policyen du brukar på offentlege tenester, og økta til minaren høyrer til egress-policyen som vel tunnelen. Noter kva rolle verten spelar og fjern reglane til den andre rolla når det endrar seg, for ein gløymd allow-regel overlever grunngjevinga si.

Prov at poolen tok imot arbeidet

Ein travel vifte og ein stigande hashrate viser at minaren reknar, ikkje at noko nådde poolen. Beviset ligg i innsendingsteljarane til klienten eller på dashbordet til poolen: aksepterte shares, avviste shares og årsaka knytt til kvar avvising. Tala skil tre feil som ser identiske ut utanfrå: inga økt, ei økt utan kreditt og ei økt som held fram med å kople til på nytt. Les dei før du endrar nokon konfigurasjon.

Sjå på eitt tilkoplingsforsøk med utførleg logging og noter det siste trinnet som lukkast. Trinnet der sekvensen stoppar, er nyttigare enn noka einskild melding rundt det:

Lat deretter klienten køyre eit fast vindauge og tel begge utfalla i loggen. Éin grep per teljar er nok, og å samanlikne dei over same vindauge skil ein treg pool frå ein øydelagd veg. Tilpass vegen til der klienten skriv, sidan dei to teljingane ikkje avheng av plasseringa:

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

Viss ei regel forbyr direkte pooltilkopling når tunnelen fell, uttrykk det som ein eksplisitt blokkering på pool-endepunktet. Ein klient som stille prøver på nytt over den fysiske lenkja, held fram med å mine og held fram med å bryte regelen, og statusvisinga nemner det ikkje. Test regelen ved å sleppe tunnelen med vilje og stadfeste at poolporten ikkje kan nåast i det heile.