pgBackRest TLS认证问题排查与解决方案

问题背景

在使用pgBackRest进行PostgreSQL数据库备份时，配置TLS加密通信是保障数据传输安全的重要环节。本文记录了一个典型的TLS认证配置问题及其解决方案，该问题表现为从备份服务器端向客户端发起检查时出现"access denied"错误。

环境配置

系统环境为CentOS 7.9，PostgreSQL 11版本，pgBackRest 2.51。采用TLS加密通信，服务器端和客户端分别配置了相应的证书文件：

• 服务器端配置：

  • 监听所有网络接口(0.0.0.0)
  • 使用服务器证书(pgbackrest-server.crt)和私钥
  • 配置了根证书(root.crt)
  • 设置了三个PostgreSQL节点的认证信息

• 客户端配置：

  • 使用客户端特定证书(如msdb7-patroni-cluster-2124579701.crt)
  • 同样配置了根证书
  • 认证服务器端服务名为"pgbackrest-server.service.consul"

问题现象

从客户端向服务器端发起的检查命令可以成功执行，WAL日志也能正常推送到存储库，ping测试也正常。但从服务器端向客户端发起检查时，出现以下错误：

WARN: unable to check pg1: [AccessError] raised from remote-0 tls protocol on 'msdb7-patroni-cluster-2124579700': access denied
ERROR: [027]: no database found

排查过程

1. 证书验证：

   • 使用openssl命令验证证书有效性，确认TLS握手成功(Verify return code: 0)
   • 检查证书主题名称(CN)与配置匹配

2. 日志分析：

   • 发现"access denied"错误信息
   • 协议层提示需要调试日志级别以获取更多参数信息

3. 服务名称分析：

   • 注意到使用了Consul服务名称(pgbackrest-server.service.consul)作为认证标识
   • 怀疑服务名称解析可能存在问题

解决方案

经过排查，发现问题根源在于使用了Consul服务名称作为认证标识。Consul服务在此环境中被用作DNS服务，但其服务名称的解析导致了认证问题。解决方案是：

1. 避免在TLS认证配置中使用Consul服务名称
2. 使用直接的服务器主机名或IP地址作为认证标识
3. 确保服务器端和客户端的认证标识配置一致

经验总结

1. TLS认证配置要点：

   • 证书的CN(Common Name)必须与配置中的认证标识完全匹配
   • 服务器端和客户端的配置需要对称
   • 避免使用可能引起解析问题的服务名称

2. 调试建议：

   • 启用pgBackRest的调试日志级别以获取更详细的错误信息
   • 使用openssl命令单独测试TLS连接
   • 逐步验证每个配置环节

3. 最佳实践：

   • 保持认证标识简单直接
   • 在复杂网络环境中，考虑使用静态IP或固定域名
   • 实施前先进行小规模测试验证

通过这次问题排查，我们认识到在配置pgBackRest的TLS认证时，保持配置的简洁性和一致性至关重要，特别是在使用服务发现工具如Consul的环境中，需要特别注意服务名称的解析问题。