反向代理设置的陷阱

Question

我们运行多个 Web 应用程序，一些仅用于内部，一些内部/外部。我正在提出一个建议，即我们使用反向代理服务器来隔离源服务器、提供 SSL 终止和（如果可能）提供负载平衡。对于我们的大部分设置，我相信它会很好地工作，但是我们确实有一些鲜为人知的专有应用程序，当我们继续进行反向代理时可能需要特殊处理。

在将源服务器从前线转移到代理后时，哪些类型的陷阱会导致问题？（例如，如果应用程序需要知道传入请求的 IP 地址，我可以想象问题。）

Answer 1

最常见的陷阱是在应用程序中生成的重定向，您必须在反向代理中重写，您已经说过的客户端 IP 地址问题，如果使用 ssl 终止可能服务器想要检查客户端证书或从中获取用户信息。对于正确的边缘反向代理缓存，可能需要修改应用程序（适当的过期标头、取消设置不需要的 cookie 等）。如果您使用的是 Windows 集成身份验证，这可能是无法实现的，或者是一场真正的噩梦

那么你可能会遇到调整问题，但我认为这些问题会更容易解决。我对这项任务的首选工具集是：

• 外层的 Nginx 用于虚拟主机管理和位置映射、压缩、ssl、访问日志
• 用于缓存的清漆
• haproxy 用于请求排队、负载平衡和后端检查。
• 如果您需要高可用性，反向代理框 keepalived 可以完成这项工作

Answer 2

反向代理背后的应用程序可能会遇到的问题：

1. 如果语言或应用程序使用 IP 地址来保持会话，则到达应用程序的唯一 IP 地址将是代理地址。使用nginx并且varnish您可以添加X-Forwarded-for带有原始 IP 地址的标头并使应用程序识别它。
2. 负载平衡环境中的会话处理很棘手。您必须为服务器使用共享资源来保存它们的会话信息，以便登录的用户可以访问负载平衡应用程序的任何后端并保持其会话。数据库和 Memcached 是会话共享的流行选择。
3. 如果反向代理应用程序在其响应中使用绝对 URL，则它们可能会破坏代理上的重写。即执行 302 重定向到与代理不同的 URL 的应用程序。

我目前在前端使用nginx并在其后面使用清漆来进行代理和负载平衡/后端检查。作为单点故障，在反向代理/负载均衡器上使用集群解决方案非常重要。

我使用corosync/pacemaker（Linux HA，最新版本）对负载平衡器进行负载平衡：三个负载平衡器，每个负载平衡器都有一个外部 IP 地址，RR 使用 DNS 平衡（一个名称指向三个 IP 地址）。如果其中一台机器停机，则指定给它的 IP 地址由 corosync 移动到另外两台机器之一。此外，如果我添加更多机器/IP 地址，它们会自动平衡，如果除一台机器之外的所有机器都关闭，所有 IP 都将位于打开的机器上。您可以使用 corosync 进行主动-主动、主动-被动和许多其他集群配置。