Packet Mirroring
本頁面概略介紹虛擬私有雲 (VPC) 網路中的 Packet Mirroring。如要大規模分析工作負載的網路流量，並使用第三方虛擬設備監控網路流量，請使用網路安全整合服務 Packet Mirroring。詳情請參閱「頻外整合總覽」。
Packet Mirroring 可複製虛擬私有雲網路中指定執行個體的流量，並轉送流量以進行檢查。Packet Mirroring 會擷取所有流量和封包資料，包括酬載和標頭。您可以設定擷取輸出和輸入流量、僅輸入流量或僅輸出流量。
鏡像作業會在虛擬機器 (VM) 執行個體上進行，而非在網路上。因此，Packet Mirroring 會耗用 VM 的額外頻寬。
Packet Mirroring 適合用於監控及分析安全性狀態。系統會匯出所有流量，而不只是取樣期間的流量。舉例來說，您可以使用安全性軟體分析鏡像流量，偵測所有威脅或異常狀況。此外，您也可以檢查完整的流量，偵測應用程式效能問題。詳情請參閱用途範例。
運作方式
Packet Mirroring 會複製鏡像來源的流量，並傳送至收集器目的地。如要設定 Packet Mirroring，請建立封包鏡像政策，指定來源和目的地。
「鏡像來源」是 Compute Engine VM 執行個體，您可以指定子網路、網路標記或執行個體名稱來選取。如果指定子網路，系統會鏡像處理該子網路中所有現有和未來的執行個體。您可以指定一或多個來源類型，只要執行個體符合其中至少一個類型，就會進行鏡像。
Packet Mirroring 會從套用 Packet Mirroring 政策的網路中，收集執行個體網路介面的流量。如果執行個體有多個網路介面，除非已設定其他政策，否則不會鏡像其他介面。
「收集器目的地」是位於內部負載平衡器後方的執行個體群組。執行個體群組中的執行個體稱為「收集器執行個體」。為避免單點故障，建議您在 Packet Mirroring 的後端服務中加入多個收集器執行個體。
指定收集器目的地時，請輸入與內部直通式網路負載平衡器相關聯的轉送規則名稱。 Google Cloud接著會將鏡像流量轉送至收集器執行個體。Packet Mirroring 的內部負載平衡器與其他內部負載平衡器類似，但轉送規則必須針對 Packet Mirroring 設定。傳送至負載平衡器的任何非鏡像流量都會遭到捨棄。
篩選
根據預設，Packet Mirroring 會收集鏡像執行個體的所有 IPv4 流量。您可以使用篩選器，將收集的流量擴大至包含所有或部分 IPv6 流量，而非收集所有 IPv4 流量。您也可以使用篩選器縮小鏡像流量的範圍，限制鏡像執行個體使用的頻寬。
您可以設定篩選器，根據通訊協定、CIDR 範圍 (IPv4、IPv6 或兩者)、流量方向 (僅限輸入、僅限輸出或兩者)，或上述條件的組合來收集流量。
政策順序
一個執行個體可以套用多項 Packet Mirroring 政策。Packet Mirroring 政策的優先順序一律為 1000，且無法變更。不支援相同的政策。 Google Cloud 可將流量傳送至任何已設定相同 Packet Mirroring 政策的負載平衡器。如要以可預測且一致的方式，將鏡像流量傳送至單一負載平衡器，請建立篩選器位址範圍不重疊的政策。如果範圍重疊，請設定不重複的篩選器通訊協定。
Google Cloud 會根據每項政策的篩選器，為每個流程選擇政策。如果您有不同的政策， Google Cloud 會使用與鏡像流量相符的對應政策。舉例來說，您可能有一項政策使用篩選器 198.51.100.3/24:TCP，另一項政策使用篩選器 2001:db8::/64:TCP:UDP。由於政策不同，因此 Google Cloud 使用的政策不會有任何模糊空間。
不過，如果政策重疊， Google Cloud 會評估篩選器，選擇要使用的政策。舉例來說，您可能有兩項政策，一項政策設有 10.0.0.0/24:TCP 篩選器，另一項政策則設有 10.0.0.0/16:TCP 篩選器。這些政策的 CIDR 範圍重疊，因此政策也重疊。
選擇政策時， Google Cloud 會比較篩選器的 CIDR 範圍大小，並據此決定政策的優先順序。
Google Cloud 根據篩選條件選擇政策：
如果政策的 CIDR 範圍不同但重疊，且通訊協定完全相同， Google Cloud 會選擇使用最明確 CIDR 範圍的政策。假設 TCP 封包離開鏡像執行個體的目的地是
10.240.1.4，且有兩項政策包含下列篩選器：10.240.1.0/24:ALL和10.240.0.0/16:TCP。由於與10.240.1.4最具體的相符項目是10.240.1.0/24:ALL，因此Google Cloud 會使用具有篩選器10.240.1.0/24:ALL的政策。如果政策指定完全相同的 CIDR 範圍，且通訊協定重疊，Google Cloud 會選擇通訊協定最明確的政策。例如，下列篩選器具有相同範圍，但通訊協定重疊：
10.240.1.0/24:TCP和10.240.1.0/24:ALL。對於相符的 TCP 流量， Google Cloud 會使用10.240.1.0/24:TCP政策。10.240.1.0/24:ALL政策適用於所有其他通訊協定的相符流量。如果政策的 CIDR 範圍完全相同，但通訊協定不同，則這些政策不會重疊。 Google Cloud 會使用與鏡像流量通訊協定對應的政策。例如，您可能有一個
2001:db8::/64:TCP政策，另一個2001:db8::/64:UDP政策。 Google Cloud 會根據鏡像流量的通訊協定，使用 TCP 或 UDP 政策。如果重疊政策的篩選器完全相同，則政策也相同。在這種情況下，每次根據這些政策重新評估相符流量時， Google Cloud 可能會選擇相同或不同的政策。建議您避免建立相同的 Packet Mirroring 政策。
虛擬私有雲流量記錄
虛擬私有雲流量記錄不會記錄鏡像封包。如果收集器執行個體位於已啟用虛擬私有雲流量記錄的子網路上，系統會記錄直接傳送至收集器執行個體的流量，包括來自鏡像執行個體的流量。也就是說，如果原始目的地 IPv4 或 IPv6 位址與收集器執行個體的 IPv4 或 IPv6 位址相符，系統就會記錄流量。
如要進一步瞭解虛擬私有雲流量記錄，請參閱「使用虛擬私有雲流量記錄」。
主要屬性
下列清單說明 Packet Mirroring 的限制或行為，請務必先瞭解這些資訊再使用：
每項 Packet Mirroring 政策都會定義「鏡像來源」和「收集器目的地」。請務必遵守下列規則：
- 所有鏡像來源都必須位於同一個專案、虛擬私有雲網路和 Google Cloud 區域。
- 收集器目的地必須與鏡像來源位於相同區域。收集器目的地可以位於與鏡像來源相同的虛擬私有雲網路，也可以位於使用虛擬私有雲網路對接，連線至鏡像來源網路的虛擬私有雲網路。
- 每項鏡像政策只能參照一個收集器目的地。不過，多個鏡像政策可以參照單一收集器目的地。
Packet Mirroring 支援所有第 4 層通訊協定。
您無法在 VM 執行個體的同一個網路介面上鏡像及收集流量，因為這樣會導致鏡像迴圈。
如要鏡像在同一個 Google Kubernetes Engine (GKE) 節點上 Pod 之間傳遞的流量，您必須為叢集啟用節點內瀏覽功能。
如要鏡像 IPv6 流量，請使用篩選器指定要鏡像的 IPv6 流量 IPv6 CIDR 範圍。您可以使用
::/0的 CIDR 範圍篩選器，鏡像所有 IPv6 流量。您可以使用下列以半形逗號分隔的 CIDR 範圍篩選器，鏡像所有 IPv4 和 IPv6 流量：0.0.0.0/0,::/0。鏡像流量會耗用鏡像執行個體的頻寬。舉例來說，如果鏡像執行個體有 1 Gbps 的輸入流量和 1 Gbps 的輸出流量，則執行個體的總流量為 1 Gbps 的輸入流量和 3 Gbps 的輸出流量 (1 Gbps 的正常輸出流量和 2 Gbps 的鏡像輸出流量)。如要限制收集的流量，可以使用篩選器。
Packet Mirroring 的費用取決於從鏡像執行個體傳送至執行個體群組的輸出流量，以及流量是否在可用區之間傳輸。
Packet Mirroring 適用於輸入和輸出方向。如果兩個鏡像 VM 執行個體互相傳送流量，Google Cloud 會收集相同封包的兩個版本。您可以指定只鏡像輸入或輸出封包，藉此變更這項行為。
每項專案可建立的 Packet Mirroring 政策數量有上限。詳情請參閱配額頁面上的各專案配額。
每項 Packet Mirroring 政策可指定的鏡像來源數量上限，取決於來源類型：
- 5 個子網路
- 5 個標記
- 50 個執行個體
Packet Mirroring 篩選器的數量上限為 30 個，也就是 IPv4 和 IPv6 位址範圍數量乘以通訊協定數量。舉例來說，您可以指定 30 個範圍和 1 個通訊協定，這樣就會有 30 個篩選器。不過，您無法指定 30 個範圍和 2 個通訊協定，因為這樣會產生 60 個篩選器，超過上限。
只有在 VM 於應用程式層加密流量時，鏡像流量才會加密。雖然虛擬私有雲網路和對等互連虛擬私有雲網路中的 VM 對 VM 連線會加密，但加密和解密作業是在管理程序中進行。從 VM 的角度來看，這項流量未經加密。
用途
以下各節說明實際情境，說明您可能使用 Packet Mirroring 的原因。
企業安全性
資安和網路工程團隊必須確保能找出所有可能代表安全漏洞和入侵行為的異常狀況和威脅。他們會鏡像所有流量，以便全面檢查可疑流量。由於攻擊可能橫跨多個封包，資安團隊必須能取得每個流量的所有封包。
舉例來說，下列安全性工具需要您擷取多個封包：
入侵偵測系統 (IDS) 工具需要單一流程的多個封包來比對特徵，才能偵測持續性威脅。
深度封包檢查引擎會檢查封包酬載，偵測通訊協定異常。
為符合 PCI 規範和其他法規用途，網路鑑識需要檢查大部分封包。Packet Mirroring 提供的解決方案可擷取不同的攻擊向量，例如不常通訊或嘗試通訊但失敗。
應用程式效能監控
網路工程師可以使用鏡像流量，排解應用程式和資料庫團隊回報的效能問題。如要檢查網路問題，網路工程師可以查看網路傳輸內容，而不必依賴應用程式記錄。
舉例來說，網路工程師可以使用 Packet Mirroring 的資料完成下列工作：
分析通訊協定和行為，找出並修正封包遺失或 TCP 重設等問題。
即時分析遠端桌面、VoIP 和其他互動式應用程式的流量模式。網路工程師可以搜尋影響應用程式使用者體驗的問題，例如多次重新傳送封包或重新連線次數超出預期。
收集器目的地拓撲範例
Packet Mirroring 可用於多種設定。下列範例顯示收集器目的地位置，以及不同 Packet Mirroring 設定 (例如虛擬私有雲網路對接和 Shared VPC) 的政策。
收集器目的地在相同網路中
下列範例顯示 Packet Mirroring 設定，其中鏡像來源和收集器目的地位於同一個虛擬私有雲網路。
在上圖中，封包鏡像政策設定為鏡像mirrored-subnet，並將鏡像流量傳送至內部直通式網路負載平衡器。Google Cloud 會鏡像子網路中現有和未來執行個體的流量。所有往返網際網路、地端部署主機或 Google 服務的流量都會鏡像。
對接網路中的收集器目的地
您可以建構集中式收集器模型，讓不同虛擬私有雲網路中的執行個體，將鏡像流量傳送至中央虛擬私有雲網路中的收集器目的地。這樣一來，您就可以使用單一目的地收集器。
在以下範例中，collector-load-balancer 內部直通式網路負載平衡器位於 project-a 中 network-a 虛擬私有雲網路的 us-central1 區域。這個目的地收集器可由兩項 Packet Mirroring 政策使用：
policy-1會從project-a中network-a虛擬私有雲網路內us-central1區域的鏡像來源收集封包，並傳送至collector-load-balancer目的地。policy-2會從project-b中network-b虛擬私有雲網路的us-central1區域收集鏡像來源的封包，並傳送至相同的collector-load-balancer目的地。
由於鏡像來源位於不同的虛擬私有雲網路，因此需要兩項鏡像政策。
在上圖中，收集器目的地會從兩個不同網路中的子網路收集鏡像流量。所有資源 (來源和目的地) 都必須位於同一個區域。network-a 中的設定與鏡像來源和收集器目的地位於相同虛擬私有雲網路的範例類似。policy-1 已設為從 subnet-a 收集流量，並傳送至 collector-ilb。
policy-2 是在 project-a 中設定，但指定 subnet-b 做為鏡像來源。由於 network-a 和 network-b 互設對等互連，因此目的地收集器可以收集 subnet-b 的流量。
這些網路位於不同專案，且可能屬於不同擁有者。只要具備適當權限，任一擁有者都可以建立 Packet Mirroring 政策：
如果由
project-a的擁有者建立 Packet Mirroring 政策，他們必須具備project-b中要鏡像的網路、子網路或執行個體的compute.packetMirroringAdmin角色。如果由
project-b的擁有者建立 Packet Mirroring 政策，則必須 具備project-a中的compute.packetMirroringUser角色。
如要進一步瞭解如何在兩個虛擬私有雲網路之間啟用私人連線，請參閱「虛擬私有雲網路對等互連」。
Shared VPC
在下列共用虛擬私有雲情境中，收集器目的地的鏡像執行個體都位於同一個共用虛擬私有雲網路。雖然資源都位於同一個網路中，但可以位於不同的專案，例如主專案或多個不同的服務專案。以下範例說明必須建立 Packet Mirroring 政策的位置，以及可建立政策的人員。
如果鏡像來源和收集器目的地都在同一個專案 (主專案或服務專案)，設定方式與所有項目都在同一個虛擬私有雲網路類似。專案擁有者可以建立所有資源，並在該專案中設定必要權限。
詳情請參閱「Shared VPC 總覽」。
服務專案中的收集器目的地
在以下範例中，收集器目的地位於服務專案中，該專案使用主專案中的子網路。在這個案例中，政策也位於服務專案。政策也可能位於主專案中。
在上圖中，服務專案包含使用 Shared VPC 網路中收集器子網路的收集器執行個體。Packet Mirroring 政策是在服務專案中建立，並設為鏡像在 subnet-mirrored 中具有網路介面的執行個體。
服務或主專案使用者可以建立 Packet Mirroring 政策。如要這麼做，使用者必須在收集器目的地所在的服務專案中，具備 compute.packetMirroringUser 角色。使用者也必須具備鏡像來源的 compute.packetMirroringAdmin 角色。
主專案中的收集器目的地
在以下範例中，收集器目的地位於主專案，鏡像執行個體則位於服務專案。
這個範例可能適用於開發人員在服務專案中部署應用程式，並使用 Shared VPC 網路的情境。他們不必管理網路基礎架構或 Packet Mirroring。而是由集中式網路或資安團隊負責佈建 Packet Mirroring 政策，並控管主專案和 Shared VPC 網路。
在上圖中，Packet Mirroring 政策是在收集器目的地所在的主專案中建立。政策設定為鏡像子網路中的鏡像執行個體。服務專案中的 VM 執行個體可以使用鏡像子網路，且流量會鏡像。
服務或主專案使用者可以建立 Packet Mirroring 政策。為此，服務專案中的使用者必須具備主專案中的 compute.packetMirroringUser 角色。主專案中的使用者必須具備服務專案中鏡像來源的 compute.packetMirroringAdmin 角色。
多介面 VM 執行個體
您可以在 Packet Mirroring 政策中加入具有多個網路介面的 VM 執行個體。
政策只能從單一網路鏡像資源。如果多 NIC 執行個體在不同網路中具有網路介面，您就無法建立單一政策來鏡像所有網路介面的流量。如要對連結至不同網路的其他網路介面進行鏡像，則必須為每個介面建立一個 Packet Mirroring 政策。