Die Zscaler Client Connector Version 3.8? Aber die ist ja schon veraltet und Zscaler hat bereits die Version 4.2.0.198 released. Wieso soll diese nun so spannend sein? Die Zscaler Version 3.8 ist so spannend, weil Zscaler in dieser Version neue Features für die Forwarding-Möglichkeiten bei Zscaler implementiert hat. Es handelt sich dabei um die beiden Funktionen «Redirect Web Traffic to Zscaler Client Connector Listening Proxy» und «Use Z-Tunnel 2.0 for Proxied Web Traffic». Doch was können diese beiden Features und was wird geändert? Genau das wird in diesem Blogeintrag vertieft aufgezeigt.
Wo ist das Feature zu finden und was macht es?
Beide Features sind im Zscaler Client Connector GUI unter Administration | Forwarding-Profil im Forwarding-Profil ersichtlich, wenn das Forwarding auf «Tunnel» gestellt und nachdem der «Z-Tunnel 2.0» ausgewählt wurde, im Dropdown-Menü «Z-Tunnel 2.0 Transport Settings» zu finden.
Nachdem nun bekannt ist, wo diese Features eingestellt werden können, widmen wir uns der Beschreibung der beiden Features.
Redirect Web Traffic to Zscaler Client Connector Listening Proxy:
Die Zscaler-Beschreibung dieses Settings beinhaltet, dass bei der Aktivierung dieses Features der gesamte Traffic auf Port 80/443 auf den Zscaler Listening Proxy geforwarded wird.
«Use Z-Tunnel 2.0 for Proxied Web Traffic»: Die Zscaler-Beschreibung dieses Features besagt, dass Traffic auf dem Zscaler Client Connector Listening Proxy via Z-Tunnel 2.0 nach Zscaler gesendet wird. Ansonsten wird dieser Traffic via den Z-Tunnel 1.0 zu Zscaler gesendet.
Nachdem nun die Beschreibung der Features bekannt ist, widmen wir uns deren Funktionalität.
Funktion der beiden Features
Um die Funktionalität der beiden Features verstehen zu können, muss zuerst die Funktionsweise des Forwarding des Zscaler Client Connectors verstanden werden.
Vor der Zscaler Version 3.8 war die vereinfachte Funktionsweise für das Forwarding wie folgt. Wenn ein Request von einem Browser kam, so wurde als Erstes im Forwarding-Profil überprüft, ob der Tunnel 2.0 «ge-bypasst» werden soll oder nicht. Wenn der Traffic via den Tunnel 2.0 gehen sollte, so wird der Traffic als Nächstes im App-Profil über die Tunnel 2.0 Configuration «Destination Exclusions» und «Destination Inclusions» geprüft. Sofern der Datenverkehr die «Destination Inclusions» matcht, wird der Traffic anhand des App-Profils PAC-File zu Zscaler weitergeleitet.
Wenn der Traffic einen Bypass vom Tunnel 2.0 aufweist, so wird dieser direkt an den Zscaler Client Connector Listening Proxy geforwardet. Danach wird dieser anhand des App-Profils «DIRECT» oder via Z-Tunnel 1.0 zu Zscaler weitergeleitet.
Mit der Version 3.8 kam das neue Forwarding, das vereinfacht, wie folgt funktioniert: Der Traffic wird neu vom Browser direkt anhand der LWF Table, also die Zscaler Z-Tunnel 2.0 Configuration analysiert. Matcht der Traffic die «Destination Inlcusions», kann über das Feature «Redirect Web Traffic to ZCC Listening Proxy» der Web Traffic (gemäss Hilfeseite von Zscaler) auf Port 80 und 443 zu Zscaler weitergeleitet werden. Dieser Traffic wird dann als Nächstes über das App-Profil PAC-File analysiert. Soll gemäss PAC-File der Traffic zu Zscaler gehen, kann mit dem Feature «Use Z-Tunnel 2.0 for Proxied Web Traffic» der Traffic anstatt via Z-Tunnel 1.0 über Z-Tunnel 2.0 zu Zscaler gesendet werden.
Und was ist nun der Vorteil davon?
Vorteile der beiden Features
Beim Durchlesen der beiden Funktionsweisen fällt auf, dass mit den neuen Settings nur ein PAC-File verwendet wird und das ist das App-Profil PAC-File. Somit vereinfacht sich hierbei die Administratorkonfiguration auf Zscaler-Seite. Weiter können mit den neuen Features wieder Fiddler- / «Charles Proxy»-Mitschnitte erstellt werden. Auch können durch die Verwendung des Z-Tunnel 2.0 mit DTLS in der richtigen Konfiguration Performanceverbesserungen erreicht werden. Eine Ausnahme davon ist, wenn der Provider DTLS Traffic blockiert. Da müsste weiterhin TLS für den Z-Tunnel 2.0 verwendet werden. Wobei auch in dieser Konfiguration mit den neuen Features eine Performanceverbesserung stattfinden kann.
Gibt es auch Nachteile?
Nachteile der beiden Features
Wenn die Features nicht korrekt konfiguriert eingesetzt werden, so kann dies Auswirkungen haben auf die Performance und somit auf die Benutzerzufriedenheit. Ansonsten sind uns aktuell keine Nachteile der beiden Features bekannt.
Was heisst das nun?
Als Erstes: Die alte Konfiguration mit zwei PAC-Files (Forwarding und App-Profil PAC-File) funktioniert auch weiterhin. Also nach der Version 3.8 und ohne die Verwendung der beiden Features. Bei der Verwendung der beiden Features ab der Version 3.8, ist es wichtig die Konfiguration auf die neuen beiden Features auszurichten, sodass keine Nachteile entstehen.
Weiterführende Links:
