白皮书

负载均衡 101:防火墙三明治

Updated May 18, 2010
  • Share via AddThis

简介

从历史上看,基于网络的硬件负载均衡器及其现代化身,应用交付控制器 (ADC) 最常见的用途是为后端应用提供高可用性、可扩展性和可管理性,尤其是在演示层。紧随其后的是为其他网络基础架构组件(如路由器和防火墙)提供同样的优势。部署防火墙,特别是在应用交付控制器之后部署防火墙具备诸多优势(其他用途请参见白皮书《负载均衡 101:向应用交付控制器的演变》)。本白皮书将向您说明如何在“防火墙三明治”中实施 ADC,从而提高整个 IT 基础架构的可用性、可扩展性和可管理性。

可用性

对防火墙实施负载均衡的一个主要原因是确保防火墙后所有服务的高可用性。提供某种形式的冗余有助于确保企业基于网络的服务始终可用。虽然这可以通过简单的主动/被动防火墙集群解决方案轻松实现,但使用基于硬件的 ADC 的一个好处是,相同的设备可以提供对服务可用性更好的可视化,并可逐步按服务器进行服务故障转移。

例如,在基于代理的防火墙上,假设只有 SMTP 进程变得无响应。主动/被动防火墙集群解决方案通常无法识别此类故障。如果能够识别,唯一的办法就是将所有连接中断,过渡到备用防火墙,这可能会限制在其他服务上工作正常的连接。ADC 不仅提供对个别服务的监控,而且还能够在不影响所有其他连接的情况下,将个别服务(如 SMTP)故障转移到备用防火墙。

可扩展性

主动/被动防火墙群集解决方案的另一个缺点是不能很好地进行扩展。一旦超过单个防火墙的容量,唯一的选择就是用更大容量的防火墙替换,处理增加的负载。而 ADC 则可以在必要时轻松增加其他防火墙来处理增加的负载。

ADC 的智能性还使公司能够根据服务需求来扩展容量。例如,假设像许多企业一样,您的公共网站的流量正在显着增长并给防火墙造成压力。相较于升级所有防火墙,您可以使用 ADC 将所有网站流量转移到专用防火墙上,而无需改变网站配置的任何其他方面。这使您能够独立地将公共网站的安全基础架构与企业的其他网络环境的安全需求分开进行扩展,并使网站流量不影响其他关键业务应用。

可管理性

最后,ADC 在管理防火墙方面提供了很大的灵活性。 因为它们可以通过多种方式快速智能地将流量定向到服务级别,所以可以用来进行维护(例如,将流量从需要离线工作的防火墙上转移);执行软件、硬件和策略的升级(例如,将用户切换到新系统,如果出现问题,将流量送回旧系统,直到问题解决为止);以及为不同的业务组、计划或其他需求在不同的防火墙之间划分流量,对现有流量几乎无影响。ADC 可用于执行 SSL 解密,从而使防火墙能够正确执行加密通信(如 HTTPS)的策略。当管理员选择通过入侵检测系统 (IDS) 或入侵防御系统 (IPS) 对流量进行路由时(可先于或晚于遍历防火墙本身),解密流量会大有帮助。

防火墙三明治的基本设计

防火墙三明治这个名称反映了大多数负载均衡防火墙实施所使用的基本设计(参见图 1)。由于防火墙本身很少是客户端连接的预期终点,因此必须双向(入站和出站)透明地引导流量通过防火墙。因此,防火墙的两侧都需要 ADC 设备,就像三明治的面包要夹裹着馅料一样。

这种设计需要注意几点。首先,要留意除了互联网路由器的外部接口外,整个基础架构都建立在不可路由的 IP 地址空间。这使得对网络的攻击很难从 Internet 下手。

图示
图 1:基本的防火墙三明治设计

第二,注意 ADC 对 #1 的虚拟服务器在 0 端口。端口 0 是“所有端口”的简写(就像 0.0.0.0 是所有网络的简写一样)。您当然可以在每个要接收流量的端口配置多个虚拟服务器,并简单地阻止 ADC 的所有其他流量,但使用端口 0 可以减少在添加新服务时所需的配置量。此外,通过在防火墙之前阻止流量,防火墙日志(或与之相关的 IDS)无法完整地了解发送到网站的流量。ADC 对 #2 有特定的虚拟服务器,用于 80 端口(Web 流量),因为它负责向后端运行 80 端口的 Web 服务器分配流量。您也可以直接使用端口 0,但更严谨的用途才是常见的做法,但有大量的重复服务在所有后端服务器上运行是特例。

最后,如果查看 ADC 对 #2 的网关 (GW),您会注意到它实际上是一个池,或“反向虚拟服务器”,将流量分布在所有三个出站防火墙。这在首次连接后防火墙发生故障的情况下,可以提供高度可用的出站路由;但是,您可能会遇到非对称路由的问题(请参见本文档后面的非对称路由章节)。

典型流量:入站

在典型的 Web 服务器负载均衡解决方案中,ADC 配备一个用作客户端流量终点、可以终止请求然后将其直接分发到托管应用服务器的虚拟服务器(参见白皮书《负载均衡 101:螺母和螺栓》)。在上一张图中,与网站 (www.example.com) 相关联的 192.0.2.5 的有效 Internet IP 地址,从技术角度而言,不会存在于任何设备的任何接口上。那么用户要如何连接到 Web 服务器呢?解决的办法需要“网络”或“通配符”虚拟服务器、普通虚拟服务器,再加上一点路由技术。如要遵循流量:

  1. 用户请求 www.example.com,解析到 192.0.2.5:80。
  2. 客户端首次请求网站。
  3. SYN: 192.168.1.1:5000 ? 192.0.2.5:80
  4. 由于 example.com 拥有 192.0.2.0 网络,所以客户端的数据包通过 Internet 路由到 www.example.com 的 Internet 路由器。
  5. 路由器 1 有路由条目,可以说明 192.0.2.0 网络的下一跳路由是 172.16.1.5,即 ADC 对 #1 的共享外部接口。
  6. SYN: 192.168.1.1:5000 ? 192.0.2.5:80 next hop router 172.16.1.5
  7. ADC 对 #1 有一个网络虚拟服务器,可以监听要传输到整个 192.0.2.0/24 网络的流量,并将其配置为不做地址转换。该虚拟服务器将流量分配到三个防火墙,根据需要进行负载均衡,并将请求路由到选定的防火墙。
  8. SYN: 192.168.1.1:5000 ? 192.0.2.5:80 next hop router 172.16.2.10
  9. 防火墙所配置的路由表明在到达 192.0.2.0 网络的下一跳是 172.16.3.5,也就是 ADC 对 #2 的共享外部接口。
  10. SYN: 192.168.1.1:5000 ? 192.0.2.5:80 next hop router 172.16.3.5
  11. ADC 对 #2 有一个普通的虚拟服务器监听指向 192.0.2.5:80 的流量,当接收到连接时,它会在后端应用服务器上进行负载均衡连接。
  12. SYN: 192.168.1.1:5000 ? 192.0.2.5:80 becomes
    SYN: 192.168.1.1:5000 ? 172.16.4.11:80
  13. 由于 ADC 对 #2 在 172.16.4.0/24 网络上有一个接口,所以只需将数据包发送给响应的服务器。

典型流量:出站

出站流量与典型部署并无太大区别,只是要选择合适的防火墙,最好使用与原始入站连接所用相同的防火墙(参见本文稍后提及的“实施潜在问题”)。如要遵循默认路由一直到 Internet:

  1. 服务器响应请求并将数据包发送到其正常的默认网关。
  2. SYN/ACK: 172.16.4.11:80 ? 192.168.1.1:5000 default GW 172.16.4.5
  3. ADC 对 #2 将其识别为负载均衡的连接返回,并重写地址。
  4. SYN/ACK: 172.16.4.11:80 ? 192.168.1.1:5000 becomes
    SYN/ACK: 192.0.2.5:80 ? 192.168.1.1:5000
  5. ADC 对 #2 现在可以选择使用哪个防火墙来返回数据包。此处会受到许多决定因素的影响,但在此示例中,它将把数据包路由回最初传来 SYN 的防火墙。
  6. SYN/ACK: 192.0.2.5:80 ? 192.168.1.1:5000 ? route via 172.16.3.10
  7. 防火墙 1 收到响应后,只需通过其默认路由转发该数据包。
  8. SYN/ACK: 192.0.2.5:80 ? 192.168.1.1:5000 ? route via default GW 172.16.2.5
  9. 路由器 1 在其内部接口上接收数据包,并通过其默认路由将数据包转发到 Internet。
  10. 最后,客户端会接收响应。
  11. SYN/ACK: 192.0.2.5:80 ? 192.168.1.1:5000

实施中的潜在问题

此配置会涉及几个潜在的问题,包括处理加密流量、避免非对称路由,以及随着防火墙接口数量的增加而带来的管理复杂性。

加密流量

如果客户端连接是 HTTPS 而非 HTTP,则流量在穿过防火墙时仍将对其加密,从而阻止防火墙进行任何形式的有效负载检查。解决这个问题最简单的办法是在 ADC 对 #2 内实施应用防火墙,或者在解密内容后,让 ADC 将其转发到 IDS/IPS/WAF,然后再发送给实际应用。如此一来,便可以使用完全相同的配置,并在防火墙边界内处理所有安全问题。

第二种解决方案涉及配置 ADC #1,以便在数据包传送到防火墙之前对其进行解密。有几种方法可以做到这一点,但由于解密是在防火墙外围进行,所以一般不推荐这种解决方案。

非对称路由

另一个常见问题与通过防火墙的非对称路由有关。当入站数据包通过防火墙,但返回的数据包却通过不同的防火墙时,就会产生问题。通常情况下,有状态检查防火墙具备一定规则,允许发起连接,然后只允许属于该建立连接的数据包通过。如果返回的数据包进入不同的防火墙,则会被拒绝。在这种情况下,可采纳几种解决方案。

一个解决方案是启用防火墙之间的共享状态,以便所有防火墙都会知道连接的状态,从而允许出站数据包通过。这种解决方案虽有合理性,但并非适用于所有防火墙,因为随着防火墙数量的增加,这往往会导致性能问题。此外,共享状态可能会对可扩展性造成损害,因为它会将整个防火墙集群限制在单个设备的状态表容量内。从正面角度而言,如果防火墙发生故障,可以轻松转移所有现有连接而不必重新创建所有状态信息,这也是许多企业宁可采用其他方式解决此问题也要共享状态的理由所在。

非对称路由的另一个比较常见的解决方案是使用持久化。通常,这代表要确保 ADC 对 #1 始终要将连接发送到原来的同一个防火墙,或者 ADC 对 #2 要一律将连接发送到同一个 Web 服务器。在这种情况下,还必须确保 ADC #2 要记住哪个防火墙(通过 IP 或媒体访问控制 [MAC])向其发送了原始连接,以便可以将返回数据包发送回该防火墙。实质上,这相当于要保证在建立首个连接后,通过消除动态负载均衡,就可以确保不发生非对称路由。

通常借助两种方式之一即可实现这点。第一种方式只对 HTTP 流量有效,即将 HTTP Cookie 插入 ADC 对 #1,让 ADC 对 #2 了解要返回哪个防火墙的流量。由于这种方式只对 HTTP 奏效(即使是 HTTPS 也不行,除非在 ADC 对 #1 处破坏加密),因此除非 ADC 无法支持其他方式,否则不会采纳这种方式。

大多数 ADC 供应商均能够支持“最后一跳”或“反向持久化”。借助这点,ADC #2 会创建其他连接状态条目,由此了解发送原始请求设备的 MAC 地址。ADC #2 并非传统意义上的路由,而只是将流量转发到接收流量防火墙的 MAC 地址。

图示
图 2:通过 MAC 最后一跳返回路由

从原始流量来看(参见图 2),前往 192.0.2.5:80 的虚拟服务器的入站流量在 ADC 对 #2 处终止。发生此种情况时,ADC 对 #2 为了维持该连接,会生成状态表条目。这通常会包括低级别 TCP 连接特性以及(由于持久化设置)选择用来接收该流量的服务器 IP。如果具有最后一跳功能,ADC 还会记录所接收数据包的防火墙 MAC 地址,此次是 01:23:45:67:89:ab。

当选定的服务器响应并将流量发回 ADC 时,ADC 不会进行正常的路由查找,而是会检查状态表,查看 MAC 条目,并将数据包转发(将源目的地改回虚拟服务器的 IP 后)到与客户端的目标 IP 指定的 MAC 地址。在大多数 ADC 实施中,这属于自动默认配置,无需用户交互。

增长与复杂性相依

上一节中的设计并不复杂;不过,所提及的防火墙只有两个“支撑”,或者说是两个接口(分别是内外部接口)。许多防火墙实施至少有三个,甚至更多的设计。为了充分使用这种设计,每个支撑上必须对应一个 ADC 型设备,以确保流量可以实现正确双向路由。随着接口数量的增加,可能会导致复杂性加大和故障排除难度加剧。虽然设计基本相同,而且已经成功部署多达 8 个支撑的防火墙三明治,但复杂性依旧是潜在的问题。

从防火墙故障中恢复

防火墙出现故障时会发生什么?显然,如果防火墙在初始客户端连接之前发生故障,ADC 将简单地把客户端连接重定向到正在工作的防火墙。请记住,有了这种设计,便可以按服务实现这点。如果防火墙不能处理 SMTP 流量,但仍然可以处理 HTTP,ADC 将继续向防火墙发送 HTTP 事务,但它将向其他防火墙发送 SMTP 流量。有两种故障会导致潜在问题:1) 故障发生于防火墙传送入站数据包后,传送返回数据包之前;2) 故障发生于防火墙建立完整的连接并被使用后。

在前一种情况下,问题是 ADC 对 #2 会希望将流量发回源防火墙,而此时该防火墙已经发生故障。好在这种情况下,客户端连接将超时,客户端将尝试重新发送连接请求,此时入站请求将通过正常运行的防火墙,从而解决了该问题,对用户几乎不会有影响。

实际上,后一种情况对客户体验的影响更大。确保要连接到正常运行的防火墙这点并无不同。然而在这种情况,无论方向性如何(入站还是出站),数据包最终都会传输到对此连接毫不知情的防火墙。除非防火墙之间实现了共享状态,否则连接将失败,客户端需要重新连接并重新开始会话。从积极角度而言,这其实只影响到了长期限的 TCP 连接,即使在这种情况下,一旦用户重新连接,他们将再次连接到服务;尽管 FTP 会受到影响,但 HTTP v1.0 很可能根本不受影响。

值得注意的是,实施全代理的 ADC(与客户端和服务器的独立连接),至少从客户端的角度来看,有一些解决方案可以缓解,甚至解决这些故障。以客户端连接在 ADC 对 #1(与服务建立自己的连接)处终止的情况为例:如果防火墙发生故障,必须重新发起连接,则需要重新启动的是 ADC 对 #1 和服务器之间的连接(不一定是来自客户端的连接)。虽然这需要几个非标准配置,并取决于个别协议,但这种解决方案可以很容易地从客户端解决防火墙故障。

这种整体解决方案的真正好处之一是,一旦有问题的防火墙重新投入使用,它将立即可以用于新的连接,而且不会对用户产生额外的影响。

结论

虽然本文所介绍的配置是数百种潜在部署选项中最简单的示例,但却足以说明在应用交付控制器之后部署防火墙的好处。您的部署最终将取决于企业自身的具体需求和现有的基础架构,还应将采购、运营和管理成本考虑在内。

防火墙三明治这种基本概念可以用来管理跨许多透明和半透明设备的流量(不管是否有状态,比如 SSL 加速器、IDS/IPS、路由器和代理服务器),包括所有需要更佳可用性、可扩展性和可管理性的内联设备。