在建置 SIEM 或 NDR Sensor 時，如果環境是架在 VMware 上，我自己最常特別確認的一個地方，
就是 第二張網卡。

一般來說，Sensor 會有一張網卡負責管理與平台之間的通訊，例如連線到 Data Center、進行系統管理等；另外一張網卡則是拿來接收 Switch Mirror 出來的流量。

乍看之下，好像只要在 VM 裡多加一張網卡，再把實體 Switch 的 Mirror Port 接進來就可以開始收資料，但實際上還有一個很容易被忽略的設定：Promiscuous Mode（混雜模式）。

正常情況下，網卡主要會接收送給自己的封包。但 Mirror 的用途，本來就是把其他設備的流量複製一份給 Sensor 看，這些封包原本並不是要傳給 Sensor 本身。

所以在 VMware 的虛擬交換器或 Port Group 上，需要確認 Promiscuous Mode 是否允許。否則即使第二張網卡存在、線也接好了，Sensor 還是可能看不到預期的 Mirror 流量。

這也是我覺得虛擬化環境裡很容易踩到的一個點。對 Promiscuous Mode 不熟的人，很容易直覺認為：「第二張網卡已經加上去了，應該就能收到封包了。」

但其實「有網卡」跟「能不能看到被複製過來的封包」是兩件事情。

我也曾經遇過另外一種理解上的落差。

客戶知道要設定 Mirror 後，一直詢問我：

「那 Sensor 的 IP 是多少？我要設定連線到它。」

但 Mirror 並不是靠 IP 去跟 Sensor 建立連線。

Switch 做的事情，是把指定介面或 VLAN 上看到的網路流量複製到 Mirror Port，
再由 Sensor 的監聽網卡被動接收。

所以管理用的網卡當然會有 IP，但專門接 Mirror 的監聽介面，本身並不是因為需要一個 IP，
Switch 才能把封包送過去。

我自己會把這件事想成：

管理用的網卡是在與其他設備「通訊」，Mirror 網卡則是在「監控」傳送過來的資料。

這兩種用途其實完全不同。

當 Sensor 建置完成，但平台上一直看不到 Network Traffic 時，我通常不會一開始就去猜是哪個系統元件壞掉，而是先直接到 Sensor 上確認第二張網卡到底有沒有收到封包。

這時我常用的工具就是 tcpdump。

tcpdump 是 Linux 上很常見的封包擷取工具，可以直接查看指定網路介面目前收到的封包。它能做的事情其實很多，不過我在這個情境下主要只是拿它做快速確認。

我通常先看：

第二張網卡到底有沒有資料進來，以及封包裡能不能看到一些基本的 IP、Port 等資訊。

網路上都可以查到相關指令我用一些範例說明

sudo tcpdump -i ens19 -nn

-i ens19：指定要觀察的第二張網卡
-nn：不要把 IP、Port 轉成名稱，直接顯示原始數字

如果 tcpdump 已經看得到封包，代表至少 Switch 到 Sensor 這一段不是完全沒有資料。接下來再確認看到的流量是不是原本預期要 Mirror 的內容。

如果收到的內容明顯不對，我就會再回頭確認 Switch 上 Mirror 的來源介面、目的介面或相關設定。

但如果 tcpdump 完全沒有看到資料，我反而會先往更前面的地方查，
例如實體線路有沒有接對、是不是接到正確的 Switch Port，以及 Switch 的 Mirror 設定到底有沒有完成。

所以我的排查方式其實很直接：

先確認封包有沒有真的走到 Sensor，再去討論後面的解析或平台問題。

這樣通常可以很快把問題範圍縮小。

除了 Sensor 的網卡設定以外，我在 Stellar Cyber 上也有稍微接觸過 HA。

我碰到的主要是 Data Center 端的高可用架構，而且通常是在客戶規模比較大的情況才會規劃。

依我接觸到的架構，需要三台同規格主機，角色包含 Master、Standby 與 Worker。

這跟一般直覺上想到的「兩台設備互相備援」不太一樣。它比較偏向平台層級的高可用設計，因此除了架構本身，硬體數量、規格以及成本也都要一起考慮。

不過對我來說，這次最重要的經驗反而不是 HA，而是前面那個看起來很小的設定：

第二張網卡加上去，不代表 Mirror 就一定收得到。

在虛擬化環境裡，Promiscuous Mode、實體 Mirror Port、線路，以及 Sensor 本身收到的封包，這幾個地方其實是連在一起的。

只要知道每一段到底在負責什麼，當平台沒有資料時，就不用從最後面的 SIEM 開始猜，而是可以從最接近封包來源的位置，一段一段確認下去，有時候會在中間就找到問題。