Zscaler Internet Access Forwarding

Tunnel 2.0, GRE, PAC File, Tunnel 1.0, direkter Proxy Eintrag, IPSec oder doch eine Kombination der verschiedenen Forwarding-Möglichkeiten? Was ist denn Best Practice? Für welche Devices wird welche Methode benötigt? Vor dieser Frage stehen viele Proxy Administratoren und Security Officers wenn sie die Konfiguration von Zscaler planen oder ihre Konfiguration den aktuellen Möglichkeiten anpassen. Um etwas Licht ins Dunkel oder besser gesagt, etwas Licht am Horizont zu entfachen, werden folgend die verschiedenen Forwarding-Methoden und Kombinationsmöglichkeiten aufgezeigt.

Forwarding-Methoden

Die folgende Tabelle beinhaltet eine Kurzübersicht der Forwarding-Methoden und deren Einsatzmöglichkeiten.

Forwarding-Methode Beschreibung Devices Einsatzmöglichkeit
Direkter Proxy-Eintrag Der direkte Proxy-Eintrag kann in den Systemsettings des jeweiligen Devices gesetzt werden und wird für jeglichen proxy-fähigen Traffic verwendet. Clients, Server Verfügbarkeitstest Zscaler & Troubleshooting
PAC File Das PAC File Forwarding kann in den System-Settings durch beispielsweise GPO gesetzt werden. Es forwarded jeglichen Proxy PAC-fähigen Traffic Clients, Server Clients & Server Tests und Troubleshooting
PAC File in Kombination mit GRE oder IPSec Tunnel Das PAC File Forwarding kann in den System-Settings durch beispielsweise GPO gesetzt werden. Es forwarded jeglichen Proxy PAC-fähigen Traffic Clients, Server Clients & Server für Unternehmensstandorte
Zscaler Client Connector Tunnel with local Proxy Direktes Forwarding des Zscaler Traffics über lokalen Proxy für Proxy PAC-fähigen Traffic. Clients Clients in Kombination mit zusätzlichen Client-VPN-Lösungen
Zscaler Client Connector Tunnel Version 1.0 Transparentes Forwarding jeglichen HTTP/HTTPS Traffics auf Port 80 443 zu Zscaler. Clients Clients Windows, Linux & MacOS sowie Android und iOs
Zscaler Client Connector Tunnel Version 2.0 Transparentes Fowarding jeglichen Traffics zu Zscaler unabhängig von Ports und Protokollen. * Clients Clients Windows, Linux & MacOS sowie Android und iOS
GRE & IPSec Tunnels Transparentes oder explizites Forwarding von Traffic zu Zscaler via definiertem Routing auf dem GRE oder IPSec –fähigen Endpoint Device. Clients, Server, IoT, Guest Wifi Netze Server, IoT-Devices oder in Kombination mit Clients mit PAC Files.

*Es gibt einzelne Protokolle, die nicht über Zscaler Tunnel 2.0 gesendet werden können aufgrund deren Protokollaufbau.

Soweit so gut. Die Forwarding-Methoden sind nun bekannt, doch welche sollen nun verwendet werden?

Forwarding für mein Unternehmen

Welche Forwarding-Methode im Unternehmen verwendet werden soll, ist abhängig von der Infrastruktur des Unternehmens. Ebenso haben sich die Forwarding-Methoden bei Zscaler in den letzten Jahren stark entwickelt. Die folgenden zwei Beispiele zeigen verschiedene Einsatzmöglichkeiten für verschiedene Unternehmen auf.

Beispiel 1 – Unternehmen «Grüne Wiese»

Das Unternehmen grüne Wiese hat aktuell noch keine Security im Bereich von Proxies. Ebenfalls werden die Firewalls gerade durch neue Appliances ersetzt. Es soll Security für Clients (überall), Server und IoT-Devices erarbeitet werden.

In diesem Fall bietet sich das folgende Forwarding an:

    • Clients: Zscaler Client Connector mit Tunnel 2.0
    • Server: GRE Tunnel mit Source Based Routing oder falls ein PAC File gewünscht ist mit Destination Based Routing unter Verwendung von Global ZEN IP-Adressen
    • IoT: GRE Tunnel mit Source Based Routing

Dieses Forwarding bietet sich an, da durch die Verwendung des Zscaler Client Connectors Features wie Captive Portal Erkennung, die Authentisierung sowie das Traffic Forwarding auf den Clients für alle Ports und Protokolle gesteuert werden kann. Die Verwendung des GRE Tunnels für Server und IoT-Devices ermöglicht ein transparentes Forwarding zu Zscaler. Durch die Verwendung des GRE Tunnels können Vorteile, wie das Erstellen von Sublocations basierend auf internen IP-Adressen, verwendet werden.

Beispiel 2 – Unternehmen «VPN Produkt wird erst in 3 Jahren ersetzt»

Das Unternehmen VPN Produkt wird erst in 3 Jahren ersetzt, hat soeben ein VPN Produkt gekauft, welches kompatibel sein muss mit dem Zscaler Forwarding. Das Unternehmen hat keine IoT-Devices, dafür Server. Die Lokation des Kunden hat keine fixe Public IP-Adresse.

In diesem Fall bietet sich das folgende Forwarding an:

    • Clients: Zscaler Client Connector
      • On Trusted Network also Intern: Tunnel 2.0
      • VPN Trusted Network also mit VPN verbunden: Tunnel 2.0 falls möglich, sonst Tunnel with local Proxy
      • Off Trusted Network also als “RoadWarrior”: Tunnel 2.0
    • Server: IPSec Tunnel mit Source Based Routing oder falls ein PAC File gewünscht ist mit Destination Based Routing unter Verwendung von Global ZEN IP Adressen.

Dieses Forwarding bietet sich an, da durch die Verwendung des Zscaler Client Connectors die oben genannten Vorteile verwendet werden können. Für die On, VPN und Off Trusted Network kann entschieden werden, welche Forwarding-Methode verwendet werden soll. Der IPSec Tunnel bietet sich an, da dieser den Tunnelaufbau auch über FQDNs aufbauen kann. Der Vorteil der Sublocations ist ebenfalls gegeben. Dafür hat der IPSec Tunnel im Gegensatz zum GRE Tunnel nicht die gleichen Durchsatzmöglichkeiten (250-400 Mbps versus 1000 Mbps).

PAC File direkt oder via GRE

Bei beiden genannten Unternehmen stellt sich während der Implementation die Frage, soll das PAC File direkt oder via GRE/IPSec heruntergeladen werden?

Für die Beantwortung dieser Frage muss etwas ausgeholt werden. Wichtig zu wissen ist, dass der Zscaler Client Connector ebenfalls ein PAC File für das Traffic Forwarding beinhaltet. Was passiert nun, wenn der Zscaler Client Connector das PAC File via GRE Tunnel herunterladen müsste und der Tunnel hat einen Fehler und lässt sich nicht mehr verbinden? Genau, alle Clients mit einem Zscaler Client Connector sowie alle Server mit einem PAC File können das PAC File nicht mehr downloaden und können den Zugriff zu Zscaler und somit ins Internet verlieren. Den einfachsten Workaround für Clients und Server, das PAC File anzupassen, habe ich mir so verunmöglicht, da das PAC File für die Clients nicht verfügbar ist.

Aus diesem Grund empfiehlt es sich, dass das PAC File direkt heruntergeladen werden kann. Bei Servern ohne Zugriff auf das Internet kann ein allfällig verwendetes PAC File auch intern gehostet werden.

Global ZEN IP-Adressen und Destination Based Routing – Was ist das?

Da stand vorher noch etwas von Global ZEN IP-Adressen und Destination Based Routing. Diese beiden Schlagwörter gehören zum Forwarding PAC File mit IPSec oder GRE Tunnel. Zuerst die Erklärung zu den Global ZEN IP-Adressen. Diese IP-Adressen können in allen Zscaler Datacenters verarbeitet werden, jedoch sollen diese nur in Kombination mit einem GRE oder IPSec Tunnel verwendet werden. Zur Verwendung der Global ZEN IP-Adressen empfiehlt sich dann für das Routing in den GRE Tunnel ein Destination Based Routing. Durch das Setzen des Proxy-Eintrages auf die Global ZEN IP-Adresse im PAC File, kann der Traffic dann zu via Tunnel zu Zscaler geroutet werden.

Und wieso soll man das tun? Eine berechtigte Frage! Dieses Forwarding bietet den Vorteil, dass weltweit intern die gleichen PAC Files verwendet werden können. Weiter kann das Routing auf dem GRE oder IPSec-fähigen Device der jeweiligen Lokation im Grundsatz gleich eingerichtet werden, einfach auf andere Zscaler Datacenter. Dies verhilft zu einem einheitlichen Setup im Unternehmen. Ebenso können verschiedene Backup-Varianten in den PAC Files hinterlegt werden, die beispielsweise durch einen Tunnelwechsel ein Ansteuern eines anderen Zscaler Datacenters auslösen. Auch hier zeigt sich, dass es von Vorteil ist, wenn das PAC File direkt und nicht via den GRE oder IPSec Tunnel heruntergeladen wird.

Und nun? Ja, nun sollte das Licht am Horizont etwas heller scheinen.

UNCODE.initRow(document.getElementById(„row-unique-0“));

Der Beitrag Zscaler Internet Access Forwarding erschien zuerst auf Tec-Bite.