Operations Lab.

Container SIG Meet-up 2016 Fall に参加しました

leave a comment »

10/7 (金)に Container SIG (Special Interest Group)の初イベントがありました。コンテナはインフラ観点でも Windows 観点でも Hot な Topic なので、一般の参加者として参加してきました。

会場は IIJ のセミナールームで、参加登録者(キャンセルした人を除く)はなんと 172 名と、初回のイベントにしてはかなり注目されているように感じました。

全体を通して

私はコンテナにそこまで詳しくないので、歴史を振り返るセッションから応用セッションまで楽しく聴講させていただきました。参加者の属性としては、コンテナに触ったことがある方がほとんどだけど、本番環境で運用している方は数名、という感じだった気がします。

セッション1:Linuxのコンテナ技術の変遷

IIJ 花高さんによる、Linuxのコンテナ技術の変遷について。コンテナ初心者かつ、普段最新情報を追いかけていない人にとっては、とても勉強になりました。なんとなく断片的に知っている内容も多いですが、改めて情報を整理できました。

セッション2:Dockerは2016年の秋現在、どのような状況なのか

さくらインターネットの前佛さん(@zembutsu)による、直近のコンテナ(主に Docker 周り)関連情報のまとめセッション。Docker はアップデートが早く、最新情報を追いかけるのも大変なので、大変助かります。最近は Docker がカバーする領域も広がってきていて、カオスですしね。

セッションスライドは SlideShare で、既に公開されています

ところで、Docker 日本語訳(Docker ドキュメント日本語化プロジェクト)って前佛さんの趣味個人プロジェクトだったのですね。

セッション3:Ansible Container – Container Automation with Ansible

Redhat 橋本さんによる Ansible を使ったコンテナの Automation に関するセッション。コンテナのデプロイを Ansible からコントロールするなど、Ansible ユーザー視点では順当な内容に思えました。本番環境でまじめにコンテナを運用管理するのであればアリかもしれません。既に Ansible で構成管理(Infrastructure as Code / Configuration as Code)を行っているところは多そうですし。

個人的には、Docker は Docker でコントロールする領域が増えてきているので、Ansible との連携がどの程度カバーしていけるか(追従していけるか)や、どのようにすみ分けていくか(ベストプラクティス的な意味でも)が気になります。

セッション4:Google Container Engineで五目並べアプリのAPIサーバーを作る

Google の中井さん(@enakai00)による、Google Container Engine を使用して五目並べのアプリケーションコンテナを起動し、サービスを提供する(API 経由でクライアントからのリクエストに応答する)というライブデモセッション。

やはり、ライブで構成(デプロイ、設定)するのはセッションとしてのインパクトが大きいですね。コンテナをステートレスにしておき、サービスをオンラインのまま、構成ファイルを書き換えてアプリをバージョンアップする(実際にはブルーグリーンデプロイメントによって本番環境がバックグラウンドで入れ替わっている)部分なども、普段からクラウドアプリケーションのバージョンアップを行っている人には当たり前ですが、レガシーアプリケーションが多い人には面白く映ったのではないかと思います。

セッションの内容は、Web で公開されています。また、デモで使用されていたコードも GitHub で公開いただいているようです。

セッション5:DDoS vs. DockerコンテナホスティングArukas

さくらインターネットの山田さん(現 Container SIG 会長)による、Arukas に DDoS を撃ち込まれた際のお話。Arukas はさくらインターネットさんが提供している Container ホスティングサービス(現在 Beta)ですが、オープンに(かつ日本で)利用可能な Docker のホスティングサービスはかなり珍しいので、お話を伺えるのは貴重な機会でした。

Arukas のユーザは 15000 人程度ということで、日本はそのうち 3000 ユーザ程度のようです。さくらさんのサービスは海外のユーザからもかなり利用されているんですね。Arukas が Beta で今のところは無償利用できる、というのと世界的にもコンテナホスティングはそれほど多くない、というのも要因としてあるとは思いますが。

DDoS のお話については、割と想像していた通りの内容でした。色々言ってしまって大丈夫なのか、心配になりました。まる。

アプリケーションエンジニアの方々におきましては、ぜひともコンテナのベースセキュリティ設定を見直していただきたく思います。インフラエンジニアは、もっと(今までインフラレイヤーの方々が OS などで培ってきた)情報を発信していかないといけないな、とも思っています。

次回

次回は半年後の予定(もしかしたらもう少し早いタイミングかも)ということなので、自分も Container への理解を深めつつ次回以降も参加していきたいと思いました。

Written by kazu

2016/10/10 at 02:15

PowerShell スクリプトのコマンドヘルプの書き方(簡易版)

leave a comment »

PowerShell では Get-Help コマンドレットでコマンドのヘルプを出力できます。自作したスクリプト(モジュール化などはしていない、単純な ps1 スクリプトファイル)であっても、ヘルプ情報を埋め込むことができます。

書き方

ヘルプ トピックの作成方法は、about_Comment_Based_Help に記載されています。

スクリプトファイルの先頭(Requires の直後)に、ブロックコメントで必要な情報を記載します。(ブロックコメントではなく 1 行ずつコメント化しても認識しますが、複数行に渡ることが多いため通常はブロックコメントを使用します。)

記述方法のサンプルは以下の通りです。

<#
    .SYNOPSIS
        Windows Server 2016 RTM の NanoServerImageGenerator を修正し、インターフェース名が ASCII 以外の場合にもアドレスを設定できるようにします。
    
    .DESCRIPTION
        Windows Server 2016 RTM の NanoServerImageGenerator は、インターフェース名が ASCII 文字列以外で表現されることを想定していません。そのため、デフォルトインターフェース名が ASCII 外の環境、例えば "イーサネット" となっている日本語環境では、IP アドレスを正しく設定できません。

        このスクリプトは、NanoServerImageGenerator モジュールを修正し、インターフェース名が ASCII 以外の環境においても、New-NanoServerImage で指定した IP アドレスが正しく設定されるよう、モジュールを修正します。
    
    .PARAMETER Path
        NanoServerImageGenerator モジュールのフォルダーを指定します。指定したフォルダー内のモジュールファイルが直接修正されます。
    
    .INPUTS
        なし。パイプラインからの入力には対応していません。
    
    .OUTPUTS
        System.Int32
        正常終了した場合は 0 を、それ以外の場合は 1 を返します。
    
    .EXAMPLE
        .\Modify-NanoServerImageGenerator.ps1 -Path C:\Temp\NanoServer\NanoServerImageGenerator
        C:\Temp にインストールメディアの NanoServer フォルダーをコピーした場合、NanoServer フォルダー内の NanoServerImageGenerator フォルダーを指定してください。
    
    .NOTES
        This script is only for Windows Server 2016 RTM (10.0.14393).
        This script is tested with Windows Server 2016 Evaluation 10.0.14393.0 JA-JP only.
        Use this at your own risk!
#>

ヘルプ キーワード

ヘルプ キーワードはドット(.)で始まります。

  • .SYNOPSIS
    関数またはスクリプトの簡単な説明。
  • .DESCRIPTION
    関数またはスクリプトの詳細な説明。
  • .PARAMETER <パラメーター名>
    パラメーターの説明。
  • .EXAMPLE
    関数またはスクリプトの使用方法(使用例)。
  • .INPUTS
    入力オブジェクトの .NET Framework 型。
  • .OUTPUTS
    出力オブジェクトの .NET Framework 型。
  • .NOTES
    関数またはスクリプトに関する追加情報。
  • .LINK
    「関連リンク」セクションに表示される内容。

キーワードは他にもありますが、簡単なスクリプトであれば上記以外を使用するシーンは少ないと思います。

スクリプトの説明を、通常のコメントとしてスクリプト内に埋め込むのもよいですが、PowerShell として用意されている方法がありますので、なるべくスクリプトのヘルプ トピックを記述するくせをつけると良さそうです。

Written by kazu

2016/09/29 at 03:24

日本語版 Nano Server イメージ作成時に IPv4 アドレスを設定する

leave a comment »

昨日の記事で日本語版は時期尚早と書きましたが、どうしても日本語版を使用したい方向け。

なぜ IPv4 アドレスを設定できないのか

New-NanoServerImage (Nano Server Image Generator モジュール)が、「イーサネット インタフェースの名前が日本語であること」(日本語環境だとデフォルトインタフェース名は「イーサネット」)を想定していないからです。

もう少し仕組みを詳しく

New-NanoServerImage で指定した IPv4 アドレスは、SetupComplete.cmd というファイルに書き込まれ、初回起動時に設定が試みられます。SetupComplete.cmd の中身は単純に netsh を呼び出しているだけで、その際に InterfaceNameOrIndex パラメータで指定したインタフェース名(またはインデックス番号)が渡されます。

日本語版の場合、デフォルトインタフェース名は「イーサネット」ですので、InterfaceNameOrIndex パラメータにも「イーサネット」(など)を指定すればよいはずですが、RTM メディアに含まれているモジュールでは正しく設定されません。

残念なことに、New-NanoServerImage は、SetupComplete.cmd を生成する際、ファイルのエンコードを強制的に ASCII に設定します。ですので、ASCII で表現できない「イーサネット」という文字列は正しく保持されず、起動時に netsh が実行されるものの不明なインタフェース名としてコマンドがエラーになります。結果として IPv4 アドレスは正しく設定されません。

つまり

以下の何れかでアドレスを正しく設定できます。

  1. インタフェース名ではなくインタフェース インデックス番号で対象を指定する
  2. Nano Server のイメージ作成後、イメージをマウントして SetupComplete.cmd を修正し、正しいエンコードで保存する
  3. New-NanoServerImage が SetupComplete.cmd を書き込む際のエンコードを変更する

Nano Server はインタフェースインデックス番号があまり変動しない(インストールの都度変わることがほぼない?経験上であり、仕様上どうなのかは不明)ようなので、一度番号が分かれば 1 の方法でもよいかもしれません。ただし、一度インストールしてみるなど、何らかの方法でインデックス番号を知る必要があります。

2 の方法は、、、面倒ですね。

ということで、3 の方法を実現するためのスクリプトを作成しました。(GitHub 上で公開しています。)

#Requires -Version 5
#Requires -RunAsAdministrator

[Cmdletbinding()]
param
(
    [Parameter(Mandatory)]
    [string]$Path
)

## Initialize
$ErrorActionPreference = "Stop"
# Target Module File
$target = $Path + "\NanoServerImageGenerator.psm1"
# Original FileHash (SHA256)
$hash = "5DDA7841FEDC064F2696D1155717E9094621722C0F2645D1062453D4047C997B"
# Target line
$line2508 = @'
    Set-Content -Value $SetupCompleteCommand -Path "$Script:TargetSetupCompleteFilePath" -Encoding UTF8
'@

## Check target
if(!(Test-Path $target)) {
    Write-Output "モジュールが存在しません。"
    Write-Verbose -Message ("Path: {0}" -f $Path)
    Write-Verbose -Message ("Target: {0}" -f $target)
    exit 1
}

$h = Get-FileHash -Algorithm SHA256 $target
if($hash -ine $h.Hash) {
    Write-Output "モジュールがオリジナルの状態ではありません。"
    Write-Verbose -Message "モジュールのハッシュ値が想定と異なります。"
    Write-Verbose -Message ("Expected Hash (SHA256): {0}" -f $hash)
    Write-Verbose -Message ("Actual Hash (SHA256): {0}" -f $h.Hash)
    exit 1
}

## Copy & Modify
Copy-Item -Path $target -Destination ($target + ".original") -Force
$c = Get-Content -Path $target -Encoding UTF8
$c[2508] = $line2508
Set-Content -Path $target -Value $c -Encoding UTF8

Write-Output "FailoverClusters モジュールを修正しました。"
return 0

このスクリプトは、NanoServerImageGenerator モジュールを書き換え、SetupComplete.cmd を UTF-8 で生成するように動作を変更します。

実行する際は、Path パラメータに書き換え対象の NanoServerImageGenerator モジュールを含んでいるフォルダーを指定してください。例えば、

PS> .\Modify-NanoServerImageGenerator.ps1 -Path C:\Temp\NanoServer\NanoServerImageGenerator

詳しくは、Get-Help .\Modify-NanoServerImageGenerator.ps1 でヘルプを参照してください。

※ご利用は自己責任でお願いします。

Written by kazu

2016/09/28 at 00:15

カテゴリー: PowerShell, Windows Server

Tagged with ,

Windows Server 2016 Nano Server と日本語環境

leave a comment »

Windows Server 2016 が RTM となり、評価版がダウンロードできるようになりました。

結論

日本語版 Nano Server を使用するのは時期尚早です。やめましょう。

どうしても利用したい方は、以下を理解したうえで自己責任でどうぞ。

日本語版で困ること

Nano Server のイメージを作成する際に、静的 IP アドレスを正しく設定できない

New-NanoServerImage で IPv4Address などを指定しても、IP アドレスが設定されません。DHCP を使用する場合は問題ありませんが、静的アドレスを使用したい場合は、Recovery Console 側で設定操作が必要です。

Recovery Console が文字化けする

Recovery Console は日本語対応していないため、日本語で出力される部分はもれなく文字化けします。例えば、時刻表示やネットワーク インタフェース名、Windows Firewall のルール名などが文字化けします。

img002618img002625

RTM の Nano Server では Recovery Console でできることが増えているため、相対的に不便さ倍増です。

新規に作成した Gen 2 仮想マシンが存在すると、仮想マシン管理サービスがクラッシュする

Hyper-V の役割をインストールして Hyper-V ホストとして使用することを考えている方も多いと思いますが、日本語版 Nano Server 上で新規に Gen 2 仮想マシンを作成し、PowerShell 上で Get-VMFirmware を実行すると、Hyper-V 仮想マシン管理サービス(Hyper-V Virtual Machine Management Services / vmms)がもれなくクラッシュします。

Gen 2 仮想マシンの状態や、セキュアブートの設定には依存しません。VM が停止状態であっても、セキュアブートが無効に設定されていてもクラッシュします。(これはおそらく、セキュアブート テンプレートに不整合が発生しているためと思われます。(次項参照))

vmms がクラッシュしても仮想マシンは停止しませんが、Hyper-V マネージャや PowerShell などから管理ができなくなります。

Gen 2 仮想マシンのセキュアブート テンプレートを変更できない

日本語 Nano Server 上で新規に Gen 2 仮想マシンを作成すると、セキュアブート テンプレートを選択するリストが表示されないため、テンプレートを選択できません。また、この状態で仮想マシンの電源をオンにすると、セキュアブートテンプレートの互換性に問題がある旨、警告が表示されます。

英語版 Nano Server

img002639

日本語版 Nano Server

img002640

img002641

なんとなく、セキュアブート テンプレートが壊れているか、内部的に不整合な状態になっている気がします。

デフォルト タイムゾーンが US に設定される

日本語版イメージを作成すると、言語環境や時刻、通貨表記などは日本語(日本環境)になりますが、タイムゾーンは米国およびカナダ(UTC-8)が設定されます。(いっその事すべて US 環境がデフォルトなら問題は少なかったかもしれないのに…。)

img002629

なお、タイムゾーンは起動後にコマンドで変更できますので、大きな問題ではありません。

最後に

Nano Server は、他の Windows Server 2016 (Core / Desktop)と異なり CBB (Current Branch for Business)で提供されます。(Windows Server は LTSB ; Long Term Service Branch)で提供されるため、不具合の改修やアップデート(に伴う仕様変更)も早いと思われます。

もう少ししたら、日本語版でも問題なく利用できるようになるかもしれません。

Written by kazu

2016/09/27 at 04:41

Docker はコンテナそのものではない(はず…)

leave a comment »

最近、あまりにも Docker という言葉が曖昧なコンテキストで使われているので、少しまとめてみます。

おことわり

  • 旧来の Docker について記載します。(Docker ファミリーはどんどん進化(領域拡大)しているので、将来的にはこのポストの内容が誤りになるかもしれません。)
  • 2016 年 9 月時点の情報をベースにしています。
  • 分かりやすさを優先するため、厳密には正しくない記載(割り切った記載)が含まれます。
  • 誤りがあれば、ぜひご指摘ください。(特に有識者の方)

初めに

Docker コンテナそのものを実現する(実行する)仕組み(機能)

乱暴に言うと、Docker はコンテナそのものではありません。仮想マシンに例えて言うなら、Windows Hyper-V における Hyper-V (ハイパーバイザ)そのものではありません。

Docker (または Docker コンテナとは)

ざっくり言うと、以下の 3 つ(のどれか)です。

  1. コンテナイメージのフォーマット(の一種)
  2. コンテナを管理・制御するためのサービスおよびツール群(dockerd および docker cli)
  3. コンテナイメージを管理、再利用するためのレポジトリ (Docker Hub, Docker Registry)

これらを含めて Docker エコシステムが形成されています。

結局 Docker は何をしてくれているのか

コンテナそのものは、(Linux であれば)Linux Containers (各種ネームスペースや cgroups などの、Linux kernel の機能)により実現されています。Windows Server 2016 の場合は、「Containers」の機能(Windows Containers / Hyper-V Containers)によって実現されています。

Docker はコンテナを実現する仕組みをうまくコントロールし、管理を行うためのサービスやユーザーインタフェースを提供してくれています。

乱暴な言い方をすると、Hyper-V の世界でいうところの、System Center Virtual Machine Manager (SCVMM) や、Hyper-V Manager、Virtual Machine Management Services (vmms)のようなものを提供してくれています。

参考資料

Written by kazu

2016/09/17 at 15:43

カテゴリー: Containers, Linux, Windows Server

Tagged with ,

System Center User Group Japan 第15回勉強会で登壇しました

leave a comment »

System Center User Group Japan (SCUGJ)第15回勉強会で登壇させていただきました。今回は、クラウドと OSS (Open Source Software)がテーマということで、PowerShell DSC for Linux と Azure Automation DSC のお話をさせていただきました。

資料は SlideShare に掲載しています。また、デモで使用したサンプルコードは GitHub 上で公開しています。

PowerShell DSC for Linux と Azure Automation DSC については、別途記事にまとめる予定です。

Windows 10 with Hyper-V で NAT を使用する

leave a comment »

※ このポストで取り扱っている NAT は、内部ネットワークから外部へ通信を行う際の Source NAT(SNAT)です。実際はポート変換も実行されるため、SNAPT (Source Network Address/Port Translation)になります。

Windows 10 Anniversary Update (Version 1607)で、Hyper-V 上の仮想マシンが外部へ通信する際に NAT を行うことが(標準の機能のみで)できるようになりました。

いままでは

Hyper-V の機能、または仮想スイッチの機能としては NAT を行うことができなかったため、仮想マシンが外部と通信を行う場合は、以下何れかの方法で外部通信を実現していました。

  • 外部(External)仮想スイッチで直接外部に接続する
  • Hyper-V ホストで、「インターネット接続共有」(クライアント OS の場合)または「ルーティングとリモートアクセス」の役割(サーバー OS の場合)を構成する
  • (NAT 用の VM を作成して、NAT を適用する)
    ※この方法は、結局他の方法で NAT VM を外部接続させる必要があります。

ノート PC などで、Hyper-V ホストの外部インターネットアクセスが無線 LAN アダプターとなっているような環境では、External スイッチへ VM を直接接続しても正しく通信が行えない(※)ため、ホスト側で「インターネット接続共有」を有効化して使用していた方も多いと思います。

※ External 仮想スイッチの場合、VM の MAC アドレスは変換されない(VM の仮想 NIC に付与された MAC アドレスで通信を行う)ため、無線アクセスポイントとの通信が正しく行えません。

今回の機能(Hyper-V 仮想スイッチでの NAT)により、無線 LAN 環境下であっても、インターネット接続共有や RRAS を使用せず外部へ通信できるようになります。

利用するには

Hyper-V の機能が有効化された Windows 10 Build 14295 が必要です。Windows 10 Anniversary Update は Build 10393 なので利用することができます。Windows Server 2016 でも(リリースされれば)利用できると思われます。(サーバー OS に無線 LAN アダプターを接続する人は少ないと思いますので、直接的な恩恵は少ないと思いますが。)

注:後述の通り、NAT スイッチには制限があるため、サーバー(システム)環境で多数のセグメントを収容し、NAT を行いたい場合は、今まで通り RRAS を使うか NAT 用の VM (仮想アプライアンス)を使用したほうが良いと思います。

設定方法

以下の流れで設定します。

  1. Hyper-V ホスト側に外部通信可能なインタフェースを用意し、IP アドレスを設定する(ホストが外部通信できる状態にする)
  2. 「内部」の(Internal タイプの)仮想スイッチを作成する
  3. ホスト OS 上に作成された(Internal 仮想スイッチに接続された)仮想 NIC (vEthernet)に IP アドレスを設定する
  4. (仮想 NIC に設定した IP アドレスをレンジに含む)NAT ネットワークを設定する

ホスト側の外部通信可能なインタフェース

これは、通常通りホスト上で IP アドレスをアサインし、ホストが外部通信可能であれば OK です。外部通信用の NIC を仮想スイッチにバインドする必要はありません。

Internel vSwitch の作成

Hyper-V マネージャーまたは PowerShell で仮想スイッチを作成します。このとき、SwitchType に Internal (内部)を指定します。

※ PowerShell で作業を行う場合は「管理者として実行」します。(以下同様)

下記の例では、「Internal」という名前の内部(Internal タイプの)仮想スイッチを作成しています。(名前は他の仮想スイッチと重複しなければ何でも OK 。)

PS C:\> New-VMSwitch -Name Internal -SwitchType Internal

Name      SwitchType NetAdapterInterfaceDescription
----      ---------- ------------------------------
Internal  Internal

PS C:\> Get-VMSwitch -Name Internal | fl *

Name                                : Internal
Id                                  : c51a5bd2-c53c-48f0-af9d-742f477fbfec
Notes                               :
Extensions                          : {Microsoft Windows フィルタリング プラットフォーム, Microsoft NDIS キャプチャ}
BandwidthReservationMode            : Absolute
PacketDirectEnabled                 : False
EmbeddedTeamingEnabled              : False
IovEnabled                          : False
SwitchType                          : Internal
AllowManagementOS                   : True
NetAdapterInterfaceDescription      :
NetAdapterInterfaceDescriptions     :
IovSupport                          : False
IovSupportReasons                   :
AvailableIPSecSA                    : 0
NumberIPSecSAAllocated              : 0
AvailableVMQueues                   : 0
NumberVmqAllocated                  : 0
IovQueuePairCount                   : 0
IovQueuePairsInUse                  : 0
IovVirtualFunctionCount             : 0
IovVirtualFunctionsInUse            : 0
PacketDirectInUse                   : False
DefaultQueueVrssEnabledRequested    : True
DefaultQueueVrssEnabled             : False
DefaultQueueVmmqEnabledRequested    : False
DefaultQueueVmmqEnabled             : False
DefaultQueueVmmqQueuePairsRequested : 16
DefaultQueueVmmqQueuePairs          : 0
BandwidthPercentage                 : 0
DefaultFlowMinimumBandwidthAbsolute : 0
DefaultFlowMinimumBandwidthWeight   : 0
CimSession                          : CimSession: .
ComputerName                        : TAKAI02
IsDeleted                           : False

PS C:\>

Internal vSwitch のホスト側仮想インタフェース(vEthernet)に IP を設定

コントロールパネル(ネットワーク接続)または PowerShell で、ホスト側に作成された仮想 NIC に IP アドレスを設定します。ここで指定した IP アドレスが、VM から見た時の GW アドレスになります。

※ 上記ホスト側仮想 NIC にはデフォルトゲートウェイを設定する必要はありません。

下記の例では、192.168.137.1/24 をホスト側の仮想 NIC へアサインしています。(192.168.137.0/24 はインターネット接続共有で使用される IP アドレスレンジなので、競合する場合は他のレンジを使用したほうが良いでしょう。)

PS C:\> Get-NetAdapter | ft Name,ifIndex,InterfaceDescription,Status

Name                       ifIndex InterfaceDescription                     Status
----                       ------- --------------------                     ------
Bluetooth ネットワーク接続      20 Bluetooth Device (Personal Area Network) Disconnected
vEthernet (Internal)            12 Hyper-V Virtual Ethernet Adapter         Up
Wi-Fi                            3 Intel(R) Dual Band Wireless-AC 7260      Up

PS C:\> New-NetIPAddress -InterfaceIndex 12 -AddressFamily IPv4 -IPAddress 192.168.137.1 -PrefixLength 24

IPAddress         : 192.168.137.1
InterfaceIndex    : 12
InterfaceAlias    : vEthernet (Internal)
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Manual
SuffixOrigin      : Manual
AddressState      : Tentative
ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource      : False
PolicyStore       : ActiveStore

IPAddress         : 192.168.137.1
InterfaceIndex    : 12
InterfaceAlias    : vEthernet (Internal)
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Manual
SuffixOrigin      : Manual
AddressState      : Invalid
ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource      : False
PolicyStore       : PersistentStore

PS C:\> Get-NetIPAddress -InterfaceIndex 12

IPAddress         : fe80::103e:d542:892c:f48c%12
InterfaceIndex    : 12
InterfaceAlias    : vEthernet (Internal)
AddressFamily     : IPv6
Type              : Unicast
PrefixLength      : 64
PrefixOrigin      : WellKnown
SuffixOrigin      : Link
AddressState      : Preferred
ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource      : False
PolicyStore       : ActiveStore

IPAddress         : 192.168.137.1
InterfaceIndex    : 12
InterfaceAlias    : vEthernet (Internal)
AddressFamily     : IPv4
Type              : Unicast
PrefixLength      : 24
PrefixOrigin      : Manual
SuffixOrigin      : Manual
AddressState      : Preferred
ValidLifetime     : Infinite ([TimeSpan]::MaxValue)
PreferredLifetime : Infinite ([TimeSpan]::MaxValue)
SkipAsSource      : False
PolicyStore       : ActiveStore

PS C:\>

NAT ネットワークの設定

ホスト側で PowerShell を使用し、NAT ネットワークを作成します。New-NetNat コマンドに Name (ネットワーク識別名)と InternalIPInterfaceAddressPrefix (NAT 対象となるネットワークプレフィックス)を指定するだけです。

下記の例では、「VMNatNetwork」という名前の NAT ネットワーク(設定)を作成しています。InternalIPInterfaceAddressPrefix に指定した 192.168.137.0/24 からの通信が NAT 対象となります。

PS C:\> New-NetNat -Name VMNatNetwork -InternalIPInterfaceAddressPrefix 192.168.137.0/24

Name                             : VMNatNetwork
ExternalIPInterfaceAddressPrefix :
InternalIPInterfaceAddressPrefix : 192.168.137.0/24
IcmpQueryTimeout                 : 30
TcpEstablishedConnectionTimeout  : 1800
TcpTransientConnectionTimeout    : 120
TcpFilteringBehavior             : AddressDependentFiltering
UdpFilteringBehavior             : AddressDependentFiltering
UdpIdleSessionTimeout            : 120
UdpInboundRefresh                : False
Store                            : Local
Active                           : True

PS C:\> Get-NetNat | fl *

Store                            : Local
TcpFilteringBehavior             : AddressDependentFiltering
UdpFilteringBehavior             : AddressDependentFiltering
UdpInboundRefresh                : False
Active                           : True
Caption                          :
Description                      :
ElementName                      :
InstanceID                       : VMNatNetwork;0
ExternalIPInterfaceAddressPrefix :
IcmpQueryTimeout                 : 30
InternalIPInterfaceAddressPrefix : 192.168.137.0/24
InternalRoutingDomainId          : {00000000-0000-0000-0000-000000000000}
Name                             : VMNatNetwork
TcpEstablishedConnectionTimeout  : 1800
TcpTransientConnectionTimeout    : 120
UdpIdleSessionTimeout            : 120
PSComputerName                   :
CimClass                         : root/StandardCimv2:MSFT_NetNat
CimInstanceProperties            : {Caption, Description, ElementName, InstanceID...}
CimSystemProperties              : Microsoft.Management.Infrastructure.CimSystemProperties

PS C:\>

InternalIPInterfaceAddressPrefix は、Internal vSwitch に接続されたホスト側の仮想 NIC にアサインした IPアドレスを含んでいる必要があります。例えば、ホスト側の仮想 NIC に 192.168.0.1/24 を設定した場合、InternalIPInterfaceAddressPrefix には 192.168.0.0/24 などを指定します。

※ NAT 先の IP アドレス(所謂、External IP Address)は指定しません。動的に決定されます。

制限事項

何れも現時点においての制限事項です。(将来どうなるかは不明です。)

  • NAT ネットワークは複数作成できません。複数作成すると意図しない動作をする可能性があります。
  • Windows Container (docker)を使用すると、NAT タイプのネットワークが自動的に作成されます。コンテナと併用する場合は、自動的に作成された NetNat を流用するか、一度 NAT 定義を削除した後両方をカバー可能な広いレンジの NAT ネットワークを定義してください。
  • NAT を行うインタフェースは指定できません。IP アドレスから動的に解決されます。

参考