株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

【Zscaler】ZPAでVPNを置き換える!#3 アプリケーション通信の流れ

こんにちは。ネットワールドSEの藤田です。

ZPAでVPNを置き換える!の第三回です。
今回はZPAがどのようにアプリケーションの通信を処理しているのか、ざっくりとご説明します。ZPAについてより具体的なイメージを持ってもらえれば幸いです。


【Zscaler】ZPAでVPNを置き換える!#1 ZPAが求められる理由 - ネットワールド らぼ
【Zscaler】ZPAでVPNを置き換える!#2 ユーザの操作感 - ネットワールド らぼ
【Zscaler】ZPAでVPNを置き換える!#3 アプリケーション通信の流れ - ネットワールド らぼ
【Zscaler】ZPAでVPNを置き換える!#4 アプリケーションの定義 - ネットワールド らぼ

免責事項

  • 本書は、株式会社ネットワールド(以下 弊社)が作成・管理します。
  • 本書の記載内容の一部または全部を弊社に無断で改変・転載することを禁じます。
  • 本書の記載内容は、一部または全部が将来予告無く変更されることがあります。
  • 本書の利用は、利用者様の責任において行われるものとします。
  • 本書の記載内容には、最善の注意を払っておりますが、正確性・完全性を保証するものではありません。従いまして、本書の利用によって生じたあらゆる損害に関して、弊社は一切の責任を負いかねます。

コンポーネントの確認

アプリケーション通信の流れを確認する前に、通過するコンポーネントを確認しておきましょう。まずは以下の図をご覧ください。

ZPAの処理は大きく3箇所に分かれます。

  1. Zscaler Client Connector(ZCC)
  2. Zero Trust Exchange(ZTE)
  3. App Connector

ZPAによるアクセスは、ZCC→ZTE→App Connector→アプリケーションと中継されます。この流れに沿ってどのような処理が行われているのか簡単に見ていきましょう。

① ZCCの処理

まずはZCCの処理からです。ZCCはZscaler各種サービスの統合クライアントソフトウェアでした。
【Zscaler】ZPAでVPNを置き換える!#2 ユーザの操作感 - ネットワールド らぼ

ZCCからZscaler社のサービス基盤であるZTEへトラフィックを転送しなければなりません。どのように対象となるアプリケーションだけを転送しているのでしょうか?

ユーザがWebアプリケーションへアクセスする例に沿って確認していきましょう。
HTTPSで「www.sample.test」へブラウザよりアクセスします。



STEP1

まず、ユーザがブラウザへURLを入力します。

STEP2

アクセス先であるFQDNの名前解決を実行します。
ZCCは、ZPAへ転送するアプリケーションの一覧、つまりFQDNとTCP/UDPポートの一覧を保持しています。DNSリクエストがこのアプリケーションの一覧のいずれかに該当する場合、ZCCがDNSレスポンスを返します。

ZCCで名前解決するIPアドレスは、100.64.0.0/16のレンジから返されます。これはRFCで定義されたISP Shared Address(100.64.0.0/10)に含まれる範囲です。CGNに利用される範囲を、ZPAは内部的に使用しています。ZPAではこれをSynthetic IPアドレスと呼びます。
https://help.zscaler.com/ja/zscaler-client-connector/zscaler-client-connector-processes-allowlist

STEP3

名前解決したSynthetic IPアドレスにHTTPS通信を開始します。この宛先はZPA宛の通信としてトンネルへ転送されます。

トンネルへ転送する仕組みはOSにより異なります。Windowsの場合、パケットフィルターベースで動作します。ルーティングテーブルに影響を与えず、該当するパケットを透過的にトンネルへ転送します。一方、その他のOSの場合、ルートベースの処理となります。つまり、トンネルへ転送する経路情報がルーティングテーブルへ追加される動作となります。そのため、該当するパケットはルーティングによりトンネルへ転送されます。

これでトンネル経由での転送は完了です。次はトンネルの先にあるZTEの処理です。

② ZTEの処理

次はZTEの処理です。

ZTEはZscaler社が管理しているプラットフォームです。Zscalerのサービスを利用する際はZTEへ接続する形となります。具体的にはPublic Service EdgeというコンポーネントがZCCからの接続を受け付けますが、一旦ここでは簡単にZscaler社のクラウド基盤でトラフィックを中継しているのだとご理解ください。

ZCCからと同様に、ZTEはアプリケーションが存在するインフラからもApp Connectorのトンネル接続を受け付けています。ZCCもApp Connectorも、アウトバウンドでZTEへ接続します。

ZTEはZCC、App Connectorからのトンネル接続を仲介し、アプリケーションの通信を中継する役割を担っています。

③ App Connectorの処理

最後はApp Connectorの処理です。

App Connectorは、プライベートネットワークに配置されたアプリケーションと通信を確立する役割を果たします。


STEP1

厳密にはこのタイミングとは限りませんが、話を簡略化するためにこの流れでご説明します。
クライアント(ZCC)は、アプリケーションのFQDNをSynthetic IPアドレスで名前解決しました。しかし、最終的にはアプリケーションの実IPアドレスを知らなければ通信ができません。その役割を果たすのがApp Connectorです。
App Connectorはアプリケーションが存在するプライベートネットワーク内に配置され、アプリケーションの名前解決を行います。

STEP2

これでアプリケーションの実IPアドレスがわかりましたので、後はアプリケーションへ通信を確立するだけです。これでZPA経由のアプリケーション通信が確立します。お疲れ様でした。


まとめ

今回はZPAによるアプリケーション通信の流れをご説明しました。次回からは個別の技術要素についてみていきたいと思います。ありがとうございました。