Ghostunnel 开源 TLS 代理支持双向认证，可热加载证书

一款名为 Ghostunnel 的开源代理工具近日受到关注。它专门为那些自身无法处理 TLS 的程序代管加密连接，在服务端模式下位于后端服务之前，接受 TLS 连接、校验客户端证书，再通过 TCP 或 UNIX 套接字把流量转给后端。

该工具以单个 Go 二进制发布，无运行时依赖，支持 Linux、macOS、Windows 和 BSD，采用 Apache 2.0 许可证，可在 GitHub 免费获取。

两种工作模式

Ghostunnel 的代理能力覆盖两个方向。服务端模式下，它部署在后端服务之前，接受 TLS 连接并校验客户端证书，随后通过 TCP 或 UNIX 套接字把流量转交给后端；客户端模式则相反，它监听本地明文连接，将这些连接包装进 TLS，并向远端服务出示客户端证书。

当两端各部署一个 Ghostunnel 时，双方都能证明自己的身份，而应用程序之间仍然以明文通信。这一设计针对的场景是：内部服务原本只说明文，后来某条链路被要求启用双向 TLS，但应用侧要么没有相应代码，要么相关实现掌握在厂商手中。Ghostunnel 把这项工作从应用中剥离出来，交给独立进程承担。

准入校验方式

在服务端模式下，代理不会在未声明准入规则的情况下启动。使用者至少要选择一种校验方式：证书的通用名、组织单位、证书中的 DNS 或 URI 名称、公钥固定，或者一项策略。多种方式可以组合使用，彼此之间为“或”的关系。

Ghostunnel 能够识别 SPIFFE ID；对于更复杂的需求，它会评估 Open Policy Agent 策略，该策略可以在隧道运行期间重新加载，无需中断服务。

证书来源与热加载

密钥和证书的来源较为多样，包括 PEM 或 PKCS 12 文件、macOS 钥匙串、Windows 证书存储、SPIFFE Workload API、PKCS 11 硬件模块（含 YubiKey），以及在服务端模式下通过 ACME 从 Let's Encrypt 获取。

证书会在收到 SIGHUP 信号或按定时器重新加载。这一机制使短期凭证具备实用性：证书轮换后，代理直接读取新证书，整个过程不需要重启任何组件。

安全默认与可观测性

Ghostunnel 有两项默认设置值得注意。除非传入 --unsafe-listen，它拒绝监听 localhost 或 UNIX 套接字之外的地址；对目标地址和 --unsafe-target 也适用同样的规则。在 Linux 上，它默认通过 Landlock 对自身进行沙箱隔离，除非使用者主动关闭该功能。

状态端口以 JSON 和 Prometheus 指标形式暴露运行信息，使隧道状态可以被现有监控体系看到。项目还提供 systemd 和 launchd 套接字激活，以及供后端获知原始连接信息的 PROXY protocol v2 支持。

要点

• 服务端模式先校验客户端证书再转发流量
• 客户端模式为本地明文连接套上 TLS 并出示客户端证书
• 准入校验支持通用名、组织单位、公钥固定和 OPA 策略
• 证书可来自 PEM、PKCS 12、SPIFFE、PKCS 11 及 ACME
• 默认仅监听本机或 UNIX 套接字，Linux 下启用 Landlock 沙箱