Ťažobný pool cez VPN: udržať reláciu na správnej ceste

Ťažobný softvér drží jeden socket otvorený na jednu adresu a každá otázka o tuneli, trase a započítanej práci visí na tom sockete. Ten socket je odchádzajúca klientska relácia ku koncovému bodu poolu, nie poslucháč, ktorý prijíma peerov. Prechádzka nižšie ho sleduje od štyroch hodnôt, ktoré pool vydal, k podielu, ktorý pool skutočne zaúčtoval, a ostatných služieb hostiteľa si nevšíma. Každý krok dáva odpoveď, ktorú možno porovnať, nie dojem.

Začnite pri koncovom bode, ktorý pool skutočne vydal

Pool vám odovzdá štyri hodnoty, ktoré tvoria celú zmluvu: názov hostiteľa alebo adresu, port, variant protokolu a reťazec účtu. Vezmite ich z panela poolu alebo z uvítacej správy, nie z návodu pre iný pool. Pre tú istú službu existujú regionálne shardy, takže názov hostiteľa skopírovaný zo starého sprievodcu sa môže stále pripojiť a stále pripísať účet, ktorý ste nikdy nechceli použiť. Skopírujte štyri hodnoty doslova do konfigurácie mineru, pretože prepísaný reťazec účtu stratí oddeľovač.

Tok, ktorý smerujete, je ten, ktorý sprievodca vývojára Bitcoinu nazýva relácia Stratum: trvalé obojsmerné TCP spojenie, v ktorom pool rozdeľuje prácu a miner vracia podiely. To nie je rovnaký tok ako peer spojenia plného uzla alebo synchronizácia reťazca peňaženky, a práve skladanie týchto tokov do jednej triedy prevádzky je miestom, kde začína väčšina zmätku. Pod túto politiku patrí len prvý z nich.

Kde pool ponúka TLS, ponechajte overenie servera, ktoré vyžaduje jeho dokumentácia. Tunel šifruje skok z vášho počítača na server VPN a tam končí; neručí za to, kto odpovedá na druhej strane. Ponechajte obe kontroly, jednu na každom konci, ak má relácia prežiť kompromitovaný výstup.

Pripútajte tunel k procesu, nie k domácnosti

Fungujú dva body pripútania: spustite klienta VPN v mennom priestore siete, ktorý miner používa, alebo tomuto mennému priestoru dajte bránu, ktorá nesie jeho prevádzku do tunela. Obe usporiadania stavajú reláciu na cestu skôr, než ju pool uvidí. Zvyčajné zlyhanie je klient na hostiteľovi, miner v kontajneri s vlastným mostom a trasa hostiteľa, ktorú kontajner nikdy nekonzultuje. Okno klienta vyzerá zdravo, zatiaľ čo pool zaznamenáva vašu domácu adresu.

Skontrolujte vlastnú dopravu tunela, skôr než čokoľvek vymedzíte. Klient musí dosiahnuť svoj server cez podložie, takže politika, ktorá zachytí každý paket, zachytí aj pakety, ktoré by tunel postavili. Potom tunel nemôže naštartovať a nič iné tiež neodíde. Vyberte funkciou split tunelingu klienta, čo do tunela vstúpi; ručná úprava predvolených trás je spôsob, akým podložie zmizne.

Keď je politika na mieste, prečítajte tabuľku socketov v mennom priestore, ktorému miner patrí. Tok na port poolu má sedieť na rozhraní tunela a na túto otázku odpovedajú dva príkazy. Port nižšie je príklad; dosaďte ten, ktorý pool vydal.

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

Čítajte trasu a resolver z vlastného kontextu mineru

Smerovanie a preklad mien platia pre menný priestor, takže kontrola spustená v bežnom shelli opisuje nesprávny stroj, vždy keď je miner v kontajneri. Najprv vstúpte do menného priestoru a potom sa pýtajte, ktoré rozhranie by nieslo paket na adresu poolu a ktorý resolver by odpovedal za jeho názov hostiteľa. Odpovede hostiteľa sa neprenášajú a priepasť medzi nimi je častým zdrojom nesprávne umiestnenej viny.

Pomenujte rozhranie, ktoré dostanete: tunel znamená, že relácia je na zamýšľanej ceste, zatiaľ čo fyzické spojenie znamená, že pravidlo odpovedalo skôr, než ste čakali. Najprv rozhoduje dĺžka prefixu, potom metrika, potom pravidlá politiky, takže tabuľka s niekoľkými predvolenými položkami pakety neduplikuje, len prehráva.

Resolver zlyháva oddelene od trás. Tunel, ktorý prepisuje /etc/resolv.conf, môže nechať menný priestor ukazovať na resolver dostupný len zvnútra tunela, čo zlyhá skôr, než dôjde k akémukoľvek TCP handshake. Vyriešte názov hostiteľa poolu vnútri menného priestoru a porovnajte ho s publikovanou adresou. Ak dotaz vyprší alebo vráti niečo iné, opravte preklad skôr, než sa dotknete trás.

Držte poolového klienta a poslucháč uzla oddelene

Port 8333 je peer port Bitcoin Core, kde plný uzol načúva prichádzajúcim spojeniam; poolový miner ho nikdy nepotrebuje otvorený a otvorenie neopraví odchádzajúce zlyhanie. Prichádzajúce poslucháče a odchádzajúce relácie sú opačné role s opačnými predpokladmi dôvery. Nič v konfigurácii mineru ten port neviaže, takže zavretý port nemôže vysvetliť žiadnu chybu, ktorú hlási. Rada písaná pre dosiahnuteľnosť uzla preto môže nechať verejnú službu bežať na hostiteľovi, ktorý mal len odosielať podiely.

Ak jeden stroj naozaj robí oboje, berte každú rolu ako vlastnú službu s vlastným rozhodnutím o prístupe. Poslucháč uzla patrí za politiku, ktorú uplatňujete na verejné služby, a relácia mineru patrí k výstupnej politike, ktorá vyberá tunel. Zaznamenajte, akú rolu hostiteľ hrá, a keď sa to zmení, odstráňte pravidlá druhej role, pretože zvyšné povoľovacie pravidlo prežije svoj dôvod.

Dokážte, že pool prácu prijal

Zaneprázdnený ventilátor a rastúci hashrate ukazujú, že miner počíta, nie že niečo dorazilo do poolu. Dôkaz je v počítadlách odosielania klienta alebo na paneli poolu: prijaté podiely, odmietnuté podiely a dôvod pri každom odmietnutí. Tie čísla oddeľujú tri zlyhania, ktoré zvonku vyzerajú rovnako: žiadna relácia, relácia bez zápočtu a relácia, ktorá sa stále znovu pripája. Prečítajte ich, než zmeníte akúkoľvek konfiguráciu.

Sledujte jeden pokus o pripojenie s podrobným logovaním a poznamenajte poslednú fázu, ktorá uspela. Fáza, v ktorej sa sekvencia zastaví, je užitočnejšia než akákoľvek jednotlivá správa okolo nej:

Potom nechajte klienta bežať pevné okno a spočítajte oba výsledky z jeho logu. Jeden grep na počítadlo stačí a ich porovnanie v rovnakom okne oddelí pomalý pool od rozbitej cesty. Prispôsobte cestu tomu, kam klient zapisuje, pretože obe počítania nezávisia od umiestnenia:

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

Ak pravidlo zakazuje priame pripojenie k poolu zakaždým, keď tunel spadne, vyjadrite to ako výslovnú blokáciu koncového bodu poolu. Klient, ktorý ticho skúša znova cez fyzické spojenie, bude ďalej ťažiť a ďalej to pravidlo porušovať, a jeho stavový displej to nezmieni. Otestujte pravidlo tým, že tunel schválne zhodíte a potvrdíte, že port poolu nie je vôbec dosiahnuteľný.