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