Citrix DaaS

Rendezvous V1

Lors de l’utilisation du service Citrix Gateway, le protocole Rendezvous permet de contourner les Citrix Cloud Connector pour se connecter directement et en toute sécurité au plan de contrôle Citrix Cloud.

Exigences

  • Accès à l’environnement à l’aide du service Citrix Workspace et 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 du proxy non transparent (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 la section Paramètre de stratégie de 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 https://*.c.nssvc.net et https://*.g.nssvc.net à la place. Pour plus d’informations, reportez-vous à la section Exigences en termes de connexion 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 Connector doivent obtenir les noms de domaine complets des VDA lors de la négociation d’une session. Ceci peut être fait de l’une de ces deux façons :
    • Activez la résolution DNS pour le site. Accédez à Paramètres et activez le paramètre Activer la résolution DNS. Vous pouvez aussi utiliser le SDK Remote PowerShell Citrix Virtual Apps and Desktops et exécuter la commande Set-BrokerSite -DnsResolutionEnabled $true. Pour plus d’informations sur le SDK Remote PowerShell 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 toujours tenter d’inscrire les 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, puis définissez Inscrire les enregistrements PTR sur Activé et Inscrire. Si le suffixe DNS de la connexion ne correspond pas au suffixe DNS du domaine, vous devez également configurer le paramètre du suffixe DNS spécifique à la connexion afin que les machines puissent inscrire les enregistrements PTR correctement.

    Remarque :

    Si vous utilisez l’option de résolution DNS, les Cloud Connector 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 machines clientes doivent également être en mesure de résoudre les noms de domaine des machines VDA.

    Si vous utilisez une zone de recherche inversée DNS, les FQDN des enregistrements PTR doivent correspondre aux noms de domaine 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 les connexions Rendezvous via un proxy.

Considérations relatives au proxy

Prenez les points suivants en considération lors de l’utilisation de proxy avec Rendezvous :

  • Les proxy transparents, les proxy HTTP non transparents et les proxy SOCKS5 sont pris en charge.
  • Le décryptage 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 de passerelle ne soit pas intercepté, décrypté ou inspecté. Sinon, la connexion est interrompue.
  • Les proxies HTTP prennent en charge l’authentification basée sur une machine à l’aide de Negotiate et des protocoles d’authentification Kerberos ou NT LAN Manager (NTLM).

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

    Remarque :

    Pour utiliser Kerberos, vous devez créer le nom principal de service (SPN) du serveur proxy et l’associer au compte Active Directory du proxy. Le VDA génère le SPN au format HTTP/<proxyURL> lorsqu’il établit une session, où l’URL du proxy est extraite du paramètre de stratégie proxy Rendezvous. Si vous ne créez pas de SPN, l’authentification bascule vers 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 actuellement pas prise en charge. Si vous utilisez un proxy SOCKS5, configurez une exception afin que le trafic destiné aux adresses du service de passerelle (spécifié dans les exigences) puisse contourner l’authentification.
  • Seuls les proxies 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 sur votre réseau, configurez le paramètre Configuration du proxy Rendezvous. Lorsque le paramètre est activé, spécifiez l’adresse proxy HTTP ou SOCKS5, ou entrez le chemin d’accès au fichier PAC pour que le VDA sache quel proxy utiliser. Par exemple :

  • Adresse proxy : http://<URL or IP>:<port> ou socks5://<URL or IP>:<port>
  • Fichier PAC : http://<URL or IP>/<path>/<filename>.pac

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

Validation de Rendezvous

Si vous remplissez toutes les conditions requises, procédez comme suit pour confirmer si Rendezvous est utilisé :

  1. Lancez PowerShell ou une invite de commandes dans 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 de la suite de chiffrement Windows

Pour un ordre de suite de chiffrement personnalisé, assurez-vous d’inclure les suites de chiffrement prises en charge par VDA dans 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 la 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 Gateway Service afin d’éviter une latence accrue et son impact sur les performances. Pour ce faire, vous devez définir des segments d’application pour les adresses Gateway Service (spécifiées dans les conditions requises) et les définir de manière à toujours appliquer le contournement. Pour plus d’informations sur la configuration de segments d’application pour contourner ZPA, reportez-vous à la documentation Zscaler.

Rendezvous V1