Inga inkommande peers på din Bitcoin-nod bakom en VPN?

Din nod är synkroniserad, VPN:en säger ansluten, och getpeerinfo visar åtta eller tio peers. Ingen av dem har inbound satt till true. Den kombinationen är normal och inte ett fel: utgående anslutningar bevisar att noden kan nå andra, och inget i dem bevisar att någon kan nå dig. Om målet är en nod som tar emot inkommande P2P-anslutningar via en VPN måste du testa den riktningen för sig.

Följ paketet från peeren till din lyssnare

Inkommande P2P är en kedja av fyra saker, och den brister vid den svagaste länken, inte den mest intressanta.

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

Cores P2P-standard på mainnet är 8333, men leverantören kan ge dig en annan offentlig port och en annan destination på klientsidan. Skriv ned den offentliga adressen, den externa porten och platsen där leverantören faktiskt levererar trafiken. Bekräfta sedan att din plan och ditt konto överhuvudtaget tillåter inkommande anslutningar, för en dedikerad utgångsadress är inte ett portvidarebefordringskontrakt.

Den skillnaden fångar folk som köper en statisk IP i förväntan på nåbarhet. Att adressen är stabil säger ingenting om huruvida leverantören vidarebefordrar en inkommande port till din session.

Kontrollera lyssnaren innan du kontrollerar leverantören

Core måste lyssna på adressen och porten som mappningen levererar till, och värdens brandvägg måste tillåta det. Om noden körs i en container eller på en annan maskin i LAN:et hör nästa hopp och dess svarsrutt också till kedjan.

En lokal brandväggsregel kan inte skapa en mappning hos en leverantör som kastar inkommande paket, och en leverantörsmappning kan inte nå en process som bara är bunden till loopback. Båda halvorna måste enas om samma tupel, och därför är första steget att skriva ned tupeln i stället för att gissa på den.

Håll den annonserade slutpunkten konsekvent med den aktuella mappningen. En statisk adress gör inte en tilldelad port eller dess lease permanent mellan återanslutningar, så en slutpunkt som publicerades för månader sedan pekar kanske inte på något nu. Läs om leverantörens sida efter varje återanslutning och jämför den med vad din nod annonserar. Om porten har flyttat sig är den gamla slutpunkten nu antingen ingens eller någon annans.

Läs inbound-flaggan, inte det totala antalet anslutningar

Från en auktoriserad lokal RPC-kontext listar den här skrivskyddade frågan peers:

bitcoin-cli getpeerinfo

RPC-referensen inbound som true för en inkommande anslutning och false för en utgående. Titta på det fältet. En totalsumma över tio bevisar ingenting om riktningen, och summorna och kategorierna ändras ändå med konfiguration och version.

Testa sedan den mappade slutpunkten utifrån med en ny nåbarhetskontroll som du har behörighet att köra, och se om en motsvarande inkommande peer dyker upp. Var försiktig med utdata du klistrar in i en supporttråd: peer-adresser är andra människors anslutningsuppgifter och behöver inte publiceras för att din fråga ska besvaras.

Lös det inte genom att exponera RPC

Bitcoin Cores RPC-dokumentation varnar uttryckligen för att exponera RPC-gränssnittet mot det publika internet. Peer-anslutningar och autentiserad administration är olika tjänster, och att göra P2P nåbar genom att publicera RPC byter ett anslutningsproblem mot ett mycket värre.

Om du hellre vill undvika att vara beroende av inkommande P2P helt och hållet är en onion-tjänst det dokumenterade alternativet, och det har sina egna förutsättningar: Tor tillgängligt, kontrollautentisering konfigurerad och lyssningsinställningar som tillåter att tjänsten skapas. Det dyker inte upp bara för att en VPN råkar köra.

Att utesluta Core från VPN:en är en tredje design, och legitim för vissa operatörer, men den lägger peer-trafiken på din vanliga anslutning. Det är inte inkommande åtkomst via VPN:en, och en router eller uppströms NAT kan fortfarande behöva sin egen tillåtna post. Välj vilken av de tre du faktiskt testar innan du ändrar något annat.