Optimieren der Konnektivität zu Workspaces mit einer direkten Workloadverbindung

Mit der direkten Workloadverbindung in Citrix Cloud optimieren Sie den internen Datenverkehr zu Apps und Desktops in Workspaces und können so HDX-Sitzungen beschleunigen. In der Regel verbinden sich Benutzer in internen und externen Netzwerken über ein externes Gateway mit VDAs. Dieses Gateway kann on-premises in Ihrer Organisation sein oder als Citrix Dienst dem Ressourcenstandort in Citrix Cloud hinzugefügt werden. 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 eine direkte Workloadverbindung einzurichten, benötigen Sie Netzwerkstandorte, die dem Standort entsprechen, an dem Clients Apps und Desktops in Ihrer Umgebung starten. Fügen Sie mit dem Netzwerkpositionsdienst (NLS) eine öffentliche Adresse für jeden Bürostandort hinzu, an dem sich diese Clients befinden. Sie haben zwei Möglichkeiten, Netzwerkspeicherorte zu konfigurieren:

• Menüoption Netzwerkspeicherorte in Citrix Cloud.
• Verwenden eines von Citrix bereitstellten PowerShell-Moduls.

Netzwerkspeicherorte entsprechen den öffentlichen IP-Bereichen der Netzwerke, von denen aus interne Benutzer eine Verbindung herstellen (z. B. Ihre Bürostandorte oder Zweigstellen). Citrix Cloud bestimmt anhand öffentlicher IP-Adressen, ob Netzwerke, aus denen virtuelle Apps oder Desktops gestartet werden, innerhalb oder außerhalb des Unternehmensnetzwerks liegen. Wenn ein Abonnent sich über das interne Netzwerk verbindet, leitet Citrix Cloud die Verbindung direkt an den VDA weiter und umgeht NetScaler Gateway. Wenn ein Abonnent eine externe Verbindung herstellt, leitet Citrix Cloud ihn über NetScaler Gateway und dann den Datenverkehr der Sitzung über Citrix Cloud Connector an den VDA im internen Netzwerk weiter. Wenn Citrix Gateway Service verwendet wird und das Rendezvous-Protokoll aktiviert ist, leitet Citrix Cloud externe Benutzer über den Gateway Service an den VDA im internen Netzwerk weiter. Roaming-Clients wie Laptops können eine dieser Netzwerkrouten verwenden, je nachdem, ob sich der Client zum Startzeitpunkt innerhalb oder außerhalb des Unternehmensnetzwerks befindet.

Wichtig:

Wenn es in Ihrer Umgebung neben On-Premises-VDAs auch Citrix DaaS Standard für Azure gibt und Sie die direkte Workloadverbindung konfigurieren, schlägt der Start im internen Netzwerk fehl.

Die Ressourcenstarts von Remote Browser Isolation, Citrix Virtual Apps Essentials und Citrix Virtual Desktops Essentials werden immer über das Gateway geleitet. Bei diesen Starts kommt es daher zu keiner Leistungsverbesserung durch die direkte Workloadverbindung.

Anforderungen

Netzwerkanforderungen

• Das Unternehmensnetzwerk und Gast-WiFi-Netzwerke müssen separate öffentliche IP-Adressen haben. Wenn Ihr Unternehmens- und Gastnetzwerk dieselbe öffentliche IP-Adresse verwendet, können Benutzer im Gastnetzwerk keine DaaS-Sitzungen starten.
• Verwenden Sie die öffentlichen IP-Adressbereiche der Netzwerke, von denen aus interne 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.
• Obwohl sich VDAs normalerweise in Ihrem On-Premises-Netzwerk befinden, können Sie auch VDAs verwenden, die in einer öffentlichen Cloud wie Microsoft Azure gehostet werden. Für den Start von Clients muss eine Netzwerkroute zum Kontakt der VDAs vorliegen, die nicht von einer Firewall blockiert wird. Dies erfordert einen VPN-Tunnel vom On-Premises-Netzwerk zu einem virtuellen Netzwerk, in dem sich die VDAs befinden.

TLS-Anforderungen

TLS 1.2 muss in PowerShell aktiviert sein, wenn Sie Ihre Netzwerkspeicherorte 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.
• Citrix DaaS ist unter Workspacekonfiguration > Serviceintegrationen aktiviert.

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

Wenn Ihre Abonnenten die Citrix Workspace-App für HTML5 zum Starten von Apps und Desktops verwenden, empfiehlt Citrix, auf den VDAs im internen Netzwerk TLS zu konfigurieren. Das Konfigurieren von TLS-Verbindungen für Ihre VDAs ermöglicht Direktstarts auf den VDAs. Ohne aktivierte TLS auf VDAs müssen App- und Desktopstarts über ein Gateway geleitet werden, wenn Abonnenten die Citrix 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.

Netzwerkspeicherorte über die GUI hinzufügen

Die Konfiguration einer direkten Workloadverbindung über Citrix Cloud umfasst das Erstellen von Netzwerkspeicherorten unter Verwendung der öffentlichen IP-Adressbereiche jedes Zweigstandorts, von dem aus sich interne Benutzer verbinden.

1. Wählen Sie in der Citrix Cloud-Konsole Netzwerkspeicherorte.

2. Klicken Sie auf Netzwerkspeicherort hinzufügen.

3. Geben Sie einen Namen und einen öffentlichen IP-Adressbereich für den Netzwerkspeicherort ein.

   

4. Klicken Sie auf Speichern.

5. Wiederholen Sie diese Schritte für jeden Netzwerkspeicherort, den Sie hinzufügen möchten.

Hinweis:

Tags für den Ort sind für die direkte Workloadverbindung nicht erforderlich, da der Konnektivitätstyp immer Intern ist. Das Feld Tags für den Ort ist nur dann auf der Seite Netzwerkspeicherort hinzufügen sichtbar (Citrix Cloud > Netzwerkspeicherort > Netzwerkspeicherort hinzufügen > Tags für den Ort), wenn die Funktion “Adaptiver Zugriff” aktiviert ist. Einzelheiten siehe Adaptiven Zugriff aktivieren.

Ändern oder Entfernen von Netzwerkspeicherorten

1. Wählen Sie in der Citrix Cloud-Konsole im Hauptmenü Netzwerkspeicherorte.

2. Suchen Sie den gewünschten Netzwerkspeicherort und klicken Sie auf die Auslassungspunkte.

   

3. Wählen Sie einen der folgenden Befehle:
   • Bearbeiten, um die Netzwerkadresse zu ändern. Nachdem Sie die Änderungen vorgenommen haben, klicken Sie auf Speichern.
   • Löschen, um den Netzwerkspeicherort zu entfernen. Wählen Sie Ja, löschen, um den Löschvorgang zu bestätigen. Sie können diese Aktion nicht rückgängig machen.

Netzwerkstandorte mit PowerShell hinzufügen und ändern

Statt der Citrix Cloud-Verwaltungskonsole können Sie das PowerShell-Skript verwenden, um die direkte Workloadverbindung zu konfigurieren. Die Konfiguration der direkten Workloadverbindung mit PowerShell umfasst die folgenden Aufgaben:

1. Bestimmen Sie die öffentlichen IP-Adressbereiche der einzelnen Zweigstellen, von denen interne 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 (NLS) 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 Netzwerkspeicherorten 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. Weitere Informationen finden Sie unter ICA-Dateiprotokollierung in diesem Artikel.

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 Netzwerkspeicherorte für Ihre VDAs einrichten.

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

Erforderliche Konfigurationsdetails

Zum Einrichten Ihrer Netzwerkspeicherorte 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 Clients 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 Clients

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.

   

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.

   

Konfigurieren von Netzwerkstandorten

1. Öffnen Sie ein PowerShell-Befehlsfenster und gehen 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 Clients 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 Netzwerkspeicherort 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 -internal $True
   

   Um keinen Bereich, sondern eine einzelne IP-Adresse anzugeben, fügen Sie /32 am Ende der IP-Adresse hinzu. Beispiel:

   New-NLSSite -name "YourSiteName" -tags @("YourTags") -ipv4Ranges @("PublicIpOfYourNetworkSite/32") -longitude 12.3456 -latitude 12.3456 -internal $True
   

   Wichtig:

   Wenn Sie den Befehl New-NLSSite verwenden, müssen Sie für jeden Parameter mindestens einen Wert einfügen. Wenn Sie diesen Befehl ohne Befehlszeilenargumente ausführen, werden Sie von PowerShell aufgefordert, für jeden Parameter nacheinander die entsprechenden Werte einzugeben. Die Eigenschaft internal ist eine erforderliche boolesche Eigenschaft mit den möglichen Werten $True oder $False, die über PowerShell der Benutzeroberfläche zugeordnet werden. Beispiel: (UI) Network Internal -> (PowerShell) –internal=$True.

   Wenn der Netzwerkspeicherort erfolgreich erstellt wurde, werden im Befehlsfenster die Details des Netzwerkspeicherorts angezeigt.

6. Wiederholen Sie Schritt 5 für alle Netzwerkspeicherorte, 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.

Ändern von Netzwerkspeicherorten

Ändern eines Netzwerkspeicherorts:

1. Listen Sie alle vorhandenen Netzwerkspeicherorte in einem PowerShell-Befehlsfenster auf: Get-NLSSite

2. Zum Ändern des IP-Bereichs für einen bestimmten Netzwerkspeicherort geben Sie ein:

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

   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] | Set-NLSSite -ipv4Ranges @("98.0.0.1/32","141.43.0.0/24")

Entfernen von Netzwerkspeicherorten

Wenn Sie Netzwerkspeicherort entfernen müssen, die Sie nicht mehr verwenden, gehen Sie folgendermaßen vor:

1. Listen Sie alle vorhandenen Netzwerkspeicherorte in einem PowerShell-Befehlsfenster auf: Get-NLSSite
2. Um alle Netzwerkspeicherorte zu entfernen, geben Sie ein: Get-NLSSite | Remove-NLSSite
3. Um bestimmte Netzwerkspeicherorte 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

Ü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 DaaS-Konsole an.
• Überprüfen Sie mit der ICA-Dateiprotokollierung die korrekte Adressierung der Clientverbindung.

Citrix DaaS-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.

Wird UDP in der DaaS-Konsole nicht angezeigt, müssen Sie die Richtlinie “Adaptiver HDX-Transport” für die VDAs aktivieren.

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.

Direkte VDA-Verbindungen

Bei einer Direktverbindung zum VDA enthält die Eigenschaft Address die IP-Adresse und den Port des VDA.

Dies ist ein Beispiel für eine ICA-Datei, wenn ein Client eine Anwendung über NLS startet:

[Notepad++ Cloud]
Address=;10.0.1.54:1494
SSLEnable=Off
<!--NeedCopy-->

Die Eigenschaft SSLProxyHost ist in dieser Datei nicht vorhanden. Diese Eigenschaft ist nur für Starts über ein Gateway enthalten.

Gateway-Verbindungen

Bei Gateway-Verbindungen enthält die Eigenschaft Address das STA-Ticket von Citrix Cloud. Die Eigenschaft SSLEnable ist auf Ein festgelegt und die Eigenschaft SSLProxyHost enthält den FQDN und Port des Gateways.

Dies ist das Beispiel einer ICA-Datei, wenn ein Client über den Citrix Gateway Service verbunden ist und eine Anwendung startet:

[PowerShell ISE Cloud]
Address=;40;CWSSTA;027C02199068B33889A40C819A85CBB4
SSLEnable=On
SSLProxyHost=global.g.nssvcstaging.net:443
<!--NeedCopy-->

Dies ist das Beispiel einer ICA-Datei, wenn ein Client über ein On-Premises-Gateway verbunden ist und eine Anwendung über ein On-Premises-Gateway startet, das innerhalb des Ressourcenstandorts konfiguriert ist:

[PowerShell ISE Cloud]
Address=;40;CWSSTA;027C02199068B33889A40C819A85CBB5
SSLEnable=On
SSLProxyHost=onpremgateway.domain.com:443
<!--NeedCopy-->

Hinweis:

Virtuelle On-Premises-Gatewayserver, die zum Starten virtueller Apps und Desktops verwendet werden, müssen virtuelle VPN-Server sein, keine virtuellen nFactor-Authentifizierungsserver. Virtuelle nFactor-Authentifizierungsserver dienen nur der Benutzerauthentifizierung und nicht als Proxy für den HDX- und ICA-Startdatenverkehr.

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

$clientId = "XXXX" #Replace with your clientId
$clientSecret = "YYY"    #Replace with your clientSecret
$customer = "CCCCCC"  #Replace with your customerid

# Connect to Network Location Service
Connect-NLS -clientId $clientId -clientSecret $clientSecret -customer $customer

# Create a new Network Location Service Site (Replace with details corresponding to your branch locations)
New-NLSSite -name "New York" -tags @("EastCoast") -ipv4Ranges @("1.2.3.0/24") -longitude 40.7128 -latitude -74.0060 -internal $True

# Get the existing Network Location Service Sites (optional)
Get-NLSSite

# Update the IP Address ranges of your first Network Location Service Site (optional)
$s = (Get-NLSSite)[0]
$s.ipv4Ranges = @("1.2.3.4/32","4.3.2.1/32")
\$s | Set-NLSSite

# Remove all Network Location Service Sites (optional)
Get-NLSSite | Remove-NLSSite

# Remove your third site (optional)
\(Get-NLSSite)\[2] | Remove-NLSSite

Problembehandlung

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 Netzwerkspeicherorte müssen Sie die öffentlichen IP-Adressbereiche des Netzwerks verwenden, von dem aus Ihre internen Benutzer eine Verbindung zum Internet herstellen. Weitere Informationen finden Sie unter Anforderungen in diesem Artikel.

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 richtige öffentliche IP-Adresse verwenden, von denen Ihre internen Benutzer eine Verbindung zum Workspace herstellen. Die auf der NLS-Site aufgeführte öffentliche IP-Adresse muss der Adresse entsprechen, die der Client, der Ressourcen startet, für den Zugriff auf das Internet verwendet. Um die korrekte öffentliche IP-Adresse für den Client zu erhalten, melden Sie sich an der Clientmaschine an, öffnen dann eine Suchmaschine und geben dort “what is my ip” in die Suchleiste ein.

Alle Clients, die Ressourcen innerhalb desselben Bürostandorts starten, greifen in der Regel über dieselbe ausgehende öffentliche IP-Adresse im Netzwerk auf das Internet zu. Für diese Clients muss eine Internetnetzwerkroute zu den Subnetzen mit den VDAs vorliegen, die nicht durch eine Firewall blockiert wird. Weitere Informationen finden Sie unter Anforderungen in diesem Artikel.

Fehler beim Ausführen von PowerShell-Cmdlets auf Nicht-Windows-Plattformen

Wenn beim Ausführen von Cmdlets mit den richtigen Parametern in PowerShell Core Fehler auftreten, stellen Sie sicher, dass der Vorgang erfolgreich ausgeführt wurde. Wenn beispielsweise beim Ausführen des Cmdlets “New-NLSSite” Fehler auftreten, führen Sie Get-NLSSite aus, um zu prüfen, ob die Site erstellt wurde. Beim Ausführen dieser Cmdlets unter macOS oder Linux mit PowerShell Core werden evtl. Fehler gemeldet, obwohl der Vorgang erfolgreich ausgeführt wurde.

Wenn das Problem beim Ausführen von Cmdlets mit den richtigen Parametern unter Windows mit PowerShell auftritt, stellen Sie sicher, dass Sie die neueste PowerShell-Modulversion verwenden. Bei Verwendung der neuesten Version des PowerShell-Moduls tritt dieses Problem unter Windows nicht auf.

Zusätzliche Hilfe und Unterstützung

Bei Fragen oder Problemen wenden Sie sich bitte an Ihren Citrix Vertriebsmitarbeiter oder an den Citrix Support.