Mynbouprogrammatuur hou een sok aan een adres oop, en elke vraag oor die tonnel, die roete en die gekrediteerde werk hang aan daardie sok. Daardie sok is 'n uitgaande kliëntsessie na 'n poel-eindpunt, nie 'n luisteraar wat eweknieë aanvaar nie. Die wandeling hieronder volg dit van die vier waardes wat die poel uitgereik het tot 'n aandeel wat die poel werklik geboek het, en dit laat die gasheer se ander dienste alleen. Elke stap lewer 'n antwoord wat jy kan vergelyk, nie 'n indruk nie.

Begin by die eindpunt wat die poel werklik uitgereik het

Die poel gee jou vier waardes wat die hele kontrak vorm: gasheernaam of adres, poort, protokolvariant en rekeningstring. Neem hulle uit die poel se paneelbord of uit die verwelkomingsboodskap, nie uit 'n tutoriaal vir 'n ander poel nie. Daar bestaan streekshardings vir dieselfde diens, so 'n gasheernaam wat uit 'n ou gids gekopieer is, kan steeds verbind en steeds 'n rekening krediteer wat jy nooit bedoel het om te gebruik nie. Kopieer die vier waardes letterlik in die myner se konfigurasie, want 'n hergetikte rekeningstring verloor 'n skeier.

Die stroom wat jy aanstuur, is die een wat die Bitcoin-ontwikkelaarsgids 'n Stratum-sessie noem: 'n aanhoudende tweerigting-TCP-verbinding waarin die poel werk versprei en die myner aandele terugstuur. Dit is nie dieselfde stroom as 'n volle nodus se eweknie-verbindings of 'n beursie se ketting-sinkronisasie nie, en om hulle in een verkeersklas te vou, is waar die meeste verwarring begin. Net die eerste val onder hierdie beleid.

Waar die poel TLS bied, behou die bedienerverifikasie wat sy dokumentasie vereis. 'n Tonnel versleutel die hop van jou masjien na die VPN-bediener en eindig daar; dit waarborg nie vir wie ook al aan die ander kant antwoord nie. Behou albei kontroles, een aan elke kant, as jy wil hê die sessie moet 'n gekompromitteerde uitgang oorleef.

Heg die tonnel aan die proses, nie aan die huishouding nie

Twee aanhegpunte werk: hardloop die VPN-kliënt in die netwerk-naamruimte wat die myner gebruik, of gee daardie naamruimte 'n poort wat sy verkeer in die tonnel dra. Albei reëlings plaas die sessie op die pad voordat die poel dit sien. Die gewone fout is 'n kliënt op die gasheer, 'n myner in 'n houer met sy eie brug en 'n gasheerroete wat die houer nooit raadpleeg nie. Die kliëntvenster lyk gesond terwyl die poel jou tuisadres aanteken.

Kontroleer die tonnel se eie vervoer voordat jy enigiets afbaken. Die kliënt moet sy bediener deur die onderlaag bereik, so 'n beleid wat elke pakkie vang, vang ook die pakkies wat die tonnel sou bou. Dan kan die tonnel nie begin nie en niks anders gaan ook uit nie. Kies met die kliënt se split-tonnel-funksie wat in die tonnel ingaan; om verstekroetes met die hand te redigeer, is hoe die onderlaag verdwyn.

Met die beleid in plek, lees die sokkentabel in die naamruimte waaraan die myner behoort. Die stroom na die poel se poort moet op die tonnel-koppelvlak sit, en twee opdragte beantwoord daardie vraag. Die poort hieronder is 'n voorbeeld; vervang dit met die een wat die poel uitgereik het.

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 roete en oplosser uit die myner se eie konteks

Roetering en naamoplossing geld per naamruimte, so 'n kontrole wat in 'n gewone skulp uitgevoer word, beskryf die verkeerde masjien wanneer die myner in 'n houer is. Gaan eers die naamruimte in en vra dan watter koppelvlak 'n pakkie na die poeladres sou dra en watter oplosser vir sy gasheernaam sou antwoord. Die gasheer se antwoorde dra nie oor nie, en die gaping tussen hulle is 'n algemene bron van verkeerd geplaasde skuld.

Noem die koppelvlak wat jy kry: die tonnel beteken die sessie is op die beoogde pad, terwyl die fisiese skakel beteken 'n reël het vroeër ooreengekom as wat jy verwag het. Die voorvoegsellengte besluit eerste, dan die metriek, dan die beleidsreëls, so 'n tabel met verskeie verstekinskrywings dupliseer nie pakkies nie, dit verloor net.

Oplossers misluk apart van roetes. 'n Tonnel wat /etc/resolv.conf herskryf, kan die naamruimte na 'n oplosser laat wys wat net van binne die tonnel bereikbaar is, wat misluk voordat enige TCP-handdruk plaasvind. Los die poel se gasheernaam binne die naamruimte op en vergelyk dit met die gepubliseerde adres. As die opsoek verstryk of iets anders teruggee, herstel die oplossing voordat jy roetes aanraak.

Hou die poel-kliënt en die nodus-luisteraar apart

Poort 8333 is Bitcoin Core se eweknie-poort, waar 'n volle nodus op inkomende verbindings luister; 'n poel-myner het dit nooit oop nodig nie, en om dit oop te maak herstel nie 'n uitgaande fout nie. Inkomende luisteraars en uitgaande sessies is teenoorgestelde rolle met teenoorgestelde vertrouensveronderstellings. Niks in 'n myner se konfigurasie bind daardie poort nie, so 'n geslote poort kan geen fout verklaar wat dit rapporteer nie. Advies wat vir 'n nodus se bereikbaarheid geskryf is, kan dus 'n openbare diens laat loop op 'n gasheer wat net aandele moes indien.

As een masjien werklik albei doen, behandel elke rol as sy eie diens met sy eie toegangsbesluit. Die nodus se luisteraar hoort agter die beleid wat jy op openbare dienste toepas, en die myner se sessie hoort by die uitgangsbeleid wat die tonnel kies. Teken aan watter rol die gasheer speel en verwyder die ander rol se reëls wanneer dit verander, want 'n oorblywende toelaatreël oorleef sy rede.

Bewys dat die poel die werk ontvang het

’n Besige waaier en 'n stygende hashrate wys die myner bereken, nie dat iets die poel bereik het nie. Die bewys lê in die kliënt se indieningstellers of op die poel se paneelbord: aanvaarde aandele, verworpe aandele en die rede wat by elke verwerping aangeheg is. Daardie syfers skei drie foute wat van buite identies lyk: geen sessie nie, 'n sessie sonder krediet en 'n sessie wat aanhou herverbind. Lees hulle voordat jy enige konfigurasie verander.

Kyk na een verbindingspoging met breedvoerige logboeke en let op die laaste stadium wat geslaag het. Die stadium waar die volgorde stop, is nuttiger as enige enkele boodskap daaromheen:

Last stage reachedWhat it rules outProbe to run next
Name lookup completedResolver and namespace reachabilityip route get for the returned address
TCP connect completedRoute and egress filteringss -tnp on the tunnel interface
Subscription returned a jobEndpoint or protocol mismatchAccepted against rejected counts

Laat die kliënt dan 'n vaste venster loop en tel albei uitkomste uit sy log. Een grep per teller is genoeg, en om hulle oor dieselfde venster te vergelyk, skei 'n stadige poel van 'n gebreekte pad. Pas die pad aan na waar jou kliënt skryf, want die twee tellings hang nie van die ligging af nie:

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

As 'n reël 'n direkte poelverbinding verbied elke keer wanneer die tonnel val, druk dit uit as 'n eksplisiete blokkade op die poel se eindpunt. 'n Kliënt wat stil oor die fisiese skakel weer probeer, sal aanhou myn en aanhou daardie reël oortree, en sy statusvertoning sal dit nie noem nie. Toets die reël deur die tonnel doelbewus te laat val en te bevestig dat die poel se poort glad nie bereikbaar is nie.

Verwante artikels