簡介
最近，有一位元客戶提問 Azure 負載平衡器 (ALB) 是否支持 FTP 通信，答案是肯定的！但要想實現這一點，就必須要有 F5 BIG-IP 的協助。FTP 服務的實施能夠很好地展示一些典型的雲端限制以及 BIG-IP 的功能。
問題陳述
客戶目前在本地使用企業級商用 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 中繼續延續這一做法。
演示
點擊此處，查看 GitHub 存儲庫並部署到 Azure：
https://github.com/mikeoleary/azure-f5-lb-ftp
分析
我們在製作此演示時繪製了下圖:
上圖做了一些簡化，但總而言之，該圖主要在展示：
– 外層：防火牆設備。在演示中我使用的是 F5 設備，但客戶（或您）可能會選擇協力廠商防火牆作為外層。
– 內層：BIG-IP 設備。這些設備使用 FTP 設定檔保護和代理 FTP 通信。
– 應用層：我僅為此次演示繪製了一個 FTP 應用伺服器，但毫無疑問您可以在 F5 BIG-IP 設備後面設置許多伺服器。可將最後一層設置為雙活模式，應用多層的設置也是如此（例如添加資料庫）。我在 Linux 上實施 vsftp，而不是客戶使用的商業產品。
技術概覽
下面我們來看一下以上問題的解決辦法。
– 圖中的外層僅部署了 FastL4 類型的 F5 VE，它們可以接收流量並通過 TCP 埠 20、21、22、80、443 和 5000-5003 進行傳輸。
– 它們只提供在第 4 層上代理的流量，不在應用層進行檢測。
– 內層 BIG-IP 設備使用了一個 LTM FTP Profile。
– 它使用了我基於此處（https://clouddocs.f5.com/api/irules/FTP__port.html）示例編寫的 iRule。這樣我們可以將 5000 個埠中的資料埠重寫為一個更易於管理的編號。
– 為了獲得更強大的保護，ASM 可使用 FTP Profile來抵禦其他類型的 FTP 攻擊。（https://techdocs.f5.com/kb/en-us/products/big-ip_asm/manuals/product/asm-implementations-12-1-0/40.html）。
– 設置 ALB 規則以及網路安全性群組 (NSG) 規則，以支援我們定義的埠範圍。這既滿足了我們對 ALB 的要求，又解決了與埠範圍相關的難題。
– 在 F5 中創建更多應用伺服器並實施負載均衡即可輕鬆獲得高可用性。F5 本身便可通過設備服務群集獲得高可用性。
– 在演示的 Web 應用用例中，內層還代理了埠 22 (SSH) 以及 80 和 443 (HTTP 和 HTTPS)。這些埠不是 FTP 運行所必需的，但設置之後可方便演示。
在演示中，我將埠範圍縮小到 4 個資料埠（tcp/5000-5003），但繁忙的網站可能需要更多埠。只要不超過 1500 的上限即可。
實際應用場景
我在創建該演示時使用了此處的 F5 Networks 演示範本。如果再來一次，我會只使用相關的範本，而不是直接套用一個大範本，但這個演示也完全可用。
關於生產環境，您需要謹記以下要點：
– 永遠不要在公開共享網路上公開您的管理介面。此處展示僅用於演示目的。
– 使用您自己的由公共 CA 簽名的有效 SSL 證書。
– 對於雲資源的部署，我創建了一個大的 ARM 範本，但如果再來一次，我會創建子範本，或者使用 Ansible 或 Terraform 之類的部署工具來部署雲資源，然後對其進行配置
– 此演示需要使用 EVAL 金鑰。在撤銷環境之前，不要忘記撤銷您的 EVAL 金鑰。否則，您將需要撥打 F5 支援電話，請求解鎖金鑰。
– 在此演示中，由於採用了默認路由和內聯設備，您需要從內而外的撤銷。
為何需要 F5？
基礎負載平衡器和全代理有什麼區別？在這個場景中，選擇 F5 的一大原因在於它的企業級特性。例如，當流量經過 BIG-IP 時，我們不僅實施負載均衡，而且還重寫埠、按需動態打開新埠、有選擇地執行安全性，並提供許多其他應用服務。經常有人問我們為何 F5 跟基礎負載均衡服務有很大的差異，這就是一個很好的例子，F5 的一些功能不是單靠基礎負載平衡器就能實現的。
結語
希望這個演示環境能讓您更清楚，如果您使用 BIG-IP 和相關應用服務來提供安全性、可用性和性能，那麼您就可以透過 Azure 負載平衡器在 Azure 中運行 FTP 伺服器！