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

長らくネットワークで生活してきましたが、ここ数年クラウドとサーバー系に触れる機会が増えて、日々成長しています。最近のお気に入りはNSXALBとGoogle Cloud。

vSAN環境で仮想マシンを構築してみる

先日、ホームラボ環境にvSAN環境を構築したので、さっそく仮想マシンを構築して動作確認をしてみたいと思います。
vSAN構築記事は、こちらを参照してください。
hironw.hatenablog.com

構成

vSANを構成するESXiホストの構成は以下の通りです。

ESXiホスト 3台
キャッシュ用ディスク 5GB×3本
キャパシティ用ディスク 10GB×3本


NFS接続設定

vSANデータストアにCentOSのISOファイルを格納しようとしたところ、VMDKファイルのみアップロード可能とのメッセージが表示されたため、ISOファイルを保存しているQNAPへNFS接続できる必要があります。

すでに、QNAPはNFS接続可能なように設定済みであるため、esx36~esx38の各ホストにNFS接続の設定を行います。
ストレージのアダプタから、ソフトウェアiSCSIを選択し、QNAPのIPアドレスである192.168.101.1と192.168.101.2のアドレスを追加します。

バイスを選択し、更新するとQNAPの2台が表示されました。

vSANデータストアに仮想マシンを作成

Cluster_vSANで新規仮想マシンを作成します。

仮想マシン名を「cent82」と入力して「NEXT」を選択します。

コンピューティングリソースターゲットを「Cluster_vSAN」として「NEXT」を選択します。

ストレージで、「vsanDatastore」を選択します。

互換性は、そのままで「NEXT」を選択します。

ゲストOSは、CentOS 7(64ビット)を選択し「NEXT」を選択します。

ハードウェアのカスタマイズで、データストアISOファイルから、QNAPのcentos7のISOファイルを選択します。

内容を確認して「FINISH」を選択します。

動作確認

仮想マシンの作成が完了したら、起動しインストールと設定作業を行い無事起動したことを確認しました。

apacheもインストールして、cent82に接続できることを確認しました。

問題なく、vSAN環境上に仮想マシンを構築し動作することを確認できました。

VMware Cloud on AWSのConnected VPCの作り方

VMware Cloud on AWSを新規に導入する際に、あらかじめAWSVPCを作成しておくと、Connected VPCとして接続することができます。
今回は、その手順について紹介したいと思います。

VPCの作成

まずは、AWS Management Consoleにログインし、サービスから「VPC」を検索しクリックします。
その後、「VPCを作成」というオレンジのボタンを選択します。

VPC作成画面で以下を入力します。
作成するリソース:VPCのみ
名前タグ:HOMELAB
IPv4 CIDR ブロック:IPv4 CIDRの手動入力
IPv4 CIDR:10.35.0.0/16
IPv6 CIDR ブロック:IPv6 CIDRブロックなし


正しく作成が完了すると以下のようにメッセージが表示されVPCが表示されます。

サブネットの作成

SDDCからVPCを選択する際にサブネットをの指定が必要となるため、ここでは、SDDC接続用のサブネットと、EC2を配置するサブネットの2つを作成してきます。
画面左のメニューからサブネットをクリックし、画面右の「サブネットを作成」を選択します。

サブネット作成画面が表示されたら、VPC IDの選択画面で、先ほど作成した「HOMELAB」のVPCを選択します。


1つの目サブネット情報として以下を入力します。
サブネット名:homelab-subnet01
アベイラビリティゾーン:指定なし
IPv4 VPC CIDR ブロック:10.35.0.0/16
IPv4 サブネットCIDR ブロック:10.35.1.0/24

続いて、「新しいサブネットを追加」を選択して2つ目のサブネットを情報を入力し、「サブネットを作成」を選択します。
サブネット名:homelab-subnet02
アベイラビリティゾーン:指定なし
IPv4 VPC CIDR ブロック:10.35.0.0/16
IPv4 サブネットCIDR ブロック:10.35.2.0/24

正しく作成が完了すると、以下のようにメッセージが表示されVPCが表示されます。

SDDCの作成

SDDCの作成から紹介しますが、CSPへのログインからの手順を確認したい方は、こちらの記事を参考にしてください。
hironw.hatenablog.com
まず最初に、SDDC作成の販売者の選択で、すでに富士ソフトになっているので、そのまま「次へ」を選択します。

続いてSDDCプロパティの各項目を、以下のように入力し「次へ」を選択します。
SDDC名:HOMELAB01
AWSリージョン:Asia Pacific(Osaka)
デプロイ:Single Host
ホストタイプ:I3(Local SSD

AWSアカウントの画面で「今すぐAWSに接続」を選択し、AWSアカウントの選択では「新しいAWSアカウントに接続」を選択し、「CLOUDFORMATIONテンプレートを使用して、AWSコンソールを開く」をクリックします。

先程、VPCを作成していればログインしているので、CloudFormationのスタック作成画面が表示されます。特に変更せずに画面右下の「スタックの作成」を選択します。


スタックの作成が行われている画面に遷移します。

画面右端の更新ボタンを押すと、作成完了画面に更新されます。

SDDC作成画面に戻り、先ほど作成したAWSの接続先(12桁のアカウントID)である「170530872815」を選択し「次へ」を選択します。

VPCおよびサブネットでは、先ほど作成した以下のVPCとサブネットを選び「次へ」を選択します。
VPC:10.35.0.0/16
サブネット:10.35.1.0/24

ネットワークの構成で、管理サブネットのCIDRを「10.16.0.0/23」と入力して「次へ」を選択します。

確認と承認でチェックボックスに✅を入れ「SDDCの展開」を選択します。

SDDC確認

この後、1~2時間ぐらいでSDDCの作成し、最初のInventoryの画面に表示されます。
現在の環境は、2つのSDDCまでしか作成できず、すでにFSI_LAB01、FSI_LAB02の2つがあるので、手順までの紹介となります。

VMware Cloud on AWSを導入してみた

VMware Cloud on AWS(以下、VMC)は、AWSのベアメタル上で稼働するVMware vSphereのクラウドサービスです。物理環境はAWSのグローバルインフラを使用し、そのホスト上にVMwareのSDDC環境を展開して提供するものになります。
今日は、VMCの検証環境を導入させてもらえることになったので、その手順を紹介したいと思います。

VMCの概要

VMware Cloud on AWSは、その名の通り、AWSクラウドサービスとVMwareクラウドサービスを組み合わせて、クラウド上でSDDCの環境を構築し、ユーザーへ提供するサービスになります。
オンプレミスでハードウェアを準備する必要がなく、AWSのグローバルインフラ基盤を利用して環境を提供することができるため、初期セットアップから数時間で環境を利用することができるとても便利なサービスになります。
VMCといっても、操作感は今までオンプレミス環境で利用していたvSphereと変わらないので、いままでのノウハウをそのままVMCの運用で利用できるのメリットです。
また、vSphereの環境をクラウドで利用するだけではなく、EC2やS3といったAWSのネイティブサービスを利用することもできます。
今回の紹介は、VMCの導入までとなりますが、AWSの接続や、AWS環境を経由したオンプレミスとの接続なども今後紹介していきたいと思います。

VMware Cloud Servicesへのログイン

まず最初に、VMCを構築するには、VMware Cloud Servicesにログインする必要があります。
今回、私が所属している富士ソフトの環境を利用して、構築していきます。
まずは、VMware Cloud Service https://console.cloud.vmware.com/csp/gateway/discovery に接続します。

アカウントを持っていない場合は、「VMWARE アカウントの作成」から新規に作成してください。
私は、アカウントを持っているので、入力して「次へ」を選択します。

パスワードを入力して、「次へ」を選択します。

二要素認証を設定しているので、MFAのコードを入力します。

ログインすると、3つのサービスが表示されています。
ここは、アカウント毎に利用できるサービスが設定されており、私の場合は、この3つだけとなります。

VMware Cloud on AWSの導入準備

それでは、さっそくVMCを導入していきたいと思います。
右端のVMware Cloud on AWSの枠の下に、「サービスを起動」というリンクがあるので選択します。

画面が切り替わり、InventoryのSDDCに、いま構築されている環境(FSI_LAB01、FSI_LAB02)の2つが表示されています。

画面右上に、「展開の追加」からVMware Cloud on AWSを選択します。

SDDCの導入には6つのステップがあるので順番に設定していきます。
まず最初は販売者の選択で、すでに富士ソフトになっているので、そのまま「次へ」を選択します。

続いてSDDCプロパティの各項目を、以下のように入力し「次へ」を選択します。
SDDC名:HOMELAB01
AWSリージョン:Asia Pacific(Osaka)
デプロイ:Single Host
ホストタイプ:I3(Local SSD

AWSアカウントは、「今はスキップ」を選択して「次へ」を選択します。

ネットワークの構成で、管理サブネットのCIDRを「10.16.0.0/23」と入力して「次へ」を選択します。

確認と承認でチェックボックスに✅を入れ「SDDCの展開」を選択します。

SDDC確認

この後、1~2時間ぐらいでSDDCの作成し、最初のInventoryの画面に表示されます。
現在の環境は、2つのSDDCまでしか作成できず、すでにFSI_LAB01、FSI_LAB02の2つがあるので、手順までの紹介となります。

ホームラボでvSAN環境を構築してみた

いままでやろうと思ってやってなかった、ホームラボ環境でvSANを組んでみたいと思います。
vSANはストレージを仮想化するソリューション(SDS:Software Defined Storage)で、複数のディスクを束ねて1つのストレージを提供することが可能です。
今回は、ホームラボ環境にNexstedESXを構築しvSANを組んでいきます。

構成

vSANを構成するESXiホストの構成は以下の通りです。

ESXiホスト 3台
キャッシュ用ディスク 5GB×3本
キャパシティ用ディスク 10GB×3本


クラスタの準備

vSANクラスタの作成

まず最初に、vSAN専用のクラスターを作成していきます。
vCenterにログインし、「新規クラスタ」を選択します。

新規クラスタの基本の部分で、名前に「Cluster_vSAN」と入力し、vSANを有効にします。
vSphere DRSとvSphere HAは必要に応じて有効にしてください。
この後、vSphere HAはエラーが発生したので、クラスタ作成後に無効にしています。

確認を行い問題なければ「完了」を選択します。

正常に作成されると、クイックスタートの画面が表示され、「1.クラスタの基本」に✅マークが付きます。

EVCの有効化

EVCを有効化します。
[Cluster_vSAN]-[構成]-[設定]-[VMware EVC]から画面右端の「編集」を選択します。

EVCモードを「Intelホスト用にEVCを有効化」をチェックし、CPUモードを「Intel "Haswell" Generation」を選び、「OK」を選択します。
CPUモードは、環境に応じて選択してください。

Cluster_vSAN用NestedESXホストの作成

ここからは、vSANようのNestedESXiホストを作成していきます。
Datacenterから、新規仮想マシンを選択します。
作成タイプの選択で、「新規仮想マシンの作成」を選択します。

仮想マシン名を「esx36」と入力して、「NEXT」を選択します。

導入するクラスタ「Cluster_Lab」を選んで、「NEXT」を選択します。

導入するストレージ「datastore_qnap2」を選んで、「NEXT」を選択します。

互換性の選択は、「ESXi 7.0 U2 以降」を選んで、「NEXT」を選択します。

ゲストOSの選択では、「その他」から「VMware ESXi 7.0 以降」を選んで、「NEXT」を選択します。

ハードウェアのカスタマイズでは、以下のような設定を行い、「NEXT」を選択します。

CPU 4
ソケットあたりのコア 1
ハードウェア仮想化 「ハードウェアアシストによる仮想化をゲストOSに公開」を有効
メモリ 32GB
新規ハードディスク 20GB(シンプロビジョニング)★OSインストール用
新規ハードディスク 10GB(シンプロビジョニング)★キャパシティディスク用
新規ハードディスク 5GB(シンプロビジョニング)★キャッシュディスク用
新規ネットワーク DPortGroup Trunk
新規ネットワーク DPortGroup Trunk
新規ネットワーク DPortGroup Trunk
新規ネットワーク DPortGroup Trunk
新規CD/DVDドライブ データストア ISOファイル(ESXiのISOファイルを指定)

内容を確認して問題がなければ、「FINISH」を選択します。
同様の手順で、esx36、esx37、esx38の3台を作成します。
ESXi7.0のインストール初期設定は割愛します。
手順を知りたい方は、以下のページを参照ください。
hironw.hatenablog.com

クラスタへホストの追加

クラスタを選択し、構成からクイックスタートから、「2.ホストの追加」にある「追加」を選択します。

新規ホストから作成したESXiホスト3台のFQDN、ユーザー名、パスワードを入力し、「すべてのホストに同じ認証情報を使用」にチェックを入れ、「次へ」を選択します。

セキュリティアラートが表示されますが、全てにチェックを入れ、「OK」を選択します。

ホストサマリで3台のホストがいることを確認して、「次へ」を選択します。
内容を確認して、「完了」を選択します。

分散スイッチへホストの追加

分散スイッチ「DSwitch」を右クリックして「ホストの追加と管理」を選択します。

タスクを選択で、「ホストの追加」を選択します。

ホストの選択で、esx36~esx38までの3台にチェックを入れて、「次へ」を選択します。

物理アダプタの管理で、vmnic0~vmnic4のアップリンクの割り当ては、「自動割り当て」を選択し、「次へ」を選択します。

VMKernelアダプタの管理で、ターゲットポートグループをManaged VLANである「DportGroup 10」を選択し、「次へ」を選択します。

仮想マシンのネットワーク移行は、仮想マシンがいないので、そのまま「次へ」を選択します。

設定の確認を行い、「完了」を選択します。

VMKernelアダプタ(vMotion、vSAN)の設定

各ホストの[構成]ー[ネットワーク]ー[VMKernelアダプタ]から、vmk1にvMotion、vm2にvSANのアダプタを割り当てます。
これを、esx36~esx38の全てで設定します。


ホストの追加まで完了すると、クイックスタートの「2.ホストの追加」に✅マークが付きます。

クラスタの構成

続いて、最後のステップの「3.クラスタの構成」の「構成」ボタンを選択します。

Distributed Switchの設定では、「後でネットワークを設定」にチェックを入れ、「次へ」を選択します。

詳細オプションでは、ホストオプションで、NTPサーバに「192.168.10.32」を入力し、EVCを有効化して、EVCモードで「Haswell」を選択し、「次へ」を選択します。


ディスクの要求は、そのまま「次へ」を選択します。

プロキシ設定もそのまま「次へ」を選択します。

確認完了後、「終了」を選択します。

ディスクの設定

[Cluster_vSAN]ー[構成]ー[vSAN]ー[ディスク管理]から、esx36.home.localにチェックを入れて、「ディスクの表示」を選択します。

10GBのディスクを選択し、「フラッシュディスクとしてマーク」を選択します。

再度確認画面が表示されるので、「はい」を選択します。

ドライプのタイプが、HDDからフラッシュに変更となったことを確認します。
画像は20GBですが、実際の設定では5GBのドライブもフラッシュに変更します。

続いて、「未使用ディスクの要求」を選択します。

未使用ディスクの要求では、5GBのディスクの要求対象を「キャッシュ層」、10GBのディスクの要求対象を「キャパシティ層」として、「作成」を選択します。


作成が完了すると、各ホストの使用中のディスクが、2/2となります。

また、vsanDatastoreも作成できました。


vSANライセンスの適用

導入直後だと、vSANのライセンスが評価モードとなっているので、ライセンスを適用していきます。
[Cluster_vSAN]ー[構成]ー[ライセンス]ー[vSANクラスタ]から、画面右端の「ライセンスの割り当て」を選択します。

ライセンスの割り当てで、「新規ライセンス」を選択し、ライセンスキーとライセンス名を入力して、「OK」を選択します。

ライセンスが反映されたことを確認します。

vSANの確認

今回は検証のため、ディスクの容量を少なくしていますが、vsanDatastoreが正しく認識されているところまで確認できました。

vSAN環境の導入は以上です。

ESXiホストでコアダンプターゲットを設定する

vCenterでのコンソールでESXiホストにアラートマークが出ていたので確認したところ、「コアダンプのターゲットが構成されていません。ホストのコアダンプを保存できません。」という表示が出ていたので、コアダンプの設定を実施してみます。

コアダンプは、ESXiホストの診断やテクニカル サポートを行う際に、診断情報を書き込むファイルで、事前に指定した場所に保存できるように設定しておく必要があります。
通常、診断情報を収集するパーティションは、ESXiホスト のインストール中にローカル ストレージ デバイスに作成されるのですが、今回、メッセージが表示されたので、再設定してきます。

構成

ベースのネットワーク構成はこちらになります。

コアダンプの作成

今回、アラートが出ていたのは、esx22なので、sshでログインし、コアダンプの一覧を表示してみますが、何も表示されません。
やはり、コアダンプがありませんね。

[root@esx22:~] esxcli system coredump file list
[root@esx22:~]
[root@esx22:~]
[root@esx22:~]

それでは、以下のコマンドを実行して、コアダンプを作成します。
作成後に再度一覧表示すると、ファイルが生成されたことが確認できます。

[root@esx22:~] esxcli system coredump file add --auto
[root@esx22:~]
[root@esx22:~]
[root@esx22:~] esxcli system coredump file list
Path                                                                                                     Active  Configured        Size
-------------------------------------------------------------------------------------------------------  ------  ----------  ----------
/vmfs/volumes/616bc6de-7639309c-7864-1cfd08727d86/vmkdump/003667C5-BF1D-48D9-8039-987E283BD5A4.dumpfile   false       false  2461007872
[root@esx22:~]
[root@esx22:~]
[root@esx22:~]

続いて、コアダンプを有効化していきます。
[Active]の欄が、「true」となり有効化できました。

[root@esx22:~] esxcli system coredump file set --smart --enable true
[root@esx22:~]
[root@esx22:~]
[root@esx22:~]
[root@esx22:~] esxcli system coredump file list
Path                                                                                                     Active  Configured        Size
-------------------------------------------------------------------------------------------------------  ------  ----------  ----------
/vmfs/volumes/616bc6de-7639309c-7864-1cfd08727d86/vmkdump/003667C5-BF1D-48D9-8039-987E283BD5A4.dumpfile    true        true  2461007872
[root@esx22:~]

設定後のGUI確認

画面の更新だけどアラートが消えないので、いったんログアウトしてから、再度ログインすると、アラートが消えていることを確認しました。

コアダンプの再設定は以上です。

APIによるゲートウェイファイアウォールのルール作成

NSXの分散ファイアウォールゲートウェイファイアウォールは、初期構築の際にポリシーやルールをたくさん作成すると思いますが、GUIで1つ1つ作成していくのは骨が折れます。
また、オンプレやNSX-Vからの移行などであれば、すでに情報はまとまっているので、今回はAPIによるポリシーとルールを作成してみたいと思います。

構成

ベースのネットワーク構成はこちらになります。
NSX:4.1.2.1.0.22667794
APIツール:Postman

Postmanのインストール

PostmanはGUIを用いたAPIの操作を行うことができるツールで、色々なメーカーがテンプレート集を公開しています。今回はこのツールを利用してFWのポリシーやルールを作成していきます。
ソフトウェアは、以下のURLから環境に合わせてダウンロードしてください。
www.postman.com


インストールが完了したらアプリケーションを起動し、左上にある「新規」をクリックします。

「HTTP」をクリックします。

画面中央の「認証」タブを選択し、「Basic認証」をクリックします。

NSX Managerにログインするユーザー名とパスワードを入力します。

ポリシー情報の取得

NSX Managerの各種設定は、JSON形式で保存されているため、決められたAPIを実行することによって取得することができます。
APIの実行は、URL形式で記載し行きます。
まずは、Tier1ゲートウェイゲートウェイファイアウォールのポリシーとルールの情報を取得してみます。
NSX Managerに接続後、[セキュリティ]ー[ゲートウェイファイアウォール]ー[ゲートウェイ固有のルール]ー[t1gw01 | Tier-1]を選択すると、デフォルトで設定されているポリシーとルールが表示されます。

これを、APIで取得してみます。
以下のURLをPostmanの「GET」と表示されている右側の空欄に入力して、「送信」をクリックします。
IPアドレス部分は、自身のNSX Manager管理IPに置き換えてください。

https://192.168.10.61/policy/api/v1/infra/domains/

実行すると画面中央に「200 OK」と表示され、JSON形式の設定情報が取得できます。

"relative_path"の「default」と「/gateway-policies」を組み合わせた「default/gateway-policies」を先ほどのURLの後ろに追記し、「送信」をクリックします。

https://192.168.10.61/policy/api/v1/infra/domains/default/gateway-policies/


実行すると、以下のような結果が出力されます。
これは、デフォルトで設定されているゲートウェイファイアウォールのポリシーとルールになります。
この情報を参考にして、新規ルールを作成していきます。

{
    "results": [
        {
            "resource_type": "GatewayPolicy",
            "id": "Policy_Default_Infra-tier0-t0gw01",
            "display_name": "Policy_Default_Infra-tier0-t0gw01",
            "description": "Policy_Default_Infra-tier0-t0gw01",
            "path": "/infra/domains/default/gateway-policies/Policy_Default_Infra-tier0-t0gw01",
            "relative_path": "Policy_Default_Infra-tier0-t0gw01",
            "parent_path": "/infra/domains/default",
            "remote_path": "",
            "unique_id": "e0e2235b-bcbf-4f81-954b-40087c8f243b",
            "realization_id": "e0e2235b-bcbf-4f81-954b-40087c8f243b",
            "owner_id": "f9d28748-e56d-4a1e-9528-92b6b8df6a9b",
            "marked_for_delete": false,
            "overridden": false,
            "sequence_number": 90999999,
            "internal_sequence_number": 90999999,
            "category": "Default",
            "stateful": false,
            "locked": false,
            "lock_modified_time": 0,
            "is_default": true,
            "_create_time": 1706919684486,
            "_create_user": "system",
            "_last_modified_time": 1706919684486,
            "_last_modified_user": "system",
            "_system_owned": false,
            "_protection": "NOT_PROTECTED",
            "_revision": 0
        },
        {
            "resource_type": "GatewayPolicy",
            "id": "Policy_Default_Infra-tier1-t1gw01",
            "display_name": "Policy_Default_Infra-tier1-t1gw01",
            "description": "Policy_Default_Infra-tier1-t1gw01",
            "path": "/infra/domains/default/gateway-policies/Policy_Default_Infra-tier1-t1gw01",
            "relative_path": "Policy_Default_Infra-tier1-t1gw01",
            "parent_path": "/infra/domains/default",
            "remote_path": "",
            "unique_id": "ff76baab-e0b8-4d87-be84-fcadf979db93",
            "realization_id": "ff76baab-e0b8-4d87-be84-fcadf979db93",
            "owner_id": "f9d28748-e56d-4a1e-9528-92b6b8df6a9b",
            "marked_for_delete": false,
            "overridden": false,
            "sequence_number": 90999999,
            "internal_sequence_number": 90999999,
            "category": "Default",
            "stateful": true,
            "locked": false,
            "lock_modified_time": 0,
            "is_default": true,
            "_create_time": 1706929780696,
            "_create_user": "system",
            "_last_modified_time": 1706929780696,
            "_last_modified_user": "system",
            "_system_owned": false,
            "_protection": "NOT_PROTECTED",
            "_revision": 0
        }
    ],
    "result_count": 2,
    "sort_by": "display_name",
    "sort_ascending": true
}

ポリシーとルールの新規作成

ポリシーだけ作成してもGUIでは表示されないため、ルールも一緒に作成していきます。
GETで取得した情報を全て記載する必要はなく、最低限以下の情報があれば、ポリシーとルールの作成は可能となります。
ルールに関しては、rurles内で、送信元、送信先、サービス、アクション、対象のT1GWを記載します。
ポリシーについては、リソースタイプ、カテゴリを記載します。
以下のコードを[Body]から[raw]を選択し、表示形式を[JSON]として貼り付けます。

{
    "rules": [
        {
            "action": "DROP",
            "resource_type": "Rule",
            "display_name": "GWRule02",
            "source_groups": [
                "ANY"
            ],
            "destination_groups": [
                "ANY"
            ],
            "services": [
                "ANY"
            ],
            "scope": [
                "/infra/tier-1s/t1gw01"
            ]
        }
    ],
    "resource_type": "GatewayPolicy",
    "display_name": "GWPolicy02",
    "category": "LocalGatewayRules"
}

APIの実行する種類を「PUT」に変更し、以下の URL を空欄に入力して、「送信」をクリックします。
この時に、URL の最後の文字列は、ポリシー名を入力します。

https://192.168.10.61/policy/api/v1/infra/domains/default/gateway-policies/GWPolicy02


実行すると、以下のような結果が出力されます。

{
    "rules": [
        {
            "action": "DROP",
            "resource_type": "Rule",
            "id": "GWRule02",
            "display_name": "GWRule02",
            "path": "/infra/domains/default/gateway-policies/GWPolicy02/rules/GWRule02",
            "relative_path": "GWRule02",
            "parent_path": "/infra/domains/default/gateway-policies/GWPolicy02",
            "remote_path": "",
            "unique_id": "00000000-0000-0000-0000-000000003050",
            "realization_id": "00000000-0000-0000-0000-000000003050",
            "owner_id": "f9d28748-e56d-4a1e-9528-92b6b8df6a9b",
            "marked_for_delete": false,
            "overridden": false,
            "rule_id": 3050,
            "sequence_number": 0,
            "sources_excluded": false,
            "destinations_excluded": false,
            "source_groups": [
                "ANY"
            ],
            "destination_groups": [
                "ANY"
            ],
            "services": [
                "ANY"
            ],
            "profiles": [
                "ANY"
            ],
            "logged": false,
            "scope": [
                "/infra/tier-1s/t1gw01"
            ],
            "disabled": false,
            "direction": "IN_OUT",
            "ip_protocol": "IPV4_IPV6",
            "is_default": false,
            "_create_time": 1710252897558,
            "_create_user": "admin",
            "_last_modified_time": 1710252897558,
            "_last_modified_user": "admin",
            "_system_owned": false,
            "_protection": "NOT_PROTECTED",
            "_revision": 0
        }
    ],
    "resource_type": "GatewayPolicy",
    "id": "GWPolicy02",
    "display_name": "GWPolicy02",
    "path": "/infra/domains/default/gateway-policies/GWPolicy02",
    "relative_path": "GWPolicy02",
    "parent_path": "/infra/domains/default",
    "remote_path": "",
    "unique_id": "854328ee-d98f-443f-b0af-8a22cfcad139",
    "realization_id": "854328ee-d98f-443f-b0af-8a22cfcad139",
    "owner_id": "f9d28748-e56d-4a1e-9528-92b6b8df6a9b",
    "marked_for_delete": false,
    "overridden": false,
    "sequence_number": 0,
    "internal_sequence_number": 50000000,
    "category": "LocalGatewayRules",
    "stateful": true,
    "tcp_strict": true,
    "locked": false,
    "lock_modified_time": 0,
    "rule_count": 1,
    "is_default": false,
    "_create_time": 1710252897550,
    "_create_user": "admin",
    "_last_modified_time": 1710252897550,
    "_last_modified_user": "admin",
    "_system_owned": false,
    "_protection": "NOT_PROTECTED",
    "_revision": 0
}

また、GUI上でも作成したポリシーとルールが反映されています。

ポリシーとルールの修正

基本的に新規作成と内容は一緒になりますが、一度作成したポリシーやルールは個別に revision 管理されています。
よって、編集を行う前は、いったん GET で revision 情報を取得し、その情報を付加して PUT する形になります。
再度、以下のURLとコードでPUTを行います。

https://192.168.10.61/policy/api/v1/infra/domains/default/gateway-policies/GWPolicy02

ポリシーとルールにそれぞれ、「"_revision": 0」を追記し実行します。

{
    "rules": [
        {
            "action": "DROP",
            "display_name": "GWRule02",
            "source_groups": [
                "192.168.1.1"
            ],
            "destination_groups": [
                "ANY"
            ],
            "services": [
                "ANY"
            ],
            "scope": [
                "/infra/tier-1s/t1gw01"
            ],
            "_revision": 0  ←★この行が必要となる
        }
    ],
    "resource_type": "GatewayPolicy",
    "display_name": "GWPolicy02",
    "category": "LocalGatewayRules",
    "_revision": 0  ←★この行が必要となる
}


実行すると、以下のような結果が出力されます。

{
    "rules": [
        {
            "action": "DROP",
            "resource_type": "Rule",
            "id": "GWRule02",
            "display_name": "GWRule02",
            "path": "/infra/domains/default/gateway-policies/GWPolicy02/rules/GWRule02",
            "relative_path": "GWRule02",
            "parent_path": "/infra/domains/default/gateway-policies/GWPolicy02",
            "remote_path": "",
            "unique_id": "00000000-0000-0000-0000-000000003050",
            "realization_id": "00000000-0000-0000-0000-000000003050",
            "owner_id": "f9d28748-e56d-4a1e-9528-92b6b8df6a9b",
            "marked_for_delete": false,
            "overridden": false,
            "rule_id": 3050,
            "sequence_number": 0,
            "sources_excluded": false,
            "destinations_excluded": false,
            "source_groups": [
                "192.168.1.1"
            ],
            "destination_groups": [
                "ANY"
            ],
            "services": [
                "ANY"
            ],
            "profiles": [
                "ANY"
            ],
            "logged": false,
            "scope": [
                "/infra/tier-1s/t1gw01"
            ],
            "disabled": false,
            "direction": "IN_OUT",
            "ip_protocol": "IPV4_IPV6",
            "is_default": false,
            "_create_time": 1710252897558,
            "_create_user": "admin",
            "_last_modified_time": 1710253089846,
            "_last_modified_user": "admin",
            "_system_owned": false,
            "_protection": "NOT_PROTECTED",
            "_revision": 1
        }
    ],
    "resource_type": "GatewayPolicy",
    "id": "GWPolicy02",
    "display_name": "GWPolicy02",
    "path": "/infra/domains/default/gateway-policies/GWPolicy02",
    "relative_path": "GWPolicy02",
    "parent_path": "/infra/domains/default",
    "remote_path": "",
    "unique_id": "854328ee-d98f-443f-b0af-8a22cfcad139",
    "realization_id": "854328ee-d98f-443f-b0af-8a22cfcad139",
    "owner_id": "f9d28748-e56d-4a1e-9528-92b6b8df6a9b",
    "marked_for_delete": false,
    "overridden": false,
    "sequence_number": 0,
    "internal_sequence_number": 50000000,
    "category": "LocalGatewayRules",
    "stateful": true,
    "locked": false,
    "lock_modified_time": 0,
    "rule_count": 1,
    "is_default": false,
    "_create_time": 1710252897550,
    "_create_user": "admin",
    "_last_modified_time": 1710253089845,
    "_last_modified_user": "admin",
    "_system_owned": false,
    "_protection": "NOT_PROTECTED",
    "_revision": 1
}

また、GUI上でも修正したルールが反映されています。

ポリシーとルールの削除

最後に、削除を実施します。
削除は、APIを「DELETE」に変更し、削除したいポリシーを指定すると、ルール含めて削除されます。
以下のURLを貼り付けて、作成したポリシーとルールを削除します。この時ボディは「なし」としてください。

https://192.168.10.61/policy/api/v1/infra/domains/default/gateway-policies/GWPolicy02


実行すると、以下のようなに画面右側に、「ステータス 200 OK」と赤字で表示されます。

また、GUI上でもポリシーとルールが削除されました。

以上、APIによるゲートウェイファイアウォール操作の紹介でした。

NSXALBのX-Forwarded-Forを調べてみた

NSXALBによるHTTP/HTTPSアクセスした際の負荷分散は、基本的にSNATをしてサーバに転送するため、サーバのアクセスログを確認すると、送信元のIPアドレスはSEになっています。
アクセス元の情報が知りたい場合は、HTTP HeaderにX-Forwarded-For(XFF)の情報を付与する必要があります。
NSXALBのXFFヘッダー処理は、3種類の設定があるのでそれぞれ動作について見ていきます。

構成

ベースのネットワーク構成はこちらになります。

接続テストは、直接クライアントからNSXALBに接続すると、XFFの設定差異がわからないので、クライアントからプロキシサーバを経由してNSXALBに接続し、負荷分散する構成とします。
一応、プロキシサーバありと、なしの接続を設定毎に実施します。

Application Profileの作成

XFFの設定は、Application Profileで行います。
デフォルトでSystem-HTTP が用意されていますが、ラボ環境では、新規に作成してみます。
[Templates]-[Profiles]-[Application]から「CREATE」を選択します。

パターン1:受信したXFF HeaderをNSXALBで作成したXFFで置き換える

以下の情報を入力します。
Name:System-HTTP_XFF
Type:HTTP
X-Forwarded-For:有効
XFF Alternate Name:X-Forwarded-For
XFF Header Handling:All incoming X-Forwarded-For headers will be appended to the Avi created header(すべての受信 X-Forward-For ヘッダーを Avi で作成されたヘッダーに置き換えます)★パターン1



パターン2:受信したXFF HeaderにNSXALBのXFFで追記する

以下の情報を入力します。
Name:System-HTTP_XFF
Type:HTTP
X-Forwarded-For:有効
XFF Alternate Name:X-Forwarded-For
XFF Header Handling:All incoming X-Forwarded-For headers will be appended to the Avi created header(すべての受信 X-Forwarded-For ヘッダーは、Avi が作成したヘッダーに追加されます)★パターン2

パターン3:受信したXFF HeaderにNSXALBで作成したXFF Headerを新たに追加する

以下の情報を入力します。
Name:System-HTTP_XFF
Type:HTTP
X-Forwarded-For:有効
XFF Alternate Name:X-Forwarded-For
XFF Header Handling:All incoming X-Forwarded-For headers will be appended to the Avi created header(新しい X-Forwarded-For ヘッダーを追加するだけです)★パターン3

Virtual ServiceとApplication Profileの紐付け

Virtual Serviceの作成手順は割愛しますが、Application Profileで作成した「System-HTTP_XFF」を選択します。


動作確認

それぞれのパターンで、クライアントからプロキシ経由あり、なしでNSXALBのVIPに接続した際に、NSXALBとWebサーバ間のパケットをキャプチャしました。

パターン1:受信したXFF HeaderをNSXALBで作成したXFFで置き換える

この設定は、受信したパケットにXFF Headerがあったとしても、NSXALBで作成したXFFに置き換えるため、元々あったHeaderは削除されます。

プロキシサーバを経由せずにアクセスした場合は、クライアントIPの192.168.100.17がXFFにセットされています。

プロキシサーバを経由した場合は、プロキシサーバーでクライアントIPの192.168.100.17がXFFにセットされますが、NSXALBでプロキシサーバの192.168.1.32に置き換えられているため、クライアントIPの情報はありません。

パターン2:受信したXFF HeaderにNSXALBのXFFで追記する

この設定は、受信したパケットにXFF Headerがある場合、NSXALBで作成したXFFに元の情報を追記します。受信したパケットにXFFがない場合は、自身が作成したXFFを付与します。

プロキシサーバを経由せずにアクセスした場合は、クライアントIPの192.168.100.17がXFFにセットされています。

プロキシサーバを経由した場合は、元々プロキシサーバーでセットしていたクライアントIPの192.168.100.17情報の後ろに、NSXALBで作成したXFFにプロキシサーバの192.168.1.32をセットします。

パターン3:受信したXFF HeaderにNSXALBで作成したXFF Headerを新たに追加する

この設定は、受信したパケットにXFF Headerがある場合、NSXALBで作成したXFFに元の情報を追記します。受信したパケットにXFFがない場合は、自身が作成したXFFを付与します。

プロキシサーバを経由せずにアクセスした場合は、クライアントIPの192.168.100.17がXFFにセットされています。

プロキシサーバを経由した場合は、プロキシサーバで作成したXFF Header(クライアントIPの192.168.100.17)を残したまま、新たにNSXALBで作成したXFF Headerにプロキシサーバの192.168.1.32をセットして、Header情報そのものを追加します。

結果

パターン毎の結果は以下の通りです。
NSXALBのデフォルト動作は、パターン1のNSXALBが作成したXFFのみが追加される形のなります。
パターン2,3の違いは、XFF Header1つの中に複数の送信元情報をセットする(パターン2)か、元々のXFF Headerは変更せずに、新たにXFF Headerを追加する(パターン3)かになります。
また、送信元の情報が表示される順序がパターン2,3では逆になります。

パターン XFF Header処理 補足
1.All incoming X-Forwarded-For headers will be appended to the Avi created header 受信したXFF HeaderをNSXALBで作成したXFFで置き換える 元々のXFFは削除される
2.Replace all incoming X-Forward-For headers with the Avi created header 受信したXFF HeaderにNSXALBのXFFで追記する 元々のXFFを自身のXFF Header内に追加する
3.Simply add a new X-Forwarded-For header 受信したXFF HeaderにNSXALBで作成したXFF Headerを新たに追加する 元々のXFF Headerの後に自身のXFF Headerを追加する

NSXALBに到達する前に、どのような形でXFFが設置されているかによりますが、不特定多数に公開している場合などは、色々なパターンが考えられるのと、あえて、プロキシサーバを経由しているということを知られたくない場合は、自身の情報のみセットすることも考えられます。
この辺は、アプリケーションで送信元情報をどのように利用しているか確認してどのようにサーバへ渡してあげるかを決定するのが良いのかなと思います。