Citrix DaaS™

Rendezvous V1

Lorsque vous utilisez le service Citrix Gateway, le protocole Rendezvous permet aux VDA de contourner les connecteurs Citrix Cloud™ pour se connecter directement et en toute sécurité au plan de contrôle Citrix Cloud.

Exigences

  • Accès à l’environnement à l’aide de Citrix Workspace™ et du service Citrix Gateway.
  • Plan de contrôle : Citrix DaaS™ (Citrix Cloud).
  • VDA : Version 1912 ou ultérieure.
    • La version 2012 est la version minimale requise pour EDT Rendezvous.
    • La version 2012 est la version minimale requise pour la prise en charge des proxys non transparents (pas de prise en charge des fichiers PAC).
    • La version 2103 est la version minimale requise pour la configuration du proxy avec un fichier PAC.
  • Activez le protocole Rendezvous dans la stratégie Citrix. Pour plus d’informations, consultez Paramètre de stratégie du protocole Rendezvous.
  • Les VDA doivent avoir accès à https://*.nssvc.net, y compris tous les sous-domaines. Si vous ne pouvez pas ajouter tous les sous-domaines à la liste d’autorisation de cette manière, utilisez plutôt https://*.c.nssvc.net et https://*.g.nssvc.net. Pour plus d’informations, consultez la section Exigences de connectivité Internet de la documentation Citrix Cloud (sous Citrix DaaS) et l’article du centre de connaissances CTX270584.
  • Les VDA doivent pouvoir se connecter aux adresses mentionnées précédemment sur TCP 443 et UDP 443 pour TCP Rendezvous et EDT Rendezvous, respectivement.
  • Les Cloud Connectors doivent obtenir les FQDN des VDA lors de l’établissement d’une session. Accomplissez cette tâche de l’une des deux manières suivantes :
    • Activez la résolution DNS pour le site. Accédez à Paramètres > Paramètres du site et activez le paramètre Activer la résolution DNS. Vous pouvez également utiliser le SDK PowerShell distant de Citrix Virtual Apps and Desktops et exécuter la commande Set-BrokerSite -DnsResolutionEnabled $true. Pour plus d’informations sur le SDK PowerShell distant de Citrix Virtual Apps and Desktops, consultez SDK et API.
    • Zone de recherche inversée DNS avec enregistrements PTR pour les VDA. Si vous choisissez cette option, nous vous recommandons de configurer les VDA pour qu’ils tentent toujours d’enregistrer des enregistrements PTR. Pour ce faire, utilisez l’Éditeur de stratégie de groupe ou l’Objet de stratégie de groupe, accédez à Configuration ordinateur > Modèles d’administration > Réseau > Client DNS, et définissez Enregistrer les enregistrements PTR sur Activé et Enregistrer. Si le suffixe DNS de la connexion ne correspond pas au suffixe DNS du domaine, vous devez également configurer le paramètre Suffixe DNS spécifique à la connexion pour que les machines enregistrent correctement les enregistrements PTR.

    Remarque :

    Si vous utilisez l’option de résolution DNS, les Cloud Connectors doivent être en mesure de résoudre les noms de domaine complets (FQDN) des machines VDA. Dans le cas où les utilisateurs internes se connectent directement aux machines VDA, les périphériques clients doivent également être en mesure de résoudre les FQDN des machines VDA.

    Si vous utilisez une zone de recherche inversée DNS, les FQDN des enregistrements PTR doivent correspondre aux FQDN des machines VDA. Si l’enregistrement PTR contient un FQDN différent, la connexion Rendezvous échoue. Par exemple, si le FQDN de la machine est vda01.domain.net, l’enregistrement PTR doit contenir vda01.domain.net. Un FQDN différent tel que vda01.sub.domain.net ne fonctionne pas.

Configuration du proxy

Le VDA prend en charge l’établissement de connexions Rendezvous via un proxy.

Considérations relatives au proxy

Tenez compte des éléments suivants lorsque vous utilisez des proxys avec Rendezvous :

  • Les proxys transparents, les proxys HTTP non transparents et les proxys SOCKS5 sont pris en charge.
  • Le déchiffrement et l’inspection des paquets ne sont pas pris en charge. Configurez une exception afin que le trafic ICA® entre le VDA et le service Gateway ne soit pas intercepté, déchiffré ou inspecté. Dans le cas contraire, la connexion est interrompue.
  • Les proxys HTTP prennent en charge l’authentification basée sur la machine à l’aide des protocoles d’authentification Negotiate et Kerberos ou NT LAN Manager (NTLM).

    Lorsque vous vous connectez au serveur proxy, le schéma d’authentification Negotiate sélectionne automatiquement le protocole Kerberos. Si Kerberos n’est pas pris en charge, Negotiate revient à NTLM pour l’authentification.

    Remarque :

    Pour utiliser Kerberos, vous devez créer le nom de principal de service (SPN) pour le serveur proxy et l’associer au compte Active Directory du proxy. Le VDA génère le SPN au format HTTP/<proxyURL> lors de l’établissement d’une session, où l’URL du proxy est récupérée à partir du paramètre de stratégie Proxy Rendezvous. Si vous ne créez pas de SPN, l’authentification revient à NTLM. Dans les deux cas, l’identité de la machine VDA est utilisée pour l’authentification.

  • L’authentification avec un proxy SOCKS5 n’est pas prise en charge actuellement. Si vous utilisez un proxy SOCKS5, vous devez configurer une exception afin que le trafic destiné aux adresses du service Gateway (spécifiées dans les exigences) puisse contourner l’authentification.
  • Seuls les proxys SOCKS5 prennent en charge le transport de données via EDT. Pour un proxy HTTP, utilisez TCP comme protocole de transport pour ICA.

Proxy transparent

Si vous utilisez un proxy transparent dans votre réseau, aucune configuration supplémentaire n’est requise sur le VDA.

Proxy non transparent

Si vous utilisez un proxy non transparent dans votre réseau, configurez le paramètre Configuration du proxy Rendezvous. Lorsque le paramètre est activé, spécifiez l’adresse du proxy HTTP ou SOCKS5, ou entrez le chemin d’accès au fichier PAC afin que le VDA sache quel proxy utiliser. Par exemple :

  • Adresse du proxy : http://<URL ou IP>:<port> ou socks5://<URL ou IP>:<port>
  • Fichier PAC : http://<URL ou IP>/<chemin>/<nom_fichier>.pac

Si vous utilisez le fichier PAC pour configurer le proxy, définissez le proxy en utilisant la syntaxe requise par le service HTTP de Windows : PROXY [<schéma>=]<URL ou IP>:<port>. Par exemple, PROXY socks5=<URL ou IP>:<port>.

Validation de Rendezvous

Si vous remplissez toutes les exigences, suivez ces étapes pour valider si Rendezvous est utilisé :

  1. Lancez PowerShell ou une invite de commandes au sein de la session HDX™.
  2. Exécutez ctxsession.exe –v.
  3. Les protocoles de transport utilisés indiquent le type de connexion :
    • TCP Rendezvous : TCP > SSL > CGP > ICA
    • EDT Rendezvous : UDP > DTLS > CGP > ICA
    • Proxy via Cloud Connector : TCP > CGP > ICA

Autres considérations

Ordre des suites de chiffrement Windows

Pour un ordre de suite de chiffrement personnalisé, assurez-vous d’inclure les suites de chiffrement prises en charge par le VDA à partir de la liste suivante :

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Si l’ordre de suite de chiffrement personnalisé ne contient pas ces suites de chiffrement, la connexion Rendezvous échoue.

Zscaler Private Access

Si vous utilisez Zscaler Private Access (ZPA), il est recommandé de configurer des paramètres de contournement pour le service Gateway afin d’éviter une latence accrue et l’impact sur les performances associé. Pour ce faire, vous devez définir des segments d’application pour les adresses du service Gateway – spécifiées dans les exigences – et les configurer pour qu’ils soient toujours contournés. Pour plus d’informations sur la configuration des segments d’application pour contourner ZPA, consultez la documentation Zscaler.

Rendezvous V1