Eikö Bitcoin-solmussasi ole saapuvia vertaisia VPN:n takana?

Solmusi on synkronoitu, VPN ilmoittaa yhteydestä ja getpeerinfo näyttää kahdeksan tai kymmenen vertaista. Yhdelläkään niistä ei ole inbound asetettuna arvoon true. Tämä yhdistelmä on normaali eikä ole vika: lähtevät yhteydet todistavat, että solmu tavoittaa muut, eikä mikään niissä todista, että joku tavoittaa sinut. Jos tavoitteena on solmu, joka vastaanottaa saapuvia P2P-yhteyksiä VPN:n kautta, sinun on testattava tätä suuntaa erikseen.

Seuraa pakettia vertaisesta kuuntelijaasi

Saapuva P2P on neljän asian ketju, ja se katkeaa heikoimmassa lenkissä, ei kiinnostavimmassa.

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

Coren P2P-oletus pääverkossa on 8333, mutta palveluntarjoaja voi antaa sinulle toisen julkisen portin ja toisen kohteen asiakaspäässä. Kirjoita ylös julkinen osoite, ulkoinen portti ja paikka, johon palveluntarjoaja todella toimittaa liikenteen. Vahvista sitten, että sopimuksesi ja tilisi ylipäätään sallivat saapuvat yhteydet, sillä varattu lähtöosoite ei ole portin edelleenlähetyssopimus.

Tämä ero nappaa ne, jotka ostavat staattisen IP:n odottaen tavoitettavuutta. Se, että osoite on vakaa, ei kerro mitään siitä, välittääkö palveluntarjoaja saapuvan portin istuntoosi.

Tarkista kuuntelija ennen palveluntarjoajaa

Coren on kuunneltava osoitteessa ja portissa, johon kartoitus toimittaa, ja isäntäkoneen palomuurin on sallittava se. Jos solmu pyörii kontissa tai toisessa LAN-koneessa, myös seuraava hyppy ja sen vastausreitti kuuluvat ketjuun.

Paikallinen palomuurisääntö ei voi luoda kartoitusta palveluntarjoajalla, joka pudottaa saapuvat paketit, eikä palveluntarjoajan kartoitus tavoita prosessia, joka on sidottu vain loopbackiin. Molempien puoliskojen on sovittava samasta monikosta, siksi ensimmäinen askel on kirjoittaa monikko ylös eikä arvata sitä.

Pidä ilmoitettu päätepiste yhdenmukaisena nykyisen kartoituksen kanssa. Staattinen osoite ei tee määritetystä portista tai sen vuokrasta pysyvää uudelleenyhdistämisten yli, joten kuukausia sitten julkaistu päätepiste ei ehkä enää osoita mihinkään. Lue palveluntarjoajan sivu uudelleen jokaisen uudelleenyhdistämisen jälkeen ja vertaa sitä siihen, mitä solmusi ilmoittaa. Jos portti on siirtynyt, vanha päätepiste on nyt joko ei kenenkään tai jonkun toisen.

Lue saapuvan liikenteen lippu, älä yhteyksien kokonaismäärää

Valtuutetusta paikallisesta RPC-kontekstista tämä vain luku -kysely luettelee vertaiset:

bitcoin-cli getpeerinfo

RPC-viite inbound-arvon todeksi saapuvalle yhteydelle ja epätodeksi lähtevälle. Katso sitä kenttää. Yli kymmenen kokonaismäärä ei todista suunnasta mitään, ja summat ja luokat muuttuvat joka tapauksessa kokoonpanon ja version mukana.

Testaa sitten kartoitettua päätepistettä ulkopuolelta tuoreella tavoitettavuustarkistuksella, jonka sinulla on lupa ajaa, ja katso ilmestyykö vastaava saapuva vertainen. Ole varovainen sen tulosteen kanssa, jonka liität tukiketjuun: vertaisten osoitteet ovat muiden ihmisten yhteystietoja, eikä niitä tarvitse julkaista, jotta kysymykseesi vastataan.

Älä ratkaise sitä paljastamalla RPC:tä

Bitcoin Coren RPC-dokumentaatio varoittaa nimenomaisesti RPC-rajapinnan paljastamisesta julkiseen internetiin. Vertaisyhteydet ja todennettu hallinta ovat eri palveluita, ja P2P:n tekeminen tavoitettavaksi RPC:n julkaisemisella vaihtaa yhteysongelman paljon pahempaan.

Jos et halua lainkaan riippua saapuvasta P2P:stä, dokumentoitu vaihtoehto on onion-palvelu, ja sillä on omat edellytyksensä: Tor saatavilla, hallinnan todennus määritetty ja kuunteluasetukset, jotka sallivat palvelun luomisen. Se ei ilmesty vain siksi, että VPN sattuu olemaan käynnissä.

Coren jättäminen VPN:n ulkopuolelle on kolmas ratkaisu ja joillekin ylläpitäjille laillinen, mutta se laittaa vertaisliikenteen tavalliselle yhteydellesi. Se ei ole saapuva pääsy VPN:n kautta, ja reititin tai ylävirran NAT voi yhä tarvita oman sallitun merkintänsä. Valitse, mitä kolmesta todella testaat, ennen kuin muutat mitään muuta.