Bányászpool VPN-en át: tartsd a munkamenetet a helyes úton

A bányászprogram egyetlen socketet tart nyitva egyetlen cím felé, és az alagútra, az útvonalra és a jóváírt munkára vonatkozó minden kérdés ezen a socketen lóg. Ez a socket egy kimenő kliens-munkamenet a pool végpontja felé, nem pedig egy peereket fogadó figyelő. Az alábbi végigvezetés a pool által kiadott négy értéktől egy olyan share-ig követi, amelyet a pool ténylegesen elkönyvelt, és a gazdagép többi szolgáltatását békén hagyja. Minden lépés összehasonlítható választ ad, nem benyomást.

A pool által ténylegesen kiadott végponttól indulj

A pool négy értéket ad át, amelyek az egész szerződést alkotják: hosztnév vagy cím, port, protokollváltozat és fiókstring. Ezeket a pool irányítópultjáról vagy bevezető üzenetéből vedd, ne egy másik poolhoz írt útmutatóból. Ugyanahhoz a szolgáltatáshoz léteznek regionális shardok, így egy régi útmutatóból másolt hosztnév még mindig csatlakozhat, és még mindig jóváírhat egy fiókot, amelyet soha nem akartál használni. Másold a négy értéket szó szerint a bányász konfigurációjába, mert az újragépelt fiókstring elveszít egy elválasztót.

A forgalom, amelyet irányítasz, az, amelyet a Bitcoin fejlesztői útmutatója Stratum-munkamenetnek nevez: egy tartós kétirányú TCP-kapcsolat, amelyben a pool munkát oszt ki, a bányász pedig share-eket küld vissza. Ez nem ugyanaz a forgalom, mint egy teljes csomópont peer-kapcsolatai vagy egy tárca láncszinkronizálása, és épp az, hogy ezeket egyetlen forgalmi osztályba hajtjuk, az, ahol a legtöbb zavar kezdődik. Csak az első tartozik e politika alá.

Ahol a pool TLS-t kínál, tartsd meg a dokumentációja által előírt szerverellenőrzést. Az alagút titkosítja az ugrást a gépedtől a VPN-kiszolgálóig, és ott véget ér; nem kezeskedik azért, aki a túloldalon válaszol. Tartsd meg mindkét ellenőrzést, egyet-egyet mindkét végén, ha azt akarod, hogy a munkamenet túléljen egy kompromittált kilépést.

Az alagutat a folyamathoz rögzítsd, ne a háztartáshoz

Két rögzítési pont működik: futtasd a VPN-klienst abban a hálózati névtérben, amelyet a bányász használ, vagy adj annak a névtérnek egy átjárót, amely a forgalmát beviszi az alagútba. Mindkét elrendezés a pool előtti pályára teszi a munkamenetet. A szokásos hiba egy kliens a gazdagépen, egy bányász a saját hídjával rendelkező konténerben, és egy gazdagép-útvonal, amelyet a konténer soha nem kérdez. Az ügyfélablak egészségesnek látszik, miközben a pool az otthoni címedet rögzíti.

Ellenőrizd az alagút saját szállítását, mielőtt bármit körülhatárolnál. A kliensnek az alaprétegen keresztül kell elérnie a szerverét, így az a szabály, amely minden csomagot elkap, azokat a csomagokat is elkapja, amelyek felépítenék az alagutat. Akkor az alagút nem tud elindulni, és semmi más sem megy ki. A kliens split-tunneling funkciójával válaszd ki, mi kerüljön az alagútba; az alapértelmezett útvonalak kézi szerkesztése az, ahogy az alapréteg eltűnik.

Ha a szabály a helyén van, olvasd ki a socket-táblát abban a névtérben, amelyhez a bányász tartozik. A pool portja felé menő forgalomnak az alagút interfészén kell ülnie, és két parancs válaszol erre a kérdésre. Az alábbi port példa; helyettesítsd azzal, amelyet a pool kiadott.

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

Az útvonalat és a feloldót a bányász saját kontextusából olvasd

Az útválasztás és a névfeloldás névtérre vonatkozik, így egy közönséges héjban futtatott ellenőrzés a rossz gépet írja le, valahányszor a bányász konténerben fut. Először lépj be a névtérbe, aztán kérdezd meg, melyik interfész vinné a csomagot a pool címére, és melyik feloldó válaszolna a hosztnevére. A gazdagép válaszai nem adódnak át, és a kettő közti különbség a rossz helyre tett vádaskodás gyakori forrása.

Nevezd meg a kapott interfészt: az alagút azt jelenti, hogy a munkamenet a szándékolt úton van, míg a fizikai kapcsolat azt, hogy egy szabály korábban illeszkedett, mint vártad. A prefixhossz dönt először, aztán a metrika, aztán a házirend-szabályok, tehát a több alapértelmezett bejegyzést tartalmazó tábla nem duplikálja a csomagokat, csak veszít.

A feloldók külön hibáznak az útvonalaktól. Egy alagút, amely átírja a /etc/resolv.conf fájlt, olyan feloldóra irányíthatja a névteret, amely csak az alagút belsejéből érhető el, és ez még azelőtt hibázik, hogy bármilyen TCP-kézfogás megtörténne. Oldd fel a pool hosztnevét a névtéren belül, és hasonlítsd össze a közzétett címmel. Ha a lekérdezés lejár vagy mást ad vissza, javítsd a feloldást, mielőtt az útvonalakhoz nyúlnál.

Tartsd külön a poolos klienst és a csomópont figyelőjét

A 8333 port a Bitcoin Core peer-portja, ahol egy teljes csomópont a bejövő kapcsolatokat figyeli; egy poolos bányásznak soha nem kell nyitva tartania, és a megnyitása nem javít ki egy kimenő hibát. A bejövő figyelők és a kimenő munkamenetek ellentétes szerepek, ellentétes bizalmi feltevésekkel. Semmi a bányász konfigurációjában nem köti ehhez a portot, így egy zárt port nem magyarázhat semmilyen hibát, amelyet jelent. Egy csomópont elérhetőségére írt tanács ezért nyitva hagyhat egy nyilvános szolgáltatást egy olyan gazdagépen, amelynek csak share-eket kellett volna beküldenie.

Ha egy gép valóban mindkettőt végzi, kezeld mindegyik szerepet saját szolgáltatásként, saját hozzáférési döntéssel. A csomópont figyelője a nyilvános szolgáltatásokra alkalmazott szabály mögé tartozik, a bányász munkamenete pedig ahhoz a kimenő szabályhoz, amely az alagutat választja. Jegyezd fel, melyik szerepet játssza a gazdagép, és amikor ez változik, távolítsd el a másik szerep szabályait, mert egy ottmaradt engedélyező szabály túléli az okát.

Bizonyítsd, hogy a pool megkapta a munkát

Egy pörgő ventilátor és egy emelkedő hashrate azt mutatja, hogy a bányász számol, nem azt, hogy bármi elérte a poolt. A bizonyíték a kliens beküldési számlálóiban vagy a pool irányítópultján van: elfogadott share-ek, elutasított share-ek és az egyes elutasításokhoz tartozó ok. Ezek a számok három olyan hibát választanak szét, amelyek kívülről azonosnak látszanak: nincs munkamenet, munkamenet jóváírás nélkül, és munkamenet, amely újra és újra csatlakozik. Olvasd el őket, mielőtt bármilyen konfigurációt módosítasz.

Figyelj meg egy kapcsolódási kísérletet részletes naplózással, és jegyezd fel az utolsó sikeres szakaszt. Az a szakasz, ahol a sorrend megáll, hasznosabb, mint bármelyik egyedi üzenet körülötte:

Ezután hagyd a klienst egy rögzített ablakon át futni, és számold meg mindkét kimenetet a naplójából. Egy grep számlálónként elég, és ugyanazon az ablakon összehasonlítva elválasztja a lassú poolt a törött úttól. Igazítsd az útvonalat oda, ahová a kliensed ír, mert a két számolás nem függ a helytől:

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

Ha egy szabály megtiltja a közvetlen poolkapcsolatot, valahányszor az alagút leesik, fejezd ki explicit blokként a pool végpontján. Egy kliens, amely csendben újrapróbál a fizikai kapcsolaton, tovább bányászik és továbbra is megsérti ezt a szabályt, és az állapotkijelzője nem említi. Teszteld a szabályt úgy, hogy szándékosan leejted az alagutat, és megerősíted, hogy a pool portja egyáltalán nem érhető el.