こんにちは、エーピーコミュニケーションズ 0-WANの山根です。
「いまのVPNをZPAへ置き換える」
「いまのプロキシをZIAへ切り替える」
言葉だけなら、とても単純に聞こえます。
しかし既存のVPNやプロキシは、長年の運用の中で多くのルール、例外、業務依存を抱えています。
誰も使っていないと思っていたバイパスが実は月末処理に必要だった。特定アプリケーションだけプロキシを経由しない。古いシステムがIPベースの通信を前提にしている。
こうした見えにくい依存関係が、移行を難しくします。
まず結論。難しいのは製品交換ではなく「既存の前提をほどくこと」
一言でいうと、
VPN/プロキシからZscalerへの移行では、既存設定をそのまま新製品へコピーするのではなく、現在の通信・例外・アプリケーション依存を把握し、「残す・変える・なくす」を判断しながら段階的に移行します。
ZIAでは通信転送方法が複数あり、既存プロキシを一時的にプロキシの多段接続でZscalerへつなぐ方式もあります。Zscaler公式ドキュメントでも、プロキシの多段接続は既存環境を活用しやすい一方、長期的な本番環境の構成としては推奨されないと説明されています。
ZPAでも、従来VPNのネットワークへのアクセスをそのまま再現するのではなく、ユーザーからのアクセスをアプリケーション単位で整理していくことが基本です。
つまり移行期には、新旧をどうつなぐかだけでなく、最終的にどんなアーキテクチャへ変えるかを同時に考えます。
プロキシ移行では「通信経路」と「例外」が積み重なっている
長く使われたプロキシには、PACファイル、バイパス、認証例外、特定アプリケーション向けの直接アクセスなどが残っていることがあります。
それらを理由も確認せず新環境へ移植すると、不要な例外まで引き継ぎます。
反対に「全部捨てる」と、業務アプリケーションが動かなくなるかもしれません。
そこで、
なぜこのルールがあるのか。誰が使うのか。今も必要か。新しい方式ではどう扱うか。
を確認します。
ZscalerのTraffic Forwarding Documentationでも、PAC、Client Connector、GRE/IPsec、プロキシの多段接続など複数方式にそれぞれ特徴があります。
移行では、既存環境の方式と新しい方式の役割を混同しないことが大切です。
VPN移行では「ネットワークへのアクセス」からアプリケーションを洗い出す
従来のリモートアクセスVPNでは、利用者がVPNへ接続すると、社内ネットワークの特定範囲へ通信できる経路が提供される構成があります。
もちろん、VPN接続後の通信をファイアウォールなどで制御することも可能です。
一方、ZPAでは、許可された利用者が必要なプライベートアプリケーションへアクセスするという考え方を基本とします。
この違いを踏まえ、VPNからZPAへの移行では、ネットワークの接続範囲だけでなく、実際に必要なアプリケーションと通信条件を整理することが重要です。
ZPAでは、許可するプライベートアプリをApplication Segmentとして整理し、ユーザーからアプリケーションへのポリシーを設計します。
そのためVPNゲートウェイだけをZPAへ置き換えるのではなく、
- ユーザーが実際に使うアプリケーション
- アプリケーションが必要とする通信
- DNSや名前解決
- ユーザー/グループごとのアクセス
- アプリケーション側の到達性
を整理する必要があります。
ZPA Leading Practicesでは、Application Discoveryを一時的に使って利用傾向を把握し、具体的なApplication Segmentときめ細かなポリシーへ移していく考え方も示されています。
つまり移行は、VPNのネットワークルールをZPAのポリシーへ翻訳する作業ではなく、アクセス単位をアプリケーションへ再整理する作業でもあります。
「一度に全部変えない」ための選択肢もある
移行中は、既存VPN/プロキシとZscalerを一定期間併用する場合があります。
ZPAには、従来型VPNからの移行を支援する機能として「VPN (for Legacy Apps)」があります。
これは、通常のZPAのアプリケーション単位のアクセスとは異なり、レイヤー3のIPベースの接続が必要な一部のレガシーアプリケーションなどを扱うための機能です。
ただし、通常のZPA接続と同じ構成で利用できるわけではありません。
利用には、対応するZscaler Client Connectorに加え、VPN Service Edge、Network Connector、対象ネットワークへのルーティングなど、専用の構成が必要になります。
また、すべての通信やアプリケーションを無条件に移行できるわけではないため、対応範囲や利用条件を事前に確認することが重要です。
移行時には、このような選択肢も検討しながら、将来的にどの通信をアプリケーション単位のアクセスへ移行し、どの例外を残すかを整理していきます。
また移行時には、問題が発生した場合に従来の構成へ切り戻す方法と手順も準備しておきます。切り戻せることを確認したうえで、小さな単位で移行を進めます。
次回は、同じ設計でもオフィス・自宅・海外では前提が変わる理由を扱います。
今回のポイント
- VPNやプロキシからの移行では、既存の通信経路、例外設定、業務上の依存関係を把握することが重要
- ZPAへの移行では、従来のネットワーク接続範囲をそのまま再現せず、利用者とアプリケーションの関係を整理する
- 一度にすべてを切り替えず、新旧環境の共存や切り戻しも含めて段階的に移行する
参考情報
- Zscaler公式：Choosing Traffic Forwarding Methods
- Zscaler公式：ZPA Leading Practices Guide
- Zscaler公式：Zero Trust User-to-App Segmentation with ZPA
- Zscaler公式：VPN (for Legacy Apps)
本記事の制作について
本記事では、一部図版の制作支援に生成AIを利用しています。技術内容については執筆者および0-WANエンジニアが確認・編集しています。
