Horizon Cloud ポッドのゲートウェイ構成で RADIUS 2 要素認証設定を構成した後、特定のゲートウェイ関連の IP アドレスからのクライアント要求を許可するように RADIUS サーバの構成も設定する必要があります。ゲートウェイの Unified Access Gateway インスタンスは、特定の IP アドレスから RADIUS サーバと通信することを試みます。ネットワーク管理者が、ポッドの Azure 仮想ネットワーク (VNet) およびサブネットに対する RADIUS サーバのネットワーク可視性を決定します。このネットワーク可視性とポッドのゲートウェイ タイプ(外部または内部)の組み合わせによって、RADIUS サーバ構成で許可されたクライアントとして構成する必要がある特定のゲートウェイ関連の IP アドレスが決まります。

重要:

RADIUS 2 要素認証システムに適したドキュメントに従って、このクライアント情報を構成する必要がある RADIUS システムで使用される特定の構成ファイルの構文を確認します。たとえば、FreeRADIUS クライアント構成のための FreeRADIUS Wikiに記載されているように、/etc/raddb/clients.conf ファイルには RADIUS クライアントの定義が次のように含まれています。

client NAME {
  ipaddr = IPADDRESS
  secret = SECRET
}

このトピックでは、ポッドのゲートウェイとの間の通信を有効にするために、また、各ポッドの更新後にその通信の復元力を維持するために、RADIUS サーバで使用する必要がある Horizon Cloud ポッドの情報について説明します。アクセスを試みるクライアント マシンからの接続を受け入れるには、RADIUS サーバがそれらのクライアント マシンの IP アドレスを許可されたクライアントとして登録する必要があります。RADIUS 2 要素認証設定で構成された Horizon Cloud ポッドのゲートウェイの場合、これらのクライアント マシンはそのゲートウェイの Unified Access Gateway インスタンスです。通常、ネットワーク管理者は、RADIUS サーバがデプロイされたポッドに接続されている VNet およびサブネットに対して持つネットワーク アクセスを決定します。RADIUS サーバとの通信時に Unified Access Gateway インスタンスが使用する特定の送信元 IP アドレスは、次のものに依存します。

  • ゲートウェイ構成が内部であるか外部であるか
  • ネットワーク管理者が、RADIUS サーバをポッドの VNet 内からアクセス可能として構成しているか、または VNet の外部に配置しているか。
  • ポッドの VNet 内で RADIUS サーバにアクセスできる場合、その VNet 内のどのポッドのサブネットから、ネットワーク管理者が RADIUS サーバへのアクセスを構成したか
内部ゲートウェイ構成
内部ゲートウェイ構成用にデプロイされた Unified Access Gateway インスタンスは、自身の NIC のプライベート IP アドレスを使用して、その RADIUS サーバに通信します。RADIUS サーバは、NIC のプライベート IP アドレスである送信元 IP アドレスから受信した要求を認識します。ネットワーク管理者は、ポッドの管理またはテナント サブネットの IP アドレス範囲に RADIUS サーバがアクセス可能かどうかを構成しています。Microsoft Azure の内部ゲートウェイのリソース グループには、そのサブネットに対応する 4 つの NIC があり、そのうち 2 つが 2 個の Unified Access Gateway インスタンスに対して現在アクティブです。もう 2 つの NIC はアイドル状態で、ポッドが更新を完了した後にアクティブになります。実行中のポッド操作のため、および各ポッドの更新後のために、ゲートウェイと RADIUS サーバ間の通信接続をサポートするには、RADIUS サーバに対して可視性のあるサブネットに対応する、Microsoft Azure での内部ゲートウェイのリソース グループにある 4 つの NIC の IP アドレスからのクライアント接続を許可するように RADIUS サーバを構成する必要があります。 ポッドのゲートウェイ NIC の IP アドレスを要求に対して許可されたクライアントとして追加する方法を参照してください。
外部ゲートウェイ構成と、ポッドの VNet の内部でアクセス可能な RADIUS サーバ
ネットワーク管理者が、ポッドと同じ VNet で RADIUS サーバがアクセス可能になるように構成している場合、 Unified Access Gateway インスタンスは NIC のプライベート IP アドレスを使用して、その RADIUS サーバと通信します。RADIUS サーバは、NIC のプライベート IP アドレスである送信元 IP アドレスから受信した要求を認識します。ネットワーク管理者は、ポッドの管理、テナント、または DMZ サブネットの IP アドレス範囲に RADIUS サーバがアクセス可能かどうかを構成しています。Microsoft Azure の外部ゲートウェイのリソース グループには、そのサブネットに対応する 4 つの NIC があり、そのうち 2 つが 2 個の Unified Access Gateway インスタンスに対して現在アクティブです。もう 2 つはアイドル状態で、ポッドが更新を完了した後にアクティブになります。実行中のポッド操作のため、および各ポッドの更新後のために、ゲートウェイと RADIUS サーバ間の通信接続をサポートするには、RADIUS サーバに対して可視性のあるサブネットに対応する、Microsoft Azure での外部ゲートウェイのリソース グループにある 4 つの NIC の IP アドレスからのクライアント接続を許可するように RADIUS サーバを構成する必要があります。 ポッドのゲートウェイ NIC の IP アドレスを要求に対して許可されたクライアントとして追加する方法を参照してください。
外部ゲートウェイ構成と、ポッドの VNet の外部でアクセス可能な RADIUS サーバ
ネットワーク管理者がポッドの VNet の外部に RADIUS サーバを構成している場合、外部ゲートウェイ構成の Unified Access Gateway インスタンスは、外部ゲートウェイの Azure ロード バランサ リソースの IP アドレスを使用して、その RADIUS サーバに接続します。外部ゲートウェイのロード バランサ リソースの IP アドレスからのクライアント接続を許可するように、RADIUS サーバを構成する必要があります。 ポッドの外部ゲートウェイのロード バランサの IP アドレスを要求に対して許可されたクライアントとして追加する方法を参照してください。

ポッドのゲートウェイ NIC の IP アドレスを要求に対して許可されたクライアントとして追加する方法

ポッドがデプロイされると、ポッド デプロイヤは Microsoft Azure サブスクリプションのゲートウェイのリソース グループに NIC のセットを作成します。次のスクリーンショットは、内部ゲートウェイ タイプと外部ゲートウェイ タイプの NIC の例です。ポッド ID がこれらのスクリーンショットでピクセル化されている場合でも、デプロイヤが NIC の名前に -management-tenant-dmz を付けているパターンを確認することができます。ポッドのリソース グループの名前については、Microsoft Azure にデプロイされたポッド用に作成されたリソース グループを参照してください。


ポッド デプロイヤが内部ゲートウェイ構成用に作成した NIC および仮想マシンのスクリーンショット。


ポッド デプロイヤが外部ゲートウェイ構成用に作成した NIC および仮想マシンのスクリーンショット。

RADIUS サーバに対するネットワーク可視性を持つサブネットに対応する、RADIUS 2 要素認証を有効にしたゲートウェイ構成の NIC の IP アドレスを取得して、それらの IP アドレスを RADIUS サーバの構成で許可されたクライアントとして指定する必要があります。

重要: 更新後に RADIUS サーバとポッドとの間の接続が中断されないようにするには、RADIUS 設定を使用して構成した各ゲートウェイで、以下に記載されている 4 つの NIC の IP アドレスが、確実に RADIUS サーバの構成で許可されたクライアントとして指定されているようにします。実行中のポッド操作の間は、NIC の半数のみがアクティブになっていますが、これらはポッドの更新後に切り替わります。ポッドを更新した後、NIC の残り半分がアクティブになり、更新前の NIC は再び切り替えられることになる次回のポッドの更新まで、アイドル状態になります。アクティブおよびアイドル状態の両方の NIC の IP アドレスを RADIUS サーバ構成に追加していない場合、RADIUS サーバは、ポッドの更新後の現在アクティブの NIC セットからの接続要求を拒否し、そのゲートウェイを使用するエンド ユーザーのログイン プロセスは停止します。

RADIUS サーバ構成に追加するゲートウェイの NIC の IP アドレスを取得するには、次の操作を行います。

  1. ネットワーク管理者から、ポッドのどのサブネットに RADIUS サーバに対するネットワーク可視性があるかについての情報を取得します(管理、テナント、または DMZ)。
  2. サブスクリプションの Microsoft Azure ポータルにログインし、ゲートウェイのリソース グループを特定します。
  3. ネットワーク管理者によって RADIUS サーバに対する可視性があると言われているサブネットに対応する NIC について、各 NIC をクリックして、その IP アドレスをコピーします。
  4. これらの NIC の IP アドレスを RADIUS サーバ クライアントの構成ファイルに追加して、それらの NIC がそのゲートウェイの設定で構成した RADIUS サーバで許可されたクライアントとなるようにします。

    次の行は、ポッドと同じ VNet 内で、ポッドのテナント サブネットからのアクセスが可能である RADIUS サーバがネットワーク管理者によって構成されている内部ゲートウェイについて、ポッドのテナント サブネットの IP アドレスを持つ NIC のクライアント構成行の一部を示しています。このポッドがデプロイされたとき、ポッドのテナント サブネットは 192.168.25.0/22 として構成されました。ポッドが最初にデプロイされるときに、NIC1 と NIC2 はアクティブになり、NIC3 と NIC4 はアイドル状態になります。ただし、これら 4 つの NIC はすべて RADIUS サーバ構成に追加されており、ポッドの更新後に、NIC3 と NIC4 がアクティブになり、NIC1 と NIC2 がアイドル状態になると、RADIUS サーバはこのゲートウェイからの接続を受け入れ続けます。ユーザー自身の RADIUS サーバには、適切な構文を使用する必要があります。

    client UAGTENANTNIC1 {
      ipaddr = 192.168.25.5
      secret = myradiussecret
    }
    client UAGTENANTNIC2 {
      ipaddr = 192.168.25.6
      secret = myradiussecret
    }
    client UAGTENANTNIC3 {
      ipaddr = 192.168.25.7
      secret = myradiussecret
    }
    client UAGTENANTNIC4 {
      ipaddr = 192.168.25.8
      secret = myradiussecret
    }

ポッドの外部ゲートウェイのロード バランサの IP アドレスを要求に対して許可されたクライアントとして追加する方法

RADIUS サーバがポッドの VNet の外部に配置されている場合は、その RADIUS サーバを指定した外部ゲートウェイに対して、外部ゲートウェイの Azure ロード バランサ リソースのパブリック IP アドレスを RADIUS サーバ構成で許可されたクライアントとして追加する必要があります。Microsoft Azure ポータルを使用し、ゲートウェイのリソース グループでロード バランサ リソースを特定することによって、このロード バランサの IP アドレスを取得できます。

  1. サブスクリプションの Microsoft Azure ポータルにログインし、ゲートウェイのリソース グループを特定します。
  2. ゲートウェイのリソース グループで、ロード バランサ リソースをクリックします。これには、vmw-hcs-podID-uag-lb というパターンの名前が付いています。その IP アドレスが概要情報にリストされます。
  3. ゲートウェイのロード バランサの IP アドレスを RADIUS サーバ クライアントの構成ファイルに追加して、ゲートウェイのロード バランサが、そのゲートウェイの設定で構成した RADIUS サーバで許可されたクライアントとなるようにします。次の行に例を示します。ユーザー自身の RADIUS サーバには、適切な構文を使用する必要があります。
    client MYPODUAGEXTLBIP {
      ipaddr = 52.191.236.223
      secret = myradiussecret
    }