通過 ALB 和 BIG-IP 在 Azure 中運行 FTP 服務

最近,有一位元客戶提問 Azure 負載平衡器 (ALB) 是否支持 FTP 通信,答案是肯定的!但要想實現這一點,就必須要有 F5 BIG-IP 的協助。FTP 服務的實施能夠很好地展示一些典型的雲端限制以及 BIG-IP 的功能。
09

簡介

最近,有一位元客戶提問 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

 

分析
我們在製作此演示時繪製了下圖:

B43(1)

上圖做了一些簡化,但總而言之,該圖主要在展示:

– 外層:防火牆設備。在演示中我使用的是 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 伺服器!