Minada baseno per VPN: tenu la sean sur la ĝusta vojo

Minada programaro tenas unu ingon malfermita al unu adreso, kaj ĉiu demando pri la tunelo, la vojo kaj la kreditita laboro pendas de tiu ingo. Tiu ingo estas elira klienta seanco al basena finpunkto, ne aŭskultanto kiu akceptas peer-ojn. La suba irado sekvas ĝin de la kvar valoroj kiujn la baseno eldonis ĝis parto kiun la baseno vere registris, kaj ĝi lasas la aliajn servojn de la gastiganto trankvilaj. Ĉiu paŝo produktas respondon kiun vi povas kompari, ne impreson.

Komencu de la finpunkto kiun la baseno vere eldonis

La baseno donas al vi kvar valorojn kiuj formas la tutan kontrakton: gastigantnomon aŭ adreson, pordon, protokolan varianton kaj kontan ĉenon. Prenu ilin el la panelo de la baseno aŭ el la bonvena mesaĝo, ne el lernilo por alia baseno. Ekzistas regionaj eroj por la sama servo, do gastigantnomo kopiita el malnova gvidilo ankoraŭ povas konektiĝi kaj ankoraŭ povas krediti konton kiun vi neniam intencis uzi. Kopiu la kvar valorojn laŭlitere en la agordon de la ministo, ĉar retajpita konta ĉeno perdas apartigilon.

La fluo kiun vi enkursigas estas tiu kiun la Bitcoin-evoluiga gvidilo nomas Stratum-sean: daŭra dudirekta TCP-konekto en kiu la baseno disdonas laboron kaj la ministo redonas partojn. Tio ne estas la sama fluo kiel la peer-konektoj de plena nodo aŭ la ĉen-sinkronigo de monujo, kaj ĝuste ilia kunfaldo en unu trafikan klason estas kie plej multo de la konfuzo komenciĝas. Nur la unua apartenas al ĉi tiu politiko.

Kie la baseno ofertas TLS, tenu la servilan kontrolon kiun ĝia dokumentaro postulas. Tunelo ĉifras la salton de via maŝino al la VPN-servilo kaj finiĝas tie; ĝi ne garantias por tiu kiu respondas aliflanke. Tenu ambaŭ kontrolojn, unu ĉe ĉiu fino, se vi volas ke la seanco postvivu kompromititan eliron.

Fiksu la tunelon al la procezo, ne al la domanaro

Du fikspunktoj funkcias: rulu la VPN-klienton ene de la reta nomspaco kiun la ministo uzas, aŭ donu al tiu nomspaco pordegon kiu portas ĝian trafikon en la tunelon. Ambaŭ aranĝoj metas la seancon sur la vojon antaŭ ol la baseno vidas ĝin. La kutima malsukceso estas kliento sur la gastiganto, ministo en ujo kun propra ponto kaj gastiganta vojo kiun la ujo neniam konsultas. La klienta fenestro aspektas sana dum la baseno registras vian hejman adreson.

Kontrolu la propran transporton de la tunelo antaŭ ol vi limigi ion ajn. La kliento devas atingi sian servilon tra la suba tavolo, do politiko kiu kaptas ĉiun paketon kaptas ankaŭ la paketojn kiuj konstruus la tunelon. Tiam la tunelo ne povas starti kaj nenio alia eliras ankaŭ. Elektu per la disigita-tunela funkcio de la kliento kio eniras la tunelon; redakti defaŭltajn vojojn permane estas kiel la suba tavolo malaperas.

Kiam la politiko estas en loko, legu la ingan tabelon en la nomspaco al kiu la ministo apartenas. La fluo al la basena pordo devus sidi sur la tunela interfaco, kaj du komandoj respondas al tiu demando. La suba pordo estas ekzemplo; anstataŭigu ĝin per tiu kiun la baseno eldonis.

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

Legu vojon kaj solvilon el la propra kunteksto de la ministo

Enkursigado kaj nom-solvado estas po nomspaco, do kontrolo rulita en ordinara ŝelo priskribas la malĝustan maŝinon kiam ajn la ministo estas en ujo. Eniru la nomspacon unue kaj poste demandu kiun interfacon portus paketon al la basena adreso kaj kiun solvilon respondus por ĝia gastigantnomo. La respondoj de la gastiganto ne transiĝas, kaj la breĉo inter ili estas ofta fonto de mise lokita kulpo.

Nomu la interfacon kiun vi ricevas: la tunelo signifas ke la seanco estas sur la celita vojo, dum la fizika ligilo signifas ke regulo kongruis pli frue ol vi atendis. La prefiksa longo decidas unue, poste la metriko, poste la politikaj reguloj, do tabelo kun pluraj defaŭltaj enskriboj ne duobligas paketojn, ĝi simple perdas.

Solviloj malsukcesas aparte de vojoj. Tunelo kiu reskribas /etc/resolv.conf povas lasi la nomspacon montranta al solvilo atingebla nur el la interno de la tunelo, kio malsukcesas antaŭ ol iu TCP-manpremo okazas. Solvu la basenan gastigantnomon ene de la nomspaco kaj komparu ĝin kun la publikigita adreso. Se la serĉo finiĝas pro tempolimo aŭ redonas ion alian, riparu la solvadon antaŭ ol tuŝi vojojn.

Tenu la basenan klienton kaj la nodan aŭskultanton aparte

Pordo 8333 estas la peer-pordo de Bitcoin Core, kie plena nodo aŭskultas envenantajn konektojn; basena ministo neniam bezonas ĝin malfermita, kaj malfermi ĝin ne riparas eliran difekton. Envenantaj aŭskultantoj kaj eliraj seancoj estas kontraŭaj roloj kun kontraŭaj fidaj supozoj. Nenio en la agordo de ministo ligas tiun pordon, do fermita pordo ne povas klarigi ajnan eraron kiun ĝi raportas. Konsilo skribita por la atingeblo de nodo do povas lasi publikan servon funkcianta sur gastiganto kiu devis nur sendi partojn.

Se unu maŝino vere faras ambaŭ, traktu ĉiun rolon kiel propran servon kun propra alirdecido. La aŭskultanto de la nodo apartenas malantaŭ la politiko kiun vi aplikas al publikaj servoj, kaj la seanco de la ministo apartenas al la elira politiko kiu elektas la tunelon. Notu kiun rolon la gastiganto ludas kaj forigu la regulojn de la alia rolo kiam tio ŝanĝiĝas, ĉar restinta permesa regulo postvivas sian kaŭzon.

Pruvu ke la baseno ricevis la laboron

Okupata ventolilo kaj supreniranta hashrate montras ke la ministo kalkulas, ne ke io atingis la basenon. La pruvo kuŝas en la sendaj nombriloj de la kliento aŭ sur la panelo de la baseno: akceptitaj partoj, malakceptitaj partoj kaj la kaŭzo alkroĉita al ĉiu malakcepto. Tiuj nombroj apartigas tri difektojn kiuj aspektas identaj de ekstere: neniu seanco, seanco sen kredito kaj seanco kiu konstante rekonektiĝas. Legu ilin antaŭ ol ŝanĝi ajnan agordon.

Observu unu konektoprovon kun detala protokolado kaj notu la lastan etapon kiu sukcesis. La etapo kie la sinsekvo haltas estas pli utila ol iu unuopa mesaĝo ĉirkaŭ ĝi:

Poste lasu la klienton ruli fiksan fenestron kaj kalkulu ambaŭ rezultojn el ĝia protokolo. Unu grep po nombrilo sufiĉas, kaj kompari ilin super la sama fenestro apartigas malrapidan basenon de rompita vojo. Adaptu la vojon al tio kie via kliento skribas, ĉar la du kalkuloj ne dependas de la loko:

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

Se regulo malpermesas rektan basenan konekton ĉiufoje kiam la tunelo falas, esprimu ĝin kiel klaran blokadon ĉe la basena finpunkto. Kliento kiu silente reprovas tra la fizika ligilo daŭrigos mini kaj daŭrigos malobservi tiun regulon, kaj ĝia stata montrilo ne mencios tion. Testu la regulon per intenca faligo de la tunelo kaj konfirmo ke la basena pordo tute ne atingeblas.