1. 加密服务概述:什么是加密服务,为什么需要加密,常见加密协议
大家好,我是这次课的讲师。做负载均衡这么多年,我见过不少因为加密配置踩坑的团队。在开始讲具体的均衡器和健康检查之前,咱们先把加密服务这件事聊透。你想想看,如果连基础概念都模糊,后面的优化策略基本就是空中楼阁。
1.1 什么是加密服务
加密服务,说白了就是一套把原始数据变成“乱码”再还原回来的机制。这乱码不是随便变的——它依赖算法和密钥。只有持有正确密钥的接收方才能解开。我以前带过一个新人,觉得加密就是“把文件压个密码包”,结果项目上线后密钥管理一团糟,回滚了两次才解决。
在负载均衡的场景下,加密服务通常部署在以下位置:
- 客户端到负载均衡器:比如 HTTPS 监听器,对外暴露公网端口。
- 负载均衡器到后端服务器:有些环境为了性能,会在内网使用明文回源,但敏感业务建议全链路加密。
- 节点之间的控制面通信:像 Consul 或 ZooKeeper 的 TLS 加密心跳。
核心要点:加密服务不是只保护传输的数据,还包括身份认证和完整性校验。三者合一才算完整的安全方案。
1.2 为什么需要加密
我经常被问到:“我们的内网有防火墙,还需要加密吗?” 我的回答很直接——需要。原因有三点:
- 数据机密性:防止第三方窃听。明文传输就像在明信片上写银行卡密码,任何人都能看。
- 数据完整性:防止中间人篡改。没有完整性校验,攻击者可以在你下载的安装包里植入恶意代码。
- 身份认证:确认通信对方的真实身份。没有证书验证,谁都可以假装成你的服务器。
我记得有次排查一个生产问题:用户登录后偶尔出现“此连接不安全”的警告。跟踪日志发现,是负载均衡器的证书链只配置了叶子证书,没有包含中间 CA 证书。浏览器拒绝信任,用户数据差点走明文回源。嗯,从那以后我强制团队把证书链完整性加进了部署 checklist。
避坑指南:我曾经遇到过某个海外节点因为使用自签名证书,被上游健康检查误判为“异常”,导致流量全被路由到另一个区域。后来我们在健康检查请求里加了独立 CA 验证,才彻底解决。
1.3 常见加密协议
从业这么多年,最常用的就那几个。我给你列个清晰的对照表。
| 协议 | 所在层级 | 典型应用 | 性能特点 |
|---|---|---|---|
| TLS/SSL | 传输层(TCP 之上) | HTTPS、MQTTS、SMTPS | 握手开销大,但后续对称加密快 |
| IPsec | 网络层(IP 包) | 站点到站点 VPN、远程接入 | 对上层透明,但配置复杂 |
| SSH | 应用层 | 远程管理、文件传输 | 交互式安全隧道,短连接效率高 |
| DTLS | 传输层(UDP 之上) | WebRTC、实时音视频 | 基于 UDP,抗丢包设计 |
| WireGuard | 网络层(新兴) | 现代 VPN | 内核级实现,极低延迟 |
TLS/SSL 协议
这是负载均衡器上配置最多的协议。TLS 1.3 减少了握手到 1-RTT,并废弃了不安全的密码套件。我建议生产环境至少启用 TLS 1.2,禁用 SSLv3 和 TLS 1.0/1.1。配置示例(Nginx 片段):
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
IPsec 协议
IPsec 有两个模式:传输模式和隧道模式。在负载均衡场景中,IPsec 隧道常用于连接不同云厂商的 VPC。我曾在混合云项目里用 IPsec 把阿里云和 AWS 打通,结果因为 IKE 版本不匹配(AWS 要求 IKEv2,阿里云默认 IKEv1),折腾了一整天。记住:两端必须协商一致的加密算法和认证方式。
IPsec 基本结构:
IKE 阶段1(主模式):证书/预共享密钥 + DH 交换
IKE 阶段2(快速模式):建立 IPsec SA,使用 ESP 头封装数据包
数据面:每个包加 ESP 头和尾,再加密。
其他协议
SSH 主要用于管理通道,但不适合高并发场景。DTLS 把 TLS 的可靠性降级到 UDP 上,适合 WebRTC。WireGuard 是后起之秀,代码量极小,内核集成后性能极佳,不过目前主流负载均衡器原生支持还不够多。
个人建议:如果你是新建系统,默认选 TLS 1.3 + ECDSA 证书。ECDSA 比 RSA 短很多,能减少握手包大小,对低带宽链路友好。
1.4 加密协议在 OSI 模型中的位置
下面这张图可以帮你快速建立空间感。我把常见加密协议按 OSI 层级排列,方便理解它们在网络栈中的位置。
从图上可以清楚看到:应用层的 SSH 和 TLS 需要应用程序自身支持;IPsec 工作在网络层,对整个 IP 包加密,负载均衡器不需要理解上层协议就能转发。这一点在做站点间 VPN 时特别有用——后端任何 TCP/UDP 流量都可以自动走加密隧道。
1.5 加密服务与负载均衡的关联
我最后点一下:为什么这本教程要把加密服务和负载均衡放在一起?因为当你用负载均衡器做 TLS 终结时,证书管理、会话复用、密码套件协商都会直接影响均衡策略。比如:
- Session Ticket 复用:负载均衡器是否在所有节点间同步 SSL 会话 ID?不同步会导致客户端每次请求都新建握手,影响性能。
- 证书轮换:AKS 或 ELB 如何热更新证书?我曾经因为证书轮换时没重启后端,导致健康检查认为后端 TLS 异常,流量全被导走。
- 密码套件降级攻击:负载均衡器如果不限制最低密码套件,攻击者可以强制使用弱加密。
这些细节我们将在后续章节里逐一拆解。先打好加密基础,后面学均衡器配置时你才能理解“为什么这里要这么配”。
小结:加密服务是数据安全的第一道防线,选对协议、配好证书、做好密钥管理,是负载均衡架构的基石。下一章我会带你看看负载均衡器是如何处理 TLS 握手的,以及我们怎么通过健康检查来验证加密通道是否可用。