El teu node està sincronitzat, la VPN diu que hi ha connexió i getpeerinfo mostra vuit o deu parells. Cap d'ells té inbound establert a true. Aquesta combinació és normal i no és cap error: les connexions sortints proven que el node pot arribar als altres, i res d'elles prova que algú pugui arribar a tu. Si l'objectiu és un node que accepti connexions P2P entrants a través d'una VPN, has de provar aquesta direcció per separat.

Segueix el paquet des del parell fins al teu escoltador

El P2P entrant és una cadena de quatre coses, i falla a l'enllaç més feble, no al més interessant.

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

El valor per defecte de P2P de Core a la xarxa principal és 8333, però el proveïdor et pot donar un port públic diferent i una destinació diferent al costat del client. Anota l'adreça pública, el port extern i on lliura realment el trànsit el proveïdor. Després confirma que el teu pla i el teu compte permeten connexions entrants, perquè una adreça de sortida dedicada no és un contracte de reenviament de ports.

Aquesta distinció enxampa qui compra una IP estàtica esperant abast. Que l'adreça sigui estable no diu res sobre si el proveïdor reenvia un port entrant a la teva sessió.

Comprova l'escoltador abans de comprovar el proveïdor

Core ha d'escoltar a l'adreça i el port on lliura el mapatge, i el tallafoc de l'amfitrió ho ha de permetre. Si el node s'executa en un contenidor o en una altra màquina de la LAN, el salt següent i la seva ruta de resposta també formen part de la cadena.

Una regla de tallafoc local no pot crear un mapatge en un proveïdor que descarta els paquets entrants, i un mapatge del proveïdor no pot arribar a un procés lligat només a loopback. Les dues meitats han de coincidir en la mateixa tupla, i per això el primer pas és escriure la tupla en lloc d'endevinar-la.

Mantén l'extrem anunciat coherent amb el mapatge actual. Una adreça estàtica no fa permanent un port assignat ni el seu lloguer entre reconnexions, així que un extrem publicat fa mesos pot no apuntar ara a res. Torna a llegir la pàgina del proveïdor després de qualsevol reconnexió i compara-la amb el que anuncia el teu node. Si el port s'ha mogut, l'extrem antic ara o no és de ningú o és d'algú altre.

Llegeix el flag entrant, no el total de connexions

Des d'un context RPC local autoritzat, aquesta consulta de només lectura llista els parells:

bitcoin-cli getpeerinfo

La referència d'RPC defineix inbound com a true per a una connexió entrant i false per a una de sortint. Mira aquest camp. Un total per sobre de deu no prova res sobre la direcció, i els totals i les categories canvien amb la configuració i la versió de totes maneres.

Després prova l'extrem mapat des de fora amb una comprovació d'abast nova que tinguis autorització per executar, i mira si apareix un parell entrant corresponent. Vés amb compte amb la sortida que enganxes en un fil de suport: les adreces dels parells són dades de connexió d'altres persones i no cal publicar-les perquè et responguin.

No ho resolguis exposant l'RPC

La documentació d'RPC de Bitcoin Core adverteix explícitament contra exposar la interfície RPC a Internet públic. Les connexions amb parells i l'administració autenticada són serveis diferents, i fer que el P2P sigui abastable publicant RPC canvia un problema de connectivitat per un de molt pitjor.

Si prefereixes no dependre gens del P2P entrant, un servei onion és l'alternativa documentada, i té els seus propis requisits previs: Tor disponible, autenticació de control configurada i paràmetres d'escolta que permetin crear el servei. No apareix només perquè hi hagi una VPN en marxa.

Excloure Core de la VPN és un tercer disseny, i legítim per a alguns operadors, però posa el trànsit dels parells a la teva connexió normal. Això no és accés entrant a través de la VPN, i un router o un NAT superior encara pot necessitar la seva pròpia entrada permesa. Tria quin dels tres estàs provant de debò abans de canviar res més.

Articles relacionats