作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化暨分散式安全防護技術方案的介紹與推廣。

使用NSX於跨中心方案內的另一個重要優點，而在傳統實體方案不容易達成的，是可以利用NSX的通用分散式防火牆 (Universal Distributed Firewall) 進行跨不同vCenter環境的東西向微分段集中防護。請大家思考，如果我們要設計一個二層業務網路連通，虛機可以飛來飛去或是備援的跨中心方案，前面我們都著重在二層三層網路面的討論，但在安全面上，如果仍然採用傳統的實體安全設備，此時幾個問題絕對會浮出，討論如下

首先，防火牆等安全設備是具備連線狀態 (Stateful) 的，這代表業務進出的連線都必須要持續通過同一台實體設備，不能左去右回。此時跨中心的架構設計會變成相當複雜，不然就是不優化。在下圖為例，原本Site A內的Web / AP / DB間安全防護可以透過左邊的防火牆進行

如果我們把整個業務遷移到右邊，而且整個業務連線要Online不要中斷…此時架構內的唯一選擇，是讓業務間的連線繼續過左邊的防火牆。走右邊防火牆的話，這是一個全新的連線，業務間網路會中斷的。也就是說，虛機飄移時，

  • 要不然網路流不優化，如下圖所示
  • 要不然業務會斷線，管理者僅能採用Offline遷移

好，那大家就決定改用Offline的方式好了，比如說災備發生的時候，再來搭配SRM進行業務備援重啟。但也沒有這麼單純：如果業務可能在左邊跑，也可能到右邊跑，那兩邊的防火牆Policy是不是必須要一模一樣？此時，原本資安Team管左邊的防火牆可能已經很累了，任何的業務異動時，還要考慮其他資料中心的防火牆政策也要同時更改喔，像下面這樣。

上面的示意圖很單純，實際多中心的實體安全設計會更複雜，但相信大家能夠理解我們要表達的意思。因此，如果讀者已經熟悉NSX的微分段技術，當我們可以在Cross-VC NSX架構內採用分散式防火牆，管理者可以取得下列效益：

  • 跨中心的業務網路東西向（想要的話也可以南北向）微分段防護
  • 防火牆政策及連線表跟隨虛機飄移，虛機 vMotion / HA / DRS等狀況不影響安全防護。管理者不用一直考慮『如果我的虛機飄到哪邊，網路流要怎麼導到安全設備上』這個問題
  • 防火牆政策跨vCenter集中管理，多資料中心環境安全防護政策自行同步

上面談到的好處，是不是直接對應到原本實體架構不容易做到的缺陷呢？在一個高度虛擬化的跨中心方案內，我們衷心推薦大家考慮導入這個機制來進行虛機間安全防護。

要配置Universal Distributed FW Rule的方式很簡單：管理者只要先在防火牆介面內，建立一個到多個的Universal DFW Section。這些防火牆Section一定位於整個防火牆配置的最前面優先進行比對，而新增時，只要選取”Mark this section for Universal Synchronization”，這個Section就會變成通用防火牆區塊，而所有在此Section內建立的規則，就都會是配置到所有Cross-VC NSX 領域內的通用規則。

其他的防火牆配置方式很直覺，大家請自行在測試環境或是VMware HoL內進行驗證吧。但我們繼續要和大家談的是通用分散式防火牆的技術限制。熟知NSX安全方案的讀者想必清楚，微分段技術除了能進行以虛機為單位的東西向防護，另一個更棒的特性是能夠和虛擬化環境管理整合，而藉此

  • 可以直接把虛擬化物件，比如說虛機、叢集、Port Group、資源池等作為防火牆來源與目的地，直接與網路地址脫鉤
  • 可以建立安全群組，採用動態條件比如說虛機的名稱、或是指定的安全標籤等等，動態將虛機加入防護的目標，達成安全自動化

但在Cross-VC NSX環境內，上述的好處受到了極大的限制，這並不是單純地只是技術還沒做出來，而是實際架構的問題。用下面的例子舉例，如果我們有一台VM-A在Site 1，VM-B在Site 2，兩個虛機在同一個二層網段內。我們要用分散式防火牆進行VM-A與VM-B之間的阻隔。此時，如果是在原本單一vCenter的環境內，防火牆規則很簡單：

在NSX的運作裡是這樣的

1. 與vCenter詢問VM-A與VM-B的UUID，並採用VMtools / Spoofguard的方式，查出對應的IP地址

2. 將IP地址寫成防火牆規則，發送到每一台vSphere Host

好，但是在Cross-VC的環境內，有多台vCenter與多台NSX Manager。狀況來了，上面的例子，當Site 1內的NSX Manager 1進行查詢時，vCenter 1知道VM-A是誰，但問題來了，VM-B不歸vCenter 1管，因此解析不出IP出來。同樣地，Site 2內的vCenter 2知道VM-B是誰，但是不歸他管的VM-A也無法解析

因此，目前通用型分散式防火牆，在運用上有下列的限制

  • 可以支援IP或是IPSets作為來源與目的地，與一般實體防火牆一樣
  • 不能採用虛擬化物件，像是直接選擇虛機、叢集、資源池、Port Group等。因為這些物件都僅是限制於單一vCenter內的物件定義
  • 可以採用安全群組，但安全群組內只能使用VM Name或是Security Tag進行定義。而且在運用時，同一個安全群組內的所有虛機，都必須位於同一個資料中心(vCenter)內

簡而言之，如果資安管理者希望能夠使用到安全群組的機制進行防火牆規則的優化與自動化，我們目前主要支援的情境為Active-Standby的災備情境，或即使是Active-Active，同業務的虛機也應該隨時都在同一邊，如果有遷移的需求，要整組業務進行搬移，如下圖所示。如果今天單一業務有出現Cross-VC的網路流，此時除非是用標準的IP / IPSets，不然極有可能由於上面敘述的原因，出現原本資安管理者所設計的防火牆規則無法生效的情況出現。

以上的七篇網誌，是我們對於NSX在多資料中心間的應用部署方式介紹。跨中心方案無論在各個IT領域都是個需要詳加規劃的架構，而原本在實體環境可能已經相當複雜，再加上雲資料中心內的特性：業務機器、業務環境快速新增與異動，虛機容易飄移，管理需要集中化等等，都再再讓傳統實體規劃模式力有未逮。但希望大家在這幾篇的連續討論下能夠看到，藉由NSX對應到多中心內的設計架構，一個接近全自動、集中管理、跨中心、安全且優化的雲方案，是有機會在各位的環境內達成的。