Skip navigation

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 5 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。


手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。 ★ここ

 

FW ルール セクションに FW ルールを追加して、通信が許可されたことを確認してみます。


FW ルール セクションに FW ルールを作成。


FW ルールごとに、XML ファイルを作成します。

XML で指定している 各オブジェクトの ID は、以前の投稿(下記)で確認ずみのものです。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

「EXT to Web」 ルール

NSX 環境の外部から、Web 層ネットワークの VM に SSH と HTTPS の通信を許可します。

  • ソース: 任意
  • ターゲット: Security Group 「Web-tier」
  • サービス: SSH、HTTPS
  • 操作: 許可

 

「EXT to Web」 ルール用の XML ファイル(dfw-rule-ext2web.txt)

cat <<EOF > dfw-rule-ext2web.txt

<rule id="0" disabled="false" logged="false">

  <name>EXT to Web</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <destinations excluded="false">

    <destination>

      <name>Web-tier</name>

      <value>securitygroup-10</value>

      <type>SecurityGroup</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>SSH</name>

      <value>application-305</value>

      <type>Application</type>

    </service>

    <service>

      <name>HTTPS</name>

      <value>application-67</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

「Web to App」ルール

Web 層ネットワークの VM から、 App 層ネットワークの論理スイッチに接続されている VM に、

MyApp サービス(TCP 8443 番ポート)の通信を許可します。

  • ソース: Security Group 「Web-tier」
  • ターゲット:論理スイッチ 「App_Tier_01」
  • サービス: サービス 「MyApp」
  • 操作: 許可

 

Web to App」 ルール用の XML ファイル(dfw-rule-web2app.txt)

cat <<EOF > dfw-rule-web2app.txt

<rule id="0" disabled="false" logged="false">

  <name>Web to App</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <sources excluded="false">

    <source>

      <name>Web-tier</name>

      <value>securitygroup-10</value>

      <type>SecurityGroup</type>

    </source>

  </sources>

  <destinations excluded="false">

    <destination>

      <name>App_Tier_01</name>

      <value>virtualwire-3</value>

      <type>VirtualWire</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>MyApp</name>

      <value>application-371</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

「App to Database」ルール

App 層ネットワークの論理スイッチに接続されている VM から DB 層ネットワークの論理スイッチに接続されている VM に、

MySQL サービスの通信を許可します。

  • ソース: 論理スイッチ「App_Tier_01」
  • ターゲット:論理スイッチ「DB_Tier_01」
  • サービス: サービス「MySQL」
  • 操作: 許可

 

「App to Database」 ルール用の XML ファイル(dfw-rule-app2db.txt)

cat <<EOF > dfw-rule-app2db.txt

<rule id="0" disabled="false" logged="false">

  <name>App to Database</name>

  <action>allow</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

  <sources excluded="false">

    <source>

      <name>App_Tier_01</name>

      <value>virtualwire-3</value>

      <type>VirtualWire</type>

    </source>

  </sources>

  <destinations excluded="false">

    <destination>

      <name>DB_Tier_01</name>

      <value>virtualwire-4</value>

      <type>VirtualWire</type>

    </destination>

  </destinations>

  <services>

    <service>

      <name>MySQL</name>

      <value>application-23</value>

      <type>Application</type>

    </service>

  </services>

</rule>

EOF

 

作成された FW ルールは、既存ルールの一番上に配置されるので、

今回は、ルールが下記の順になるように、作成順序を工夫しています。

 

FW ルールの順序。

  1. EXT to Web
  2. Web to App
  3. App to Database

 

FW ルールの作成順序。

  1. App to Database
  2. Web to App
  3. EXT to Web

 

※ただし今回の FW ルールでは、FW ルールセクション内で順序が異なっても問題になりません。

 

「App to Database」 ルールの作成

 

FW ルール セッション ID 1005 の ETag を取得して・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

FW ルールを作成します。

cat dfw-rule-app2db.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

「Web to App」ルールの作成

 

同様にセクションの Etag を取得しなおして・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

 

FW ルールを作成します。

cat dfw-rule-web2app.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

「EXT to Web」ルールの作成

 

同様にセクションの Etag を取得しなおして・・・

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005 | grep ETag | awk '{print $2}'`

 

FW ルールを作成します。

cat dfw-rule-ext2web.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1005/rules

 

このような感じで実行します。

hol-1603-mod3-p6-01.png

 

確認

 

Web Client からでも、FW ルールが作成されていることが確認できます。

hol-1603-mod3-p6-02.png

 

Web テストページが表示可能になったことを確認します。

hol-1603-mod3-p6-03.png

 

Web サーバ「web-01a」 にSSH アクセスが可能になったことを確認します。

ちなみに、マイクロセグメンテーションを意識した FW ルール設定なので、

この状態では Web 層のネットワークに所属する VM 同士(web-01a と web-02a) でも

不要な通信は許可されていません。

hol-1603-mod3-p6-04.png

 

このような感じで、Web Client で設定できる FW 設定は、NSX API でも可能です。

XML で設定値を指定しているので複雑に見えるかもしれませんが、

API 実行時に変更が必要な設定値は、ある程度、環境によって限定されるはずです。

今回は XML ファイルを手作業で作成したり、ID を grep で探したりしていますが、

ちゃんとツールを作成すれば手作業より安全に NSX の FW 設定を管理できそうです。

 

以上、NSX API で DFW を設定してみる話でした。

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 4 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。 ★ここ
  6. セクションに FW ルールを作成。


今回は FW ルール作成の準備として、FW ルールのセクションを作成します。


FW ルール セクションの作成。

 

FW ルールのセクション「3-tier App」を作成します。

 

セクションを作成する場合、XML はセクション名(name)だけでも大丈夫です。

また、NSX API ガイドにあるように FW ルールを含めてセクションを作成することも可能です。

API ガイドを見た様子では、FW ルールの順序の入れ替えなどはセクション全体の更新となるようなので、

実際は FW ルールもセッションと同時に作成したほうが便利かもしれません。

 

ここでは下記の XML で空のセクションを作成して、後から FW ルールを作成してみます。

<section name="3-tier App"/>

 

API でセクションを作成します。

テキストの量が少なかったので、今回は XML ファイルを作成してません。

echo '<section name="3-tier App"/>' | curl -k -s -u admin:VMware1! -X POST -H 'Content-type: text/xml' -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections

 

「3-tier App」セクションは、ID 1005 で作成されました。

hol-1603-mod3-p5-01.png

 

Web Client でも「3-tier App」 セクションの作成が確認できます。

hol-1603-mod3-p5-02.png

 

この状態で、次回の投稿で FW ルールを追加してみます。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

参考: FW ルールセクションの作成。(FW ルール含む)

 

FW ルールも含めてセクションを作成する場合は、下記のような XML になります。

この XML を投入すれば今回の設定は終わりですが、HoL の「テキストの送信」で

この量のテキストを送信するのはつらいので、あえて今回は FW ルールを別作成にしました。

<section name="3-tier App" >

  <rule disabled="false" logged="false">

    <name>EXT to Web</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <destinations excluded="false">

      <destination>

        <name>Web-tier</name>

        <value>securitygroup-10</value>

        <type>SecurityGroup</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>SSH</name>

        <value>application-305</value>

        <type>Application</type>

      </service>

      <service>

        <name>HTTPS</name>

        <value>application-67</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

  <rule disabled="false" logged="false">

    <name>Web to App</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <sources excluded="false">

      <source>

        <name>Web-tier</name>

        <value>securitygroup-10</value>

        <type>SecurityGroup</type>

      </source>

    </sources>

    <destinations excluded="false">

      <destination>

        <name>App_Tier_01</name>

        <value>virtualwire-3</value>

        <type>VirtualWire</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>MyApp</name>

        <value>application-371</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

  <rule disabled="false" logged="false">

    <name>App to Database</name>

    <action>allow</action>

    <appliedToList>

      <appliedTo>

        <name>DISTRIBUTED_FIREWALL</name>

        <value>DISTRIBUTED_FIREWALL</value>

        <type>DISTRIBUTED_FIREWALL</type>

      </appliedTo>

    </appliedToList>

    <sources excluded="false">

      <source>

        <name>App_Tier_01</name>

        <value>virtualwire-3</value>

        <type>VirtualWire</type>

      </source>

    </sources>

    <destinations excluded="false">

      <destination>

        <name>DB_Tier_01</name>

        <value>virtualwire-4</value>

        <type>VirtualWire</type>

      </destination>

    </destinations>

    <services>

      <service>

        <name>MySQL</name>

        <value>application-23</value>

        <type>Application</type>

      </service>

    </services>

  </rule>

</section>

 

ちなみに、FW セッションを作成する API では、FW ルールを含んでいても ETtag (If-Match ヘッダ)の指定は不要です。

上記の XML を「dfw-section-3tier.txt」 というファイルに保存してあるとすると、

下記のようなコマンドラインで FW セッションが作成できます。

cat dfw-section-3tier.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections

 

まだつづく・・・

NSX API での 分散 FW 設定を体験してみる。Part 6 (HOL-SDC-1603 Module 3 より)

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。 ★ここ
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

ここから、FW ルールの設定を変更します。

FW ルールで設定した通信のみ許可するため、まず FW のデフォルトルールを

すべて許可(Allow)される状態から、すべてブロックされる状態に変更します。

 

デフォルトの FW ルールを Allow → Block に変更。

 

「Default Section Layer3」セクションの「Default Rule」を、Allow から Block(deny)に変更します。

NSX API での FW ルールの設定変更では、まず XML ファイルを作成しておきます。

 

既存の FW ルールの情報は下記のようなコマンドラインで確認できるので、用意する XML の参考にします。

URL に含まれる ID は、前回の投稿で確認したものを指定しています。

  • 「Default Section Layer3」 の Section ID = 1003
  • 「Default Rule」 の Rule ID = 1001

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001 | xmllint --format -

 

今回は「Default Rule」ルールを設定変更するための XML を、「dfw-rule-default.txt」として用意します。

  • ルールの ID は、1001。※前回の投稿で確認した ID。
  • action で、Block に対応する「deny」を指定。

cat <<EOF > dfw-rule-default.txt

<rule id="1001" disabled="false" logged="false">

  <name>Default Rule</name>

  <action>deny</action>

  <appliedToList>

    <appliedTo>

      <name>DISTRIBUTED_FIREWALL</name>

      <value>DISTRIBUTED_FIREWALL</value>

      <type>DISTRIBUTED_FIREWALL</type>

    </appliedTo>

  </appliedToList>

</rule>

EOF

 

FW ルールの設定を変更する NSX API では、ETag ヘッダの指定が必要なため、設定変更の対象となるリソースの ETag を確認しておきます。

ヘッダ情報を確認するため、下記の curl コマンドラインでは「-I」 オプションを付けています。

curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001

hol-1603-mod3-p4-01.png


今回は、ETag の値を「ETAG」 という変数に代入して、コマンドラインで指定しています。

Etag の値を取得します。

ETAG=`curl -k -I -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001 | grep ETag | awk '{print $2}'`

 

さきほど作成した XML ファイル(dfw-rule-default.txt) の内容で、FW ルールを設定変更します。

cat dfw-rule-default.txt | curl -k -s -u admin:VMware1! -X PUT -H "Content-type: text/xml" -H "If-Match: $ETAG" -d @- https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections/1003/rules/1001

 

コマンドラインの実行結果から、action が deny になったことが確認できます。

hol-1603-mod3-p4-02.png

 

Web Client の情報を更新すると、ルールの Action が Allow から Block に変更されたことがわかります。

hol-1603-mod3-p4-03.png

 

「3-Tier Web App」のテストページが表示できなくなります。

hol-1603-mod3-p4-04.png

 

NSX 管理外の環境(ラボのコンソール)から、Web 層の VM 「web-01a」 への SSH アクセスができなくなります。

hol-1603-mod3-p4-05.png

 

つづく。

NSX API での 分散 FW 設定を体験してみる。Part 5 (HOL-SDC-1603 Module 3 より)

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 2 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみます。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。
  3. オブジェクト ID の確認。 ★ここ
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

NSX API では、URL や XML で設定対象を指定するときに、対象オブジェクトの ID 指定が必要になります。

そこで、各オブジェクトの ID を確認しておきます。

XML の出力結果を整形するため、パイプで 「xmllint --format -」 をつけています。

また、NSX API で取得した情報は、XML としてパースするわけではなく grep で簡易的に絞り込んでいます。

 

Transport Zone ID


Transport Zone の ID を確認しておきます。

今回の設定では、「Local-Transport-Zone-A」 という名前の Transport Zone を指定します。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/scopes | xmllint --format - | grep -E "vdnscope-|name" | grep -B1 "Local-Transport-Zone-A"

 

ID には、「vdnscope-」 がつきます。

  • Local-Transport-Zone-A → vdnscope-1

hol-1603-mod3-p3-01.png

 

論理スイッチ ID

 

論理スイッチ「App_Tier_01」、「DB_Tier_01」 の ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/vdn/scopes/vdnscope-1/virtualwires | xmllint --format - | grep -E "virtualwire-|name" | grep -B1 -E "App_Tier_01|DB_Tier_01"

 

ID には、「virtualwire-」 がつきます。

  • App_Tier_01 → virtualwire-3
  • DB_Tier_01 → virtualwire-4

hol-1603-mod3-p3-02.png


セキュリティグループ ID

 

FW ルールで指定する、セキュリティグループの ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/securitygroup/scope/globalroot-0 | xmllint --format - | grep -E "securitygroup-|name" | grep -B1 "Web-tier"

 

ID には、「securitygroup-」 がつきます。

hol-1603-mod3-p3-03.png

 

サービス ID

 

FW ルールで指定するサービスの ID を確認しておきます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/2.0/services/application/scope/globalroot-0 | xmllint --format - | grep -E "objectId|name" | grep -B1 -E "SSH|HTTPS|MyApp|MySQL"

 

ID には、「application-」 がつきます。

  • HTTPS → application-67
  • SSH → application-305
  • MyApp → application-371 ※ここまでの手順で作成したサービス。
  • MySQL → application-23

hol-1603-mod3-p3-04.png

 

FW ルール セクション ID


「Default Section Layer3」セクションの情報を確認します。

ルール名に含まれる半角スペースは、URL エンコーディングの都合で 「%20」 としています。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config/layer3sections?name=Default%20Section%20Layer3 | xmllint --format - | grep section

 

「Default Section Layer3」 セクションが ID = 1003 だということがわかります。

hol-1603-mod3-p3-05.png

 

FW ルール ID


ruleType=LAYER3 のルールで、ルール名に「default」 が含まれるルールの情報を取得してみます。

curl -k -s -u admin:VMware1! -X GET https://192.168.110.15/api/4.0/firewall/globalroot-0/config?ruleType=LAYER3\&name=default | xmllint --format - | grep -E "id=|name=" -A1

 

「Default Rule」 ルールが ID = 1001 だとわかります。

hol-1603-mod3-p3-06.png

 

つづく・・・

NSX API での 分散 FW 設定を体験してみる。Part 4 (HOL-SDC-1603 Module 3 より)

この投稿は、下記のつづきです。

NSX API での 分散 FW 設定を体験してみる。Part 1 (HOL-SDC-1603 Module 3 より)

 

NSX の分散ファイアウォール(DFW)を、API で設定してみようと思います。

手順では、ラボ(HOL-SDC-1603)の vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

手順の流れ。

  1. Security Group の作成。
  2. Service の作成。 ★ここ
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

ここでは、あとで FW ルールで通信許可のために指定する Service オブジェクトを作成します。

 

Service の作成

 

下記のサービスを作成します。

  • サービス名: MyApp
  • プロトコル: TCP
  • ボート番号: 8443

 

サービスの設定を記載した XML ファイルを作成します。

API ガイドをもとにすると、下記のような XML になりますが・・・

<application>

  <objectId></objectId>

  <type>

    <typeName/>

  </type>

  <description></description>

  <name>MyApp</name>

  <revision>0</revision>

  <objectTypeName></objectTypeName>

  <element>

    <applicationProtocol>TCP</applicationProtocol>

    <value>8443</value>

  </element>

</application>

 

今回は、デフォルト値でよいものは省略して、下記のように XML ファイルを作成しました。

cat <<EOF > app-myapp.txt

<application>

  <name>MyApp</name>

  <description/>

  <element>

    <applicationProtocol>TCP</applicationProtocol>

    <value>8443</value>

  </element>

</application>

EOF

 

作成した XML ファイルをもとに、API でサービスを作成します。

サービスは、API では「Application」 として扱われています。

cat app-myapp.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @-  https://192.168.110.15/api/2.0/services/application/globalroot-0

 

「MyApp」 サービスが、「application-371」 という ID で作成されたことがわかります。

hol-1603-mod3-p2-01.png

 

Web Client でも、サービスが作成されたことが確認できます。

サービスは、ホームの「Network & Security」 → 「NSX Managers」 → NSX Manager →

「Manage」 →「Grouping Objects」 →「Service」 で確認できます。

hol-1603-mod3-p2-02.png

 

つづく。

NSX API での 分散 FW 設定を体験してみる。Part 3 (HOL-SDC-1603 Module 3 より)

これまで、VMware Hands-on Labs(HoL)で NSX API を試すポストをしてきました。

今回は、分散ファイアウォール(DFW)を、API で設定してみようと思います。

DFW の設定については、「HOL-SDC-1603 VMware NSX Introduction」の Module 3 シナリオをもとにしました。

 

VMware Hands-on Labs

http://labs.hol.vmware.com/HOL/catalogs/

 

同じく HOL-SDC-1603 をもとにした、以前のポストもどうぞ・・・

NSX-v の API を HoL で実行してみる。

NSX API で NW 構成変更を体験してみる。(HOL-SDC-1603 Module 1)

NSX API で NW 構成変更を体験してみる。Part 2(HOL-SDC-1603 Module 2 より)

 

NSX API ガイドは下記です。

 

NSX vSphere API Guide NSX 6.2 for vSphere

http://pubs.vmware.com/NSX-62/topic/com.vmware.ICbase/PDF/nsx_62_api.pdf

 

手順の流れ。

 

HoL のシナリオと同様の設定をしますが、グループオブジェクトの作成などは順番を工夫しています。

1 ~ 3 については、あとで FW ルールで指定するための準備です。

  1. Security Group の作成。 ★今回はここまで。
  2. Service の作成。
  3. オブジェクト ID の確認。
  4. デフォルトの FW ルールを Allow → Block に変更。
  5. FW ルール セクションの作成。
  6. セクションに FW ルールを作成。

 

今回も、ラボの vCenter Server Appliance「vcsa-01a」の curl コマンドで、

NSX Manager 「192.168.110.15」 に API を実行しています。

 

Lab の初期状態。

 

設定変更前の Lab の環境について Web Client で状態確認しておきます。

「Default Section Layer3」セクションにある「Default Rule」が、この環境でデフォルトになる FW ルールです。

Action が「Allow」になっています。

hol-1603-mod3-p1-01.png

 

Web ブラウザで、「3-Tier Web App」のテストページが表示できます。

hol-1603-mod3-p1-02.png

 

NSX 管理外の環境(ラボのコンソール)から、Web 層の VM、「web-01a」 に SSH でアクセスできます。

hol-1603-mod3-p1-03.png

 

Security Group の作成。

 

ラボのシナリオでは、FW ルールでの送信元と送信元として、Security Group を指定しています。

そのため、FW ルール作成の準備として Security Group を作成しておきます。

 

「web-01a」、「web-02a」 という VM を含む、「Web-tier」という名前の Security Group を作成します。

今回は、Security Group の作成と、VM の追加を同時に実施します。

Security Group の設定を記載する XML では VM ID の指定が必要なので、

ここでは PowerCLI で確認しておきます。

PowerCLI> Connect-VIServer -Server vcsa-01a -User CORP\Administrator -Password VMware1!

PowerCLI> Get-VM web-0[12]a | sort Name | ft -AutoSize Name,Id

 

Security Group のメンバーにする VM のID がわかりました。

  • web-01a → vm-350
  • web-02a → vm-304

hol-1603-mod3-p1-04.png

 

XML ファイル(sg-web-tier.txt)を下記のように作成しておきます。

cat <<EOF > sg-web-tier.txt

<securitygroup>

  <objectId />

  <objectTypeName>SecurityGroup</objectTypeName>

  <name>Web-tier</name>

  <description></description>

  <scope>

    <id>globalroot-0</id>

    <objectTypeName>GlobalRoot</objectTypeName>

  </scope>

  <member>

    <name>web-01a</name>

    <objectId>vm-350</objectId>

    <objectTypeName>VirtualMachine</objectTypeName>

  </member>

  <member>

    <name>web-02a</name>

    <objectId>vm-304</objectId>

    <objectTypeName>VirtualMachine</objectTypeName>

  </member>

</securitygroup>

EOF

 

下記のコマンドラインで、Security Group を作成します。

cat sg-web-tier.txt | curl -k -s -u admin:VMware1! -X POST -H "Content-type: text/xml" -d @-  https://192.168.110.15/api/2.0/services/securitygroup/bulk/globalroot-0

 

実行すると、作成された Security Group の ID がわかります。

「Web-tier」は、securitygroup-10 として作成されました。

hol-1603-mod3-p1-05.png

 

Web Client からも確認できます。

Security Group は、ホームの「Network & Security」 → 「NSX Managers」 → NSX Manager(192.168.110.15)→

「Manage」 →「Grouping Objects」 →「Security Group」 で確認できます。

hol-1603-mod3-p1-06.png

 

つづく。

NSX API での 分散 FW 設定を体験してみる。Part 2 (HOL-SDC-1603 Module 3 より)