リナックス バーチャル デリバリー エージェント

Linux向けHDX™ダイレクト

Citrixが提供するリソースにアクセスする際、直接通信が可能な場合、HDX Directは内部および外部のクライアントデバイスがセッションホストとの安全な直接接続を確立することを可能にします。

システム要件

HDX Directを使用するためのシステム要件は以下のとおりです。

  • コントロールプレーン

    • シトリックス DaaS™
    • シトリックス バーチャルアプリとデスクトップ™ 2503 以降のバージョン
  • バーチャル デリバリー エージェント (VDA)

    • Linux: バージョン2503以降
  • ワークスペースアプリ

    • Windows: バージョン2503以降
    • Linux: バージョン2411以降
    • Mac: バージョン2411以降
  • アクセス層

    • Citrix ワークスペース™
    • シトリックス ストアフロント™ 2503 以降のバージョン
    • シトリックス ゲートウェイ サービス
    • シトリックス ネットスケーラー® ゲートウェイ

ネットワーク要件

以下は、HDX Direct を使用するためのネットワーク要件です。

セッションホスト

セッションホストにファイアウォールがある場合、内部接続のために以下のインバウンドトラフィックを許可する必要があります。

Description 送信元 プロトコル ポート
直接的な内部接続 クライアント TCP 443
直接的な内部接続 クライアント UDP 443

クライアントネットワーク

次の表は、内部ユーザーと外部ユーザーのクライアントネットワークについて説明しています。

内部ユーザー

説明内容 プロトコル ソース 送信元ポート 接続先 宛先ポート
直接的な内部接続 TCP クライアントネットワーク 1024–65535 VDAネットワーク 443
直接的な内部接続 UDP クライアントネットワーク 1024–65535 VDAネットワーク 443

外部ユーザー

説明文 プロトコル ソース 送信元ポート 接続先 宛先ポート
STUN (外部ユーザーのみ) UDP クライアントネットワーク 1024–65535 インターネット (下記の注記を参照) 3478, 19302
外部ユーザー接続 UDP クライアントネットワーク 1024–65535 データセンターのパブリックIPアドレス 1024–65535

データセンターネットワーク

以下の表は、内部ユーザーと外部ユーザーのデータセンターネットワークについて説明しています。

内部ユーザー

説明内容 プロトコル ソース 送信元ポート 接続先 宛先ポート
内部への直接接続 TCP クライアントネットワーク 1024~65535 VDAネットワーク 443
内部への直接接続 UDP クライアントネットワーク 1024–65535 VDAネットワーク 443

外部ユーザー

内容説明 プロトコル ソース ソースポート 接続先 宛先ポート
STUN (外部ユーザーのみ) UDP VDAネットワーク 1024–65535 インターネット(下記の注記を参照) 3478, 19302
外部ユーザー接続 UDP DMZ / 内部ネットワーク 1024–65535 VDAネットワーク 55000–55250
外部ユーザー接続 UDP VDAネットワーク 55000–55250 クライアントのパブリックIP 1024–65535

注:

VDAとWorkspaceアプリの両方が、以下のサーバーに同じ順序でSTUNリクエストを送信しようとします:

  • stun.cloud.com:3478
  • stun.cloudflare.com:3478
  • stun.l.google.com:19302

HDX Direct port rangeポリシー設定を使用して外部ユーザー接続のデフォルトポート範囲を変更した場合、対応するファイアウォール規則は、カスタムポート範囲と一致する必要があります。

設定方法

HDX Directはデフォルトで無効になっています。この機能は、CitrixポリシーのHDX Direct設定を使用して構成できます。

  • HDX Direct: 機能を有効または無効にするには。
  • HDX Direct mode: HDX Directが内部クライアントのみで利用可能か、内部クライアントと外部クライアントの両方で利用可能かを決定します。
  • HDX Direct port range: VDAが外部クライアントからの接続に使用するポート範囲を定義します。

考慮事項

HDX Directを使用する際の考慮事項は次のとおりです:

  • 外部ユーザー向けのHDX Directは、トランスポートプロトコルとしてEDT(UDP)を使用する場合にのみ利用可能です。したがって、Adaptive Transportを有効にする必要があります。
  • HDX Insightを使用している場合、HDX Directを使用すると、セッションがNetScaler Gatewayを介してプロキシされなくなるため、HDX Insightのデータ収集が妨げられることに注意してください。
  • HDX Directで独自の証明書を使用することは現在サポートされていません。

仕組み

HDX Directは、直接通信が可能な場合、クライアントがセッションホストへの直接接続を確立できるようにします。HDX Directを使用して直接接続が行われる場合、自己署名証明書がネットワークレベルの暗号化 (TLS/DTLS) で直接接続を保護するために使用されます。

内部ユーザー

次の図は、内部ユーザーのHDX Direct接続プロセスの概要を示しています。

HDXダイレクトの概要(/ja-jp/citrix-virtual-apps-desktops/media/hdx-direct-overview.png)

  1. クライアントはGateway Serviceを介してHDXセッションを確立します。
  2. 接続が成功すると、VDAはHDX接続を介して、VDAマシンのFQDN、そのIPアドレスのリスト、およびVDAマシンの証明書をクライアントに送信します。
  3. クライアントは、VDAに直接到達できるかどうかを確認するためにIPアドレスをプローブします。
  4. クライアントが共有されたIPアドレスのいずれかを使用してVDAに直接到達できる場合、クライアントはVDAとの直接接続を確立し、ステップ (2) で交換された証明書と一致する証明書を使用して (D)TLS で保護されます。
  5. 直接接続が正常に確立されると、セッションは新しい接続に転送され、Gateway Serviceへの接続は終了します。

注:

上記のステップ2で接続を確立した後、セッションはアクティブになります。その後の手順は、ユーザーが仮想アプリケーションまたはデスクトップを使用する能力を遅らせたり、妨げたりすることはありません。その後の手順のいずれかが失敗した場合でも、ユーザーのセッションを中断することなく、Gatewayを介した接続は維持されます。

外部ユーザー

次の図は、外部ユーザー向けのHDX Direct接続プロセスの概要を示しています。

HDXダイレクト接続プロセス

  1. クライアントはGateway Serviceを介してHDXセッションを確立します。
  2. 接続が成功すると、クライアントとVDAの両方がSTUNリクエストを送信し、それぞれのパブリックIPアドレスとポートを検出します。
  3. STUNサーバーは、クライアントとVDAにそれぞれのパブリックIPアドレスとポートで応答します。
  4. HDX接続を介して、クライアントとVDAはそれぞれのパブリックIPアドレスとUDPポートを交換し、VDAはクライアントに証明書を送信します。
  5. VDAはクライアントのパブリックIPアドレスとUDPポートにUDPパケットを送信します。クライアントはVDAのパブリックIPアドレスとUDPポートにUDPパケットを送信します。
  6. VDAからのメッセージを受信すると、クライアントはセキュアな接続リクエストで応答します。
  7. DTLSハンドシェイク中に、クライアントは証明書がステップ4で交換された証明書と一致することを確認します。検証後、クライアントは認証トークンを送信します。これでセキュアな直接接続が確立されます。
  8. 直接接続が正常に確立されると、セッションは新しい接続に転送され、Gateway Serviceへの接続は終了します。

注:

上記のステップ2で接続が確立された後、セッションはアクティブになります。その後の手順は、ユーザーが仮想アプリケーションまたはデスクトップを使用する能力を遅らせたり、妨げたりすることはありません。その後の手順のいずれかが失敗した場合でも、Gatewayを介した接続はユーザーのセッションを中断することなく維持されます。

NAT互換性

外部ユーザーデバイスとセッションホスト間の直接接続を確立するために、HDX DirectはNATトラバーサルのためのホールパンチングと、クライアントデバイスおよびセッションホストのパブリックIPアドレスとポートマッピングの交換を容易にするSTUNを活用します。これは、VoIP、ユニファイドコミュニケーション、P2Pソリューションの仕組みに似ています。

ファイアウォールやその他のネットワークコンポーネントがSTUNリクエストおよびHDXセッションのUDPトラフィックを許可するように構成されている限り、外部ユーザー向けのHDX Directは機能すると予想されます。ただし、ユーザーとセッションホストのネットワークのNATタイプが互換性のない組み合わせとなり、HDX Directが失敗する特定のシナリオがあります。

検証項目

クライアントとセッションホストでNATタイプとフィルタリングを検証するには、STUNTMANのSTUNクライアントユーティリティを使用します。

  1. stunprotocol.orgからターゲットプラットフォームに適したパッケージをダウンロードし、コンテンツを抽出します。
  2. ターミナルプロンプトを開き、コンテンツが抽出されたディレクトリに移動します。
  3. 次のコマンドを実行します。 ./stunclient stunserver2024.stunprotocol.org --mode behavior
  4. 出力をメモします。

    バインディングテストと動作テストが成功した場合、バインディングテスト動作テストの両方が成功を報告し、NAT動作が指定されます。

    ナット成功

    テストが失敗した場合、バインディングテストおよび/または動作テストが失敗を報告します。

    ナット失敗

  5. 次のコマンドを実行します。 ./stunclient stunserver2024.stunprotocol.org --mode filtering
  6. 出力をメモします。

    NATフィルタリング

クライアントとセッションホストの両方のテスト結果に基づいて、外部ユーザー向けのHDX Directが機能するかどうかを判断するには、次の表を参照してください。

クライアントNAT動作 クライアントNATフィルタリング セッションホストのNAT動作 セッションホストのNATフィルタリング 動作しますか?
エンドポイント独立マッピング 任意 エンドポイント独立マッピング 任意 はい
エンドポイント独立マッピング エンドポイント独立フィルタリング アドレス依存マッピング 任意 はい
エンドポイント独立マッピング アドレス依存フィルタリング アドレス依存マッピング 任意 いいえ
エンドポイント独立マッピング アドレスとポート依存フィルタリング アドレス依存マッピング 任意 いいえ
エンドポイント独立マッピング エンドポイント独立フィルタリング アドレスとポート依存マッピング エンドポイント独立フィルタリング はい
エンドポイント独立マッピング アドレス依存フィルタリング アドレス依存マッピング 任意 いいえ
エンドポイント独立マッピング アドレスおよびポート依存フィルタリング アドレス依存マッピング 任意 いいえ
アドレス依存マッピング 任意 エンドポイント独立マッピング エンドポイント独立フィルタリング はい
アドレス依存マッピング 任意 エンドポイント独立マッピング アドレス依存フィルタリング いいえ
アドレス依存マッピング 任意 エンドポイント独立マッピング アドレスおよびポート依存フィルタリング いいえ
アドレス依存マッピング 任意 アドレス依存マッピング 任意 いいえ
アドレス依存マッピング 任意 アドレスおよびポート依存マッピング 任意 いいえ
アドレスおよびポート依存マッピング 任意 エンドポイント独立マッピング エンドポイント独立フィルタリング はい
アドレスおよびポート依存マッピング 任意 エンドポイント独立マッピング アドレス依存フィルタリング いいえ
アドレスおよびポート依存マッピング 任意 エンドポイント独立マッピング アドレスおよびポート依存フィルタリング いいえ
アドレスおよびポート依存マッピング 任意 アドレス依存マッピング 任意 いいえ
アドレスおよびポート依存マッピング 任意 アドレスおよびポート依存マッピング 任意 いいえ
失敗 任意 任意 任意 なし
任意 任意 失敗 任意 なし
失敗 任意 失敗 任意 なし
Linux向けHDX™ダイレクト