Citrix DaaS™

Rendezvous V1

Bei Verwendung des Citrix Gateway Service ermöglicht das Rendezvous-Protokoll VDAs, die Citrix Cloud™ Connectors zu umgehen, um sich direkt und sicher mit der Citrix Cloud-Steuerungsebene zu verbinden.

Anforderungen

  • Zugriff auf die Umgebung über Citrix Workspace™ und den Citrix Gateway Service.
  • Steuerungsebene: Citrix DaaS™ (Citrix Cloud).
  • VDA: Version 1912 oder höher.
    • Version 2012 ist die Mindestanforderung für EDT Rendezvous.
    • Version 2012 ist die Mindestanforderung für die Unterstützung nicht-transparenter Proxys (keine PAC-Datei-Unterstützung).
    • Version 2103 ist die Mindestanforderung für die Proxykonfiguration mit einer PAC-Datei.
  • Aktivieren Sie das Rendezvous-Protokoll in der Citrix-Richtlinie. Weitere Informationen finden Sie unter Rendezvous-Protokoll-Richtlinieneinstellung.
  • Die VDAs müssen Zugriff auf https://*.nssvc.net haben, einschließlich aller Subdomains. Wenn Sie nicht alle Subdomains auf diese Weise zur Positivliste hinzufügen können, verwenden Sie stattdessen https://*.c.nssvc.net und https://*.g.nssvc.net. Weitere Informationen finden Sie im Abschnitt Anforderungen an die Internetkonnektivität der Citrix Cloud-Dokumentation (unter Citrix DaaS) und im Knowledge Center-Artikel CTX270584.
  • Die VDAs müssen in der Lage sein, sich mit den zuvor genannten Adressen über TCP 443 und UDP 443 für TCP Rendezvous bzw. EDT Rendezvous zu verbinden.
  • Cloud Connectors müssen die FQDNs der VDAs beim Brokern einer Sitzung abrufen. Erledigen Sie diese Aufgabe auf eine der folgenden zwei Arten:
    • DNS-Auflösung für die Site aktivieren. Navigieren Sie zu Einstellungen > Site-Einstellungen und aktivieren Sie die Einstellung DNS-Auflösung aktivieren. Alternativ können Sie das Citrix Virtual Apps and Desktops Remote PowerShell SDK verwenden und den Befehl Set-BrokerSite -DnsResolutionEnabled $true ausführen. Weitere Informationen zum Citrix Virtual Apps and Desktops Remote PowerShell SDK finden Sie unter SDKs und APIs.
    • DNS-Reverse-Lookup-Zone mit PTR-Einträgen für die VDAs. Wenn Sie diese Option wählen, empfehlen wir Ihnen, die VDAs so zu konfigurieren, dass sie immer versuchen, PTR-Einträge zu registrieren. Verwenden Sie dazu den Gruppenrichtlinien-Editor oder das Gruppenrichtlinienobjekt, navigieren Sie zu Computerkonfiguration > Administrative Vorlagen > Netzwerk > DNS-Client, und setzen Sie PTR-Einträge registrieren auf Aktiviert und registrieren. Wenn das DNS-Suffix der Verbindung nicht mit dem DNS-Suffix der Domäne übereinstimmt, müssen Sie auch die Einstellung Verbindungsspezifisches DNS-Suffix für die Maschinen konfigurieren, damit die PTR-Einträge erfolgreich registriert werden.

    Hinweis:

    Wenn Sie die Option zur DNS-Auflösung verwenden, müssen die Cloud Connectors die vollqualifizierten Domänennamen (FQDNs) der VDA-Maschinen auflösen können. Falls interne Benutzer direkt eine Verbindung zu den VDA-Maschinen herstellen, müssen die Clientgeräte auch die FQDNs der VDA-Maschinen auflösen können.

    Wenn Sie eine DNS-Reverse-Lookup-Zone verwenden, müssen die FQDNs in den PTR-Einträgen mit den FQDNs der VDA-Maschinen übereinstimmen. Wenn der PTR-Eintrag einen anderen FQDN enthält, schlägt die Rendezvous-Verbindung fehl. Wenn der FQDN der Maschine beispielsweise vda01.domain.net lautet, muss der PTR-Eintrag vda01.domain.net enthalten. Ein anderer FQDN wie vda01.sub.domain.net funktioniert nicht.

Proxykonfiguration

Der VDA unterstützt den Aufbau von Rendezvous-Verbindungen über einen Proxy.

Überlegungen zum Proxy

Beachten Sie bei der Verwendung von Proxys mit Rendezvous Folgendes:

  • Transparente Proxys, nicht-transparente HTTP-Proxys und SOCKS5-Proxys werden unterstützt.
  • Paketentschlüsselung und -inspektion werden nicht unterstützt. Konfigurieren Sie eine Ausnahme, damit der ICA®-Datenverkehr zwischen dem VDA und dem Gateway Service nicht abgefangen, entschlüsselt oder inspiziert wird. Andernfalls bricht die Verbindung ab.
  • HTTP-Proxys unterstützen die maschinenbasierte Authentifizierung mithilfe der Authentifizierungsprotokolle Negotiate und Kerberos oder NT LAN Manager (NTLM).

    Wenn Sie eine Verbindung zum Proxyserver herstellen, wählt das Negotiate-Authentifizierungsschema automatisch das Kerberos-Protokoll aus. Wenn Kerberos nicht unterstützt wird, greift Negotiate zur Authentifizierung auf NTLM zurück.

    Hinweis:

    Um Kerberos zu verwenden, müssen Sie den Dienstprinzipalnamen (SPN) für den Proxyserver erstellen und ihn dem Active Directory-Konto des Proxys zuordnen. Der VDA generiert den SPN im Format HTTP/<proxyURL> beim Aufbau einer Sitzung, wobei die Proxy-URL aus der Richtlinieneinstellung Rendezvous-Proxy abgerufen wird. Wenn Sie keinen SPN erstellen, greift die Authentifizierung auf NTLM zurück. In beiden Fällen wird die Identität der VDA-Maschine zur Authentifizierung verwendet.

  • Die Authentifizierung mit einem SOCKS5-Proxy wird derzeit nicht unterstützt. Wenn Sie einen SOCKS5-Proxy verwenden, müssen Sie eine Ausnahme konfigurieren, damit der für Gateway Service-Adressen (in den Anforderungen angegeben) bestimmte Datenverkehr die Authentifizierung umgehen kann.
  • Nur SOCKS5-Proxys unterstützen den Datentransport über EDT. Verwenden Sie für einen HTTP-Proxy TCP als Transportprotokoll für ICA.

Transparenter Proxy

Wenn Sie einen transparenten Proxy in Ihrem Netzwerk verwenden, ist keine zusätzliche Konfiguration auf dem VDA erforderlich.

Nicht-transparenter Proxy

Wenn Sie einen nicht-transparenten Proxy in Ihrem Netzwerk verwenden, konfigurieren Sie die Einstellung Rendezvous-Proxykonfiguration. Wenn die Einstellung aktiviert ist, geben Sie die HTTP- oder SOCKS5-Proxyadresse an oder geben Sie den Pfad zur PAC-Datei ein, damit der VDA weiß, welchen Proxy er verwenden soll. Zum Beispiel:

  • Proxyadresse: http://<URL oder IP>:<Port> oder socks5://<URL oder IP>:<Port>
  • PAC-Datei: http://<URL oder IP>/<Pfad>/<Dateiname>.pac

Wenn Sie die PAC-Datei zur Konfiguration des Proxys verwenden, definieren Sie den Proxy mit der vom Windows HTTP-Dienst benötigten Syntax: PROXY [<Schema>=]<URL oder IP>:<Port>. Zum Beispiel: PROXY socks5=<URL oder IP>:<Port>.

Rendezvous-Validierung

Wenn Sie alle Anforderungen erfüllen, führen Sie die folgenden Schritte aus, um zu überprüfen, ob Rendezvous verwendet wird:

  1. Starten Sie PowerShell oder eine Eingabeaufforderung innerhalb der HDX™-Sitzung.
  2. Führen Sie ctxsession.exe –v aus.
  3. Die verwendeten Transportprotokolle geben den Verbindungstyp an:
    • TCP Rendezvous: TCP > SSL > CGP > ICA
    • EDT Rendezvous: UDP > DTLS > CGP > ICA
    • Proxy über Cloud Connector: TCP > CGP > ICA

Weitere Überlegungen

Reihenfolge der Windows-Cipher-Suites

Stellen Sie bei einer benutzerdefinierten Reihenfolge der Cipher-Suites sicher, dass Sie die vom VDA unterstützten Cipher-Suites aus der folgenden Liste aufnehmen:

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

Wenn die benutzerdefinierte Reihenfolge der Cipher-Suites diese Cipher-Suites nicht enthält, schlägt die Rendezvous-Verbindung fehl.

Zscaler Private Access

Wenn Sie Zscaler Private Access (ZPA) verwenden, wird empfohlen, Bypass-Einstellungen für den Gateway Service zu konfigurieren, um erhöhte Latenzzeiten und die damit verbundenen Leistungseinbußen zu vermeiden. Dazu müssen Sie Anwendungssegmente für die Gateway Service-Adressen – wie in den Anforderungen angegeben – definieren und diese so einstellen, dass sie immer umgangen werden. Informationen zur Konfiguration von Anwendungssegmenten zum Umgehen von ZPA finden Sie in der Zscaler-Dokumentation.

Rendezvous V1