Miningupool VPN-i kaudu: hoia sessioon õigel teel
Pooli mainer avab ühe väljuva Stratum-sessiooni, mitte peer-pordi. Aseta tunnel selle protsessi alla ja loe marsruut ja resolver selle nimeruumist.
Miningutarkvara hoiab ühte socketit avatuna ühe aadressi suunas ja iga küsimus tunneli, marsruudi ja arvestatud töö kohta ripub selle socketi küljes. See socket on väljuv kliendisessioon pooli lõpp-punkti, mitte peer'e vastuvõttev kuulaja. Alljärgnev teekond viib selle pooli väljastatud neljast väärtusest kuni osani, mille pool tegelikult arvele võttis, ja jätab hosti muud teenused puutumata. Iga samm annab vastuse, mida saab võrrelda, mitte mulje.
Alusta lõpp-punktist, mille pool tegelikult väljastas
Pool annab sulle neli väärtust, mis moodustavad kogu lepingu: hostinimi või aadress, port, protokolli variant ja konto string. Võta need pooli armatuurlaualt või onboardingu sõnumist, mitte mõne teise pooli õpetusest. Sama teenuse jaoks on piirkondlikud shardid, seega vanast juhendist kopeeritud hostinimi võib endiselt ühenduda ja endiselt krediteerida kontot, mida sa ei kavatsenud kunagi kasutada. Kopeeri neli väärtust täpselt maineri konfiguratsiooni, sest ümber trükitud konto string kaotab eraldaja.
Voog, mida sa marsruudid, on see, mida Bitcoini arendaja juhend nimetab Stratum-sessiooniks: püsiv kahesuunaline TCP-ühendus, kus pool jagab tööd ja mainer tagastab osi. See ei ole sama voog nagu täissõlme peer-ühendused või rahakoti ahela sünkroonimine, ja just nende kokkuvoldimine ühte liiklusklassi on koht, kust suurem osa segadusest algab. Selle poliitika alla kuulub ainult esimene.
Kus pool pakub TLS-i, säilita serveri kontroll, mida selle dokumentatsioon nõuab. Tunnel krüpteerib hüppe sinu masinast VPN-serverini ja lõpeb seal; see ei garanteeri selle eest, kes vastab teisel pool. Säilita mõlemad kontrollid, üks kummaski otsas, kui tahad, et sessioon jääks ellu kompromiteeritud väljapääsu korral.
Kinnita tunnel protsessi, mitte majapidamise külge
Kaks kinnituspunkti töötavad: käivita VPN-klient võrgu nimeruumis, mida mainer kasutab, või anna sellele nimeruumile lüüs, mis kannab selle liikluse tunnelisse. Mõlemad paigutused panevad sessiooni teele enne, kui pool seda näeb. Tavaline ebaõnnestumine on klient hostil, mainer oma sillaga konteineris ja hosti marsruut, mida konteiner kunagi ei küsi. Kliendi aken näeb terve välja, samal ajal kui pool registreerib sinu koduse aadressi.
Kontrolli tunneli enda transporti enne, kui midagi piirama hakkad. Klient peab jõudma oma serverini aluskihi kaudu, seega poliitika, mis püüab iga paketi, püüab ka paketid, mis ehitaksid tunneli. Siis ei saa tunnel käivituda ja midagi muud ei välju samuti. Vali kliendi jagatud tunneli funktsiooniga, mis tunnelisse läheb; vaikimisi marsruutide käsitsi muutmine on viis, kuidas aluskiht kaob.
Kui poliitika on paigas, loe socketite tabel nimeruumist, kuhu mainer kuulub. Voog pooli pordi suunas peaks olema tunneli liidesel, ja kaks käsku vastavad sellele küsimusele. Allpool olev port on näide; asenda see, mille pool väljastas.
sudo nsenter -t "$(pidof cgminer)" -n ss -tnp state established 'dport = :3333'
sudo nsenter -t "$(pidof cgminer)" -n ip route get 203.0.113.10Loe marsruut ja resolver maineri enda kontekstist
Marsruutimine ja nimelahendus kehtivad nimeruumi kohta, seega tavalises kestas käivitatud kontroll kirjeldab vale masinat, kui mainer on konteineris. Sisene esmalt nimeruumi ja küsi siis, milline liides kannaks paketi pooli aadressile ja milline resolver vastaks selle hostinimele. Hosti vastused ei kandu üle ja nendevaheline lõhe on tavaline valesse kohta pandud süü allikas.
Nimeta liides, mille saad: tunnel tähendab, et sessioon on kavandatud teel, füüsiline link aga seda, et reegel klappis varem, kui ootasid. Prefiksi pikkus otsustab esimesena, siis metric, siis poliitikareeglid, seega mitme vaikekirjega tabel ei dubleeri pakette, see lihtsalt kaotab.
Resolverid ebaõnnestuvad marsruutidest eraldi. Tunnel, mis kirjutab üle /etc/resolv.conf, võib jätta nimeruumi osutama resolverile, mis on kättesaadav ainult tunneli seest, ja see ebaõnnestub enne mis tahes TCP-kätlust. Lahenda pooli hostinimi nimeruumi sees ja võrdle avaldatud aadressiga. Kui päring aegub või tagastab midagi muud, paranda lahendus enne marsruutide puutumist.
Hoia pooli klient ja sõlme kuulaja lahus
Port 8333 on Bitcoin Core'i peer-port, kus täissõlm kuulab sissetulevaid ühendusi; pooli mainer ei vaja seda kunagi avatuna ja selle avamine ei paranda väljuvat riket. Sissetulevad kuulajad ja väljuvad sessioonid on vastandlikud rollid vastandlike usalduseeldustega. Miski maineri konfiguratsioonis ei seo seda porti, seega suletud port ei saa seletada ühtegi viga, mida see teatab. Sõlme kättesaadavuse jaoks kirjutatud nõuanne võib seega jätta avaliku teenuse tööle hostil, mis pidi ainult osi saatma.
Kui üks masin teeb tõesti mõlemat, käsitle kumba rolli eraldi teenusena oma juurdepääsuotsusega. Sõlme kuulaja kuulub avalikele teenustele rakendatava poliitika taha ja maineri sessioon kuulub väljundpoliitikasse, mis valib tunneli. Pane kirja, millist rolli host mängib, ja eemalda teise rolli reeglid, kui see muutub, sest allesjäänud lubamisreegel elab oma põhjuse üle.
Tõesta, et pool sai töö kätte
Hõivatud ventilaator ja tõusev hashrate näitavad, et mainer arvutab, mitte et midagi jõudis pooli. Tõend on kliendi saatmisloendurites või pooli armatuurlaual: vastuvõetud osad, tagasilükatud osad ja iga tagasilükkamise juurde kuuluv põhjus. Need numbrid eraldavad kolme riket, mis väljastpoolt näevad identsed: sessioon puudub, sessioon ilma krediidita ja sessioon, mis pidevalt uuesti ühendub. Loe need enne mis tahes konfiguratsiooni muutmist.
Jälgi üht ühenduskatset üksikasjaliku logimisega ja märgi viimane õnnestunud etapp. Etapp, kus jada peatub, on kasulikum kui ükskõik milline üksik sõnum selle ümber:
| Last stage reached | What it rules out | Probe to run next |
|---|---|---|
| Name lookup completed | Resolver and namespace reachability | ip route get for the returned address |
| TCP connect completed | Route and egress filtering | ss -tnp on the tunnel interface |
| Subscription returned a job | Endpoint or protocol mismatch | Accepted against rejected counts |
Seejärel lase kliendil töötada fikseeritud aken ja loenda selle logist mõlemad tulemused. Üks grep loenduri kohta on piisav ja nende võrdlemine samas aknas eraldab aeglase pooli katkisest teest. Kohanda tee sinna, kuhu sinu klient kirjutab, sest kaks loendust ei sõltu asukohast:
grep -c Accepted /var/log/miner.log
grep -c Rejected /var/log/miner.logKui reegel keelab otsese pooliühenduse iga kord, kui tunnel kukub, väljenda seda selge blokeeringuna pooli lõpp-punktis. Klient, mis vaikselt proovib uuesti füüsilise lingi kaudu, jätkab kaevandamist ja jätkab selle reegli rikkumist ning selle olekunäidik ei maini seda. Testi reeglit, lastes tunnelil meelega kukkuda ja kinnitades, et pooli porti ei ole üldse võimalik saavutada.