Miningpool over VPN: hold sessionen på den rigtige vej

Miningsoftware holder én socket åben mod én adresse, og hvert spørgsmål om tunnelen, ruten og det godskrevne arbejde hænger på den socket. Den socket er en udgående klientsession til et pool-endpoint, ikke en listener, der accepterer peers. Gennemgangen nedenfor følger den fra de fire værdier, poolen udstedte, til en share, poolen faktisk bogførte, og den lader værtens øvrige tjenester være. Hvert trin giver et svar, du kan sammenligne, ikke et indtryk.

Start ved det endpoint, poolen faktisk udstedte

Poolen giver dig fire værdier, som udgør hele kontrakten: værtsnavn eller adresse, port, protokolvariant og kontostreng. Tag dem fra poolens dashboard eller onboardingbesked, ikke fra en vejledning til en anden pool. Der findes regionale shards til den samme tjeneste, så et værtsnavn kopieret fra en gammel guide kan stadig forbinde og stadig godskrive en konto, du aldrig mente at bruge. Kopiér de fire værdier ordret ind i minerens konfiguration, for en genindtastet kontostreng mister en separator.

Den strøm, du router, er den, som Bitcoin-udviklervejledningen kalder en Stratum-session: en vedvarende tovejs TCP-forbindelse, hvor poolen fordeler arbejde, og mineren returnerer shares. Det er ikke den samme strøm som en fuld nodes peer-forbindelser eller en wallets kædesynkronisering, og at folde dem sammen i én trafikklasse er, hvor det meste forvirring begynder. Kun den første hører under denne politik.

Hvor poolen tilbyder TLS, skal du beholde den serververifikation, dens dokumentation kræver. En tunnel krypterer hoppet fra din maskine til VPN-serveren og slutter der; den garanterer ikke for den, der svarer på den anden side. Behold begge kontroller, én i hver ende, hvis du vil have sessionen til at overleve en kompromitteret udgang.

Fastgør tunnelen til processen, ikke til husstanden

To fastgørelsespunkter virker: kør VPN-klienten inde i det netværksnamespace, mineren bruger, eller giv det namespace en gateway, der bærer dens trafik ind i tunnelen. Begge opsætninger sætter sessionen på vejen, før poolen ser den. Den sædvanlige fejl er en klient på værten, en miner i en container med sin egen bridge og en værtsrute, som containeren aldrig konsulterer. Klientvinduet ser sundt ud, mens poolen registrerer din hjemadresse.

Kontrollér tunnelens egen transport, før du afgrænser noget. Klienten skal nå sin server gennem underlaget, så en politik, der fanger hver pakke, fanger også de pakker, der ville bygge tunnelen. Så kan tunnelen ikke starte, og intet andet kommer heller ud. Vælg med klientens split-tunneling-funktion, hvad der går ind i tunnelen; at redigere standardruter i hånden er, hvordan underlaget forsvinder.

Når politikken er på plads, læs sockettabellen i det namespace, der ejer mineren. Strømmen til poolporten bør ligge på tunnelinterfacet, og to kommandoer besvarer det spørgsmål. Porten nedenfor er et eksempel; indsæt den, poolen udstedte.

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

Læs rute og resolver ud fra minerens egen kontekst

Routing og navneopløsning er per namespace, så en kontrol kørt i en almindelig shell beskriver den forkerte maskine, når mineren er containeriseret. Gå først ind i namespacet og spørg så, hvilket interface der ville bære en pakke til pooladressen, og hvilken resolver der ville svare på dens værtsnavn. Værtens svar overføres ikke, og kløften mellem dem er en almindelig kilde til fejlplaceret skyld.

Navngiv det interface, du får: tunnelen betyder, at sessionen er på den tilsigtede vej, mens det fysiske link betyder, at en regel matchede tidligere, end du forventede. Præfikslængden afgør først, derefter metric, derefter politikregler, så en tabel med flere standardposter duplikerer ikke pakker, den taber bare.

Resolvere fejler adskilt fra ruter. En tunnel, der omskriver /etc/resolv.conf, kan efterlade namespacet pegende på en resolver, der kun kan nås indefra tunnelen, hvilket fejler, før nogen TCP-handshake sker. Opløs poolens værtsnavn inde i namespacet og sammenlign det med den offentliggjorte adresse. Hvis opslaget løber ud eller returnerer noget andet, skal du rette opløsningen, før du rører ved ruter.

Hold poolklienten og nodelisteneren adskilt

Port 8333 er Bitcoin Cores peer-port, hvor en fuld node lytter efter indgående forbindelser; en poolminer har aldrig brug for den åben, og at åbne den reparerer ikke en udgående fejl. Indgående listenere og udgående sessioner er modsatte roller med modsatte tillidsantagelser. Intet i en miners konfiguration binder den port, så en lukket port kan ikke forklare nogen fejl, den rapporterer. Råd skrevet til en nodes tilgængelighed kan derfor efterlade en offentlig tjeneste kørende på en vært, der kun skulle indsende shares.

Hvis én maskine virkelig gør begge dele, skal du behandle hver rolle som sin egen tjeneste med sin egen adgangsbeslutning. Nodens listener hører til bag den politik, du anvender på offentlige tjenester, og minerens session hører til egress-politikken, der vælger tunnelen. Noter, hvilken rolle værten spiller, og fjern den anden rolles regler, når det ændrer sig, for en efterladt allow-regel overlever sin begrundelse.

Bevis, at poolen modtog arbejdet

En travl blæser og en stigende hashrate viser, at mineren regner, ikke at noget nåede poolen. Beviset ligger i klientens indsendelsestællere eller på poolens dashboard: accepterede shares, afviste shares og årsagen knyttet til hver afvisning. De tal adskiller tre fejl, der ser identiske ud udefra: ingen session, en session uden kredit og en session, der bliver ved med at genoprette forbindelsen. Læs dem, før du ændrer nogen konfiguration.

Overvåg ét forbindelsesforsøg med udførlig logning, og noter det sidste trin, der lykkedes. Det trin, hvor sekvensen stopper, er mere nyttigt end nogen enkelt besked omkring det:

Lad derefter klienten køre et fast vindue, og tæl begge udfald i dens log. Én grep per tæller er nok, og at sammenligne dem over det samme vindue skiller en langsom pool fra en brudt vej. Tilpas stien til, hvor din klient skriver, da de to tællinger ikke afhænger af placeringen:

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

Hvis en regel forbyder en direkte poolforbindelse, hver gang tunnelen falder, så udtryk det som en eksplicit blokering på pool-endpointet. En klient, der stille prøver igen over det fysiske link, bliver ved med at mine og bliver ved med at overtræde den regel, og dens statusvisning nævner det ikke. Test reglen ved at droppe tunnelen med vilje og bekræfte, at poolporten slet ikke kan nås.