我有防火墙、LoadBalancer（IIS-ARR 负载均衡器）和 2 个 IIS Web 服务器。2 个 IIS Web 服务器将位于 LAN 中，具有私有 IP。我的网站托管在这两个 Web 服务器上。我面临的实际挑战是，我的网站中有一个支付网关，只有当请求来自网站名称（如www.abc.com) 或配置为 IIS-ARR 负载均衡器的公共静态 IP。
我有 4 个疑问：
当 2 个 Web 服务器中的任何一个处理 http 请求时，请求将来自分配给负载均衡器的网站名称/公共静态 IP。或者它将是 Web 服务器的私有 IP。
当 http 请求以明文形式在 LAN 内从负载均衡器流向真实服务器时，IIS-ARR 负载均衡器上的 SSL 卸载是否容易受到攻击。
在哪里为我的网站创建 SSL CSR 请求。在 IIS-ARR 服务器或两个 WebServer 中的任何一个上。需要多少个 SSL 证书。
如何在整个请求过程中保留 https (SSL)。从客户端浏览器到防火墙，然后是负载均衡器，然后是真实服务器。（无 SSL 卸载）
答案1
1. 客户端期望答案来自与它认为已使用防火墙外部地址启动的同一个 ssl 会话中。
客户端不知道防火墙是否将 tcp 流传递到其他设备（例如 SSL 终止负载平衡器）。它也不知道负载平衡器是否将终止的 SSL 会话传递到内部后端服务器（无论负载平衡器是以重新加密的 https 还是未加密的 http 形式将数据传递到后端服务器）。客户端只知道它以某种方式与 IP 地址建立了 SSL 会话，而该 IP 地址恰好是防火墙的外部 IP。
通过防火墙、负载平衡器和 SSL 终端层，请求一路到达后端服务器。但是，当后端准备响应时，如果后端服务器查看发送方 IP 地址并在那里看到客户端外部 IP 地址，它将直接响应客户端的 IP 地址。直接从后端发送到客户端的响应将在客户端发起并发送请求的 SSL 会话之外接收。客户端自然不会期待这样的响应并会拒绝它。
因此，为了确保答案通过客户端启动的 SSL 会话到达，负载平衡器必须在将请求传递给后端服务器之前对其进行调整。
它首先解密客户端 ssl 会话，然后修改原始请求，以便用属于负载均衡器的源 ip 地址覆盖源 ip 地址，然后再将请求发送到后端服务器。
后端服务器现在认为该请求源自负载均衡器并将其响应发送到负载均衡器而不是原始客户端。
负载均衡器再次修改数据，以便响应看起来来自负载均衡器而不是后端服务器。之后，负载均衡器将数据加密到它与客户端建立的同一 SSL 会话中，然后继续将响应直接发送给客户端。
客户端很高兴地接受了这一点并且没有注意到产生响应所采用的实际网络路径。
负载均衡器所做的这些 IP 修改被称为源 NAT（SNAT）并且对于我曾经使用过的所有负载均衡器来说都是常见的。
为了简洁起见，我没有包括公共和私有地址空间之间的防火墙转换。我建议将这个问题完全分开，以免混淆防火墙所做的重写和负载平衡器所做的重写。这是因为防火墙重写可以通过多种方式完成，一旦决定或缩小了防火墙品牌的选择范围，就值得提出自己的问题。在此之前，请将其视为当每个入站或出站数据包通过防火墙时发生的魔术。
验证上述正确设置的一个简单方法是首先使用内部客户端，并在客户端和负载均衡器之间以及负载均衡器和后端服务器之间配置未加密的 http 会话。
使用数据包嗅探器，例如Wireshark在客户端、负载均衡器和后端，人们可以看到这些重写在实践中对任何给定的请求/响应对以及每个网络部分的影响。
一旦设置工作正常并且理解了流程，就可以先加密客户端到负载均衡器的路径，然后加密负载均衡器到后端的路径。这是一项建议，旨在简化学习曲线并促进正确的最终配置。
需要注意的一点是后端服务器对请求的感知。
无论外部客户端的实际数量是多少，后端都会看到并仅记录一个客户端：内部负载均衡器 SNAT 地址。
这个困境是由负载均衡器对请求进行 SNAT 而产生的，通过让负载均衡器将实际客户端外部 ip 地址告知后端服务器来解决。由于请求源 ip 本身被修改，因此通过在 http 请求中插入 http 标头将真实客户端 ip 地址的信息传递给后端。
标题可以具有任何尚未使用的有效名称，常见的选择是转发。
配置负载均衡器以插入此类标头是此修复生效的首要要求，第二个要求是通知后端服务器此标头的存在。配置特定于负载均衡器和后端服务器的品牌，可轻松通过 Google 搜索。这里例如如何配置 tomcat 后端以从 x-forwarded-for 进行日志记录。距离我上次配置 ARR 已经过去很长时间了，我记不清 x-forwarded-for 是如何添加的，但我记得我花了一些时间进行实验和谷歌搜索才开始工作。
2）是的，由于如上所述，流量可以被协议解码器（例如 Wireshark）嗅探，因此存在攻击媒介。
这表明攻击者可以访问网络流量。
如果以明文发送负载均衡器到后端的流量，则排除负载均衡器或后端服务器配置错误的问题会更容易，但会带来上述风险。
如何做出这个设计选择是值得内部以及与外部利益相关者进行讨论的。
3) CSR 通常在 SSL 终止的地方制作。
要加密客户端到负载均衡器的流量，请在负载均衡器上创建 csr 请求。
要加密负载均衡器到后端的流量，请在后端服务器上创建 csr。
有多种方法可以将签名证书和相应的私钥导出为一个包，然后将其导入到不同的服务器上。这对于配置负载平衡器集群非常有用，因为所有成员都需要提供相同的证书，或者对于配置多个相同的后端以简化负载平衡器客户端 SSL 配置（即，负载平衡器在重新加密 http 数据时充当后端服务器的 SSL 客户端）。
4) 决定客户端 ssl 终止的位置。
在某些防火墙中可以终止 SSL，但更常见的是仅将 tcp 流通过防火墙转发到负载均衡器，然后终止客户端 ssl 会话。
还可以让负载平衡器对纯 tcp 流进行负载平衡，后端服务器会终止 ssl。这种情况并不常见，因此我不会在这里探讨该选项。
一旦初始 SSL 终止，就决定是否应重新加密数据，例如在负载均衡器和下一个跳转之间。下一个跳转可以是后端服务器或另一个负载均衡器或...
重复此步骤，直到数据以明文形式发送或到达链中的最后一台服务器。
终止 SSL 是负载均衡器能够插入 http x-forwarded-for 标头或执行其他需要访问明文数据的操作的必要条件。因此，通常在负载均衡器之前终止 SSL，或在负载均衡器上终止 SSL，或同时终止两者。
向后端发送加密流量和不加密流量也很常见。这完全取决于组织的情况和发送数据的用途。
SSL 卸载只是一个术语，描述一项技术代替另一项技术进行 SSL 加密/解密的过程。
它可以是一个负载均衡器，解密 SSL 并将明文传递到后端 - 后端已经卸载了 SSL。
它可以是一个负载平衡器，具有专用于 SSL 加密/解密的专用硬件电路 - 负载平衡器 CPU 已被 SSL 卸载。等等...