Hyperledger Fabric跨主机部署时Node SDK连接网络的配置与故障排查

核心问题定位 #

当前报错的根源有两个：

• Fabric节点的TLS证书与peer0.org1.example.com、peer0.org2.example.com、orderer.example.com这些内部域名强绑定，跨主机部署时，运行应用的HOST2无法解析这些域名对应的IP
• 动态服务发现返回的节点地址是容器内部域名，初始的connection profile只配置了Org1的单个peer，缺失其他peer、orderer的连接参数、TLS证书配置，SDK拿到发现结果后没有对应的连接信息，自然无法建立链路。

分步配置修复 #

1. 先校验基础网络连通性 #

在配置应用前，先在HOST2上逐台验证HOST1的对应端口是否可通，排除防火墙、安全组拦截问题：

• 测试peer0.org1端口连通性：nc -zv <HOST1IP> 7051
• 测试peer0.org2端口连通性：nc -zv <HOST1IP> 9051
• 测试orderer节点端口连通性：nc -zv <HOST1IP> 7050
  所有端口返回连通结果后，再进行后续配置。

2. 配置HOST2的本地主机名映射 #

因为Fabric节点的TLS握手会校验连接地址的域名是否和证书内的SAN字段匹配，不能直接用IP替换域名配置，需要把所有Fabric节点的内部域名映射到HOST1的IP：

• 打开HOST2的hosts配置文件：
  • Linux/macOS路径：/etc/hosts
  • Windows路径：C:\Windows\System32\drivers\etc\hosts
• 在文件末尾追加三行映射规则，替换<HOST1IP>为HOST1的实际IP：

  <HOST1IP> peer0.org1.example.com
  <HOST1IP> peer0.org2.example.com
  <HOST1IP> orderer.example.com
  

3. 补全Connection Profile的缺失配置 #

你初始的connection profile只配置了Org1的peer，需要把orderer、peer0.org2的连接信息完整补全，不然动态服务发现返回这些节点信息时，SDK找不到对应的TLS证书、端口配置，就会报连接失败。
需要在原JSON结构中新增两个配置块：

1. 新增orderers配置块，填入orderer的连接参数，其中tlsCACerts.pem替换为HOST1上orderer节点的CA证书内容：

   "orderers": {
       "orderer.example.com": {
           "url": "grpcs://<HOST1IP>:7050",
           "tlsCACerts": {
               "pem": "-----BEGIN CERTIFICATE-----\n把对应证书内容粘贴在这里\n-----END CERTIFICATE-----\n"
           },
           "grpcOptions": {
               "ssl-target-name-override": "orderer.example.com",
               "hostnameOverride": "orderer.example.com"
           }
       }
   }
   

2. 在peers配置块中新增peer0.org2的连接参数，tlsCACerts.pem替换为HOST1上Org2 peer的CA证书内容：

   "peer0.org2.example.com": {
       "url": "grpcs://<HOST1IP>:9051",
       "tlsCACerts": {
           "pem": "-----BEGIN CERTIFICATE-----\n把对应证书内容粘贴在这里\n-----END CERTIFICATE-----\n"
       },
       "grpcOptions": {
           "ssl-target-name-override": "peer0.org2.example.com",
           "hostnameOverride": "peer0.org2.example.com"
       }
   }
   

4. 确认Gateway的服务发现配置 #

你之前修改的discovery: { enabled: true, asLocalhost: false }是正确配置，不需要调整。其中asLocalhost: false的作用就是阻止SDK把服务发现返回的节点地址强行替换为localhost，直接使用解析后的域名地址连接节点。

• 如果做完上述配置后还是出现连接超时的问题，可以临时关闭动态发现验证基础链路是否正常：把gateway连接配置改为discovery: { enabled: false }，此时SDK只会严格按照connection profile里写的配置连接节点，不会请求动态发现结果。如果这种模式下可以正常发起交易，就说明之前的问题是动态发现返回的域名因为hosts映射未配置，无法解析。

常见踩坑注意事项 #

• 所有TLS证书必须从HOST1的test-network对应路径下原封不动拷贝，不要自行修改或者替换：
  • peer0.org1的CA证书路径：test-network/organizations/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.crt
  • peer0.org2的CA证书路径：test-network/organizations/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/tls/ca.crt
  • orderer的CA证书路径：test-network/organizations/ordererOrganizations/example.com/orderers/orderer.example.com/tls/ca.crt
• Fabric的grpcs连接不支持关闭TLS校验，不能通过修改配置跳过证书校验完成连接，必须保证证书内容、域名覆盖配置正确。

内容的提问来源于stack exchange，提问作者Marcin Beza