ここでのテストを実行することで、DNS が内部アドレスと外部アドレスの両方を解決できる、および必要な送信ポートが開いている、という 2 つのネットワーク関連の領域が適切に設定されていることを確認します。これらのテストは、テスト用仮想マシンを使用して実行します。

ポッドは DNS によって内部アドレスと外部アドレスの両方を解決します。ここでの最初の 2 つのテストでは、ネットワーク環境で設定された DNS が、内部アドレスと外部アドレスの既知の FQDN を解決できるかを確認します。

重要: すべてのトラフィックをオンプレミス ネットワーク経由で通るように向けていて、認証トラフィックの通過のみを許可している場合に、ポッド デプロイ ウィザードでプロキシを使用するための値を指定しなかった場合は、これらの手動のテストがすべて成功しても、非認証ソースであるジャンプ ボックスによって送信されたトラフィックは失敗します。この状況では、ポッド デプロイが保留中の状態で停止します。この状況が発生した場合は、[はじめに] ページからポッドを削除し、ポッド デプロイ ウィザードを再実行し、必要なプロキシ情報を指定する必要があります。

前提条件

これらのテストを実行する前に、Microsoft Azure サブスクリプションにテスト用仮想マシンを作成するおよびSSH を使用してテスト用仮想マシンに接続するでの説明に従って、Microsoft Azure サブスクリプションでテスト用仮想マシンを作成し、SSH 接続があることを確認します。

Active Directory ドメイン コントローラなど、VNet からアクセス可能であると考えられるネットワークの内部にあるサーバの IP アドレスと完全修飾ドメイン名 (FQDN) を取得します。この情報は、DNS 検証テストで使用します。

手順

  1. dlg コマンドを使用して Microsoft Azure の VNet の内部にある既知のドメイン名をクエリすることにより、DNS が環境内で動作し、内部 FQDN を解決できることを確認します。
    SSH 接続ウィンドウで、 dig コマンドを実行し、Active Directory ドメイン コントローラなどネットワークの内部にあることがわかっているサーバのドメイン名をクエリします。
    dig internal-domain-name
    ここで、 internal-domain-name は、ネットワークの内部にあることがわかっているサーバの完全修飾ドメイン名です。

    dig (Domain Information Groper) は、ネットワーク トラブルシューティングのためのコマンドライン ツールです。内部ホスト名を使用してこのコマンドを実行した結果により、DNS 構成が内部アドレスを適切に解決できるかどうかが検証されます。DNS 構成がコマンドで使用される internal-domain-name を解決できる場合、コマンド出力はそのドメイン名に関連付けられた正しい IP アドレスを返します。

    たとえば VNet が、DNS エントリが skylo.local で IP アドレスが 192.168.0.15 の Active Directory ドメイン コントローラを持つ内部 Active Directory サーバで構成されているとします。 dig skylo.local を発行すると、VNet の DNS 構成がその内部の skylo.local サーバ名を解決できるかどうかがチェックされます:
    testvmadmin@HCS-testingVM:~$ dig skylo.local
    
    ; <<>> DiG 9.10.3-P4-Ubuntu <<>> skylo.local
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64899
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4000
    ;; QUESTION SECTION:
    ;skylo.local.                   IN      A
    
    ;; ANSWER SECTION: skylo.local.600 IN A 192.168.0.15
    
    ;; Query time: 1 msec
    ;; SERVER: 192.168.0.15#53(192.168.0.15)
    ;; WHEN: Mon Mar 26 20:58:01 UTC 2018
    ;; MSG SIZE  rcvd: 56
    
    testvmadmin@HCS-testingVM:~$
    ANSWER SECTION が、指定したホスト名がそのホスト名に対して予測される IP アドレスに解決されたことを示している場合は、テストは成功です。
    注: 場合によっては DNS が完全に信頼できるものではなく、一部の要求は正常に解決され、他の要求は失敗することがあります。コマンドの最初の発行が失敗する場合は、コマンドを 10 ~ 20 回繰り返して実行し、信頼できる応答が毎回得られるかどうかを確認します。
  2. dlg コマンドを使用して既知の外部ドメイン名をクエリすることにより、DNS が環境内で動作し、外部 FQDN を解決できることを確認します。
    SSH 接続ウィンドウで、 dig コマンドを発行し、 vmware.com または microsoft.com などの外部の業界標準ドメイン名をクエリします。
    dig external-domain-name
    ここで、 external-domain-name は、VNet の外部にある完全修飾ドメイン名です。たとえば、 dig vmware.com を発行すると VNet の DNS 構成がその外部名を解決できたかどうかチェックします。
    testvmadmin@HCS-testingVM:~$ dig vmware.com
    
    ; <<>> DiG 9.10.3-P4-Ubuntu <<>> vmware.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38655
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4000
    ;; QUESTION SECTION:
    ;vmware.com.                    IN      A
    
    ;; ANSWER SECTION: vmware.com.150 IN A 107.154.105.19 vmware.com.150 IN A 107.154.106.19
    
    ;; Query time: 28 msec
    ;; SERVER: 192.168.0.15#53(192.168.0.15)
    ;; WHEN: Mon Mar 26 21:14:29 UTC 2018
    ;; MSG SIZE  rcvd: 71
    
    testvmadmin@HCS-testingVM:~
    上記の例では、ANSWER SECTION は外部ドメイン名 vmware.com が 2 つの IP アドレスに適切に解決されたことを示しています。
    注: このテストを azure.commicrosoft.com などのさまざまな外部ドメイン名を使用して繰り返し、DNS が異なる外部名を解決できることを確認できます。
    DNS テストが機能しない場合は、ネットワーク構成および DNS サーバを確認してください。DNS サーバを VNet に追加したことを確認します。
    重要: DNS サーバを VNet に追加する必要がある場合、または VNet の DNS サーバ構成を変更する必要がある場合は、VNet に接続されているすべての仮想マシンを再起動して変更を反映する必要があります。VNet の DNS サーバ設定を変更した後、その VNet に接続されたすべての仮想マシンを再起動しないと、変更は VNet 上で正しく伝達されません。
  3. netcat コマンドを使用して、必要な送信ポートが使用可能であることを確認します。
    Horizon Cloud ではいくつかの送信ポートを開く必要があります。それによって、ポッド ソフトウェアを Microsoft Azure 環境に安全にダウンロードすることができ、またポッドを Horizon Cloud 制御プレーンに戻すことができます。 Microsoft Azure での Horizon Cloud ポッドの DNS の要件で説明するように、以下の送信 TCP ポートをポッドの管理サブネットから開く必要があります:port 80、443、および 11371。以下に示すように netcat コマンドを実行すると、それらの送信ポートが要求されるとおりに開いていることを確認できます。
    SSH 接続ウィンドウで、次のコマンドを発行します(ポートごとに 1 つ)。
    注: ポート 11371 をテストする以下のコマンドは packages.microsoft.com を指定してその接続をテストし、他の 2 つの行は Horizon Cloud 制御プレーンへの送信接続をテストします。
    testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 80
    Connection to cloud.horizon.vmware.com 80 port [tcp/http] succeeded!
    testvmadmin@HCS-testingVM:~$ netcat -v -w 3 cloud.horizon.vmware.com 443
    Connection to cloud.horizon.vmware.com 443 port [tcp/https] succeeded!
    testvmadmin@HCS-testingVM:~$ netcat -v -w 3 packages.microsoft.com 11371
    Connection to packages.microsoft.com 11371 port [tcp/hkp] succeeded!
    ポートが正常に開くと、 netcat コマンドはそのテストに対して succeeded! 行を返します。
    netcat コマンドが失敗を返す場合は、Microsoft Azure のネットワーク接続、サブスクリプションのネットワーク セキュリティ グループ、および使用しているファイアウォールを確認します。 Microsoft Azure での Horizon Cloud ポッドの DNS の要件で説明されているように、ポッドがデプロイのために必要とする DNS、ポート、およびプロトコルの要件を、ネットワーク構成が確実に満たすようにします。

結果

上記のテストが成功した場合は、ポッドを正常にデプロイすることができます。

注: Radius の 2 要素認証や True SSO など、ポッドで使用するオプションの機能を設定している場合は、それらの目的に応じて追加のポートが必要になることがあります。上記の送信ポートのテスト方法を使用して、それらのポートが適切に開いていることを確認することができます。

次のタスク

テストを完了したら、Microsoft Azure 環境からテスト用仮想マシンと、その仮想マシンのディスク、IP アドレス、NIC などの関連するアーティファクトのすべてを削除する必要があります。理想的には、テスト仮想マシンのリソース グループを作成してあり、単純にそのリソース グループを削除することで仮想マシンのすべてのアーティファクトを削除できることが望ましいです。テストの完了後にテスト用仮想マシンを削除する の手順に従います。

重要: Microsoft Azure 環境からすべてのテスト用仮想マシンのアーティファクトを削除しないで、仮想マシンをポッドのサブネットの 1 つに接続した場合、後でポッドの [削除] アクションを使用して Horizon Cloud 環境からポッドを削除しようとしても、システムはこれらの残りの接続されているアーティファクトのためにポッドを完全に削除できない可能性があります。デフォルトでは、 [削除] アクションを使用してポッドを削除する場合に、 Horizon Cloud はポッドのために作成したこれらのリソース グループおよびサブネットを削除します。Microsoft Azure は、継続して使用中であるサブネットの削除を防止します。テスト用仮想マシンのアーティファクトがポッドのサブネットに接続されている場合は、これらのサブネットは削除できず、ポッドの削除は完了しません。この状況を回避するには、ポッドを正常にデプロイした後に、テスト用仮想マシンのすべてのアーティファクトが確実に削除されるようにします。