Optimieren der Konnektivität zu Workspaces mit einer direkten Workloadverbindung

Hinweis:

Dieses Feature ist derzeit ein Limited Release. Das Feature kann in einer Produktionsumgebung verwendet werden, ist aber möglicherweise nicht für alle Kunden geeignet. Weitere Informationen finden Sie unter Info über dieses Limited Release in diesem Artikel.

Mit der direkten Workloadverbindung in Citrix Cloud optimieren Sie den internen Datenverkehr zu Apps und Desktops, die Sie Abonnenten in ihrem Workspace zur Verfügung stellen, und können so HDX-Sitzungen beschleunigen. In der Regel müssen sich Benutzer in internen und externen Netzwerken über ein externes Gateway mit VDAs verbinden. Während dies für externe Benutzer zu erwarten ist, können sich interne Benutzer dadurch langsamer mit virtuellen Ressourcen verbinden. Mit der direkten Workloadverbindung können interne Benutzer das Gateway umgehen und sich direkt mit VDAs verbinden, wodurch die Latenz für den internen Netzwerkverkehr verringert wird.

Um die direkte Workloadverbindung einzurichten, konfigurieren Sie Netzwerkstandorte, die den VDAs in der Umgebung mit dem Netzwerkpositionsdienst entsprechen. Um diese Standorte zu konfigurieren, verwenden Sie ein von Citrix bereitgestelltes PowerShell-Modul. Diese Netzwerkstandorte entsprechen den öffentlichen IP-Bereichen der Netzwerke, von denen Ihre internen Benutzer eine Verbindung herstellen (z. B. Ihre Bürostandorte oder Zweigstellen). Wenn Abonnenten eine Virtual Apps and Desktops-Sitzung vom Workspace aus starten, prüft Citrix Cloud anhand der öffentlichen IP-Adresse des Netzwerks, von dem aus sie eine Verbindung herstellen, ob sie sich innerhalb oder außerhalb des Firmennetzwerk befinden. Wenn ein Abonnent sich über das interne Netzwerk verbindet, leitet Citrix Cloud die Verbindung direkt an den VDA weiter und umgeht Citrix Gateway. Wenn ein Abonnent eine externe Verbindung herstellt, leitet Citrix Cloud den Abonnenten erwartungsgemäß über Citrix Gateway und dann durch den Citrix Cloud Connector an den VDA im internen Netzwerk.

Info über dieses Limited Release

Der Netzwerkpositionsdienst (NLS), den die direkte Workloadverbindung verwendet, wird derzeit in mehreren Verfügbarkeitszonen in der Region USA Ost von Amazon Web Service gehostet. Ein Aufruf an den NLS erfolgt zur Desktop- oder App-Startzeit parallel zu vielen anderen Aufrufen. NLS prüft die öffentliche IP-Adresse, von der der Aufruf stammt, und antwortet, ob der Benutzer intern oder extern ist. In dem seltenen Fall, dass keine Antwort von NLS empfangen wird, bevor die anderen parallelen Aufrufe zurückgegeben werden, wird der Start über das Gateway geleitet.

Der NLS wird in einem einzigen PoP gehostet. Wenn es also bei AWS in der Region USA Ost zu einen regionalen Ausfall kommt, der alle Verfügbarkeitszonen betrifft, wird der NLS offline geschaltet. Bis heute hat AWS noch nie einen regionalen Ausfall erlitten und verfügt über eine garantierte Betriebsbereitschaft von 99,999%. Wenn jedoch ein Ausfall auftritt, werden alle Starts über das Gateway statt direkt an die VDAs weitergeleitet. Starts werden über VDAs geleitet, wenn die Region USA Ost wieder online ist. Obwohl keine Startfehler oder Verzögerungen auftreten würden, hätten Sie wieder die Latenz, die Sie hatten, bevor die direkte Workloadverbindung aktiviert wurde. Citrix empfiehlt, dass Sie überlegen, ob diese Möglichkeit akzeptabel ist, bevor Sie die direkte Workloadverbindung aktivieren.

Unterstützte Produkte

Die direkte Workloadverbindung wird nur für Virtual Apps and Desktops Service unterstützt. Unterstützung für Citrix Managed Desktops und Citrix SD-WAN ist im Limited Release verfügbar.

Wichtig:

Wenn es in Ihrer Umgebung neben On-Premises-VDAs auch Citrix Managed Desktops gibt und Sie die direkte Workloadverbindung konfigurieren, schlägt der Start von Citrix Managed Desktops im internen Netzwerk fehl.

Der Start von Secure Browser, Citrix Virtual Apps Essentials und Citrix Virtual Desktops Essentials wird immer über das Gateway geleitet. Bei diesen Starts kommt es daher zu keiner Leistungsverbesserung durch die direkte Workloadverbindung.

Anforderungen

Netzwerkanforderungen

  • Wenn Sie ein Unternehmensnetzwerk und ein Gast-WiFi-Netzwerk verwenden, müssen diese Netzwerke separate öffentliche IP-Adressen haben. Wenn Ihr Unternehmens- und Gastnetzwerk dieselbe öffentliche IP-Adresse verwendet, können Benutzer im Gastnetzwerk keine Virtual Apps and Desktops-Sitzung starten.
  • Sie müssen die öffentlichen IP-Adressbereiche der Netzwerke verwenden, von denen Ihre internen Benutzer eine Verbindung herstellen. Interne Benutzer in diesen Netzwerken müssen über eine direkte Verbindung zu den VDAs verfügen. Andernfalls schlägt der Start virtueller Ressourcen fehl, da Workspace versucht, interne Benutzer direkt an den VDA weiterzuleiten. Diese Verbindung ist jedoch nicht möglich.

TLS-Anforderungen

TLS 1.2 muss in PowerShell aktiviert sein, wenn Sie Ihre Netzwerkstandorte konfigurieren. Um in PowerShell TLS 1.2 zu erzwingen, verwenden Sie den folgenden Befehl, bevor Sie das PowerShell-Modul verwenden:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Workspaceanforderungen

  • Sie haben einen Workspace in Citrix Cloud konfiguriert.
  • Der Virtual Apps and Desktops Service ist unter Workspacekonfiguration > Serviceintegrationen aktiviert.
  • Sie verwenden ON-Premises-VDAs, um Workspace-Abonnenten virtuelle Ressourcen bereitzustellen.

Aktivieren von TLS für Workspace-App für HTML5-Verbindungen

Wenn Abonnenten die Citrix Workspace-App für HTML5 zum Starten von Apps und Desktops verwenden, empfiehlt Citrix, TLS auf den VDAs im internen Netzwerk zu aktivieren, um eine direkte Verbindung zu diesen VDAs zu sicherzustellen. Wenn für VDAs TLS nicht aktiviert ist, werden App- und Desktopstarts über das Gateway geleitet, wenn Abonnenten die Workspace-App für HTML5 verwenden. Starts mit dem Desktop Viewer sind davon nicht betroffen. Weitere Informationen zum Schutz direkter VDA-Verbindungen mit TLS finden Sie unter CTX134123 im Citrix Support Knowledge Center.

Konfigurationsübersicht

Um die direkte Workloadverbindung zu konfigurieren, führen Sie Folgendes aus:

  1. Bestimmen Sie die öffentlichen IP-Adressbereiche der einzelnen Zweigstellen, von denen Ihre internen Benutzer eine Verbindung herstellen.
  2. Download des PowerShell-Moduls.
  3. Erstellen Sie einen sicheren API-Client in Citrix Cloud und notieren Sie sich die Client-ID und den geheimen Clientschlüssel.
  4. Importieren Sie das PowerShell-Modul und stellen Sie eine Verbindung zum Netzwerkpositionsdienst mit Ihren API-Clientdetails her.
  5. Erstellen Sie NLS-Sites für jeden Ihrer Zweigstellen mit den öffentlichen IP-Adressbereichen, die Sie zuvor festgelegt haben. Die direkte Workloadverbindung wird automatisch für alle Starts aktiviert, die von den von Ihnen angegebenen internen Netzwerkstandorten stammen.
  6. Starten Sie eine App oder einen Desktop von einem Gerät in Ihrem internen Netzwerk und prüfen Sie, ob die Verbindung direkt zum VDA geht, also das Gateway umgeht.

PowerShell-Modul und Konfiguration

Download des PowerShell-Moduls

Vor dem Einrichten Ihrer Netzwerkstandorte laden Sie das von Citrix bereitgestellte PowerShell-Modul (nls.psm1) aus dem Citrix GitHub-Repository herunter. Mit diesem Modul können Sie beliebig viele Netzwerkstandorte für Ihre VDAs einrichten.

  1. Navigieren Sie in einem Webbrowser zu https://github.com/citrix/sample-scripts/blob/master/workspace/nls.psm1.
  2. Klicken Sie bei gedrückter ALT-Taste auf die Schaltfläche Raw. Github-Dateiansicht mit markierter Schaltfläche "Raw"
  3. Wählen Sie einen Speicherort auf Ihrem Computer und klicken Sie auf Speichern.

Erforderliche Konfigurationsdetails

Zum Einrichten Ihrer Netzwerkstandorte sind folgende Informationen erforderlich:

  • Kunden-ID, Client-ID und Clientgeheimnis für den sicheren Client in Citrix Cloud. Informationen zum Abrufen dieser Werte finden Sie unter Erstellen eines sicheren Client in diesem Artikel.
  • Öffentliche IP-Adressbereiche für die Netzwerke, von denen Ihre internen Benutzer eine Verbindung herstellen. Weitere Informationen zu diesen öffentlichen IP-Adressbereichen finden Sie unter Anforderungen in diesem Artikel.

Erstellen eines sicheren Client

  1. Melden Sie sich bei Citrix Cloud auf https://citrix.cloud.com an.
  2. Wählen Sie im Menü “Citrix Cloud” Identitäts- und Zugriffsverwaltung und dann API-Zugriff.
  3. Notieren Sie sich die Kunden-ID auf der Registerkarte Sichere Clients. Sichere Clients-Konsole mit markierter Kunden-ID
  4. Geben Sie einen Namen für den Client ein und wählen Sie Client erstellen.
  5. Kopieren Sie die Client-ID und das Clientgeheimnis. Dialogfeld mit ID und Geheimnis für sicheren Client

Konfigurieren von Netzwerkstandorten

  1. Öffnen Sie ein PowerShell-Befehlsfenster und navigieren Sie zum Verzeichnis, in dem Sie das PowerShell-Modul gespeichert haben.
  2. Importieren Sie das Modul: Import-Module .\nls.psm1 -Force
  3. Legen Sie die erforderlichen Variablen fest. Verwenden Sie hierfür die Angaben zum sicheren Client, die Sie unter Erstellen eines sicheren Client erfasst haben:
    • $clientId = "YourSecureClientID"
    • $customer = "YourCustomerID"
    • $clientSecret = "YourSecureClientSecret"
  4. Verbinden Sie sich mit den Anmeldeinformationen für Ihren sicheren Client mit dem Netzwerkpositionsdienst:

    Connect-NLS -clientId $clientId -clientSecret $clientSecret -customer $customer
    
  5. Erstellen Sie einen Netzwerkstandort und ersetzen Sie die Parameterwerte durch die Werte für das interne Netzwerk, von dem Ihre internen Benutzer eine direkte Verbindung herstellen:

    New-NLSSite -name "YourSiteName" -tags @("YourTags") -ipv4Ranges @("PublicIpsOfYourNetworkSites") -longitude 12.3456 -latitude 12.3456
    

    Wenn der Netzwerkstandort erfolgreich erstellt wurde, werden im Befehlsfenster die Details des Netzwerkstandorts angezeigt.

  6. Wiederholen Sie Schritt 5 für alle Netzwerkstandorte, von denen die Benutzer eine Verbindung herstellen.
  7. Der Befehl Get-NLSSite gibt eine Liste aller Sites zurück, die Sie mit NLS konfiguriert haben. Überprüfen Sie, ob die Details korrekt sind.

Überprüfen der fehlerfreien Weiterleitung interner Startvorgänge

Verwenden Sie eine der folgenden Methoden, um zu überprüfen, ob interne Starts direkt auf VDAs zugreifen:

  • Zeigen Sie VDA-Verbindungen über die Virtual Apps and Desktops-Konsole an.
  • Überprüfen Sie mit der ICA-Dateiprotokollierung die korrekte Adressierung der Clientverbindung.

Virtual Apps and Desktops Service-Konsole

Wählen Sie Verwalten > Überwachen und suchen Sie einen Benutzer mit aktiver Sitzung. Im Abschnitt “Sitzungsdetails” der Konsole werden direkte VDA-Verbindungen als UDP-Verbindungen angezeigt, während Gateway-Verbindungen als TCP-Verbindungen angezeigt werden.

ICA-Dateiprotokollierung

Aktivieren Sie die ICA-Dateiprotokollierung auf dem Clientcomputer wie unter Aktivieren der Protokollierung für die Datei launch.ica beschrieben. Überprüfen Sie nach dem Start von Sitzungen die Einträge Address und SSLProxyHost in der Protokolldatei.

Bei direkten VDA-Verbindungen enthält die Eigenschaft Address die IP-Adresse und den Port des VDA und die Eigenschaft SSLProxyHost den FQDN und Port des VDA.

Bei Gateway-Verbindungen enthält die Eigenschaft Address das STA-Ticket und die Eigenschaft SSLProxyHost den FQDN und Port des Gateways.

Ändern von Netzwerkstandorten

Verwenden Sie die Schritte in diesem Abschnitt, wenn Sie Änderungen an einem vorhandenen Netzwerkstandort machen müssen.

  1. Listen Sie alle vorhandenen Netzwerkstandorte in einem PowerShell-Befehlsfenster auf: Get-NLSSite
  2. Zum Ändern des IP-Bereichs für einen bestimmten Netzwerkstandort geben Sie ein:

    (Get-NLSSite)[N] -ipv4Ranges @("1.2.3.4/32","4.3.2.1/32") | Set-NLSSite

    Dabei ist [N] die Ziffer, die der Position in der Liste entspricht (beginnend mit Null) und "1.2.3.4/32","4.3.2.1/32" sind die durch Kommas getrennten IP-Bereiche, die Sie verwenden möchten. Um beispielsweise den ersten aufgelisteten Standort zu ändern, geben Sie folgenden Befehl ein:

    (Get-NLSSite)[0] -ipv4Ranges @("98.0.0.1/32","141.43.0.0/24") | Set-NLSSite

Entfernen von Netzwerkstandorten

Verwenden Sie die Schritte in diesem Abschnitt, wenn Sie Netzwerkstandort entfernen müssen, die Sie nicht mehr verwenden.

  1. Listen Sie alle vorhandenen Netzwerkstandorte in einem PowerShell-Befehlsfenster auf: Get-NLSSite
  2. Um alle Netzwerkstandorte zu entfernen, geben Sie ein: Get-NLSSite | Remove-NLSSite
  3. Um bestimmte Netzwerkstandorte zu entfernen, geben Sie ein: (Get-NLSSite)[N] | Remove-NLSSite. Dabei ist [N] die Ziffer, die der Position in der Liste entspricht. Um beispielsweise den ersten aufgelisteten Standort zu entfernen, geben Sie folgenden Befehl ein: (Get-NLSSite)[0] | Remove-NLSSite

Beispielskript

Das Beispielskript enthält alle Befehle, die Sie zum Hinzufügen, Ändern und Entfernen der öffentlichen IP-Adressbereiche für Ihre Zweigstellen benötigen. Sie müssen jedoch nicht alle Befehle ausführen, um eine einzelne Funktion auszuführen. Damit das Skript ausgeführt werden kann, müssen Sie stets die ersten 10 Zeilen angeben, von Import-Module bis einschließlich Connect-NLS. Anschließend können Sie nur die Befehle für die Funktionen angeben, die Sie ausführen möchten.

Import-Module .\nls.psm1 -Force
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

$clientId = "XXXX" #Durch Ihre Client-ID ersetzen
$clientSecret = "YYY"    #Durch Ihren geheimen Clientschlüssel ersetzen
$customer = "CCCCCC"  #Durch Ihre Kunden-ID ersetzen

# Verbindung zum Netzwerkpositionsdienst herstellen
Connect-NLS -clientId $clientId -clientSecret $clientSecret -customer $customer

# Neue Netzwerkpositionsdienstsite erstellen (Fügen Sie die entsprechenden Details für Ihre Filialstandorte ein)
New-NLSSite -name "New York" -tags @("EastCoast") -ipv4Ranges @("1.2.3.0/24") -longitude 40.7128 -latitude -74.0060

# Vorhandene Netzwerkpositionsdienstsites abrufen (optional)
Get-NLSSite

# IP-Adressbereiche Ihrer ersten Netzwerkpositionsdienstsite aktualisieren (optional)
$s = (Get-NLSSite)[0]
$s.ipv4Ranges = @("1.2.3.4/32","4.3.2.1/32")
$s | Set-NLSSite

# Alle Netzwerkpositionsdienstsites entfernen (optional)
Get-NLSSite | Remove-NLSSite

# Ihre dritte Site entfernen (optional)
(Get-NLSSite)[2] | Remove-NLSSite

Problembehandlung

Fehler bei Connect-NLS

Wenn beim Ausführen des Befehls Connect-NLS (Schritt 2 in Konfigurieren von Netzwerkstandorten) eine Fehlermeldung angezeigt wird, müssen Sie möglicherweise in PowerShell die Verwendung von TLS 1.2 erzwingen. Führen Sie hierfür den folgenden Befehl aus:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Fehler beim VDA-Start

Wenn VDA-Sitzungen nicht gestartet werden, müssen Sie sicherstellen, dass Sie öffentliche IP-Adressbereiche aus dem richtigen Netzwerk verwenden. Beim Konfigurieren Ihrer Netzwerkstandorte müssen Sie die öffentlichen IP-Adressbereiche des Netzwerks verwenden, von dem Ihre internen Benutzer eine Verbindung herstellen. Weitere Informationen finden Sie unter Anforderungen in diesem Artikel.

Um die öffentliche IP-Adresse eines VDAs zu überprüfen, melden Sie sich bei jeder VDA-Maschine an, rufen Sie https://google.com auf und geben Sie in der Suchleiste “what is my ip” ein.

Interne VDA-Starts werden weiterhin über das Gateway geleitet

Wenn intern gestartete VDA-Sitzungen weiterhin über das Gateway geleitet werden (als wären sie externe Sitzungen), müssen Sie sicherstellen, dass Sie die richtigen IP-Adressbereiche für die Netzwerke verwenden, von denen Ihre internen Benutzer eine Verbindung herstellen. Dies sind in der Regel öffentliche IP-Adressbereiche, die den Netzwerken entsprechen, in denen sich Ihre VDAs befinden; Benutzer können aber auch über ein VPN auf die VDAs zugreifen. Verwenden Sie nicht die lokalen IP-Adressen der VDAs. Weitere Informationen finden Sie unter Anforderungen in diesem Artikel.

Um die öffentliche IP-Adresse eines VDAs zu überprüfen, melden Sie sich bei jeder VDA-Maschine an, rufen Sie https://google.com auf und geben Sie in der Suchleiste “what is my ip” ein.

Zusätzliche Hilfe und Unterstützung

Wenn Sie Hilfe oder Fragen zur Problembehandlung benötigen, wenden Sie sich an Ihren Citrix Vertriebsmitarbeiter oder Citrix Support.