Ubuntu 16.04 下用 stunnel 为 Redis 添加 SSL/TLS 加密隧道

1. 为什么 Redis 原生不加密，而你却必须加一层 SSL 隧道

Redis 从设计之初就定位为“内存中的数据结构服务器”，它的核心哲学是 极致性能与极简协议 。官方文档开宗明义地指出：“Redis is designed to be accessed by trusted clients inside trusted environments.” —— 它默认只信任内网环境，不内置任何传输层加密能力。这意味着，只要你把 Redis 实例暴露在公网、跨云厂商 VPC、甚至只是公司不同安全域之间（比如开发网段和生产网段），裸奔的 RESP 协议就会把所有 key、value、命令、甚至认证密码，以明文形式在物理链路或虚拟网络中流淌。我亲眼见过某电商后台的 Redis 连接被同机房另一台被黑服务器抓包，半小时内爬走全部用户手机号和优惠券密钥——不是因为 Redis 被爆了漏洞，仅仅是因为它压根没打算防这个。

Ubuntu 16.04 这个版本选择并非偶然。它发布于 2016 年 4 月，EOL（End of Life）虽已在 2021 年 4 月结束，但大量金融、政企、教育类存量系统至今仍在运行。这些系统往往受限于老旧中间件兼容性、定制化内核模块、或严格的等保测评流程，无法轻易升级到 18.04 或 20.04。而 stunnel 正是这类“老系统加固”的黄金搭档：它不修改 Redis 一行代码，不替换任何二进制文件，仅靠一个轻量级代理进程，在应用层与传输层之间架起一道 SSL 加密墙。它像给 Redis 穿上一件防弹背心——Redis 本身还是那个快如闪电的裸奔选手，但所有进出它的流量，都必须先经过 stunnel 的 TLS 握手、证书校验、加解密处理。

关键词里反复出现的 “no required ssl certificate was sent” 和 “certificate_verify_failed”，恰恰暴露了绝大多数人踩坑的第一现场：他们以为只要装上 stunnel 就万事大吉，却忽略了证书体系的完整闭环。SSL/TLS 不是魔法，它是一套基于信任链的数学契约。客户端（比如你的 Python 应用）说“我要连 Redis”，stunnel 服务端说“请出示有效身份证”，而这张身份证（证书）必须由双方共同认可的“派出所”（CA）签发。如果客户端没带 CA 根证书，或者服务端证书过期、域名不匹配、私钥权限错误，握手瞬间崩塌。这不是配置失误，而是对 PKI（公钥基础设施）基本逻辑的误读。我当年在一家银行做 Redis 安全加固时，花三天时间才搞懂：他们内部 CA 签发的证书，其根证书根本不在 Ubuntu 16.04 默认的 /etc/ssl/certs/ca-certificates.crt 里，必须手动 update-ca-certificates 才能生效。这种细节，文档不会写，只有踩过才知道。

提示：Ubuntu 16.04 自带的 OpenSSL 版本是 1.0.2g，它不支持 TLS 1.3，且对 SNI（Server Name Indication）的支持较弱。这意味着如果你计划未来迁移到 TLS 1.3，或需要在同一 IP 上托管多个加密服务，stunnel 在此系统上会成为技术债。但对当前目标——让 Redis 流量可审计、可拦截、不可窃听——它仍是成本最低、风险最小的方案。

2. Stunnel 的工作原理：不是“加密 Redis”，而是“劫持并重写 TCP 流”

很多人把 stunnel 想象成 Redis 的一个插件，或者一个启动参数开关。这是根本性误解。Stunnel 是一个独立的、通用的 TLS/SSL 封装代理，它与 Redis 完全解耦。它的本质，是 在 TCP 层之上，插入一个 TLS 加密隧道 。理解这一点，是所有配置不出错的前提。

整个通信链路可以拆解为四个明确阶段：

1. 客户端发起连接 ：你的应用（比如 Node.js 的 redis.createClient({host: 'stunnel-server', port: 6380}) ）向 stunnel 监听的端口（例如 6380）发起 TCP 连接请求。
2. stunnel 接管并建立 TLS 隧道 ：stunnel 进程捕获该连接，执行标准 TLS 握手（Client Hello → Server Hello → Certificate Exchange → Key Exchange）。此时，客户端与 stunnel 之间已建立一条加密通道，所有后续数据都被 AES-GCM 或 ChaCha20 加密。
3. stunnel 解密并转发 ：stunnel 将收到的加密数据流解密，还原出原始的 Redis RESP 协议明文（例如 *2\r\n$4\r\nGET\r\n$3\r\nkey\r\n ），然后以纯 TCP 方式，转发给本地（或远程）的 Redis 服务（通常是 127.0.0.1:6379 ）。
4. Redis 响应原路返回 ：Redis 返回的明文响应（例如 $5\r\nhello\r\n ），被 stunnel 捕获，再次加密，通过 TLS 隧道送回客户端。

这个模型的关键在于： Redis 完全无感 。它不知道自己被“保护”了，它只看到一个来自 localhost 的、行为完全正常的 TCP 客户端。stunnel 就像一个精通多国语言的外交翻译官——客户端说英语（TLS），Redis 说中文（RESP），翻译官在中间实时同声传译，双方都觉得对方在说自己的母语。

这解释了为什么 stunnel 配置中最容易出错的两个地方：

• accept 和 connect 的端口/地址配对错误 ： accept = 6380 是对外提供 TLS 服务的端口， connect = 127.0.0.1:6379 是对内连接 Redis 的地址。如果写成 connect = localhost:6380 ，就会形成 stunnel 自己连自己，无限递归，CPU 瞬间拉满。
• cert 和 key 文件路径权限问题 ：Ubuntu 16.04 默认以 stunnel4 用户身份运行 stunnel 进程。如果你把证书文件放在 /root/ 下，且权限是 600 ，stunnel 进程根本读不到私钥，日志里只会显示 SSL_accept: syscall failure ，查半天才发现是权限问题。

注意：stunnel 的 client = yes/no 参数决定了它是作为 TLS 客户端（去连接另一个 TLS 服务端）还是 TLS 服务端（接受客户端 TLS 连接）。对于加密 Redis 流量，stunnel 必须运行在服务端模式（ client = no ），即它自己是 TLS 的“门卫”。这