Zscaler

【SSE】[Zscaler] [ZIA] [設計] [全体] Z-Tunnel1.0とZ-Tunnel2.0の違いと設定

buffoon

はじめに

Z-Tunnel 1.0やZ-Tunnel 2.0はどちらもZCC(Zscaler Client Connector)が通信をPSEへ転送するための方式ですが、実際に設計・運用を行う上では、単純に「1.0」「2.0」の違いだけを理解していても十分ではありません。

重要になるのは、「通信がどのような経路でPSEへ転送されるのか」「PACファイルがどこで評価されるのか」という点です。

特に既存の社内プロキシやオンプレミス環境と共存させる場合、この違いを理解しているかどうかで設計のしやすさが大きく変わります。

本記事では、Z-Tunnel 1.0とZ-Tunnel 2.0の違いと、それぞれで利用されるPACファイルの役割について解説します。

ZCCでは2種類のPACファイルを利用できる

一般的なPACファイルは、「どのプロキシへ通信を送るのか」をブラウザやOSへ指示するためのものです。

一方、ZCCでは用途の異なる2種類のPACファイルを利用できます。

  • Forwading Profileで設定できるPACファイル(以降、Forwarding PACと呼びます)
  • App Profileで設定できるPACファイル(以降、Custom PACと呼びます)

Forwarding PAC

Forwarding PACは、ブラウザやOSへ配布される一般的なPACファイルです。

どの通信をZCCへ転送するのかを決定します。

  • 社内システムはDirect
  • 一部システムは社内プロキシ
  • インターネット通信はZCCへ転送

通常のPACファイルとの違いは、ZIAの提供するPACファイルをインターネット上で管理する機能(Hosted PAC Files)と組み合わせることにより、Zscaler専用のPAC変数を利用できる点です。

この組み合わせによって、後述するZCC内部に存在するListening Proxyに転送する通信を指定することができます。

Custom PAC

Custom PACは、Listening Proxy上で評価されるPACファイルです。

Forwading PACと同様に Hosted PAC Files機能と組み合わせることにより、Zscaler専用のPAC変数を利用でき、Zscalerに最適化された転送設定が可能です。

通信がListening Proxyへ到達した後、以下を制御します。

  • 社内システムへのバイパス
  • 社内プロキシへの転送
  • 転送先のPublic Service Edge(POP)の選択

つまり、Forwarding PACが「どの通信をZCCへ渡すか」を決めるPACであるのに対し、Custom PACは「ZCCが受け取った通信をどのように転送するか」を決めるPACと言えます。

Z-Tunnel1.0ではListening Proxyが中心となる

Z-Tunnel1.0では、端末上でListening Proxyと呼ばれる仮想プロキシが動作します。

Web通信は一度Listening Proxyへ到達し、その後Zscalerへ転送されます。

そのため、Listening Proxy上で評価されるCustom PACが重要な役割を担います。

Tunnel1.0モード

Z-Tunnel1.0には、

  • Tunnel1.0
  • Tunnel with Local Proxy

という2つのモードがあります。

Tunnel1.0

まず通常のTunnel1.0では、ブラウザからの通信は強制的にListening Proxyへ転送されます。

つまり、Forwarding PACは評価されません。

例えばPACファイルへ「DIRECT」と記載していても、Listening Proxyへ転送されます。

その後、Listening Proxy上でCustom PACが評価され、

  • 社内システム
  • バイパス通信
  • 利用するPublic Service Edge

などが決定されます。

Tunnel with Local Proxy

一方、Tunnel with Local Proxyでは動作が異なります。

まずForwarding PACが評価され、ZCCへ転送する通信のみListening Proxyへ送られます。この時、ZCCへ転送する通信についてはPACファイル内、return文に「ZAPP_LOCAL_PROXY」という宣言が必要です。

その後、Listening Proxy上でCustom PACが評価され、最終的な転送先POPなどが決定されます。

つまり、Tunnel with Local ProxyではForwarding PACとCustom PACの両方が利用されます。

Z-Tunnel2.0ではデフォルトでListening Proxyを利用しない

Z-Tunnel2.0ではデフォルトでListening Proxyは利用されません。

Web通信・非Web通信ともに、ZCCから直接Public Service Edgeへ転送されます。

そのため、Web通信ではCustom PACは評価されません。

非Web通信はプライベートIP宛をデフォルトでバイパスする

まず前提として整理したいのが、非Web通信の動作です。

Z-Tunnel2.0は非Web通信にも対応していますが、すべての通信を無条件でZscalerへ転送するわけではありません。

デフォルトでは、RFC1918で定義されるプライベートIPアドレス宛の非Web通信はZ-Tunnel2.0の対象外となり、ローカルネットワークへ直接転送されます。

そのため、Active Directoryやファイルサーバ、社内DNS、社内アプリケーション 等への通信は、特別な設定をしなくても従来どおり社内ネットワークへ到達できます。

一方で、Web通信については動作が異なります。

Web通信はListening Proxyを利用しない限りCustom PACが評価されないため、社内Webシステムや既存プロキシとの共存を考える場合は、次に紹介する設定が重要になります。

社内環境ではListening Proxyを有効にするケースが多い

既存の社内環境と共存する場合、デフォルト設定ではWeb通信に対する柔軟な制御が不足するケースがあります。

そのため、以下2つのオプションを有効にする構成がよく採用されます。

  • Redirect Web Traffic to Zscaler Client Connector Listening Proxy
  • Use Z-Tunnel 2.0 for Proxied Web Traffic

Redirect Web Traffic to Zscaler Client Connector Listening Proxy

このオプションは、Web通信をListening Proxyへ転送するための設定です。

有効化することで、Custom PACが評価されるようになります。

つまり、Z-Tunnel1.0と同様に、

  • 社内Webシステム
  • 社内プロキシ
  • バイパス通信

などをCustom PACで制御できるようになります。

Use Z-Tunnel 2.0 for Proxied Web Traffic

こちらは、Listening ProxyからPublic Service Edgeへ転送する際のトンネル方式を変更する設定です。

通常はZ-Tunnel1.0でカプセル化されますが、このオプションを有効にするとZ-Tunnel2.0(DTLS)で通信するようになります。

機能面での違いはほとんどありませんが、DTLSによる性能向上が期待できるためListening Proxyを利用する場合は合わせて有効化することをおすすめします。

Z-Tunnel1.0とZ-Tunnel2.0の違い

両者の違いをまとめると以下のようになります。

項目Z-Tunnel1.0Z-Tunnel2.0
Listening Proxy標準で利用デフォルトでは利用しない
Forwarding PACTunnel with Local Proxyで利用不要(ZCC version3.7以下は必要)
Custom PAC利用Listening Proxy有効時のみ利用
Web通信対応対応
非Web通信対象外対応(RFC1918宛はデフォルトでバイパス)
トンネル方式TLSTLS / DTLS

設計で重要なのは社内環境との共存

ここまで紹介した内容を見ると、Z-Tunnel2.0の方が新しく、高性能な方式であることが分かります。

しかし、設計では性能だけで判断することはできません。

企業ネットワークには、社内プロキシ、VPN、Active Directory、社内Webシステム、PACファイル既存 等 既存環境との共存が求められます。

そのため、

Listening Proxyを利用するのか、

Forwarding PACをいつ評価するのか、

Custom PACをどのように設計するのか、

といった点が非常に重要になります。

特にZ-Tunnel2.0では、非Web通信はプライベートIP宛をデフォルトでローカルへ転送しますが、Web通信はListening Proxyを有効にしなければCustom PACによる柔軟な制御ができません。

この違いを理解していないと、「非Web通信は社内へ到達できるのに、社内WebシステムだけZscalerへ転送されてしまう」といった設計上の問題に直面することがあります。

つまり、Z-Tunnel1.0とZ-Tunnel2.0の違いは、トンネル方式ではなく、既存環境へどのように適合させるかという設計思想の違いと言えるでしょう。

おわりに

本記事では、Z-Tunnel1.0とZ-Tunnel2.0の違いと、PACファイルの役割について紹介しました。

以下、振り返りとまとめです。

  • ZCCにはForwarding PACとCustom PACという2種類のPACファイルが存在すること
  • Z-Tunnel1.0とZ-Tunnel2.0ではListening Proxyの扱いが異なること
  • Z-Tunnel2.0では非Web通信はRFC1918宛をデフォルトでローカルへ転送する一方、Web通信はListening Proxyを利用しない限りCustom PACが評価されないこと
  • 社内環境との共存を考える上では、PACファイルとListening Proxyの理解が欠かせないこと

➡【次の記事へ】【SSE】[Zscaler] [ZIA] [設計] [全体] トラフィックフロー解説

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

管理人
管理人

自称SASEエンジニアです。 2児の父親をやりながら、日々エンタープライズ向けの次世代ネットワークインフラと格闘しています。一日一投稿を目標に投稿頑張りますので、是非読んでください!
記事URLをコピーしました