Jūsu Bitcoin mezglā aiz VPN nav ienākošo vienaudžu?

Jūsu mezgls ir sinhronizēts, VPN ziņo par savienojumu, un getpeerinfo rāda astoņus vai desmit vienaudžus. Nevienam no tiem nav inbound iestatīts uz true. Šāda kombinācija ir normāla un nav kļūda: izejošie savienojumi pierāda, ka mezgls var sasniegt citus, un nekas tajos nepierāda, ka kāds var sasniegt jūs. Ja mērķis ir mezgls, kas pieņem ienākošos P2P savienojumus caur VPN, šis virziens jāpārbauda atsevišķi.

Izsekojiet pakei no vienaudža līdz savam klausītājam

Ienākošais P2P ir četru lietu ķēde, un tā plīst vājākajā posmā, nevis interesantākajā.

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

Core P2P noklusējums galvenajā tīklā ir 8333, taču pakalpojumu sniedzējs var dot citu publisku portu un citu galamērķi klienta pusē. Pierakstiet publisko adresi, ārējo portu un vietu, kur sniedzējs faktiski piegādā trafiku. Pēc tam apstipriniet, ka jūsu plāns un konts vispār atļauj ienākošos savienojumus, jo īpašā izejas adrese nav portu pāradresācijas līgums.

Šī atšķirība noķer tos, kuri pērk statisku IP, cerēdami uz sasniedzamību. Tas, ka adrese ir stabila, neko nepasaka par to, vai sniedzējs pāradresē ienākošo portu uz jūsu sesiju.

Pārbaudiet klausītāju pirms sniedzēja

Core ir jāklausās adresē un portā, uz kurieni piegādā kartējums, un resursdatora ugunsmūrim tas jāatļauj. Ja mezgls darbojas konteinerā vai citā LAN mašīnā, arī nākamais lēciens un tā atbildes maršruts pieder ķēdei.

Vietējs ugunsmūra noteikums nevar izveidot kartējumu pie sniedzēja, kas izmet ienākošos pakešus, un sniedzēja kartējums nevar sasniegt procesu, kas piesaistīts tikai loopback. Abām pusēm jāvienojas par vienu un to pašu kortežu, tāpēc pirmais solis ir kortežu pierakstīt, nevis minēt.

Turiet izziņoto galapunktu saskaņā ar faktisko kartējumu. Statiska adrese nepadara piešķirto portu vai tā nomu pastāvīgu starp atkārtotiem savienojumiem, tāpēc pirms mēnešiem publicēts galapunkts tagad var neuzrādīt neko. Pēc katras atkārtotās savienošanās vēlreiz izlasiet sniedzēja lapu un salīdziniet to ar to, ko izziņo jūsu mezgls. Ja ports ir pārvietojies, vecais galapunkts tagad vai nu nepieder nevienam, vai pieder kādam citam.

Lasiet ienākošo karodziņu, nevis kopējo savienojumu skaitu

No autorizēta vietējā RPC konteksta šis tikai lasīšanas vaicājums uzskaita vienaudžus:

bitcoin-cli getpeerinfo

RPC uzziņa inbound kā true ienākošam savienojumam un false izejošam. Apskatiet šo lauku. Kopsumma virs desmit neko nepierāda par virzienu, un kopsummas un kategorijas tik un tā mainās līdz ar konfigurāciju un versiju.

Pēc tam pārbaudiet kartēto galapunktu no ārpuses ar jaunu sasniedzamības pārbaudi, kuru jums ir atļauts izpildīt, un skatieties, vai parādās atbilstošs ienākošs vienaudzis. Esiet uzmanīgi ar izvadi, ko ielīmējat atbalsta pavedienā: vienaudžu adreses ir citu cilvēku savienojuma dati, un tās nav jāpublicē, lai uz jūsu jautājumu atbildētu.

Nerisiniet to, atklājot RPC

Bitcoin Core RPC dokumentācija skaidri brīdina neatklāt RPC saskarni publiskajā internetā. Savienojumi ar vienaudžiem un autentificēta administrēšana ir dažādi pakalpojumi, un P2P sasniedzamības nodrošināšana, publicējot RPC, apmaina savienojamības problēmu pret daudz sliktāku.

Ja labprātāk vispār neesat atkarīgs no ienākošā P2P, dokumentētā alternatīva ir onion pakalpojums, un tam ir savi priekšnosacījumi: pieejams Tor, konfigurēta vadības autentifikācija un klausīšanās iestatījumi, kas ļauj izveidot pakalpojumu. Tas neparādās tikai tāpēc, ka nejauši darbojas VPN.

Core izslēgšana no VPN ir trešais risinājums un dažiem operatoriem likumīgs, taču tas novieto vienaudžu trafiku uz jūsu parasto savienojumu. Tā nav ienākoša piekļuve caur VPN, un maršrutētājam vai augšupējam NAT joprojām var būt nepieciešams savs atļautais ieraksts. Izvēlieties, kuru no trim jūs patiešām pārbaudāt, pirms maināt jebko citu.