Write a commentDieser Artikel befasst sich mit den Citrix Cloud Network Lokationen Services (NLS) und erklärt, warum bei Citrix "Undefiniert" das Neue extern ist. Wer sich mit den Netzwerklokationen befasst, kommt vielleicht durcheinander, da das Wörding evtl. nicht ganz zutreffend ist, zumindest für mich.
Warum schreibe ich, dass das Undefiniert das neue Extern ist? Das klären wir gleich als Erstes: In den NLS Einstellungen kann ich intern und extern definieren, also z. B. meine Zentrale als intern und meine netzwerktechnisch nicht verbundene Niederlassung als extern. Technisch gesehen sind dies zwei feste IP-Adressen und meist die Firewall, über die die Kommunikation mit extern läuft. Alle anderen zig Millionen IP-Adressen sind dann undefiniert und nicht extern? Ja, aber genau das ist so bei den Citrix Network Lokationen Services und durchaus auch verständlich, wenn wir von der Definitionsseite das betrachten. Wir definieren IP-Adressen, die wir kennen, also uns bekannt sind und damit ist alles andere dann undefiniert, also auch logisch.
Es könnte auch so beschrieben werden:
Intern = Direkter Zugriff zwischen Citrix WorkspaceApp und Citrix VDA
Client -> VDA
Extern = Indirekter Zugriff (Gateway Service) zwischen Citrix WorkspaceApp und Citrix VDA, bekannten Ursprungs.
Firmen Client -> Gateway Service -> VDA
Undefiniert = Indirekter Zugriff (Gateway Service) zwischen Citrix WorkspaceApp und Citrix VDA, unbekannten Ursprungs.
Alle unbekannten Clients -> Gateway Service -> VDA
Mit diesen drei Definitionen gibt es auch drei Standard-Tags: LOCATION_internal, LOCATION_external und LOCATION_undefined. Diese TAGs können dann an verschiedenen Stellen zu Einsatz kommen.
Hier ein Beispiel für eingerichtete Network Locations:
Damit teilen sich die TAGs wie folgt auf
LOCATION_internal = HQ_DE und Azure_Amsterdam
LOCATION_external = BranchOffice_muenster,BranchOffice_mannheim,BranchOffice_luxemburg und BranchOffice_goettingen
LOCATION_undefined = Alles andere.
Diese TAGs können wir dann z.B. in Citrix Richtlinien verwenden und hier als Beispiel allen BranchOffice eine Richtlinie zuweisen oder allen unbekannten (undefined) das Client-Laufwerksverbinden verbieten.
Durch zusätzliche Location TAGs kann dann separate Richtlinien zugewiesen werden, da die Location BranchOffice_luxemburg noch den Location TAG "luxemburg" hat, kann dieser nur für den Standort Luxemburg verwendet werden, mit LOCATION_TAG_luxemburg. Somit können z.B. Richtlinien individuell zugewiesen werden.
Frage: Mein Unternehmen setzt Zscaler ein und damit einen cloudbasierten Proxy, um die Clients des Unternehmens zu schützen - Zero-Trust. Hierdurch wurden auch interne Clients zu einem LOCATION_undefined.
Antwort: Hier sollten Ausnahmen, Bypass oder wie immer die Lösung es nennt verwendet werden. Mit der Ausnahme *.cloud.com wäre dann ein Anfang gemacht.
