O teu nodo está sincronizado, a VPN di que hai conexión e getpeerinfo mostra oito ou dez pares. Ningún deles ten inbound establecido en true. Esa combinación é normal e non é un fallo: as conexións saíntes demostran que o nodo pode chegar aos demais, e nada nelas demostra que alguén poida chegar a ti. Se o obxectivo é un nodo que acepta conexións P2P entrantes a través dunha VPN, tes que probar esa dirección por separado.

Segue o paquete desde o par ata o teu escoitador

O P2P entrante é unha cadea de catro cousas, e falla no elo máis feble, non no máis interesante.

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

O valor predeterminado de P2P de Core na rede principal é 8333, pero o provedor pode darche outro porto público e outro destino do lado do cliente. Anota o enderezo público, o porto externo e o lugar onde o provedor entrega realmente o tráfico. Despois confirma que o teu plan e a túa conta permiten conexións entrantes, porque un enderezo de saída dedicado non é un contrato de reenvío de portos.

Esa distinción atrapa a quen compra unha IP estática esperando accesibilidade. Que o enderezo sexa estable non di nada sobre se o provedor reenvía un porto entrante á túa sesión.

Comproba o escoitador antes de comprobar o provedor

Core ten que escoitar no enderezo e no porto aos que entrega a asignación, e o cortafuegos do host ten que permitilo. Se o nodo se executa nun contedor ou noutra máquina da LAN, o seguinte salto e a súa ruta de resposta tamén forman parte da cadea.

Unha regra de cortafuegos local non pode crear unha asignación nun provedor que descarta os paquetes entrantes, e unha asignación do provedor non pode chegar a un proceso ligado só a loopback. As dúas metades teñen que coincidir na mesma tupla, e por iso o primeiro paso é escribir a tupla en lugar de adiviñala.

Mantén o extremo anunciado coherente coa asignación vixente. Un enderezo estático non fai permanente un porto asignado nin o seu alugueiro entre reconexións, así que un extremo publicado hai meses pode que agora non apunte a nada. Vuelve ler a páxina do provedor despois de calquera reconexión e compáraa co que anuncia o teu nodo. Se o porto se moveu, o extremo antigo agora ou non é de ninguén ou é doutra persoa.

Le o indicador entrante, non o total de conexións

Desde un contexto RPC local autorizado, esta consulta de só lectura lista os pares:

bitcoin-cli getpeerinfo

A referencia de RPC define inbound como true para unha conexión entrante e false para unha saínte. Fíxate nese campo. Un total por riba de dez non demostra nada sobre a dirección, e os totais e as categorías cambian coa configuración e a versión de todos os xeitos.

Despois proba o extremo asignado desde fóra cunha comprobación de accesibilidade nova que teñas autorización para executar, e mira se aparece un par entrante correspondente. Ten coidado coa saída que pegas nun fío de asistencia: os enderezos dos pares son datos de conexión doutras persoas e non cómpre publicalos para que respondan á túa pregunta.

Non o resolvas expoñendo RPC

A documentación de RPC de Bitcoin Core advirte explicitamente contra expoñer a interface RPC á internet pública. As conexións con pares e a administración autenticada son servizos distintos, e facer que o P2P sexa accesible publicando RPC cambia un problema de conectividade por un moito peor.

Se prefires non depender en absoluto do P2P entrante, un servizo onion é a alternativa documentada, e ten os seus propios requisitos previos: Tor dispoñible, autenticación de control configurada e axustes de escoita que permitan crear o servizo. Non aparece porque resulte que hai unha VPN en marcha.

Excluír Core da VPN é un terceiro deseño, e lexítimo para algúns operadores, pero pon o tráfico dos pares na túa conexión normal. Iso non é acceso entrante a través da VPN, e un router ou un NAT superior aínda pode necesitar a súa propia entrada permitida. Escolle cal dos tres estás probando de verdade antes de cambiar calquera outra cousa.

Artigos relacionados