Neniuj envenantaj peer-oj sur via Bitcoin-nodo malantaŭ VPN?

Via nodo estas sinkronigita, la VPN diras konektita, kaj getpeerinfo montras ok aŭ dek peer-ojn. Neniu el ili havas inbound agordita al true. Tiu kombino estas normala kaj ne estas difekto: elirantaj konektoj pruvas, ke la nodo povas atingi aliajn, kaj nenio ĉe ili pruvas, ke iu povas atingi vin. Se la celo estas nodo, kiu akceptas envenantajn P2P-konektojn tra VPN, vi devas testi tiun direkton aparte.

Sekvu la paketon de la peer ĝis via aŭskultilo

Envenanta P2P estas ĉeno el kvar aferoj, kaj ĝi rompiĝas ĉe la plej malforta ligo, ne ĉe la plej interesa.

other peer
  -> provider's public address and assigned port
  -> the permitted VPN mapping
  -> Bitcoin Core's P2P listener

La P2P-defaŭlto de Core en la ĉefa reto estas 8333, sed la provizanto povas doni al vi alian publikan pordon kaj alian celon ĉe la klienta flanko. Notu la publikan adreson, la eksteran pordon kaj la lokon, kie la provizanto fakte liveras la trafikon. Poste konfirmu, ke via plano kaj konto entute permesas envenantajn konektojn, ĉar dediĉita elira adreso ne estas pordvarba kontrakto.

Tiu distingo kaptas homojn, kiuj aĉetas statikan IP atendante atingeblon. Tio, ke la adreso estas stabila, diras nenion pri tio, ĉu la provizanto plusendas envenantan pordon al via sesio.

Kontrolu la aŭskultilon antaŭ ol kontroli la provizanton

Core devas aŭskulti ĉe la adreso kaj pordo, al kiuj la mapado liveras, kaj la gastiga fajroŝirmilo devas permesi tion. Se la nodo ruliĝas en ujo aŭ sur alia LAN-maŝino, la sekva salto kaj ĝia respondvojo ankaŭ apartenas al la ĉeno.

Loka fajroŝirmila regulo ne povas krei mapadon ĉe provizanto, kiu forĵetas envenantajn paketojn, kaj provizanta mapado ne povas atingi procezon ligitan nur al loopback. Ambaŭ duonoj devas konsenti pri la sama opo, kaj tial la unua paŝo estas skribi la opon anstataŭ diveni ĝin.

Tenu la anoncitan finpunkton kongrua kun la aktuala mapado. Statika adreso ne igas asignitan pordon aŭ ĝian luon daŭraj tra rekonektoj, do finpunkto publikigita antaŭ monatoj eble nun montras al nenio. Relutu la paĝon de la provizanto post ĉiu rekonekto kaj komparu ĝin kun tio, kion via nodo anoncas. Se la pordo moviĝis, la malnova finpunkto nun aŭ estas de neniu aŭ de iu alia.

Legu la envenantan flagon, ne la totalon de konektoj

El rajtigita loka RPC-kunteksto, ĉi tiu nurlega peto listigas peer-ojn:

bitcoin-cli getpeerinfo

La RPC-referenco difinas inbound kiel true por envenanta konekto kaj false por eliranta. Rigardu tiun kampon. Totalo super dek pruvas nenion pri la direkto, kaj la totaloj kaj kategorioj ŝanĝiĝas kun agordo kaj eldono ĉiuokaze.

Poste testu la mapitan finpunkton de ekstere per freŝa atingebla kontrolo, kiun vi rajtas ruli, kaj vidu, ĉu aperas responda envenanta peer. Estu singardema pri la eligo, kiun vi algluas en subtenan fadenon: peer-adresoj estas konektaj detaloj de aliaj homoj, kaj ili ne bezonas esti publikigitaj por ke oni respondu vian demandon.

Ne solvu ĝin per elmeto de RPC

La RPC-dokumentaro de Bitcoin Core eksplicite avertas kontraŭ elmeti la RPC-interfacon al la publika interreto. Peer-konektoj kaj aŭtentikigita administrado estas malsamaj servoj, kaj igi P2P atingebla per publikigo de RPC interŝanĝas konektecan problemon kontraŭ multe pli malbona.

Se vi preferus tute ne dependi de envenanta P2P, onion-servo estas la dokumentita alternativo, kaj ĝi havas siajn proprajn antaŭkondiĉojn: Tor disponebla, kontrola aŭtentikigo agordita kaj aŭskultaj agordoj, kiuj permesas krei la servon. Ĝi ne aperas nur ĉar VPN hazarde funkcias.

Ekskludi Core el la VPN estas tria dezajno, kaj por iuj operatoroj legitima, sed ĝi metas la peer-trafikon sur vian ordinaran konekton. Tio ne estas envenanta aliro tra la VPN, kaj enkursigilo aŭ supra NAT eble ankoraŭ bezonas sian propran permesitan enskribon. Elektu, kiun el la tri vi fakte testas, antaŭ ol ŝanĝi ion ajn alian.