作者： Michael OLeary

本文主要阐述了通过 ALB 和 F5 BIG-IP 在 Azure 中运行 FTP 的实例探讨。

01 简介

最近，有一位客户问我 Azure 负载均衡器 (ALB) 是否支持 FTP 通信，答案是肯定的！但要想实现这一点，就必须要有 F5 BIG-IP 的相助。FTP 服务的实施能够很好地展示一些典型的云限制以及 BIG-IP 的作用。

02 问题陈述

客户目前在本地使用企业级商用 FTP 服务器，他们希望将其迁移到 Azure。目前，他们支持 FTP 主动和被动连接，并已将被动 FTP 数据端口锁定为 5000。数量虽多，但在本地部署中很常见。

初期需要克服的挑战：

• ○分层架构： 考虑到本地采用的是传统架构，为了在 Azure 通过复制实现一致性，他们打算在 BIG-IP 层的前面安装一个面向互联网的防火墙。这样入站 FTP 客户端流量将先流经防火墙，然后再通过 Azure 负载均衡器提供服务。

• ○端口： 如果您曾经使用过 FTP，那么您肯定知道 FTP 使用一个控制通道（通常是端口 21）和多个数据通道（通常是随机的高位数端口，有时会锁定在一定范围内）。

• ○主动 FTP： 要求流量从服务器返回至客户端。然后，客户端通常在目标端口 20 上与服务器通信。

• ○被动 FTP： （如今更为常见）要求客户端与服务器建立这些连接，端口范围不固定。

• ○每个 ALB 规则 只允许打开一个端口。当端口范围在 5000 以内时，使用不同的 ALB 规则打开端口将会打破

  （当前）Azure 1500 的上限。（https://github.com/MicrosoftDocs/azure-docs/blob/master/includes/azure-virtual-network-limits.md）

• ○ALB 限制： 内部 ALB 可以使用在所有端口上监听的规则，但外部 ALB 却不可。他们打算在防火墙设备前面安装一个外部 ALB，让他们的客户端通过互联网访问 FTP 服务器。

• 传统 IT： 受 Azure 限值的影响，他们无法轻松地将这一端口范围缩小到可管理的程度，其中一部分原因就是采用了传统架构。

• ○高可用性要求： 他们在本地对双活 FTP 服务器实施了负载均衡，并希望在 Azure 中继续延续这一做法。

  
  

  03 演示

  点击此处，查看 GitHub 存储库并部署到 Azure：
  

  https://github.com/mikeoleary/azure-f5-lb-ftp

  
  

  04 分析

  我在制作此演示时绘制了下图:

  
  

  上图做了一些简化，但总而言之，该图旨在展示：

  • 外层：防火墙设备。在演示中我使用的是 F5 设备，但客户（或您）可能会选择第三方防火墙作为外层。

  • 内层：BIG-IP 设备。这些设备使用 FTP 配置文件保护和代理 FTP 通信。

  • 应用层：我仅为此次演示绘制了一个 FTP 应用服务器，但毫无疑问您可以在 F5 BIG-IP 设备后面设置许多服务器。可将最后一层设置为双活模式，应用多层的设置也是如此（例如添加数据库）。我在 Linux 上实施 vsftp，而不是客户使用的商业产品。

    
    

  05 技术概览

  下面我们来看一下以上问题的解决办法。
  

  • 1.图中的外层仅部署了 FastL4 类型的F5 VE，它们可以接收流量并通过 TCP 端口 20、21、22、80、443 和 5000-5003 进行传输。

  • 2.它们只提供在第 4 层上代理的流量，不在应用层进行检测。

  • 3.内层 BIG-IP 设备使用了一个 LTM FTP Profile。

  • 4.它使用了我基于此处（https://clouddocs.f5.com/api/irules/FTP__port.html）示例编写的 iRule。这样我们可以将 5000 个端口中的数据端口重写为一个更易于管理的编号。

  • 5.为了获得更强大的保护，ASM 可使用 FTP Profile来抵御其他类型的 FTP 攻击。（https://techdocs.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-12-1-0/40.html）。

  • 6.设置 ALB 规则以及网络安全组 (NSG) 规则，以支持我们定义的端口范围。这既满足了我们对 ALB 的要求，又解决了与端口范围相关的难题。

  • 7.在 F5 中创建更多应用服务器并实施负载均衡即可轻松获得高可用性。F5 本身便可通过设备服务群集获得高可用性。

  • 8.在演示的 Web 应用用例中，内层还代理了端口 22 (SSH) 以及 80 和 443 (HTTP 和 HTTPS)。这些端口不是 FTP 运行所必需的，但设置之后可方便演示。

  在演示中，我将端口范围缩小到 4 个数据端口（tcp/5000-5003），但繁忙的站点可能需要更多端口。只要不超过 1500 的上限即可。

  
  

  06 实际应用场景

  我在创建该演示时使用了此处的 F5 Networks 演示模板。如果再来一次，我会只使用相关的模板，而不是直接套用一个大模板，但这个演示也完全可用。

  关于生产环境，您需要谨记以下要点：

  • ○永远不要在公网上公开您的管理接口。此处展示仅用于演示目的。

  • ○使用您自己的由公共 CA 签名的有效 SSL 证书。

  • ○对于云资源的部署，我创建了一个大的 ARM 模板，但如果再来一次，我会创建子模板，或者使用 Ansible 或 Terraform 之类的部署工具来部署云资源，然后对其进行配置

  • ○此演示需要使用EVAL密钥。在撤销环境之前，不要忘记撤销您的EVAL密钥。否则，您将需要拨打F5支持电话，请求解锁密钥。

  • ○在此演示中，由于采用了默认路由和内联设备，您需要从内而外的撤销。

    
    

    07 为何需要F5？

    基础负载均衡器和全代理有什么区别？在这个场景中，选择 F5 的一大原因在于它的企业级特性。例如，当流量经过 BIG-IP 时，我们不仅实施负载均衡，而且还重写端口、按需动态打开新端口、有选择地执行安全性，并提供许多其他应用服务。经常有人问我为何 F5 不等同于基础负载均衡服务，这就是一个很好的例子，F5 的一些功能不是单靠基础负载均衡器就能实现的。

    
    

    08 结语

    希望这个演示环境能让您明白，如果您使用 BIG-IP 和相关应用服务来提供安全性、可用性和性能，那么您就可以通过 Azure 负载均衡器在 Azure 中运行 FTP 服务器！

  
  

  04jishu