VPN 后面的 Bitcoin 节点没有入站对等节点？

出站对等节点和已同步的链并不能证明入站可达性。在归咎 VPN 之前，先检查映射、监听器和 inbound 标志。

你的节点已同步，VPN 显示已连接，而 getpeerinfo 显示八个或十个对等节点。它们当中没有任何一个把 inbound 设为 true。这种组合是正常的，并不是故障：出站连接只证明节点能到达别人，其中没有任何东西证明别人能到达你。如果目标是一个通过 VPN 接受入站 P2P 连接的节点，就必须单独验证这个方向。

沿着数据包从对等节点追到你的监听器

入站 P2P 是四个环节组成的链条，它断在最弱的一环，而不是最有趣的一环。

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

Core 在主网上的 P2P 默认端口是 8333，但服务商可能给你另一个公网端口和另一个客户端侧目标。记下公网地址、外部端口，以及服务商实际把流量投递到哪里。然后确认你的套餐和账户究竟允不允许入站连接，因为一个专用出口地址并不等于端口转发合同。

这个区别正好抓住那些买了静态 IP 就以为可达的人。地址稳定与否，完全不能说明服务商是否把入站端口转发到你的会话。

先检查监听器，再检查服务商

Core 必须监听映射所投递的地址和端口，主机防火墙必须放行。如果节点跑在容器里或局域网的其他机器上，后面那一跳及其回程路由也属于这条链。

本地防火墙规则无法在丢弃入站数据包的服务商那里建立映射，服务商的映射也无法到达只绑定在 loopback 上的进程。两半必须对齐同一个元组，所以第一步是把元组写下来，而不是去猜。

让对外公布的端点与当前映射保持一致。静态地址并不会让被分配的端口或它的租约在重连之后保持永久，所以几个月前公布的端点现在可能指向空处。每次重连后重新读一遍服务商的页面，并与你的节点所通告的内容对照。如果端口已经变了，旧端点现在要么不属于任何人，要么属于别人。

读入站标志，而不是连接总数

在获得授权的本地 RPC 环境中，这条只读查询会列出对等节点：

bitcoin-cli getpeerinfo

RPC 参考 把 inbound 定义为入站连接为 true、出站连接为 false。看看这个字段。超过十的总数并不能证明方向，而且总数与分类本来也会随配置和版本变化。

然后从外部，用一次你有权执行的全新可达性检查来测试被映射的端点，看看是否出现对应的入站对等节点。把输出贴到支持帖时要小心：对等节点地址是别人的连接信息，并不需要公开才能让你的问题得到回答。

不要靠暴露 RPC 来解决

Bitcoin Core 的 RPC 文档明确警告不要把 RPC 接口暴露到公网。对等节点连接与带身份验证的管理是不同的服务，为了打通 P2P 而公开 RPC，是把连接问题换成一个严重得多的问题。

如果你完全不想依赖入站 P2P，文档给出的替代方案是 onion 服务，而它有自己的前提：Tor 可用、控制认证已配置，以及允许创建服务的监听设置。它不会仅仅因为碰巧有 VPN 在跑就出现。

把 Core 排除在 VPN 之外是第三种设计，对某些运营者来说是合理的，但它会让对等节点流量走你的普通连接。那不是通过 VPN 的入站访问，而且路由器或上游 NAT 可能仍需要各自的放行条目。在改动其他东西之前，先确定你真正在测的是三者中的哪一个。

相关文章