Pool ng pagmimina sa VPN: itago ang sesyon sa tamang landas

Ang software ng pagmimina ay nagpapanatili ng isang socket na bukas sa isang address, at bawat tanong tungkol sa tunnel, ruta at na-kreditong trabaho ay nakasabit sa socket na iyon. Ang socket na iyon ay isang papalabas na sesyon ng kliyente patungo sa endpoint ng pool, hindi isang listener na tumatanggap ng peer. Sinusundan ito ng lakad sa ibaba mula sa apat na halagang inilabas ng pool hanggang sa share na aktuwal na naitala ng pool, at hindi ginagalaw ang ibang serbisyo ng host. Bawat hakbang ay gumagawa ng sagot na maihahambing mo, hindi isang impresyon.

Magsimula sa endpoint na aktuwal na inilabas ng pool

Binibigyan ka ng pool ng apat na halaga na bumubuo sa buong kontrata: pangalan ng host o address, port, variant ng protocol at string ng account. Kunin ang mga ito mula sa dashboard ng pool o sa mensahe ng onboarding, hindi mula sa tutorial para sa ibang pool. May mga rehiyonal na shard para sa parehong serbisyo, kaya ang pangalan ng host na kinopya mula sa lumang gabay ay maaari pa ring kumonekta at maaari pa ring magkredito ng account na hindi mo kailanman pinlanong gamitin. Kopyahin ang apat na halaga nang eksakto sa configuration ng miner, dahil ang string ng account na muling na-type ay nawawalan ng separator.

Ang daloy na iniruruta mo ay ang tinatawag ng gabay ng developer ng Bitcoin na sesyong Stratum: isang tuloy-tuloy na two-way na koneksyong TCP kung saan ipinamimigay ng pool ang trabaho at ibinabalik ng miner ang share. Hindi ito ang parehong daloy ng mga koneksyon ng peer ng isang buong node o ng chain sync ng isang wallet, at ang pagtiklop sa kanila sa isang klase ng trapiko ang pinagmumulan ng karamihan ng kalituhan. Ang una lamang ang kabilang sa patakarang ito.

Kung saan nag-aalok ng TLS ang pool, panatilihin ang pagpapatunay ng server na hinihiling ng dokumentasyon nito. Ang tunnel ay nag-encrypt ng hop mula sa iyong makina patungo sa server ng VPN at nagtatapos doon; hindi ito nananagot para sa sinumang sumasagot sa kabilang dulo. Panatilihin ang dalawang pagsusuri, isa sa bawat dulo, kung gusto mong mabuhay ang sesyon matapos ang kompromisadong labasan.

Ikabit ang tunnel sa proseso, hindi sa sambahayan

Dalawang punto ng pagkabit ang gumagana: patakbuhin ang kliyente ng VPN sa loob ng namespace ng network na ginagamit ng miner, o bigyan ang namespace na iyon ng gateway na nagdadala ng trapiko nito sa tunnel. Ang alinman sa dalawang ayos ay naglalagay ng sesyon sa landas bago pa ito makita ng pool. Ang karaniwang kabiguan ay isang kliyente sa host, isang miner sa container na may sariling tulay at isang rutang host na hindi kailanman kinukonsulta ng container. Mukhang malusog ang window ng kliyente habang itinatala ng pool ang iyong address sa bahay.

Suriin ang sariling transport ng tunnel bago mo limitahan ang anuman. Kailangang maabot ng kliyente ang server nito sa pamamagitan ng underlay, kaya ang patakarang humuhuli sa bawat packet ay humuhuli rin sa mga packet na bubuo ng tunnel. Kung gayon hindi makakapagsimula ang tunnel at wala ring lumalabas. Piliin gamit ang split tunnel na tampok ng kliyente kung ano ang pumapasok sa tunnel; ang manu-manong pag-edit ng default na ruta ang paraan ng pagkawala ng underlay.

Kapag nasa lugar na ang patakaran, basahin ang talahanayan ng socket sa namespace na pag-aari ng miner. Ang daloy patungo sa port ng pool ay dapat nasa interface ng tunnel, at dalawang utos ang sumasagot sa tanong na iyon. Ang port sa ibaba ay isang halimbawa; palitan ng inilabas ng 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

Basahin ang ruta at resolver mula sa sariling konteksto ng miner

Ang routing at paglutas ng pangalan ay bawat namespace, kaya ang pagsusuring tumatakbo sa ordinaryong shell ay naglalarawan ng maling makina tuwing nasa container ang miner. Pumasok muna sa namespace at pagkatapos itanong kung aling interface ang magdadala ng packet patungo sa address ng pool at aling resolver ang sasagot para sa pangalan ng host nito. Hindi naglilipat ang mga sagot ng host, at ang agwat sa pagitan nila ay karaniwang pinagmumulan ng maling bintang.

Pangalanan ang interface na nakukuha mo: ang tunnel ay nangangahulugang nasa nilalayong landas ang sesyon, samantalang ang pisikal na link ay nangangahulugang mas maaga ang pagtutugma ng isang patakaran kaysa sa inaasahan mo. Ang haba ng prefix ang unang nagpapasya, pagkatapos ang metric, pagkatapos ang mga patakaran ng patakaran, kaya ang talahanayang may ilang default na entry ay hindi nagdodoble ng packet, natatalo lang.

Bumabagsak ang resolver nang hiwalay sa ruta. Ang tunnel na nagsusulat muli ng /etc/resolv.conf ay maaaring mag-iwan sa namespace na nakaturo sa resolver na maabot lamang mula sa loob ng tunnel, na bumabagsak bago pa mangyari ang anumang TCP handshake. Lutasin ang pangalan ng host ng pool sa loob ng namespace at ihambing sa nailathalang address. Kung nag-time out ang paghahanap o nagbalik ng iba, ayusin ang paglutas bago hawakan ang ruta.

Panatilihing hiwalay ang kliyente ng pool at ang listener ng node

Ang port 8333 ay ang peer port ng Bitcoin Core, kung saan nakikinig ang buong node sa mga papasok na koneksyon; hindi kailanman kailangan ng miner ng pool na bukas ito, at ang pagbubukas nito ay hindi nag-aayos ng papalabas na kabiguan. Ang mga papasok na listener at papalabas na sesyon ay magkasalungat na tungkulin na may magkasalungat na palagay sa tiwala. Wala sa configuration ng miner ang nagbibigkis sa port na iyon, kaya ang saradong port ay hindi maipapaliwanag ang anumang error na iniuulat nito. Ang payong isinulat para sa maabot ng node ay maaaring mag-iwan ng pampublikong serbisyo na tumatakbo sa host na dapat ay nagpapadala lamang ng share.

Kung talagang ginagawa ng isang makina ang dalawa, tratuhin ang bawat tungkulin bilang sariling serbisyo na may sariling desisyon sa pag-access. Ang listener ng node ay kabilang sa likod ng patakarang inilalapat mo sa mga pampublikong serbisyo, at ang sesyon ng miner ay kabilang sa patakarang palabas na pumipili ng tunnel. Itala kung anong tungkulin ang ginagampanan ng host at alisin ang mga patakaran ng kabilang tungkulin kapag nagbago iyon, dahil ang naiwang patakaran ng pahintulot ay nabubuhay nang mas matagal kaysa sa dahilan nito.

Patunayan na natanggap ng pool ang trabaho

Ang abalang bentilador at tumataas na hashrate ay nagpapakita na nagkukuwenta ang miner, hindi na may nakarating sa pool. Ang ebidensya ay nasa mga counter ng pagsumite ng kliyente o sa dashboard ng pool: mga share na tinanggap, mga share na tinanggihan at ang dahilang nakalakip sa bawat pagtanggi. Hinihiwalay ng mga bilang na iyon ang tatlong kabiguang magkamukha mula sa labas: walang sesyon, sesyong walang kredito at sesyong paulit-ulit na kumokonekta. Basahin ang mga ito bago baguhin ang anumang configuration.

Pagmasdan ang isang pagtatangkang kumonekta na may detalyadong logging at itala ang huling yugtong nagtagumpay. Ang yugto kung saan humihinto ang pagkakasunod-sunod ay mas kapaki-pakinabang kaysa sa anumang iisang mensahe sa paligid nito:

Pagkatapos hayaan ang kliyente na tumakbo sa isang takdang window at bilangin ang dalawang kinalabasan mula sa log nito. Sapat na ang isang grep bawat counter, at ang paghahambing sa kanila sa parehong window ay naghihiwalay ng mabagal na pool mula sa sirang landas. Isagawa ang landas sa lugar kung saan nagsusulat ang iyong kliyente, dahil ang dalawang bilang ay hindi nakadepende sa lokasyon:

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

Kung ipinagbabawal ng isang patakaran ang direktang koneksyon sa pool tuwing bumabagsak ang tunnel, ipahayag ito bilang malinaw na pagharang sa endpoint ng pool. Ang kliyenteng tahimik na muling sumusubok sa pisikal na link ay patuloy na magmimina at patuloy na lalabag sa patakarang iyon, at hindi ito babanggitin ng display ng estado nito. Subukan ang patakaran sa pamamagitan ng sadyang pagpapatumba ng tunnel at pagtiyak na hindi talaga maabot ang port ng pool.