Miningpool via VPN: de sessie op het juiste pad houden

Miningssoftware houdt één socket open naar één adres, en elke vraag over de tunnel, de route en het gecrediteerde werk hangt aan die socket. Die socket is een uitgaande clientsessie naar een pool-endpoint, geen listener die peers accepteert. De wandeling hieronder volgt hem van de vier waarden die de pool uitgaf tot een share die de pool daadwerkelijk boekte, en laat de andere diensten van de host met rust. Elke stap levert een antwoord op dat u kunt vergelijken, geen indruk.

Begin bij het endpoint dat de pool werkelijk uitgaf

De pool geeft u vier waarden die het hele contract vormen: hostnaam of adres, poort, protocolvariant en accountstring. Haal ze uit het dashboard van de pool of uit het onboardingbericht, niet uit een handleiding voor een andere pool. Er bestaan regionale shards voor dezelfde dienst, dus een hostnaam uit een oude gids kan nog steeds verbinden en nog steeds een account crediteren dat u nooit wilde gebruiken. Kopieer de vier waarden letterlijk in de configuratie van de miner, want een opnieuw getypte accountstring verliest een scheidingsteken.

De stroom die u routeert is degene die de Bitcoin-ontwikkelaarsgids een Stratumsessie: een persistente tweerichtings-TCP-verbinding waarin de pool werk verdeelt en de miner shares teruggeeft. Dat is niet dezelfde stroom als de peer-verbindingen van een volledige node of de ketensynchronisatie van een wallet, en ze in één verkeersklasse samenvouwen is waar de meeste verwarring begint. Alleen de eerste hoort onder dit beleid.

Waar de pool TLS biedt, houdt u de serververificatie die zijn documentatie vereist. Een tunnel versleutelt de hop van uw machine naar de VPN-server en eindigt daar; hij staat niet garant voor wie aan de andere kant antwoordt. Houd beide controles, één aan elk uiteinde, als u wilt dat de sessie een gecompromitteerde uitgang overleeft.

Hang de tunnel aan het proces, niet aan het huishouden

Twee bevestigingspunten werken: voer de VPN-client uit in de netwerknamespace die de miner gebruikt, of geef die namespace een gateway die zijn verkeer de tunnel in draagt. Beide opstellingen zetten de sessie op het pad voordat de pool hem ziet. De gebruikelijke fout is een client op de host, een miner in een container met een eigen bridge en een hostroute die de container nooit raadpleegt. Het clientvenster ziet er gezond uit terwijl de pool uw thuisadres registreert.

Controleer het eigen transport van de tunnel voordat u iets afbakent. De client moet zijn server via de underlay bereiken, dus een beleid dat elk pakket onderschept, onderschept ook de pakketten die de tunnel zouden opbouwen. Dan kan de tunnel niet starten en gaat er ook niets anders naar buiten. Kies met de split-tunnelingfunctie van de client wat de tunnel in gaat; standaardroutes met de hand bewerken is hoe de underlay verdwijnt.

Met het beleid op zijn plaats leest u de sockettabel in de namespace die de miner bezit. De stroom naar de poolpoort hoort op de tunnelinterface te staan, en twee opdrachten beantwoorden die vraag. De poort hieronder is een voorbeeld; vervang hem door degene die de pool uitgaf.

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

Lees route en resolver uit de eigen context van de miner

Routing en naamresolutie zijn per namespace, dus een controle in een gewone shell beschrijft de verkeerde machine zodra de miner in een container draait. Betreed eerst de namespace en vraag dan welke interface een pakket naar het pooladres zou dragen en welke resolver voor zijn hostnaam zou antwoorden. De antwoorden van de host gaan niet over, en de kloof ertussen is een veelvoorkomende bron van verkeerd geplaatste schuld.

Noem de interface die u krijgt: de tunnel betekent dat de sessie op het bedoelde pad zit, terwijl de fysieke link betekent dat een regel eerder overeenkwam dan u verwachtte. De prefixlengte beslist eerst, dan de metriek, dan de beleidsregels, dus een tabel met meerdere standaarditems dupliceert geen pakketten, hij verliest gewoon.

Resolvers falen apart van routes. Een tunnel die /etc/resolv.conf herschrijft, kan de namespace naar een resolver laten wijzen die alleen van binnen de tunnel bereikbaar is, wat mislukt voordat er enige TCP-handshake plaatsvindt. Los de poolhostnaam op binnen de namespace en vergelijk die met het gepubliceerde adres. Als de lookup verloopt of iets anders teruggeeft, repareer dan de resolutie voordat u routes aanraakt.

Houd de poolclient en de nodelistener gescheiden

Poort 8333 is de peer-poort van Bitcoin Core, waar een volledige node op inkomende verbindingen luistert; een poolminer heeft hem nooit open nodig, en hem openen repareert geen uitgaande fout. Inkomende listeners en uitgaande sessies zijn tegengestelde rollen met tegengestelde vertrouwensannahmen. Niets in de configuratie van een miner bindt die poort, dus een gesloten poort kan geen fout verklaren die hij meldt. Advies dat voor de bereikbaarheid van een node is geschreven, kan daarom een publieke dienst laten draaien op een host die alleen shares hoorde in te dienen.

Als één machine echt beide doet, behandel elke rol dan als een eigen dienst met een eigen toegangsbeslissing. De listener van de node hoort achter het beleid dat u op publieke diensten toepast, en de sessie van de miner hoort bij het egress-beleid dat de tunnel kiest. Leg vast welke rol de host speelt en verwijder de regels van de andere rol wanneer dat verandert, want een achtergebleven allow-regel overleeft zijn reden.

Bewijs dat de pool het werk ontving

Een drukke ventilator en een stijgende hashrate laten zien dat de miner rekent, niet dat er iets de pool bereikte. Het bewijs zit in de inzendtellers van de client of op het dashboard van de pool: geaccepteerde shares, geweigerde shares en de reden bij elke weigering. Die getallen scheiden drie fouten die er van buiten identiek uitzien: geen sessie, een sessie zonder credit en een sessie die blijft herverbinden. Lees ze voordat u welke configuratie dan ook wijzigt.

Bekijk één verbindingspoging met uitgebreide logging en noteer de laatste fase die slaagde. De fase waar de reeks stopt is nuttiger dan welk afzonderlijk bericht eromheen ook:

Laat de client daarna een vast venster draaien en tel beide uitkomsten uit zijn log. Eén grep per teller is genoeg, en ze over hetzelfde venster vergelijken scheidt een trage pool van een kapot pad. Pas het pad aan naar waar uw client schrijft, want de twee tellingen hangen niet van de locatie af:

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

Als een regel een directe poolverbinding verbiedt zodra de tunnel wegvalt, druk die dan uit als een expliciete blokkade op het pool-endpoint. Een client die stilletjes via de fysieke link opnieuw probeert, blijft minen en blijft die regel overtreden, en zijn statusdisplay zal het niet vermelden. Test de regel door de tunnel expres te laten vallen en te bevestigen dat de poolpoort helemaal niet bereikbaar is.