是否可以使用负载均衡器加密内部网络服务器之间的流量[关闭]

您始终可以加密属于已定义组的任何系统之间的流量。IPsec 传输模式是专门为此创建的。这些服务器承担哪些角色（后端、前端等）并不重要，在这种情况下它们只是 IP 节点。将此视为一种通用解决方案，它使“是的，有可能”成为所有问题的有效答案，例如“是否可以加密 A 和 B 之间的流量”。但是，有时它并不方便，因此通常还有其他选择。

其他选项取决于您需要此加密的目的。不要回答“只是为了安全”，没有“只是为了安全”这回事。有威胁模型，也有应对这些已定义威胁的安全模型。例如，简单来说，HTTP 的威胁模型是中间人，他可以窃听并注入自己的数据，将自己伪装成有效的服务器和/或有效的客户端；HTTPS 旨在通过对所有通信进行加密和签名来实现这一点。MitM 充其量可以通过所有流量而无法窃听或完全中断通信。那么，你在防御什么，你的威胁是什么？

您的后端和平衡器之间的网络不受信任？为什么？这些网络应该只包括平衡器和后端，而不包括其他任何东西，你那里有哪些不受信任的参与者？但是，在这种情况下，传输模式中的 IPsec 是可接受的解决方案，因为它将加密线路上的所有内容。

您还可以在平衡器和后端之间（以及后端本身之间）使用 HTTPS。没关系，您的平衡器将终止用户 HTTPS，以纯文本形式查看请求和回复，能够破坏它们（添加/删除/更改标头），并且能够通过分析内容来选择后端和处理，例如，选择一个后端用于静态内容，其他用于动态内容。然后它将建立另一个到后端的 HTTPS 连接。后端的唯一 HTTPS 客户端将是平衡器和其他后端，因此它们使用全局认可的证书并不重要。（例如，Google Frontends 不检查位于 Google Cloud 内的 HTTPS 后端证书，因此即使是自签名证书也可以使用。）您可以创建自己的内部 CA，为所有后端和平衡器颁发证书，并通过安装使它们受信任每个系统存储中的 CA 证书。只有平衡器需要配置全局有效的证书，并且仅在面向客户端的一侧。Let's Encrypt 自动化可能也是这些平衡器的职责，因为已颁发的证书将安装在它们上。

你不信任你的负载均衡器？SSL 直通可能会有所帮助，但它也有其自身的缺点。在此设置中，平衡器是创建 HTTPS 的中间人之一。因此它无法访问 HTTP 详细信息来平衡请求，甚至无法知道 http Host 标头值来区分 vhost；它不能注入额外的代理头，比如那些“代理”，等等；连接按预期受到保护。它所能做的就是希望跟踪连接，否则会盲目地将数据包转发到某个后端。在这种情况下，您无需在其上配置任何证书，甚至无需配置任何服务器名称。只需指定后端的 IP。此外，在这种情况下，必须在所有后端安装有效证书，因为事先不知道哪个后端将获得哪个请求。