トラブルシューティング

セッションの切断

ユーザーが以下の操作を行うと、Citrix Receiverセッションを終了せずに切断できます:

  • セッションで公開アプリまたはデスクトップを表示している間に次のことを実行する:
    • 画面を上部で矢印をタップして、セッションのドロップダウンメニューを表示させる。
    • [ホーム] ボタンをタップして、起動パッドに戻る。
    • アクティブなセッションに残っている公開アプリのいずれかのアイコンの下にある白い影をタップする。
    • 切断をタップする。
  • Citrix Receiverを閉じる:
    • デバイスの [ホーム] ボタンをダブルタップする。
    • iOS App SwitcherビューでReceiverを探す。
    • 表示されるダイアログで切断をタップする。
  • モバイルデバイスのホームボタンを押す。
  • アプリのドロップダウンメニュー内の[ホーム]または[切り替え]をタップする。

これらの操作を行うと、セッションは切断状態のままサーバーに保持されます。ユーザーはこの切断セッションに再接続できますが、管理者は特定の時間が経過した後に切断セッションが自動的に終了するように設定できます。これを行うには、リモートデスクトップセッションホストサーバーの構成(「ターミナルサービス構成」の新名称)で[ICA-tcp]接続の設定を変更します。リモートデスクトップサービス(「ターミナルサービス」の新名称)の設定について詳しくは、Microsoft Windows Serverの製品ドキュメントを参照してください。

アプリケーションでのテンキーの問題

公開アプリケーションでテンキーの使用に問題が生じる場合は、Citrix ReceiverでUnicodeキーボードを無効にします。これを行うには、[設定]タブで [キーボードオプション] をタップし、[Unicodeキーボードを使用]を [オフ] にします。

XenDesktopでのHDXの音質

Citrix Receiver for iOSを使用したXenDesktopのセッションで、音声と動画を使用するときにHDX機能の音質が低下することがあります。この問題は、XenDesktopのHDXに関連するポリシーが音声と動画のデータ量に対応できない場合に発生します。音質を改善するためのポリシー作成については、Knowledge CenterのCTX123543を参照してください。

Citrix Cloudで使用できるデモ用アカウント

現在アカウントを持っていないユーザーは、Citrix Cloud(http://cloud.citrix.com/)デモサイトでデモ用ユーザーアカウントを作成できます。

Citrix Cloudでは、独自に環境を設定しなくても、Citrixソリューションの有効性を体験することができます。Citrix Cloudのデモ環境では、XenServer、XenApp、NetScaler、およびAccess Gatewayなどの、数多くの主要なCitrixソリューションが使用されています。

ただし、このデモ環境ではデータが保存されません。また、セッションを切断した後に再接続できない可能性があります。

有効期限が切れたパスワード

Citrix Receiverでは、有効期限が切れたパスワードをユーザーが変更することができます。パスワードの有効期限が切れると、必要な情報を入力するためのメッセージが表示されます。

接続パフォーマンスの低下

XenApp Servicesサイトへの接続パフォーマンスが低下したり、アプリケーションアイコンが表示されなくなったり、「プロトコルドライバーエラー」が表示されたりする場合は、XenAppサーバーおよびCitrix Secure GatewayまたはWeb Interfaceサーバーのネットワークインターフェイスで、以下のCitrix PV Ethernet Adapterプロパティを無効にしてください:

  • 大量送信オフロード
  • オフロードIPチェックサム
  • オフロードTCPチェックサム
  • オフロードUDPチェックサム

サーバーを再起動する必要はありません。この回避策は、Windows Server 2003およびWindows Server 2008(32ビット)で使用できます。Windows Server 2008 R2では、この問題は発生しません。

アプリケーションが個別のセッションで実行されることがある

アプリケーションの共有機能が有効になっている場合でも、サーバー側でこの問題が発生することがあります。これは間欠的な問題であり、現在回避策はありません。

App Switcherが動作していない

IT管理者によりアプリが同じサーバー上で公開されている必要があります。そうでない場合は、App Switcherは動作しません。

ジェイルブレイクされたデバイスでのStoreFrontからのアプリケーションの実行の禁止

ユーザーがジェイルブレイクされたiOSデバイスで接続することにより、展開環境のセキュリティを侵害する可能性があります。ジェイルブレイクしたデバイスは、その所有者によりセキュリティ権限が変更され、特定のセキュリティ保護機能を効果的にバイパスします。

Citrix ReceiverでジェイルブレイクされたiOSが検出されると、ユーザーに通知が表示されます。環境のセキュリティをさらに保護する野に役立てるため、StoreFrontまたはWeb Interfaceを構成して、検出したジェイルブレイクされたデバイスでアプリを実行できないようにすることができます。

要件

  • Citrix Receiver for iOS 6.1以降
  • StoreFront 3.0またはWeb Interface 5.4以降
  • StoreFrontまたはWeb Interfaceへの管理者アカウントによるアクセス

検出したジェイルブレイクされたデバイスでアプリを実行できないようにするには

  1. StoreFrontまたはWeb Interfaceサーバーに管理者特権を持つユーザーとしてログオンします。

  2. default.icaファイルを見つけます。このファイルは以下のいずれかの場所にあります:

    • C:\inetpub\wwwroot\Citrix\storename\conf(Microsoftインターネットインフォメーションサービス)
    • C:\inetpub\wwwroot\Citrix\storename\App_Data(Microsoftインターネットインフォメーションサービス)
    • ./usr/local/tomcat/webapps/Citrix/XenApp/WEB-INF(Apache Tomcat)
  3. [Application] セクションに以下の行を追加します。AllowJailBrokenDevices=OFF

  4. ファイルを保存してStoreFrontまたはWeb Interfaceサーバーを再起動します。

StoreFrontサーバーを再起動した後は、ジェイルブレイクされたデバイスについての通知を受け取ったユーザーはStoreFrontまたはWeb Interfaceサーバーからアプリを起動できません。

検出したジェイルブレイクされたデバイスでアプリを実行できるようにするには

AllowJailBrokenDevicesを設定しなければ、デフォルトの動作ではジェイルブレイクされたデバイスについてユーザーに通知が表示されますが、依然としてアプリケーションを起動が許可されます。

ジェイルブレイクされたデバイスでのアプリの実行をユーザーに明確に許可するには、次の手順に従います:

  1. StoreFrontまたはWeb Interfaceサーバーに管理者特権を持つユーザーとしてログオンします。

  2. default.icaファイルを見つけます。このファイルは以下のいずれかの場所にあります:

    • C:\inetpub\wwwroot\Citrix\storename\conf(Microsoftインターネットインフォメーションサービス)
    • C:\inetpub\wwwroot\Citrix\storename\App_Data(Microsoftインターネットインフォメーションサービス)
    • ./usr/local/tomcat/webapps/Citrix/XenApp/WEB-INF(Apache Tomcat)
  3. [Application] セクションに以下の行を追加します。AllowJailBrokenDevices=ON

  4. ファイルを保存してStoreFrontまたはWeb Interfaceサーバーを再起動します。

AllowJailBrokenDevicesをONに設定すると、ユーザーはジェイルブレイクされたデバイスについて通知を受け取りますが、StoreFrontまたはWeb Interfaceサーバー経由でアプリケーションを実行できます。

Citrix Receiver for iOS通信のセキュリティ保護

サーバーファームとCitrix Receiver for iOS間の通信を保護するには、Citrix NetScaler Gatewayなど、以下の一連のセキュリティ技術を使用します。

注:

StoreFrontサーバーとユーザーデバイス間の通信を保護するには、NetScaler Gatewayを使用することをお勧めします。

  • SOCKSプロキシサーバーまたはSecureプロキシサーバー(セキュリティプロキシサーバー、HTTPSプロキシサーバーとも呼ばれます)。プロキシサーバーでネットワークから外部へのアクセスや外部からネットワークへのアクセスを制限して、Citrix Receiverとサーバー間の接続を制御できます。Citrix Receiver for iOSは、SOCKSプロトコルとSecureプロキシプロトコルをサポートしています。
  • Secure Gateway Secure GatewayをWeb Interfaceと一緒に使うと、社内ネットワーク上のサーバーにインターネットを介して接続できる、暗号化された安全な単一のアクセスポイントをユーザーに提供できます。
  • Transport Layer Security(TLS)プロトコルによるSSL Relayソリューション
  • ファイアウォール。ネットワークファイアウォールは、送信先アドレスとポート番号に基づいてパケットを通過させたりブロックしたりできます。サーバーの内部IPアドレスを外部インターネットアドレスにマップするネットワークファイアウォール(つまりNAT(Network Address Translation:ネットワークアドレス変換))を介してCitrix Receiver for iOSを使用する場合は、外部アドレスを構成します。

証明書について

プライベート(自己署名)証明書

リモートゲートウェイにプライベート証明書がインストールされている場合は、組織の証明機関のルート証明書をユーザーデバイスにインストールしないと、Citrix Receiver for iOSを使用してCitrixリソースにアクセスできません。

注:

接続時にリモートゲートウェイの証明書を検証できない場合(iOSのキーストアにルート証明書が含まれていないため)、信頼されていない証明書の警告が表示されます。ユーザーが警告に対してそのまま続行することを選択した場合、アプリケーションの一覧が表示されますが、アプリケーションの起動に失敗します。

Citrix Receiver for iOSデバイスへのルート証明書のインポート

証明書の発行者のルート証明書を取得して、デバイスに設定されているアカウントに電子メールで送信します。添付ファイルをクリックすると、ルート証明書をインポートするかどうかを確認するメッセージが表示されます。

ワイルドカード証明書

ワイルドカード証明書は、同一ドメイン内の任意のサーバーで個別のサーバー証明書の代わりに使用します。Citrix Receiver for iOSでは、ワイルドカード証明書がサポートされています。

NetScaler Gatewayの中間証明書

証明書チェーンに中間証明書が含まれる場合は、中間証明書をNetScaler Gatewayのサーバー証明書にマップする必要があります。方法については、Citrix Gatewayのドキュメントを参照してください。中間証明書をNetScaler Gatewayアプライアンスにインストールして、プライマリCAとリンクする方法については、「How to Install and Link Intermediate Certificate with Primary CA on NetScaler Gateway」を参照してください。

サーバー証明書検証ポリシー

Citrix Receiver for iOS 7.5以降のリリースでは、サーバー証明書の新しい、より厳格な検証ポリシーが導入されました。

重要

Citrix Receiver for iOSをインストールする前に、サーバーまたはゲートウェイの証明書が、ここで説明されているように正しく構成されていることを確認してください。以下の場合、接続できないことがあります:

  • サーバーまたはゲートウェイの構成に間違ったルート証明書が含まれている
  • サーバーまたはゲートウェイ構成にすべての中間証明書が含まれていない
  • サーバーまたはゲートウェイ構成に期限切れまたは無効な中間証明書が含まれている
  • サーバーまたはゲートウェイ構成にクロスルート用中間証明書が含まれていない

Citrix Receiver for iOSは、サーバー証明書を検証するときにサーバー(またはゲートウェイ)が提供するすべての証明書を使用するようになりました。以前のリリースと同様に、Citrix Receiver for iOSは証明書が信頼済みかについても確認します。すべての証明書が信頼済みでない場合、接続に失敗します。

このポリシーは、Webブラウザーの証明書ポリシーより厳格です。多くのWebブラウザーには、多数の信頼済みのルート証明書セットが含まれます。

サーバー(またはゲートウェイ)は、正しい証明書セットで構成する必要があります。不正な証明書のセットを使用すると、Citrix Receiver for iOSの接続に失敗することがあります。

以下は、ゲートウェイがこのような有効な証明書で構成されていることを前提としています。この構成は、Citrix Receiver for iOSで使用されるルート証明書を正確に確認するために、より厳格な検証が必要なユーザーにお勧めします:

  • 「サーバー証明書サンプル」
  • 「中間証明書サンプル」
  • 「ルート証明書サンプル」

次に、Citrix Receiver for iOSはこれらすべての証明書が有効であることを確認します。Citrix Receiver for iOSが「ルート証明書サンプル」を信頼済みであることも確認します。Citrix Receiver for iOSが「ルート証明書サンプル」を信頼していない場合、接続に失敗します。

重要

証明機関によっては、複数のルート証明書があります。このような、より厳格な検証が必要であれば、構成で適切なルート証明書が使用されていることを確認してください。たとえば、現在同じサーバー証明書を検証できる2つの証明書(「DigiCert」/「GTE CyberTrust Global Root」および「DigiCert Baltimore Root」/「Baltimore CyberTrust Root」)があるとします。ユーザーデバイスによっては、両方のルート証明書が使用できます。その他のデバイスでは、1つの証明書のみを使用できます(「DigiCert Baltimore Root」/「Baltimore CyberTrust Root」)。ゲートウェイで「GTE CyberTrust Global Root」を構成すると、これらのユーザーデバイスでCitrix Receiver for Macの接続に失敗します。どのルート証明書を使用すべきかについては、証明機関のドキュメントを参照してください。また、ルート証明書の有効期限についても注意してください。

注:

次に、Citrix Receiver for iOSはこれらの証明書が有効であることを確認します。次に、ユーザーデバイスでルート証明書を検索します。正しく検証される証明書が見つかり、信頼済みである場合(「ルート証明書サンプル」など)、接続は成功します。信頼済みの証明書が見つからない場合は、失敗します。この構成では、Citrix Receiver for iOSが必要とする中間証明書が提供されますが、Citrix Receiver for iOSは任意の有効な、信頼済みのルート証明書を選択できます。

以下は、ゲートウェイがこのような証明書で構成されていることを前提としています。

  • 「サーバー証明書サンプル」
  • 「中間証明書サンプル」
  • 「間違ったルート証明書」

Webブラウザーは、不正なルート証明書を無視することがありますが、Citrix Receiver for iOSは不正なルート証明書を無視しないため、接続は失敗します。

証明機関によっては、複数の中間証明書を使用します。この場合、ゲートウェイは通常、以下のようにすべて中間証明書(ルート証明書ではない)で構成されます:

  • 「サーバー証明書サンプル」
  • 「中間証明書サンプル1」
  • 「中間証明書サンプル2」

重要

証明機関によっては、クロスルート用中間証明書を使用します。これは、複数のルート証明書があり、以前のルート証明書が最新のルート証明書と同時に使用中の状況を想定しています。この場合、少なくとも2つの中間証明書が存在します。たとえば、以前のルート証明書「Class 3 Public Primary Certification Authority」には、関連するクロスルート用中間証明書「VeriSign Class 3 Public Primary Certification Authority - G5」があります。ただし、最新のルート証明書「VeriSign Class 3 Public Primary Certification Authority - G5」も利用可能であり、「Class 3 Public Primary Certification Authority」に置き換わります。最新のルート証明書はクロスルート用中間証明書を使用しません。

メモ

クロスルート用中間証明書およびルート証明書は、同じサブジェクト名(発行先)ですが、クロスルート中間証明書には異なる発行者名(発行元)があります。これによって、クロスルート用中間証明書と通常の中間証明書(「中間証明書サンプル2」など)を区別できます。

通常は、このルート証明書およびクロスルート用中間証明書を省略した構成が推奨されます:

  • 「サーバー証明書サンプル」
  • 「中間証明書サンプル」

クロスルート用中間証明書をゲートウェイで構成しないでください。これは、ゲートウェイで以前のルート証明書が選択されるようになるのを避けるためです:

  • 「サーバー証明書サンプル」
  • 「中間証明書サンプル」
  • 「クロスルート用中間証明書サンプル」(非推奨)

ゲートウェイでサーバー証明書のみを構成しないでください。

  • 「サーバー証明書サンプル」

この場合、Citrix Receiver for iOSはすべての中間証明書を検出できないため、接続に失敗します。

NetScaler Gateway経由の接続

リモートのユーザーがNetScaler Gatewayを介してXenMobile環境に接続できるようにするには、StoreFrontと通信するようにNetScaler Gatewayを構成します。このアクセスを有効にする方法は、XenMobileのエディションによって異なります。

ネットワークでXenMobileを展開する場合、NetScalerとStoreFrontを統合することでNetScaler Gatewayを経由して内部ユーザーやリモートユーザーがStoreFrontに接続できます。ユーザーは、StoreFrontに接続してXenAppの公開アプリケーションやXenDesktopの仮想デスクトップにアクセスします。ユーザーは、Citrix Receiverを使用して接続を行います。

Secure Gatewayを経由する接続

このトピックの内容は、Web Interface環境にのみ適用されます。

Secure Gatewayを通常モードまたはリレーモードのどちらかで使用すると、Citrix Receiver for iOSとサーバー間の通信チャネルをセキュリティで保護することができます。Secure Gatewayを通常モードで使用し、ユーザーがWeb Interface経由で接続する場合は、Citrix Receiver側での構成は不要です。

Citrix Receiver for iOSがSecure Gatewayサーバーに接続するときは、リモートのWeb Interfaceサーバーで構成されている設定が使用されます。

Secure Gateway Proxyがセキュリティで保護されたネットワーク内のサーバーにインストールされている場合は、Secure Gateway Proxyをリレーモードで使用できます。ただし、リレーモードで使用する場合、Secure Gatewayサーバーはプロキシサーバーとして機能するため、Citrix Receiver for iOSで次の項目を構成する必要があります:

  • Secure Gatewayサーバーの完全修飾ドメイン名。
  • Secure Gatewayサーバーのポート番号。Secure Gateway, Version 2.0では、リレーモードはサポートされていません。

完全修飾ドメイン名には、以下の3つの要素を順に指定する必要があります:

  • ホスト名
  • サブドメイン名
  • 最上位ドメイン名

例えば、my_computer.example.comは完全修飾ドメイン名です。ホスト名(my_computer)、サブドメイン名(example)、最上位ドメイン名(com)が順に指定されています。一般的には、サブドメイン名と最上位ドメイン名の組み合わせ(example.com)をドメイン名といいます。

プロキシサーバー経由の接続

プロキシサーバーは、ネットワークから外部へのアクセスや外部からネットワークへのアクセスを制限して、Citrix Receiver for iOSとサーバー間の接続を制御するために使います。Citrix Receiver for iOSは、SOCKSプロトコルとSecureプロキシプロトコルの両方をサポートしています。

Citrix Receiver for iOSでXenAppサーバーまたはXenDesktopサーバーと通信する場合、Web Interfaceサーバー上でリモートで構成されているプロキシサーバー設定が使用されます。

Citrix Receiver for iOSでWebサーバーと通信する場合は、ユーザーデバイス上のデフォルトのWebブラウザーで構成されているプロキシサーバー設定が使用されます。各ユーザーデバイス上のデフォルトのWebブラウザーで、プロキシサーバー設定を構成する必要があります。

ファイアウォールを介した接続

ネットワークファイアウォールは、送信先アドレスとポート番号に基づいてパケットを通過させたりブロックしたりできます。ファイアウォールが使用されている環境では、Citrix Receiver for iOSとWebサーバーおよびCitrix製品のサーバーとの通信がファイアウォールでブロックされないように設定する必要があります。このためには、ユーザーデバイスとWebサーバー間のHTTPトラフィック(一般に標準HTTPポート80、またはセキュアなWebサーバーを使用している場合はポート443での通信)がファイアウォールを通過できるように設定します。また、ReceiverとCitrix製品サーバー間の通信では、ポート1494とポート2598の受信ICAトラフィックがファイアウォールを通過できるように設定します。

ファイアウォールによるネットワークアドレス変換(NAT:Network Address Translation)を使用している場合は、Web Interfaceを使って内部アドレスから外部アドレスおよびポートへのマッピングを定義できます。たとえば、XenAppサーバーやXenDesktopサーバーに代替アドレスが設定されていない場合は、Web InterfaceからCitrix Receiver for iOSに代替アドレスが提供されるように設定できます。これにより、Citrix Receiver for iOSでのサーバー接続で、外部アドレスおよびポート番号が使用されるようになります。

TLSを使用したインストール

Citrix Receiver for iOS 7.2.2はXenApp/XenDesktopとのTLS接続に、以下の暗号の組み合わせを使用したTLS 1.0、1.1、1.2をサポートします:

  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_RC4_128_SHA
  • TLS_RSA_WITH_RC4_128_MD5
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

注:

iOS 9上で実行されているCitrix Receiver for iOSは、以下の暗号化の組み合わせをサポートしません:

  • TLS_RSA_WITH_RC4_128_SHA
  • TLS_RSA_WITH_RC4_128_MD5

Transport Layer Security(TLS)は、SSLプロトコルの最新の標準化バージョンです。IETF(Internet Engineering TaskForce)が、TLSの公開標準規格の開発をNetscape Communications社から引き継いだ時に、SSLという名前をTLSに変更しました。

TLSは、サーバーの認証、データの暗号化、メッセージの整合性の確認を行って、データ通信を保護します。米国政府機関をはじめとする組織の中には、データ通信を保護するためにTLSの使用を義務付けているところもあります。このような組織では、さらにFIPS 140(Federal Information Processing Standard)などのテスト済み暗号化基準の使用を義務付けられる場合があります。FIPS 140は、暗号化の情報処理規格です。

Citrix Receiver for iOSは、ビット長1024、2048および、3072のRSAキーをサポートします。さらに、ビット長4096のRSAキーを持つルート証明書がサポートされます。

注:

Citrix Receiver for iOSは、プラットフォーム(iOS)の暗号化機能をCitrix Receiver for iOSとStoreFrontの接続に使用します。

Citrix Receiver for iOSのTLSの構成と有効化

TLSのセットアップは、以下の2つの手順で行います:

  1. XenAppサーバー、XenDesktopサーバー、およびWeb Interfaceサーバー上でSSL Relayをセットアップし、必要なサーバー証明書を入手してインストールします。詳しくは、XenAppおよびWeb Interfaceのドキュメントを参照してください。
  2. ユーザーデバイス上で、ルート証明書をインストールします。

ユーザーデバイスへのルート証明書のインストール

TLS機能が有効になっているCitrix Receiver for iOSとサーバーファーム間の通信をTLSで保護するには、サーバー証明書の証明機関の署名を認証するためのルート証明書がユーザーデバイスにインストールされている必要があります。

iOSには約100の商用ルート証明書が付属していますが、ほかの証明書を使用する場合は、証明機関から証明書を入手して、それを各ユーザーデバイスにインストールします。

企業の方針によっては、ルート証明書のインストールはエンドユーザーではなく管理者が行う場合があります。ルート証明書を簡単および確実にインストールするには、iOSのキーチェーンにその証明書を追加します。

ルート証明書をキーチェーンに追加するには

  1. 証明書ファイルをメール添付で自分に送信します。
  2. 証明書ファイルをデバイスで開きます。これにより、キーチェーンアクセスが起動します。
  3. プロンプトに従って証明書を追加します。
  4. iOS 10を起動して[iOS設定]>[情報]>[証明書信頼設定]から証明書が信頼されていることを確認します。[証明書信頼設定]で、[ルート証明書の完全な信頼を有効にする]のセクションを参照します。証明書が完全に信頼されていることを確認して下さい。

ルート証明書は、TLSが有効なクライアントと、TLSを使用するその他のアプリケーションでインストールされ、使用可能になります。