Ingen innkommende peers på Bitcoin-noden din bak en VPN?

Noden din er synkronisert, VPN-en sier tilkoblet, og getpeerinfo viser åtte eller ti peers. Ingen av dem har inbound satt til true. Den kombinasjonen er normal og ikke en feil: utgående tilkoblinger beviser at noden kan nå andre, og ingenting ved dem beviser at noen kan nå deg. Hvis målet er en node som godtar innkommende P2P-tilkoblinger gjennom en VPN, må du teste den retningen for seg selv.

Følg pakken fra peeren til listeneren din

Innkommende P2P er en kjede av fire ting, og den ryker på den svakeste lenken, ikke 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 gi deg en annen offentlig port og en annen destinasjon på klientsiden. Skriv ned den offentlige adressen, den eksterne porten og stedet der leverandøren faktisk leverer trafikken. Bekreft deretter at planen og kontoen din i det hele tatt tillater innkommende tilkoblinger, for en dedikert utgangsadresse er ikke en portvideresendingskontrakt.

Den forskjellen fanger folk som kjøper en statisk IP i forventning om tilgjengelighet. At adressen er stabil, sier ingenting om hvorvidt leverandøren videresender en innkommende port til økten din.

Kontroller listeneren før du kontrollerer leverandøren

Core må lytte på adressen og porten som mappingen leverer til, og vertens brannmur må tillate det. Hvis noden kjører i en container eller på en annen maskin i LAN-et, hører det neste hoppet og svarruten dets også med i kjeden.

En lokal brannmurregel kan ikke opprette en mapping hos en leverandør som dropper innkommende pakker, og en leverandørmapping kan ikke nå en prosess som bare er bundet til loopback. Begge halvdeler må bli enige om samme tuple, og derfor er første steg å skrive tuple-en ned i stedet for å gjette på den.

Hold det annonserte endepunktet konsistent med den gjeldende mappingen. En statisk adresse gjør ikke en tildelt port eller leasen dens permanent gjennom gjentilkoblinger, så et endepunkt som ble publisert for måneder siden peker kanskje ikke på noe nå. Les leverandørens side på nytt etter hver gjentilkobling og sammenlign den med det noden din annonserer. Hvis porten har flyttet seg, er det gamle endepunktet nå enten ingens eller noen andres.

Les inbound-flagget, ikke det totale antallet tilkoblinger

Fra en autorisert lokal RPC-kontekst lister denne skrivebeskyttede spørringen peers:

bitcoin-cli getpeerinfo

RPC-referansen inbound som true for en innkommende tilkobling og false for en utgående. Se på det feltet. Et totaltall over ti beviser ingenting om retningen, og totalene og kategoriene endrer seg uansett med konfigurasjon og versjon.

Test deretter det mappede endepunktet utenfra med en ny tilgjengelighetssjekk du har tillatelse til å kjøre, og se om en tilsvarende innkommende peer dukker opp. Vær forsiktig med utdataene du limer inn i en støttetråd: peer-adresser er andre folks tilkoblingsopplysninger, og de trenger ikke publiseres for at spørsmålet ditt skal besvares.

Ikke løs det ved å eksponere RPC

Bitcoin Cores RPC-dokumentasjon advarer uttrykkelig mot å eksponere RPC-grensesnittet mot det offentlige internettet. Peer-tilkoblinger og autentisert administrasjon er forskjellige tjenester, og å gjøre P2P tilgjengelig ved å publisere RPC bytter et tilkoblingsproblem mot et mye verre.

Hvis du heller vil slippe å være avhengig av innkommende P2P i det hele tatt, er en onion-tjeneste det dokumenterte alternativet, og den har sine egne forutsetninger: Tor tilgjengelig, kontrollautentisering konfigurert og lytt inn-innstillinger som tillater at tjenesten opprettes. Den dukker ikke opp bare fordi en VPN tilfeldigvis kjører.

Å utelukke Core fra VPN-en er et tredje design, og legitimt for noen operatører, men det legger peer-trafikken på den vanlige tilkoblingen din. Det er ikke innkommende tilgang gjennom VPN-en, og en ruter eller oppstrøms NAT kan fortsatt trenge sin egen tillatte oppføring. Velg hvilken av de tre du faktisk tester før du endrer noe annet.