- はじめに
- 1. 設定の全体像
- 2. カスタムアプリケーションの作成
- 3. プローブタイプの選択
- 4. Web Probeの設定
- 5. Cloud Path Probeの設定
- 6. 設定後の確認
- 7. まとめ
- おわりに
はじめに
こんにちは、エーピーコミュニケーションズ iTOC事業部 BzD部 0-WANの片桐です。
ZDX連載の第3回です。前回の前編では、Cloud Path Probeの仕組みとダッシュボードの読み方を解説しました。
今回はいよいよ手を動かすフェーズです。ZDX上でカスタムアプリケーションを作成し、Web ProbeとCloud Path Probeを実際に設定する手順をウォークスルーで解説します。
今回の監視対象は、弊社APC（エーピーコミュニケーションズ）の公式サイト（https://www.ap-com.co.jp）です。認証不要のWebサイトなので、シンプルにプローブの設定フローを確認できます。
注意事項： 本記事は筆者個人の技術的な知見と検証に基づいた内容です。弊社の公式見解や性能保証を示すものではありません。正確な仕様や最新情報については、Zscaler公式ドキュメントをご確認ください。
1. 設定の全体像
カスタムアプリケーションの監視を始めるまでの流れは以下のとおりです。
- カスタムアプリケーションの作成：監視対象のアプリケーションをZDXに登録する
- プローブタイプの選択：Web ProbeとCloud Path Probeを選択する
- Web Probeの設定：アプリケーションの可用性を監視するプローブを構成する
- Cloud Path Probeの設定：ネットワーク経路を可視化するプローブを構成する
Cloud Path ProbeにはWeb Probeの宛先に追従する設定があるため、Web Probe → Cloud Path Probeの順で作成すると効率的です（詳しくはセクション5で解説します）。
2. カスタムアプリケーションの作成
ZDX Admin Portalの Configuration から Add Application をクリックします。
- Name：今回は
AP Corp Siteとしました。プローブ名と関連付けやすい命名にしておくと管理しやすくなります - Application Type：
Customを選択します
StatusはこのタイミングではDisable固定です。プローブの設定完了後にEnableへ切り替えます。
入力が済んだら Add をクリックしてアプリケーションを登録します。
3. プローブタイプの選択
作成したアプリケーションから Add Probe をクリックし、End User Web と End User Cloud Path の両方にチェックを入れて Next をクリックします。
両方を選択すると、Web Probe → Cloud Path Probeの順にウィザード形式で設定が進みます。
4. Web Probeの設定
4-1. General / Probing Criteria / Exclusion Criteria
Nameは AP Corp Site - Web としました。StatusはDisableのまま、Run Frequencyは5分です。
Probing Criteria（対象条件）とExclusion Criteria（除外条件）は、検証用であればデフォルト（All / None）のままで問題ありません。本番環境ではユーザーグループや拠点を絞り込むことで不要なプローブトラフィックを抑えられます。なお、CollectionレベルでProbing Criteriaが定義されている場合、プローブレベルの設定は無視される点に注意してください。
4-2. Additional Parameters（詳細パラメータ）
ここがWeb Probe固有の設定です。設定項目は多いですが、実際に判断が必要なのは主に Destination URL、HTTP Response Status Codes、Follow Redirect の3つです。まず設定値の一覧を示し、そのあと判断ポイントを解説します。
| 項目 | 今回の設定値 | 備考 |
|---|---|---|
| Request Type | GET |
GETのみ対応（変更不可） |
| Destination URL | https://www.ap-com.co.jp/ |
判断ポイント① |
| Request Header | なし | 認証トークン等が必要な場合に設定 |
| HTTP Response Status Codes | 200-299, 304 |
判断ポイント② |
| Number of Attempts | 1（デフォルト） | |
| Timeout | 60秒（デフォルト） | |
| Follow Redirect | Enable | 判断ポイント③ |
| Maximum Redirects | 5（デフォルト） |
判断ポイント① Destination URL
URLの選び方は第1回でも触れましたが、ポイントは「認証の有無」です。認証が必要なアプリケーションの場合、ログインページのURLを指定し、Request Headerにトークン等を追加することで監視できます。認証不要のサイトであれば、今回のようにURLを入れるだけで完了です。
なお、URLのスキーム（http/https）やポート番号を変更すると、このWeb Probeに追従するCloud Path ProbeのTCPポートも自動的に更新されます。
判断ポイント② HTTP Response Status Codes
デフォルトで Successful responses (200-299) と 304 Not Modified が登録されており、多くのケースではこのままで問題ありません。
ただし、アプリケーションによっては注意が必要です。たとえば、SSO認証を経由するアプリケーションで認証前のリダイレクトレスポンス（302等）を正常とみなしたい場合や、特定のAPIエンドポイントが204 No Contentを返す場合など、アプリケーションの挙動に合わせてコードを追加・変更してください。
判断ポイント③ Follow Redirect
今回はEnableにしています。SSOリダイレクトがあるアプリケーションでは、これを有効にしないと最終的なレスポンスではなくリダイレクトレスポンスが記録されてしまいます。
ここまで設定したら Next をクリックして、Cloud Path Probeの設定に進みます。
5. Cloud Path Probeの設定
Web ProbeのSubmit後、Cloud Path Probeの設定画面に遷移します。
5-1. General（基本設定）
Nameは AP Corp Site - Cloud としました。
ここで注目したいのは Follow Web Probe です。有効にするとWeb Probeと同じ宛先を自動的に引き継ぐため、宛先の二重管理が不要になります。可用性の監視対象と経路の監視対象が異なる場合のみ、無効にしてCloud Path Hostに別の宛先を指定します。
今回は設定手順をすべてお見せするため、Follow Web Probe は有効にしていません。
Cloud Path ProbeにもProbing Criteria / Exclusion Criteriaの設定がありますが、今回はWeb Probeと同じ条件で進めます。
5-2. Additional Parameters（詳細パラメータ）
ここがCloud Path Probe固有の設定です。まず設定値の一覧を示し、そのあと判断ポイントを解説します。
| 項目 | 今回の設定値 | 備考 |
|---|---|---|
| Protocol | Adaptive |
判断ポイント① |
| TCP Port | 443（デフォルト） | Adaptive / TCP選択時に必要 |
| UDP Port | 33434（デフォルト） | Adaptive / UDP選択時に必要 |
| Packet Count | 5（デフォルト） | 範囲：3〜20。ZPA環境では3〜6推奨 |
| Interval (ms) | 1,000（デフォルト） | 範囲：1,000〜10,000 |
| Timeout (ms) | 1,000（デフォルト） | 範囲：500〜5,000。ZPA環境では500推奨 |
| Cloud Path Host | www.ap-com.co.jp | 判断ポイント② |
| Force Reverse Cloud Path | 無効 | 判断ポイント③ |
判断ポイント① Protocol
前編で解説したとおり、Adaptive Modeは各区間で最適なプロトコルを自動選択するモードで、迷ったらこれを選んでおけば問題ありません。
ただし、ZPA経由のプライベートアプリケーションではAdaptive Modeは使えないため、その場合はICMP、TCP、UDPのいずれかを明示的に選択してください。
判断ポイント② Cloud Path Host
Follow Web Probeを有効にしている場合はWeb Probeの宛先が自動反映されます。5-1で触れたように、可用性の監視対象と経路の監視対象が異なる場合は、ここにIPアドレス（IPv4）またはFQDNを手動で入力します。
判断ポイント③ Force Reverse Cloud Path
信頼されたネットワーク内のファイアウォール等がフォワード方向のtracerouteをブロックしている場合、Force Reverse Cloud Path in Trusted Network を有効にできます。これにより、ZIA Public Service Edgeからエグレスに向けてリバース（逆方向）のtracerouteが実行されます。
通常の環境では不要ですが、「Cloud Pathの途中でホップが表示されない」といった場合に試してみる価値のあるオプションです。
パケット設定（Packet Count、Interval、Timeout）はデフォルト値から始めて、誤検知が多い場合や検知が遅い場合に調整するのが実践的です。
ここまで設定したら Next をクリックし、Reviewで内容を確認して Submit をクリックします。
6. 設定後の確認
アプリケーションの配下に2つのプローブが表示されます。この時点ではDisabled状態です。
アプリケーションのStatusを Enable に切り替えると、配下のプローブも自動的にEnabledになり、データ収集が始まります。
最初のデータがダッシュボードに反映されるまで数分〜15分ほど待つ必要があります。データが反映されたら、前編で解説したレイテンシグラフやHop Viewで結果を確認してみてください。
7. まとめ
本記事では、カスタムアプリケーションに対するWeb ProbeとCloud Path Probeの設定手順を解説しました。
- Web Probeを先に作成し、Cloud Path ProbeをFollow（追従）させるのが基本の流れ
- Web ProbeではDestination URLの選定とHTTP Response Status Codesのカスタマイズがアプリケーションごとの判断ポイント
- Cloud Path ProbeではAdaptive Modeを基本とし、ZPA環境のみプロトコルを明示的に指定
- パケット設定やタイムアウトはデフォルトから始め、運用しながら調整する
次回は、プローブが検知した異常を運用チームにプロアクティブに通知する——ZDXアラートについて解説します。
おわりに
私たち0-WANは、ゼロトラスト製品を中心とした、マルチベンダーでのご提案で、お客様の経営課題解決を支援しております。
「ゼロトラストってどうやるの？」「製品を導入したけれど使いこなせていない気がする」「ZDXを導入したいが、どこから手をつければいいか分からない」等々、どんな内容でも支援いたします。お気軽にご相談ください。
