Sinu Bitcoin-sõlmel VPN-i taga pole ühtegi sissetulevat peer'i?

Sinu sõlm on sünkroonitud, VPN teatab ühendusest ja getpeerinfo näitab kaheksat või kümmet peer'i. Ühelgi neist ei ole inbound seatud väärtusele true. See kombinatsioon on tavaline ega ole rike: väljuvad ühendused tõestavad, et sõlm jõuab teisteni, ja miski nende juures ei tõesta, et keegi jõuab sinuni. Kui eesmärk on sõlm, mis võtab VPN-i kaudu vastu sissetulevaid P2P-ühendusi, tuleb seda suunda eraldi testida.

Jälgi paketti peer'ist sinu kuulajani

Sissetulev P2P on nelja asja ahel ja see puruneb nõrgimas lülis, mitte kõige huvitavamas.

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

Core'i P2P vaikeväärtus põhivõrgus on 8333, kuid teenusepakkuja võib anda sulle teise avaliku pordi ja teise sihtkoha kliendi poolel. Kirjuta üles avalik aadress, väline port ja koht, kuhu pakkuja liikluse tegelikult toimetab. Seejärel kinnita, et sinu plaan ja konto üldse lubavad sissetulevaid ühendusi, sest pühendatud väljumisaadress ei ole pordiedastusleping.

See erinevus püüab kinni need, kes ostavad staatilise IP lootuses kättesaadavusele. See, et aadress on stabiilne, ei ütle midagi selle kohta, kas pakkuja edastab sissetuleva pordi sinu sessiooni.

Kontrolli kuulajat enne pakkuja kontrollimist

Core peab kuulama aadressil ja pordil, kuhu vastendus toimetab, ja hosti tulemüür peab seda lubama. Kui sõlm töötab konteineris või teises LAN-masinas, kuuluvad ahelasse ka järgmine hüpe ja selle vastusmarsruut.

Kohalik tulemüürireegel ei saa luua vastendust pakkuja juures, kes viskab sissetulevad paketid ära, ja pakkuja vastendus ei jõua protsessini, mis on seotud ainult loopbackiga. Mõlemad pooled peavad kokku leppima samas korteežis, seepärast on esimene samm korteež üles kirjutada, mitte seda arvata.

Hoia teatatud lõpp-punkt kooskõlas tegeliku vastendusega. Staatiline aadress ei tee määratud porti ega selle renti ühenduste vahel püsivaks, nii et kuid tagasi avaldatud lõpp-punkt ei pruugi nüüd enam millelegi osutada. Loe pakkuja lehte uuesti pärast iga taasühendust ja võrdle seda sellega, mida sinu sõlm teatab. Kui port on liikunud, on vana lõpp-punkt nüüd kas mitte kellegi või kellegi teise oma.

Loe sissetuleku lippu, mitte ühenduste koguarvu

Volitatud kohalikust RPC-kontekstist loetleb see ainult lugemiseks mõeldud päring peer'e:

bitcoin-cli getpeerinfo

RPC-viide inbound väärtusena true sissetuleva ühenduse ja false väljuva ühenduse jaoks. Vaata seda välja. Kogusumma üle kümne ei tõesta suuna kohta midagi ning summad ja kategooriad muutuvad konfiguratsiooni ja versiooniga niikuinii.

Seejärel testi vastendatud lõpp-punkti väljastpoolt värske kättesaadavuse kontrolliga, mille käivitamiseks sul luba on, ja vaata, kas ilmub vastav sissetulev peer. Ole ettevaatlik väljundi suhtes, mille kleepid tugiteemasse: peer'ide aadressid on teiste inimeste ühenduste andmed ja neid ei ole vaja avaldada, et sinu küsimusele vastataks.

Ära lahenda seda RPC paljastamisega

Bitcoin Core'i RPC-dokumentatsioon hoiatab selgesõnaliselt RPC-liidese avalikku internetti paljastamise eest. Peer-ühendused ja autenditud haldus on erinevad teenused ning P2P kättesaadavaks tegemine RPC avaldamise teel vahetab ühenduvusprobleemi palju hullema vastu.

Kui eelistad sissetulevast P2P-st üldse mitte sõltuda, on dokumenteeritud alternatiiv onion-teenus ja sellel on omad eeltingimused: Tor on saadaval, juhtimise autentimine on seadistatud ja kuulamisreeglid lubavad teenuse luua. See ei ilmu lihtsalt sellepärast, et VPN juhtub töötama.

Core'i VPN-ist väljajätmine on kolmas lahendus ja mõne operaatori jaoks legitiimne, kuid see paneb peer-liikluse sinu tavalisse ühendusse. See ei ole sissetulev juurdepääs VPN-i kaudu ning ruuteril või ülesvoolu NAT-il võib ikkagi olla vaja oma lubatud kirjet. Otsusta, millist kolmest sa tegelikult testid, enne kui midagi muud muudad.