Aucun pair entrant sur votre nœud Bitcoin derrière un VPN ?

Votre nœud est synchronisé, le VPN annonce la connexion, et getpeerinfo affiche huit ou dix pairs. Aucun d'eux n'a inbound défini à true. Cette combinaison est normale et ce n'est pas une panne : les connexions sortantes prouvent que le nœud peut atteindre les autres, et rien en elles ne prouve que quelqu'un puisse vous atteindre. Si l'objectif est un nœud qui accepte des connexions P2P entrantes via un VPN, vous devez tester cette direction séparément.

Suivez le paquet du pair jusqu'à votre écouteur

Le P2P entrant est une chaîne de quatre éléments, et elle casse au maillon le plus faible, pas au plus intéressant.

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

La valeur par défaut du P2P de Core sur le réseau principal est 8333, mais le fournisseur peut vous donner un autre port public et une autre destination côté client. Notez l'adresse publique, le port externe et là où le fournisseur livre réellement le trafic. Confirmez ensuite que votre offre et votre compte autorisent ne serait-ce que les connexions entrantes, car une adresse de sortie dédiée n'est pas un contrat de redirection de port.

Cette distinction attrape ceux qui achètent une IP statique en espérant la joignabilité. Le fait que l'adresse soit stable ne dit rien sur la question de savoir si le fournisseur redirige un port entrant vers votre session.

Vérifiez l'écouteur avant de vérifier le fournisseur

Core doit écouter sur l'adresse et le port vers lesquels le mappage livre, et le pare-feu de l'hôte doit l'autoriser. Si le nœud tourne dans un conteneur ou sur une autre machine du réseau local, le saut suivant et sa route de retour font aussi partie de la chaîne.

Une règle de pare-feu locale ne peut pas créer un mappage chez un fournisseur qui jette les paquets entrants, et un mappage du fournisseur ne peut pas atteindre un processus lié uniquement à loopback. Les deux moitiés doivent s'accorder sur le même tuple, et c'est pourquoi la première étape consiste à écrire le tuple plutôt qu'à le deviner.

Gardez le point de terminaison annoncé cohérent avec le mappage en vigueur. Une adresse statique ne rend pas un port attribué ni son bail permanents d'une reconnexion à l'autre, si bien qu'un point de terminaison publié il y a des mois peut désormais ne pointer vers rien. Relisez la page du fournisseur après chaque reconnexion et comparez-la à ce que votre nœud annonce. Si le port a bougé, l'ancien point de terminaison n'appartient plus à personne ou appartient à quelqu'un d'autre.

Lisez l'indicateur entrant, pas le total des connexions

Depuis un contexte RPC local autorisé, cette requête en lecture seule liste les pairs :

bitcoin-cli getpeerinfo

La référence RPC définit inbound à true pour une connexion entrante et à false pour une connexion sortante. Regardez ce champ. Un total supérieur à dix ne prouve rien sur la direction, et les totaux et catégories changent de toute façon avec la configuration et la version.

Testez ensuite le point de terminaison mappé depuis l'extérieur avec un nouveau contrôle de joignabilité que vous êtes autorisé à lancer, et voyez si un pair entrant correspondant apparaît. Faites attention à la sortie que vous collez dans un fil d'assistance : les adresses des pairs sont les données de connexion d'autres personnes, et elles n'ont pas besoin d'être publiées pour que votre question reçoive une réponse.

Ne le réglez pas en exposant RPC

La documentation RPC de Bitcoin Core met explicitement en garde contre l'exposition de l'interface RPC à l'internet public. Les connexions entre pairs et l'administration authentifiée sont des services différents, et rendre le P2P joignable en publiant RPC échange un problème de connectivité contre un problème bien pire.

Si vous préférez ne pas dépendre du tout du P2P entrant, un service onion est l'alternative documentée, et il a ses propres prérequis : Tor disponible, authentification de contrôle configurée et réglages d'écoute qui permettent de créer le service. Il n'apparaît pas parce qu'un VPN se trouve tourner.

Exclure Core du VPN est une troisième conception, et légitime pour certains opérateurs, mais elle place le trafic des pairs sur votre connexion ordinaire. Ce n'est pas un accès entrant via le VPN, et un routeur ou un NAT en amont peut encore avoir besoin de sa propre entrée autorisée. Choisissez lequel des trois vous testez réellement avant de changer quoi que ce soit d'autre.