Operations Lab.

Archive for the ‘Windows Server’ Category

Network Controller の API に関するドキュメントの在処

leave a comment »

いつもどこにリファレンスがあるか分からなくなるのでメモ。API の在処はページ末尾に直リンクを記載しています。

Microsoft のプロトコル仕様等のドキュメント

プロトコルやインタフェースに関するドキュメントは MSDN にまとめられていますが、必要な時にたどり着けない(見つけられない)ことが多い気がします。「Protocol」ドキュメント階層へのナビゲーションも含めて、メモします。

MSDN での辿り方

MSDN のトップページから辿る場合、日本語版のページからではほぼたどり着けません。英語版に切り替えてからリンクを辿っていきます。(表示や階層は随時変更される可能性がありますので、2016/12/18 時点での情報です。)

  1. MSDN のトップページへアクセスします。(日本語でも英語でも OK)
  2. 「ドキュメント」の「API とリファレンス」を選択します。
    msdn-161219-01msdn-161219-02
  3. MSDN ライブラリが表示されるので、「Microsoft API とリファレンスのカタログ(Microsoft API and reference catalog)」で「ライブラリ TOC 表示に切り替える(Switch to Library TOC view)」を選択します。
    msdn-161219-03msdn-161219-04
  4. ライブラリ TOC が日本語で表示されている場合は、URL を書き換えて英語版のページを表示します。
    変更前:https://msdn.microsoft.com/ja-jp/library/ms310241
    変更後:https://msdn.microsoft.com/en-us/library/ms310241
    msdn-161219-05
    ※日本語版と英語版で TOC の中身が異なっており、英語版にしかリンクが存在しません。
  5. 左メニューで「Open Specifications」を選択します。
    msdn-161219-06
  6. 「Protocols」を選択します。
    msdn-161219-07
  7. 「Windows Protocols」を選択します。全ての仕様書を一括でダウンロードしたい場合は、ページ下部に一括ダウンロードのリンクがあります。
    msdn-161219-08
  8. 「Windows Technical Specifications」を選択します。
    msdn-161219-09
  9. プロトコルやインタフェースの仕様に関するドキュメントが一覧で表示されます。
    msdn-161219-10

Network Controller の Northbound API

Network Controller の API については、以下にドキュメントがあります。前述の手順で(も)辿れます。

2016/09/26 時点での最新版は ver.2.0 です。PDF 及び DOCX 形式でのダウンロードも可能です。(直リンク)

広告

Written by kazu

2016/12/19 at 00:18

Azure Automation DSC を使ってみる

with one comment

この記事は、PowerShell Advent Calendar 2016 の14日目です。

Microsoft Azure Automation DSC とは

Azure Automation DSC は、Azure Automation アカウントを作成することで利用可能な機能の一つです。シンプルに言うと、DSC Pull サーバー相当の機能を Azure のサービスとして利用できます。これにより、自分で DSC サーバーを用意(Windows Server で構築)することなく、管理対象のサーバーを Azure へ接続するだけで、DSC による構成管理を行えます。

そもそも DSC とは?

Desired State Configuration (DSC)は PowerShell をベースとした構成管理のためのテクノロジーです。ChepAnsible などと同じく、対象の構成を管理するためのものです。Configuration as Code を実現するという点においても似ています。

余談:Configuration as Code と Infrastructure as Code

Configuration as Code と Infrastructure as Code は同じような概念ですが、対象としている範囲が若干違います。

  • Infrastructure as Code は、主にインフラのファブリック構成をコードとして定義し、管理するものです。
  • Configuration as Code は、主に各機器(ノード)の設定をコードとして定義し、管理するものです。

両方をまとめて、広義の Infrastructure as Code として取り扱う場合もあります。Microsoft Azure 利用者の場合、Azure 内の(利用者としての)インフラ(どのような VM や仮想ネットワークを作成して、どうつなげるか)は ARM (Azure Resource Manager)が担っていますが、ARM テンプレートに記載される構成が Infrastructure as Code の部分、作成された仮想マシンの内部を設定する DSC が Configuration as Code となるイメージです。

PowerShell DSC と Azure Automation DSC

PowerShell DSC は特にサーバーがなくても(Configuration を対象に PUSH できれば)利用できます。ローカルノードを構成したいだけであれば、PowerShell DSC を PUSH モードで利用することが一番お手軽です。オンプレミスでもクラウド上の仮想マシンでも、Windows でも Linux でも PowerShell DSC を利用できます。(Linux で使用する場合は、それなりに準備が必要です。)

Azure Automation DSC は PowerShell DSC の PULL サーバー(及びレポートサーバー)相当の機能を提供します。このため、DSC で集中管理を行いたい場合に、DSC のためのサーバーをわざわざ自分で用意する必要がなくなります。オンプレミスの危機でもクラウド上の仮想マシンでも、Windows でも Linux でも、Azure Automation DSC の管理対象とすることができます。さらに、Azure の Windows 仮想マシンの場合は、Azure Automation DSC との連携を簡単に設定できるようになっています。(※)

(※)通常、DSC を PULL モードで使用する場合は、ローカルノード(管理対象)側で、PULL サーバの場所などを設定する必要があります。(当たり前ですが、PULL サーバがどこにあるか分からないと、接続できないですので。)Azure Automation DSC を利用する場合、同じサブスクリプション内の Windows 仮想マシンであれば、ポータルから紐づけを行うことができるようになっており、VM の内部で設定を行う必要がありません。

Azure Automation DSC を使用して、Azure の Windows 仮想マシンを管理する

ここからは Step-by Step で。

  1. Azure 管理ポータルから「新規」→「Monitoring + management」→「オートメーション」を選択します。
    aadsc-161214-001
  2. 「Automation アカウント」を作成します。「名前」は管理用の名前ですので、何でも OK です。その他の項目は、VM を作成する場合と同じです。アクションアカウントは、作成しておいたほうが後々面倒なことになりません。
    aadsc-161214-002
  3. Automation アカウントを新規に作成すると、以下のリソースが作成されます。
    aadsc-161214-003
  4. 管理対象となる VM をデプロイしておきます。既に存在する VM へ設定を行う場合は、改めてデプロイする必要はありません。VM デプロイ時に特殊な設定は不要で、デプロイされている VM を後から紐づけることができます。尚、ARM(Azure Resource Manager)管理の Virtual Machine (クラシック仮想マシンではないもの)で、OS が Windows Server となるものを選択すると、設定時の手間が少ないです。(以下はその手順を記載しています。)
    aadsc-161214-005aadsc-161214-006aadsc-161214-007aadsc-161214-008aadsc-161214-009aadsc-161214-010
  5. 以下の PowerShell スクリプト(DSC Configuration)を作成し、適当な名前で保存します。
    Configuration SampleConfig {
        
        Node "WebServer" {
    
            WindowsFeature IIS {
                Name = "Web-Server"
                Ensure = "Present"
            }
    
            WindowsFeature IISTools {
                Name = "Web-Mgmt-Tools"
                Ensure = "Present"
            }
    
            WindowsFeature xTelnet {
                Name = "Telnet-Client"
                Ensure = "Absent"
            }
            
        }
    
        Node "DNSServer" {
    
            WindowsFeature DNS {
                Name = "DNS"
                Ensure = "Present"
            }
    
            WindowsFeature DNSTools {
                Name = "RSAT-DNS-Server"
                Ensure = "Present"
            }
    
            WindowsFeature xTelnet {
                Name = "Telnet-Client"
                Ensure = "Absent"
            }
    
        }
    
    }
    
  6. Azure ポータルで、作成した Azure Automation アカウントを選択します。Automation アカウントの管理画面は以下の構成となっています。

    aadsc-161214-004

    Azure Automation DSC で主に使用するのは「リソース」内の「DSC 構成」と「DSC ノード」です。標準の DSC モジュール以外を使用する場合は。「資産」も使用します。(今回は使用しません。)

  7. 「DSC 構成」から「構成を追加」を選択し、先ほど作成した DSC Configuration ファイルをアップロードします。「名前」欄は、DSC Configuration で記載した Configuration 名が自動で入力されます。

    aadsc-161214-011
  8. 「DSC 構成」に先ほど登録した構成(SampleConfig)が追加されていることを確認します。

    aadsc-161214-012
  9. 追加した構成の名前(SampleConfig)を選択し、「コンパイル」をクリックします。DSC Configuration のコンパイルが実行されます。コンパイル ジョブはキューイングされた後、順次実行されますので、ジョブが完了するまで待ちます。

    aadsc-161214-013

    aadsc-161214-014

    aadsc-161214-015

  10. コンパイル ジョブが完了すると、コンパイルした DSC Configuration 内で定義された DSC 構成が利用できる状態になります。「プル サーバーで使用可能」の「ノード構成」に定義したノード構成が表示されていることを確認します。

    aadsc-161214-016
  11. 「DSC ノード」から「Azure VM の追加」を選択し、「Virtual Machine – オンボードする仮想マシンの選択」をクリックします。

    aadsc-161214-017
  12. 構成対象とする VM を選択します。尚、ここで選択できるのは ARM 管理の Virtual Machine で、OS が Windows のもののみです。クラシック仮想マシンの Windows については、仮想マシンの拡張機能の設定から操作を行います。Linux の場合は、OS にログインして構成スクリプトを実行する必要があります。

    aadsc-161214-018
  13. 「登録 – 登録データの構成」を選択し、先ほど選択した VM に対して紐づける DSC 構成を選択します。コンパイル済みの DSC ノード構成が表示されるため、プルダウンから選択します。その他のオプションは、オンプレミスの PowerShell DSC でプル サーバーを使用する際定義するものと同じです。(詳細は省略します。)

    aadsc-161214-019
  14. 「作成」をクリックして VM とノード構成の紐づけを作成します。正常に作成が完了すると、プル サーバーから DSC ノード構成が配布される(各管理対象ノードが構成を取得しに行く)状態となります。

    aadsc-161214-020
  15. しばらく待つと、各管理対象ノードが Azure Automation DSC プル サーバーから構成を取得し、取得した構成をもとに自身を再構成します。

    aadsc-161214-021

    一度構成を適用した後は、定期的にチェックが実行され結果がレポートサーバー(Azure Automation DSC プル サーバー)上に保存されます。各レポートの行を選択すると、詳細を表示できます。

まとめ

Azure Automation DSC は DSC サーバーを自前で用意する必要がないので楽。Azure 上の仮想マシンを管理対象とする場合にはとても楽。

機会があれば、Linux の DSC、及び Linux を Azure Automation DSC で管理する方法もまとめたいと思います。

Written by kazu

2016/12/14 at 00:00

日本語版 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 アドレスから動的に解決されます。

参考