Louhintapooli VPN:n yli: pidä istunto oikealla polulla

Louhintaohjelmisto pitää yhden pistokkeen auki yhteen osoitteeseen, ja jokainen tunnelia, reittiä ja hyvitettyä työtä koskeva kysymys riippuu siitä pistokkeesta. Se pistoke on lähtevä asiakasistunto poolin päätepisteeseen, ei vertaisia vastaanottava kuuntelija. Alla oleva kulkureitti seuraa sitä neljästä arvosta, jotka pooli antoi, shareen, jonka pooli todella kirjasi, ja se jättää isännän muut palvelut rauhaan. Jokainen vaihe tuottaa vastauksen, jonka voi vertailla, ei vaikutelmaa.

Aloita päätepisteestä, jonka pooli todella antoi

Pooli antaa neljä arvoa, jotka muodostavat koko sopimuksen: isäntänimi tai osoite, portti, protokollavariantti ja tilitunniste. Ota ne poolin hallintapaneelista tai käyttöönottoviestistä, ei toisen poolin ohjeesta. Samalle palvelulle on alueellisia shardeja, joten vanhasta oppaasta kopioitu isäntänimi voi yhä yhdistää ja yhä hyvittää tiliä, jota et koskaan tarkoittanut käyttää. Kopioi neljä arvoa sellaisenaan louhijan asetuksiin, sillä uudelleen kirjoitettu tilitunniste menettää erottimen.

Liikennevirta, jota reitität, on se, jota Bitcoinin kehittäjäopas kutsuu nimellä Stratum-istunto: pysyvä kaksisuuntainen TCP-yhteys, jossa pooli jakaa työtä ja louhija palauttaa shareja. Se ei ole sama virta kuin täyden solmun vertaisyhteydet tai lompakon ketjusynkronointi, ja niiden taittaminen yhteen liikenneluokkaan on se, mistä suurin osa sekaannuksesta alkaa. Vain ensimmäinen kuuluu tämän käytännön alle.

Kun pooli tarjoaa TLS:ää, pidä dokumentaation vaatima palvelinvarmennus. Tunneli salaa hypyn koneeltasi VPN-palvelimelle ja päättyy siihen; se ei takaa sitä, kuka vastaa toisella puolella. Pidä molemmat tarkistukset, yksi kummassakin päässä, jos haluat istunnon kestävän kompromettoituneen ulostulon.

Kiinnitä tunneli prosessiin, ei kotitalouteen

Kaksi kiinnityspistettä toimii: aja VPN-asiakasohjelma nimiavaruudessa, jota louhija käyttää, tai anna sille nimiavaruudelle yhdyskäytävä, joka vie sen liikenteen tunneliin. Kumpi tahansa järjestely asettaa istunnon polulle ennen kuin pooli näkee sen. Tavallinen virhe on asiakasohjelma isännällä, louhija omalla sillallaan olevassa kontissa ja isännän reitti, jota kontti ei koskaan kysy. Asiakasohjelman ikkuna näyttää terveeltä, kun pooli kirjaa kotiosoitteesi.

Tarkista tunnelin oma kuljetus ennen kuin rajaat mitään. Asiakasohjelman on päästävä palvelimelleen aliverkon kautta, joten käytäntö, joka kaappaa jokaisen paketin, kaappaa myös paketit, jotka rakentaisivat tunnelin. Silloin tunneli ei voi käynnistyä, eikä mitään muutakaan lähde ulos. Valitse asiakasohjelman split tunneling -toiminnolla, mikä menee tunneliin; oletusreittien muokkaaminen käsin on se, miten aliverkko katoaa.

Kun käytäntö on paikallaan, lue pistoketaulukko nimiavaruudesta, joka omistaa louhijan. Poolin porttiin menevä virta pitäisi olla tunnelin rajapinnalla, ja kaksi komentoa vastaa tähän kysymykseen. Alla oleva portti on esimerkki; vaihda tilalle se, jonka pooli antoi.

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

Lue reitti ja resolveri louhijan omasta kontekstista

Reititys ja nimien selvitys ovat nimiavaruuskohtaisia, joten tavallisessa kuoressa ajettu tarkistus kuvaa väärää konetta aina, kun louhija on kontitettu. Astu ensin nimiavaruuteen ja kysy sitten, mikä rajapinta veisi paketin poolin osoitteeseen ja mikä resolveri vastaisi sen isäntänimestä. Isännän vastaukset eivät siirry, ja niiden välinen ero on tavallinen syy väärin kohdistettuun syyllisyyteen.

Nimeä saamasi rajapinta: tunneli tarkoittaa, että istunto on aiotulla polulla, kun taas fyysinen linkki tarkoittaa, että sääntö osui aikaisemmin kuin odotit. Etuliitteen pituus ratkaisee ensin, sitten metriikka, sitten käytäntösäännöt, joten taulukko, jossa on useita oletusmerkintöjä, ei monista paketteja, se vain häviää.

Resolverit epäonnistuvat erikseen reiteistä. Tunneli, joka kirjoittaa uudelleen /etc/resolv.conf, voi jättää nimiavaruuden osoittamaan resolveriin, joka on saavutettavissa vain tunnelin sisältä, mikä epäonnistuu ennen kuin yhtään TCP-kättelyä tapahtuu. Selvitä poolin isäntänimi nimiavaruuden sisällä ja vertaa sitä julkaistuun osoitteeseen. Jos haku aikakatkaistaan tai palauttaa jotain muuta, korjaa selvitys ennen kuin kosket reitteihin.

Pidä pooliasiakasohjelma ja solmun kuuntelija erillään

Portti 8333 on Bitcoin Coren vertaisportti, jossa täysi solmu kuuntelee saapuvia yhteyksiä; poolilouhija ei koskaan tarvitse sitä auki, eikä sen avaaminen korjaa lähtevää vikaa. Saapuvat kuuntelijat ja lähtevät istunnot ovat vastakkaisia rooleja, joilla on vastakkaiset luottamusoletukset. Mikään louhijan asetuksissa ei sido tuota porttia, joten suljettu portti ei voi selittää mitään sen raportoimaa virhettä. Solmun saavutettavuudelle kirjoitettu neuvo voi siksi jättää julkisen palvelun pyörimään isännälle, jonka piti vain lähettää shareja.

Jos yksi kone todella tekee molempia, käsittele kumpaakin roolia omana palvelunaan omalla pääsypäätöksellään. Solmun kuuntelija kuuluu julkisiin palveluihin soveltamasi käytännön taakse, ja louhijan istunto kuuluu lähtevään käytäntöön, joka valitsee tunnelin. Kirjaa, mitä roolia isäntä pelaa, ja poista toisen roolin säännöt, kun se muuttuu, sillä jäljelle jäänyt sallintasääntö elää perusteensa yli.

Todista, että pooli vastaanotti työn

Kiireinen tuuletin ja nouseva hashrate osoittavat, että louhija laskee, ei että mitään saapui poolille. Todiste on asiakasohjelman lähetyslaskureissa tai poolin hallintapaneelissa: hyväksytyt sharet, hylätyt sharet ja kunkin hylkäyksen syy. Ne luvut erottavat kolme vikaa, jotka näyttävät ulkopuolelta samoilta: ei istuntoa, istunto ilman hyvitystä ja istunto, joka yhdistää jatkuvasti uudelleen. Lue ne ennen kuin muutat mitään asetuksia.

Seuraa yhtä yhteysyritystä yksityiskohtaisella lokituksella ja kirjaa viimeinen vaihe, joka onnistui. Vaihe, jossa sarja pysähtyy, on hyödyllisempi kuin mikään yksittäinen viesti sen ympärillä:

Anna asiakasohjelman sitten käydä kiinteä ikkuna ja laske molemmat lopputulokset sen lokista. Yksi grep laskuria kohden riittää, ja niiden vertaaminen saman ikkunan yli erottaa hitaan poolin rikkinäisestä polusta. Mukauta polku siihen, mihin asiakasohjelmasi kirjoittaa, koska kaksi laskentaa eivät riipu sijainnista:

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

Jos sääntö kieltää suoran pooliyhteyden aina kun tunneli putoaa, ilmaise se nimenomaisena estona poolin päätepisteessä. Asiakasohjelma, joka hiljaa yrittää uudelleen fyysisen linkin kautta, jatkaa louhimista ja rikkoo sääntöä edelleen, eikä sen tilanäyttö mainitse sitä. Testaa sääntö pudottamalla tunneli tahallaan ja vahvistamalla, ettei poolin porttiin pääse lainkaan.