ネットワークエンジニアのITブログ

長らくネットワークで仕事をしてきましたが、ここ数年クラウドとサーバー系に触れる機会が増えて、クラウドのネットワークというのが自分の性分にはあっているようです。最近のお気に入りはNSXALBとGoogle Cloud。

NSXの分散ファイアウォール(DFW)で「隣のサーバー」からの攻撃を防ぐ

NSX-T ホームラボ vSphere8 Nested ESXi vSAN

前回、力技でNSX Edgeノードを構築し、オーバーレイネットワークと物理ネットワークと繋ぐことができました。
あの苦労のおかげで、今は仮想マシンからインターネットへ、そしてインターネットから仮想マシンへと、自由に通信ができる「土管（ネットワーク）」が完成しています。

しかし、冷静に考えると「ただ繋ぐだけ」なら、L2スイッチやルーターがあれば十分なんです。
わざわざリソースを食うNSX Managerをデプロイし、Nested ESXiという茨の道を歩んできた最大の動機は「守る」ことにあります。

今回は、NSXの中でも特徴的な機能である「Distributed Firewall (DFW: 分散ファイアウォール)」 を検証します。これこそが、ゼロトラスト時代の必修科目「マイクロセグメンテーション」の正体です。

従来型ファイアウォールの限界

今までのオンプレミスの常識では、同じセグメント（L2、同じサブネット）にいるサーバー同士の通信をネットワーク機器側で止めるのは至難の業でした。
L2スイッチだと素通しにならざるを得ません。
かといって、OSのFW (iptables/Windows Defender)で個別に全台設定するのは現実的ではありません。
結局、「同じセグメント内は信頼する（性善説）」という運用になりがちでした。
しかし、これでは1台のWebサーバーが乗っ取られたら、隣にあるDBサーバーへ簡単に侵入（ラテラルムーブメント／横展開）されてしまいます。

NSX DFWが覆す常識

NSX DFWは、この常識を覆します。
ハイパーバイザー（vSphere）のカーネルレベル（vNICの直前）でパケットを検査するため、ネットワーク構成を一切変えることなく、隣の仮想マシンとの通信を遮断できます。
例えば、同じ 192.168.1.0/24 のネットワークにいても、「WebサーバーからDBサーバーへのSQL通信だけ許可し、それ以外はPingすら通さない」という制御が可能になるのです。

実験の舞台：無防備なVMたち

検証のために、オーバーレイセグメント（192.168.41.0/24）の2台のVMを利用して制御をかけてみようと思います。

  • CL-Tier (192.168.41.11)
  • Web-Tier (192.168.41.21)

当然、現状は何の制限もありません。同じスイッチに繋がっているので、お互いにPingも通ればSSHも通ります。

vyos@vyos:~$
vyos@vyos:~$ ping 192.168.41.21
PING 192.168.41.21 (192.168.41.21) 56(84) bytes of data.
64 bytes from 192.168.41.21: icmp_seq=1 ttl=64 time=0.643 ms
64 bytes from 192.168.41.21: icmp_seq=2 ttl=64 time=0.608 ms
64 bytes from 192.168.41.21: icmp_seq=3 ttl=64 time=0.467 ms
64 bytes from 192.168.41.21: icmp_seq=4 ttl=64 time=0.517 ms
64 bytes from 192.168.41.21: icmp_seq=5 ttl=64 time=0.507 ms
64 bytes from 192.168.41.21: icmp_seq=6 ttl=64 time=0.483 ms

IPアドレスはもう書かない。「タグ」で管理する

DFWの設定画面に行く前に、NSXならではの「作法」を実践します。
従来のFW運用だと、以下のようにIPアドレスでルールを書きますよね？

Source: 192.168.100.10, Dest: 192.168.100.11, Action: Allow

しかし、クラウド時代にIPアドレス管理はナンセンスです。
NSXでは「タグ」を使います。
「Webサーバーというタグが付いているマシン」なら、IPが変わろうが、台数が100台に増えようが、自動的にルールが適用されます。この抽象化こそがNSXの醍醐味です。
それでは、実際に設定していきましょう。

タグの作成

まずは、タグを作成します。
「インベントリ」-「タグ」から「タグの追加」をクリックします。
クライアント想定のタグとして「CL-Tier」という名前を付けて、割当先の数字「0」をクリックします。
表示では、「1」となっていますが、新規作成の場合は「0」になっています。

クライアント想定の仮想マシンは、「vyos」のほうなので、こちらにチェックを入れて「適用」をクリックします。

元の画面に戻ったら「保存」をクリックします。
同様に、WEBサーバー想定のタグは「Web-Tier」として作成し、クライアントは「seg41-web01」にチェックを入れて「適用」をクリックします。


グループの作成

続いて、タグ付けしたVMをグループに追加します。
実運用では、同一のタグを持ったVMは複数あることが想定されるので、これらをまとめたグループを作成します。
DFWのルール設定でもタグのついている仮想マシンを直接選択することができないためグループの作成は必須となります。
「インベントリ」-「タグ」から「タグの追加」をクリックします。
ここでは、Web-Tierのグループを作成するので、コンピュートメンバの「設定」をクリックします。

このグループに追加する条件として、以下のメンバーシップ基準の条件を選択します。


このグループの名前を「Grp-Web」として「保存」をクリックします。

同様に、CL-Tierのグループを以下の条件で作成します。


これで準備完了です。

DFWポリシー設定

続いて、分散ファイアウォールのルールを作成していきます。
今回は「HTTPのみ許可しそれ以外はすべて拒否する」ルールを作成していきます。

「セキュリティ」-「分散ファイアウォール」-「カテゴリ個別のルール」-「アプリケーション」から「ポリシーの追加」をクリックします。

追加すると「新規ポリシー」という名前のポリシーが追加されるので名前を「Pol-MicroSeg-Demo」に変更し、ポリシーにチェックを入れて「ルールを追加」をクリックします。

ここからは、以下のようなルールを作成してきます。

  • 送信元：Grp-CL
  • 宛先：Grp-Web
  • サービス：HTTP
  • アクション：許可

「新規ルール」という名前のルールが追加されるので名前を「Allow CL to Web http」に変更し、「送信元」の任意部分にある鉛筆マークの編集ボタンをクリックします。

送信元は「Grp-CL」を選択し「適用」をクリックします。

同様に宛先は「Grp-Web」を選択します。

サービスは「HTTP」を選択します。

続いて、以下のようなルールを作成してきます。

  • 送信元：Grp-CL
  • 宛先：Grp-Web
  • サービス：any
  • アクション：ドロップ

先ほど作成した「Allow CL to Web http」のルールのクローンを作成して、名前を「Deny CL to Web any」に変更します。



サービス、アクションを変更し、「Deny CL to Web any」ルールを「Allow CL to Web http」の下に、ドラッグ＆ドロップで移動し右上の「公開」をクリックします。

これでDFWのポリシーとルールの作成が完了しました。

動作確認：Pingは止まり、Web通信のみで許可されているのか？

CLであるvyos（192.168.41.11）から、Webサーバのseg41-web01（192.168.41.21）に対してPingを実行します。
その結果、Pingが100%パケットロスしていることを確認しました。

vyos@vyos:~$ ping 192.168.41.21
PING 192.168.41.21 (192.168.41.21) 56(84) bytes of data.
^C
--- 192.168.41.21 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6168ms
vyos@vyos:~$

続いて、HTTPアクセスを実行してみます。
こちらは、HTTPの応答が返ってきました。
正しく制御できました。

vyos@vyos:~$ curl -v http://192.168.41.21
*   Trying 192.168.41.21:80...
* Connected to 192.168.41.21 (192.168.41.21) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.41.21
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.24.0 (Ubuntu)
< Date: Fri, 19 Dec 2025 15:14:54 GMT
< Content-Type: text/html
< Content-Length: 615
< Last-Modified: Fri, 19 Dec 2025 14:36:19 GMT
< Connection: keep-alive
< ETag: "694562e3-267"
< Accept-Ranges: bytes
<
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
* Connection #0 to host 192.168.41.21 left intact
vyos@vyos:~$

まとめ：これがカーネルレベルの制御だ

従来の物理ファイアウォールでこれを実現しようとすると、WebとDBでVLAN（サブネット）を分けて、間にファイアウォール装置を挟んで、ルーティングさせて...と、通信経路を無理やり曲げる（ヘアピン通信）必要があり、設計が非常に複雑になります。

NSX DFWなら、ネットワークはフラットなままでOKです。
パケットが仮想マシンのvNICから出た瞬間、ハイパーバイザーが「おっと、君はタグCLだね。あっちのタグWebへのPingは禁止されているよ」と、出口で止めてくれるイメージです。

この「ネットワーク構成に依存しないセキュリティ」こそが、苦労してVCF/NSX環境を手に入れた最大のメリットと言えるでしょう。
今までの苦労が報われた気がします。

さて、内部の守りは固めました。 しかし、今回の検証ではVMのIPアドレスを手動設定（Static）しましたが、VMが増えるたびに手動設定していては運用が回りません。
次回は、NSXが提供するDHCP機能を使って、IPアドレス管理を自動化してみます。
物理ルーターのDHCPリレーを使うのか、NSXのDHCPサーバーを使うのか？ を紹介します。