Těžební pool přes VPN: udržet relaci na správné cestě

Těžební software drží jeden socket otevřený na jednu adresu a každá otázka o tunelu, trase a započtené práci visí na tom socketu. Ten socket je odchozí klientská relace ke koncovému bodu poolu, ne posluchač, který přijímá peery. Procházka níže ho sleduje od čtyř hodnot, které pool vydal, k podílu, který pool skutečně zaúčtoval, a ostatních služeb hostitele si nevšímá. Každý krok dává odpověď, kterou lze porovnat, ne dojem.

Začněte u koncového bodu, který pool skutečně vydal

Pool vám předá čtyři hodnoty, které tvoří celou smlouvu: název hostitele nebo adresu, port, variantu protokolu a řetězec účtu. Vezměte je z panelu poolu nebo z uvítací zprávy, ne z návodu pro jiný pool. Pro tutéž službu existují regionální shardy, takže název hostitele zkopírovaný ze starého průvodce se může stále připojit a stále připsat účet, který jste nikdy nechtěli použít. Zkopírujte čtyři hodnoty doslova do konfigurace mineru, protože přepsaný řetězec účtu ztratí oddělovač.

Tok, který směrujete, je ten, který průvodce vývojáře Bitcoinu nazývá relace Stratum: trvalé obousměrné TCP spojení, ve kterém pool rozděluje práci a miner vrací podíly. To není stejný tok jako peer spojení plného uzlu nebo synchronizace řetězce peněženky, a právě skládání těchto toků do jedné třídy provozu je místem, kde začíná většina zmatku. Pod tuto politiku patří jen první z nich.

Kde pool nabízí TLS, ponechte ověření serveru, které jeho dokumentace vyžaduje. Tunel šifruje skok z vašeho počítače na server VPN a tam končí; neručí za to, kdo odpovídá na druhé straně. Ponechte obě kontroly, jednu na každém konci, pokud má relace přežít kompromitovaný výstup.

Připoutejte tunel k procesu, ne k domácnosti

Fungují dva body připojení: spusťte klienta VPN ve jmenném prostoru sítě, který miner používá, nebo tomuto jmennému prostoru dejte bránu, která nese jeho provoz do tunelu. Obě uspořádání staví relaci na cestu dřív, než ji pool uvidí. Obvyklé selhání je klient na hostiteli, miner v kontejneru s vlastním mostem a trasa hostitele, kterou kontejner nikdy nekonzultuje. Okno klienta vypadá zdravě, zatímco pool zaznamenává vaši domácí adresu.

Zkontrolujte vlastní transport tunelu, než cokoli vymezíte. Klient musí dosáhnout svého serveru přes podloží, takže politika, která zachytí každý paket, zachytí i pakety, které by tunel postavily. Pak tunel nemůže nastartovat a nic jiného také neodejde. Vyberte funkcí split tunelingu klienta, co do tunelu vstoupí; ruční úprava výchozích tras je způsob, jakým podloží zmizí.

Když je politika na místě, přečtěte tabulku socketů ve jmenném prostoru, kterému miner patří. Tok na port poolu má sedět na rozhraní tunelu a na tuto otázku odpovídají dva příkazy. Port níže je příklad; dosaďte ten, který 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

Čtěte trasu a resolver z vlastního kontextu mineru

Směrování a překlad jmen platí pro jmenný prostor, takže kontrola spuštěná v běžném shellu popisuje špatný stroj, kdykoli je miner v kontejneru. Nejprve vstupte do jmenného prostoru a potom se ptejte, které rozhraní by neslo paket na adresu poolu a který resolver by odpovídal za jeho název hostitele. Odpovědi hostitele se nepřenášejí a propast mezi nimi je častým zdrojem špatně umístěné viny.

Pojmenujte rozhraní, které dostanete: tunel znamená, že relace je na zamýšlené cestě, zatímco fyzické spojení znamená, že pravidlo odpovídalo dřív, než jste čekali. Nejdřív rozhoduje délka prefixu, potom metrika, potom pravidla politiky, takže tabulka s několika výchozími položkami pakety neduplikuje, jen prohrává.

Resolver selhává odděleně od tras. Tunel, který přepisuje /etc/resolv.conf, může nechat jmenný prostor ukazovat na resolver dostupný jen zevnitř tunelu, což selže dřív, než dojde k jakémukoli TCP handshake. Vyřešte název hostitele poolu uvnitř jmenného prostoru a porovnejte ho s publikovanou adresou. Pokud dotaz vyprší nebo vrátí něco jiného, opravte překlad dřív, než se dotknete tras.

Držte poolového klienta a posluchač uzlu odděleně

Port 8333 je peer port Bitcoin Core, kde plný uzel naslouchá příchozím spojením; poolový miner ho nikdy nepotřebuje otevřený a otevření neopraví odchozí selhání. Příchozí posluchače a odchozí relace jsou opačné role s opačnými předpoklady důvěry. Nic v konfiguraci mineru ten port neváže, takže zavřený port nemůže vysvětlit žádnou chybu, kterou hlásí. Rada psaná pro dosažitelnost uzlu proto může nechat veřejnou službu běžet na hostiteli, který měl jen odesílat podíly.

Pokud jeden stroj opravdu dělá obojí, berte každou roli jako vlastní službu s vlastním rozhodnutím o přístupu. Posluchač uzlu patří za politiku, kterou uplatňujete na veřejné služby, a relace mineru patří k výstupní politice, která vybírá tunel. Zaznamenejte, jakou roli hostitel hraje, a když se to změní, odstraňte pravidla druhé role, protože zbylé povolovací pravidlo přežije svůj důvod.

Dokažte, že pool práci přijal

Zaneprázdněný ventilátor a rostoucí hashrate ukazují, že miner počítá, ne že něco dorazilo do poolu. Důkaz je v počítadlech odesílání klienta nebo na panelu poolu: přijaté podíly, odmítnuté podíly a důvod u každého odmítnutí. Ta čísla oddělují tři selhání, která zvenku vypadají stejně: žádná relace, relace bez zápočtu a relace, která se pořád znovu připojuje. Přečtěte je, než změníte jakoukoli konfiguraci.

Sledujte jeden pokus o připojení s podrobným logováním a poznamenejte poslední fázi, která uspěla. Fáze, ve které se sekvence zastaví, je užitečnější než jakákoli jednotlivá zpráva kolem ní:

Pak nechte klienta běžet pevné okno a spočítejte oba výsledky z jeho logu. Jeden grep na počítadlo stačí a jejich porovnání ve stejném okně oddělí pomalý pool od rozbité cesty. Přizpůsobte cestu tomu, kam klient zapisuje, protože obě počítání nezávisí na umístění:

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

Pokud pravidlo zakazuje přímé připojení k poolu pokaždé, když tunel spadne, vyjádřete to jako výslovnou blokaci koncového bodu poolu. Klient, který tiše zkouší znovu přes fyzické spojení, bude dál těžit a dál to pravidlo porušovat, a jeho stavový displej to nezmíní. Otestujte pravidlo tím, že tunel schválně shodíte a potvrdíte, že port poolu není vůbec dosažitelný.