Ingen innkomande peers på Bitcoin-noden din bak ein VPN?

Noden din er synkronisert, VPN-en seier tilkopla, og getpeerinfo viser åtte eller ti peers. Ingen av dei har inbound sett til true. Den kombinasjonen er normal og ikkje ein feil: utgåande tilkoplingar beviser at noden kan nå andre, og ingenting ved dei beviser at nokon kan nå deg. Viss målet er ein node som tek imot innkomande P2P-tilkoplingar gjennom ein VPN, må du teste den retninga for seg sjølv.

Følg pakken frå peeren til listeneren din

Innkomande P2P er ei kjede av fire ting, og ho ryker på den svakaste lenkja, ikkje den mest interessante.

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

Cores P2P-standard på mainnet er 8333, men leverandøren kan gje deg ein annan offentleg port og ein annan destinasjon på klientsida. Skriv ned den offentlege adressa, den eksterne porten og staden der leverandøren faktisk leverer trafikken. Stadfest deretter at abonnementet og kontoen din i det heile tillèt innkomande tilkoplingar, for ei dedikert utgangsadresse er ikkje ein portvideresendingskontrakt.

Den skilnaden fangar folk som kjøper ei statisk IP i von om tilgjenge. At adressa er stabil, seier ingenting om leverandøren videresender ein innkomande port til økta di.

Kontroller listeneren før du kontrollerer leverandøren

Core må lytta på adressa og porten som mappinga leverer til, og brannmuren på verten må tillate det. Viss noden køyrer i ein container eller på ein annan maskin i LAN-et, høyrer det neste hoppet og svarvegen dets også med i kjeda.

Ein lokal brannmurregel kan ikkje lage ei mapping hos ein leverandør som droppar innkomande pakkar, og ei leverandørmapping kan ikkje nå ein prosess som berre er bunden til loopback. Begge halvdelane må bli samde om same tuple, og difor er første steg å skrive tuple-en ned i staden for å gisse på han.

Hald det annonserte endepunktet konsistent med den gjeldande mappinga. Ei statisk adresse gjer ikkje ein tildelt port eller leiga hans permanent gjennom attkoplingar, så eit endepunkt som vart publisert for månader sidan peikar kanskje ikkje på noko no. Les sida til leverandøren på nytt etter kvar attkopling og samanlikn ho med det noden din annonserer. Viss porten har flytta seg, er det gamle endepunktet no anten ingens eller nokon annan sin.

Les inbound-flaggja, ikkje det totale talet på tilkoplingar

Frå ein autorisert lokal RPC-kontekst listar denne skriveverna spørjinga peers:

bitcoin-cli getpeerinfo

RPC-referansen inbound som true for ei innkomande tilkopling og false for ei utgåande. Sjå på det feltet. Eit totaltal over ti beviser ingenting om retninga, og totalane og kategoriane endrar seg uansett med konfigurasjon og versjon.

Test deretter det mappa endepunktet utanfrå med ein ny tilgjengesjekk du har løyve til å køyre, og sjå om ein tilsvarande innkomande peer dukkar opp. Ver varsam med utdataa du limer inn i ein støttetråd: peer-adresser er tilkoplingsopplysningane til andre folk, og dei treng ikkje publiserast for at spørsmålet ditt skal bli svara.

Ikkje løys det ved å eksponere RPC

RPC-dokumentasjonen til Bitcoin Core åtvarar uttrykkeleg mot å eksponere RPC-grensesnittet mot det offentlege internettet. Peer-tilkoplingar og autentisert administrasjon er ulike tenester, og å gjere P2P tilgjengeleg ved å publisere RPC byter eit tilkoplingsproblem mot eit mykje verre.

Viss du heller vil sleppe å vere avhengig av innkomande P2P i det heile, er ein onion-teneste det dokumenterte alternativet, og han har sine eigne føresetnader: Tor tilgjengeleg, kontrollautentisering konfigurert og lytting-innstillingar som tillèt at tenesta blir oppretta. Ho dukkar ikkje opp berre fordi ein VPN tilfeldigvis køyrer.

Å utelukke Core frå VPN-en er eit tredje design, og legitimt for nokre operatørar, men det legg peer-trafikken på den vanlege tilkoplinga di. Det er ikkje innkomande tilgang gjennom VPN-en, og ein ruter eller oppstraums NAT kan framleis trenge si eiga tillatne oppføring. Vel kva av dei tre du faktisk testar før du endrar noko anna.