オーケストレーションされた導入ワークフロー
この項では、オーケストレーションされた統合を実行するために必要な設定について説明します。
Aruba CentralとZscaler Internet Access間のオーケストレーション
オーケストレーションを行うためには、最初のステップは、APIを介してAruba CentralとZIAの間の通信を可能にすることです。これにより、CentralはZscaler内の場所を定義したり、最適なサービスエッジをクエリしたりできるようになります。
Aruba CentralとZscaler間のAPI通信の確立
APIアクセス用にZscalerを設定する
Aruba SD-Branchのパートナーキーを追加するには、次の手順を実行します。
Step 1 Zscaler管理ポータルにログインします。
Step 2 ZIAポータルのパートナー統合ページで**Administration > Partner Integrations > SD-WAN **をクリックします。
“Add Partner Key”をクリックします。パートナーキーを作成します。
Step 3 パートナー管理者ロールを作成して、APIアクセスの資格情報を指定します。これは、 Administration > Role Managementから行います。
Step 4 最近作成したロールを使用して、Aruba Centralのパートナーアカウントを作成します。これは、Administration > Administrator Management から実行できます。
これが完了すると、Zscalerポータルでは次のようになります。
Zscalerオーケストレーション用にAruba Centralを構成する
オーケストレーションされた統合を有効にする最初のステップは、Cloud Connect ServiceがZIAサービスと通信するためのパートナーの資格情報とAPIキーを入力することです。これは、 Network Services > Cloud Connect > Settings > Accountsの下の”Global”コンテキストから構成できます。
その後、アカウントは”アACCESS VERIFIED”としてマークされます。必要に応じて、複数のZscalerアカウントを追加できます。
Aruba Centralのサイトおよびトンネルオーケストレーション
この時点で、Aruba CentralはAPIを介してZIAと通信できるため、ゲートウェイまたはマイクロブランチとZIAサービス間の通信を調整できます。
最初のステップは、Network Services > Cloud Connect > Settings > Deploymentに移動し、ZIAに接続するGatewayまたはMicrobranchグループを選択することです。そのようなグループに存在するデバイスの場合、Aruba Centralは目的の属性を持つZIAに”location”を作成します。”Connection”チェックボックスをクリックして、オーケストレーションするグループを選択します。
Aruba Centralからの場所固有の構成の定義
すると、右側に小さな”歯車”アイコンが表示されます。このアイコンをクリックすると、Aruba Centralからlocationを編集できます。
また、特定のグループのゲートウェイまたはマイクロブランチが接続するサービスエッジを指定することもできます。[ZIA Service Edgeを上書き]オプションが選択されていない場合、Aruba Centralは単にすべてのゲートウェイまたはマイクロブランチから最も近い2つのZIA Service Edgeにトンネルを構築します。
Zscalerのサブロケーション
より幅広いユーザーを持つ可能性のあるサイトの場合、Aruba Centralではサブロケーションの作成も可能です。サブロケーションを実装することで、お客様はブランチゲートウェイの背後にある異なるVLANに異なるポリシーを適用できます。サブロケーションの詳細については、Zscaler helpを参照してください。サブロケーションを作成するには、下の図に示すように、テーブルの左側にある”キャレット”をクリックし、次に右上にある”+”をクリックするだけです。
最初のユーザ定義のサブロケーションを作成すると、”other”という名前のサブロケーションが自動的に作成されることに注意してください。このサブロケーションは、ユーザ定義のサブロケーションに属していないすべてのトラフィックに対する”catch all”ポリシーとして機能します。
サブロケーションは、サイトオプションと同じ方法で定義および編集できます。
| 注: |
|---|
| Aruba Centralからサブロケーションを編集する機能は、ブランチゲートウェイでのみ使用できます。 |
構成の適用
各グループに存在するサイトの数に応じて、ZIAでのサイトの定義には数分かかる場合があります。このため、Aruba Centralはすべての変更が行われるまで構成をプッシュします。準備ができたら、 “プレビュー”に移動し、すべての変更が理にかなっている場合は”送信”をクリックしてください。
オーケストレーションプロセスを監視しています
ZIA（またはその他のサードパーティ製サービス）への接続を調整するのに必要な時間は、グループ内のゲートウェイの数と、パートナーAPI（この場合はZscaler）の負荷によって異なります。Aruba Centralは残り時間の指標を提供します。これはNetwork Services > Cloud Connect > List > Zscaler.から確認できます。オーケストレーションプロセスが完了すると、デプロイステータスバーにその旨が表示されます。
サイトとトンネルのオーケストレーションを検証しています
グループでZIA Service Edge Orchestrationが有効になると、そのグループに属するすべてのデバイス（MicrobranchまたはGateway ） 、または将来そのグループに追加された新しいデバイスは、Zscalerで場所の作成をトリガーします（必要なすべての属性を持ちます） 。たとえば、カリフォルニア州レッドウッド市に3つのサブ位置を持つサイトを追加すると、Zscalerで次のサイトが作成されます。
また、すべてのパブリックWANインターフェイス(INET、LTE、Metro Ethernet)から適切なZIAサービスエッジへのIPsecトンネルの確立もトリガされます。例えば、スペインのマドリッドのマイクロブランチサイトは、スペインのマドリッドとフランスのマルセイユの公共サービスエッジに自動的に接続されます。
さらに、ブランチゲートウェイからオーケストレーションされたすべてのトンネルは、すべてのトンネルを通る通信の品質を評価するために、 http://gateway.<zscaler cloud domain>/vpntestをプローブするように自動的に設定されます。これにより、ゲートウェイはよりスマートな転送の決定を行うことができます。
トンネルの状態は、Aruba Centralのインターフェースから簡単に確認できます。これは、ゲートウェイ監視ダッシュボードのTunnelsタブから確認できます。なお、オーケストレーションされたトンネルの場合は”ORCH-IKE”、手動トンネルの場合は”IKE”と表示されます。
ZIAを介したトラフィック転送
Aruba GatewaysとZIA間のトンネルが確立されたら、残りのステップは、ZIAを介して送信するトラフィックを選択することだけです。これはポリシーベースのルーティングを使用して行われますが、転送ポリシーの実装方法の詳細は、ゲートウェイを使用して行うか、マイクロブランチを使用して行うかによって異なります。
ゲートウェイによるトラフィック転送
ブランチゲートウェイは、すべてのアクティブ（パブリック）アップリンクインターフェイスを介してZIAへのトンネルを自動的に確立し、（ArubaOSバージョン10.3以降を使用している場合）各トンネルの品質を監視するためにプローブをZIAに送信します。次のステップは、トンネルを”next-hop-list”に編成して、WANおよびルーティングポリシーで使用できるようにすることです。
ルーティングとWANポリシーの相互作用をより深く理解する。ルーティング/PBRはネクストホップを決定します。WANエンジンへの最大4つのアクティブ（コスト/優先度が最も高い）パスを提供します。次に、WANポリシー(SaaS/DPS)によって、各トラフィックフローにどのパスを使用すべきかが決定されます。次の図は、PBRとグローバルルーティングが、DPSまたはSaaS Expressで定義されたWANポリシーとどのように共存するかを説明しています。
![ルーティングとWANポリシーの共存]（Media/PBRとDPSの共存.png）
これを行うには、まずトンネルを使用して”next-hop-list”を作成し、それらをPBRポリシーに含め、最後にそのポリシーを適切なオブジェクト（ロール、VLAN、またはオーバーレイ）に接続します。これは、グループレベルの基本構成モードでPolicies > PBRに移動することにより、単一のワークフローで処理することができます（下のスクリーンショットを参照）。
このメカニズムの仕組みをより詳細に理解するために、このドキュメントでは、ゲートウェイの設定にアドバンスドモードを使用して必要なすべての手順を説明します。
トンネルを使用してネクストホップリストを作成し、（オプションで）SLAを定義します
この設定の重要な側面は、同じサービスエッジに向かうトンネルが常に同じ優先順位を持つようにすることです。これにより、Dynamic Path Steering（DPS;ダイナミックパスステアリング）は、サービスエッジに至るすべてのトンネルでどのトラフィックフローを通過させるかを決定できます。これはRouting > Next Hop Configurationから設定できます。
Step 1 next-hop-listを作成します。
Step 2 IPSecマップの下にサイト間トンネルのIPSecマップを追加します。この場合、オプションでSLAを設定できます。
Step 3 同じサービスエッジに向かうすべてのトンネルに同じ優先順位を使用します。オーケストレーションされたトンネルの場合、プライマリとしてマークされたトンネルとセカンダリとしてマークされたトンネルの間の優先順位は同じにする必要があります。
Step 4 ZIAサービスエッジごとに異なる優先順位を使用します。
Step 5 プリエンプティブフェールオーバーが有効になっていることを確認します。これにより、ゲートウェイは、プライマリトンネルでサービスに影響を与える問題から復旧した後にトラフィックを元に戻すことができます。
SLAプロファイルは、必要に応じてネクストホップリストに関連付けることができます。これにより、ゲートウェイは準拠していないトンネルを選択的にネクストホップリストから削除できます（IPsecトンネルはアップ状態が続きますが、トラフィックの転送には使用されません）。次の2つの操作モードがあります。
- Liveness:このモードでは、ZIAプローブレスポンダー(
http://gateway.<zscaler cloud domain>/vpntest)に到達できないトンネルはパッシブとしてマークされ、トラフィックの転送には使用されません。 - Performance:このモードでは、トラフィック転送用のトンネルを考慮するために、特定のSLA目標（遅延、パケット損失）を満たす必要があります。ネクストホップリスト内のトンネルのどれも”準拠”していない場合、ゲートウェイは単に、定義されたSLAから最も逸脱していないトンネルを選択します。
どちらの場合も、ネクストホップが”非準拠”とマークされるたびに、トンネル間のフラッピングを回避するために、ネクストホップは最低3分間はその状態のままになります。
IP-SLAプロファイルは、ブランチゲートウェイの構成ページのWAN > Health Check >IP-SLA Profilesページから管理します。
ルーティングポリシーに次ホップを追加
ZIAへのトンネルを持つネクストホップリストが作成されたら、WAN > Health Check >IP-SLA Profilesのルーティングポリシーに追加します。
次の例では、ポリシーは特定のアプリケーション（ZoomとMicrosoft Teams）とすべてのトラフィックを通常のパスを介してプライベートネットワーク（RFC1918アドレスを表すエイリアス）に送信し、残りのトラフィックは定義済みのネクストホップリストを使用してZIA Public Service Edgesを介して送信します。
ルーティングポリシーの適用
ルーティングポリシーが作成された後、最後のステップは、そのポリシーを関連トラフィックに適用することです。
ブランチゲートウェイの場合、これらのポリシーは、ZIAを介して送信する必要のあるデバイスがある役割またはVLANに適用されます。
– ポリシーをVLANに適用するには、 Security > Apply Policiesに移動し、各VLANの横のドロップダウンから選択します。 – ポリシーをロールに適用するには、 Security > Rolesに移動し、ルーティングポリシーを追加して、ZIA経由で送信するロールを編集します（ルーティングポリシーは常に最後に来ます）。
VPNCの場合、ルーティングポリシーは通常、着信SD-WANトラフィックに適用されます。これは、 VPN > SDWAN Overlay > Advancedで設定できます。
ルーティングポリシーを検証
PBRを設定し、適切なロール、インターフェイスなどに適用すると、トラフィックがそのパスを効果的に通過していることを検証できます。そのためには、まず、クライアントデバイスに関連付けられているユーザーロールを確認します。
また、トラフィックが実際にZIAへのトンネルを経由してインターネットに向かっていることを確認する必要があります。
追加の検証として、クライアントデバイスは https://ip.zscaler.com を参照できます。このページには、クライアントがZIAを介してインターネットにアクセスしているかどうか、および使用されているService Edgeが表示されます。
マイクロブランチAPを使用したトラフィック転送
ZIAを介してトラフィックを転送するようにMicrobranch APを設定することも非常に簡単で、Branch Gatewaysで使用される手順と非常によく似ています。ゲートウェイと同様に、PBRポリシーを作成し、対応するユーザーロールに適用する必要があります。
ZIA経由でインターネットトラフィックを送信するためのPBRポリシーを定義
PBRを使用してトラフィックをZIA経由で強制する場合、一般的なベストプラクティスは、パブリックアドレッシング空間に対してのみ行い、内部トラフィックのセキュリティポリシーをNGFWやマイクロブランチAP自体などのオンプレミスのアプライアンスに残すことです。そのため、まず企業のIPアドレスを表すネットワークエイリアスを作成することから始めるのが理にかなっています。これは、Security > Policies & Access Control > Aliasesから(グループレベルで)実行できます。
次のステップは、ZIAサービスへのトンネルを表す”ネクストホップ”を作成することです。このネクストホップは、トンネルの1つがダウンする稀な場合に、トラフィックが自動的にフェールオーバーすることを保証します。これは、次の図に示すようにTunnels & Routing > NextHop Listから実行できます。
これにより、ZIAを介してすべての非RFC1918トラフィックを送信するPBRポリシーをTunnels & Routing > Policy-based Routingから簡単に作成できます。次に示すポリシーの例を示します。
関連するユーザーロールにPBRポリシーを適用
最後の手順では、PBRポリシーを必要とするすべてのユーザーロールにPBRポリシーを追加します。これは、次の図に示すようにSecurity > Policies & Access Control > Rolesから実行できます。
ルーティングポリシーを検証
ゲートウェイの場合と同様に、クライアントがPBRポリシーに従って転送されていることを検証するには、最初の手順として、クライアントが適切なユーザーロールを持っていることを検証します。これは、クライアントの詳細ページとクライアントのリストページから確認できます。ロールが適切な場合は、そのロールにPBRポリシーが関連付けられていることを確認します。
AP CLIを使用して、さらにデバッグを行うことができます。
“show acces-list”を使用すると、トラフィックのリダイレクトに使用されているルーティングACLを検証できます。
EC-Microbranch# show access-list
Access list table
-----------------
Name AclId Type Use Count Roles
---- ----- ---- --------- -----
"default policy" 471 route
internet-through-zia 472 route 1 EC-Microbranch
EC-Microbranch#
EC-Microbranch# show access-list internet-through-zia
Route Access-List Rules
-----------------------
Src IP Src Mask Dest IP Dest Mask Eth Type Dest Match Protocol (id:sport:eport) Application Action Log TOS 802.1P Blacklist App Throttle (Up:Down) Mirror DisScan ClassifyMedia TimeRange
------ -------- ------- --------- -------- ---------- ------------------------- ----------- ------ --- --- ------ --------- ---------------------- ------ ------- ------------- ---------
netdest rfc1918(2) netdest rfc1918(2) IPv4/6 match any permit ClassifyMedia
any any any any IPv4/6 match any route nexthop-list ZIA-Bundle ClassifyMedia
EC-Microbranch#
“show ip nexthop-list”を使用すると、PBRポリシーで使用されているネクストホップ一覧に正しいトンネルが接続されていること、およびそれらのトンネルの1つがアクティブであること（ * が付いていること）を確認できます。
EC-Microbranch#
EC-Microbranch# sh ip nexthop-list
Nexthop-List Entries
--------------------
Name Dest Preemptive Failover Nexthop Nexthop Dest Nexthop Priority
---- ---- ------------------- ------- ------------ ----------------
ZIA-Bundle 0x4401 Enabled *zs-init-samuel-production-primary-comcast 0x443e 128
zs-init-samuel-production-secondary-comcast 0x443f 64
EC-Microbranch#
show datapath session”は、トラフィックが以前に定義されたnext-hop-listにリダイレクトされていることを確認するために使用できます。
EC-Microbranch# sh datapath session | i -
------------------------------
Flags: A - Application Firewall Inspect
C - client, D - deny, E - Media Deep Inspect
F - fast age, G - media signal, H - high prio
I - Deep inspect, L - ALG session, M - mirror, N - dest NAT
O - Session is programmed through SDN/Openflow controller
P - set prio, R - redirect, S - src NAT,
T - set ToS, U - Locally destined, V - VOIP
X - Http/https redirect for dpi denied session
Y - no syn
a - rtp analysis, h - Https redirect error page
i - in offload flow, m - media mon
p - Session is marked as permanent
s - media signal
d - DPI cache hit
RAP Flags: 0 - Q0, 1 - Q1, 2 - Q2, r - redirect to conductor, t - time based, i - in flow
Flow Offload Blacklist Flags: O - Openflow, E - Default, U - User os unknown, T - Tunnel
---------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- ------- ----- ------ -------------
151.101.194.137 10.127.17.126 6 443 55954 0 0 0 1 pbr-nhl 1 501 22 49b0 Fi
13.227.76.59 10.127.17.126 6 443 55942 0 0 0 1 pbr-nhl 1 508 5ab 18395b Fi
13.35.122.126 10.127.17.126 6 443 55944 0 0 0 1 pbr-nhl 1 505 16 1bee Fi
13.35.122.26 10.127.17.126 6 443 55957 0 0 0 1 pbr-nhl 1 4fe 17 1e99 F
13.35.122.43 10.127.17.126 6 443 55958 0 0 0 1 pbr-nhl 1 4fd 22 2c46 F
10.127.17.126 151.101.194.137 6 55954 443 0 0 8 1 pbr-nhl 1 501 1f a32 FCi
10.127.17.126 13.35.122.126 6 55944 443 0 0 8 1 pbr-nhl 1 505 16 755 FCi
10.127.17.126 13.35.122.43 6 55958 443 0 0 8 1 pbr-nhl 1 4fd 26 1852 FC
10.127.17.126 13.35.122.26 6 55957 443 0 0 8 1 pbr-nhl 1 4fe 1a a23 FC
10.127.17.126 99.84.226.109 6 55953 443 0 0 8 1 pbr-nhl 1 501 22 b6b FC
10.127.17.126 13.227.76.59 6 55942 443 0 0 8 1 pbr-nhl 1 508 13d 4569 FCi
10.127.17.126 99.84.226.140 6 55945 443 0 0 8 1 pbr-nhl 1 505 16 761 FC
10.127.17.126 99.84.226.173 6 55946 443 0 0 8 1 pbr-nhl 1 505 17 77d FC
10.127.17.126 99.84.226.186 6 55949 443 0 0 8 1 pbr-nhl 1 505 3a 10ea FC
10.127.17.126 99.84.226.201 6 55952 443 0 0 8 1 pbr-nhl 1 502 1f b49 FC
99.84.226.201 10.127.17.126 6 443 55952 0 0 0 1 pbr-nhl 1 502 22 3a34 F
99.84.226.186 10.127.17.126 6 443 55949 0 0 0 1 pbr-nhl 1 505 5a 1572b F
99.84.226.173 10.127.17.126 6 443 55946 0 0 0 1 pbr-nhl 1 505 15 1b8f F
99.84.226.140 10.127.17.126 6 443 55945 0 0 0 1 pbr-nhl 1 505 14 1edd F
99.84.226.109 10.127.17.126 6 443 55953 0 0 0 1 pbr-nhl 1 501 29 6170 F
EC-Microbranch#
最後に、クライアントデバイスから https://ip.zscaler.com を参照することで、追加の検証を取得できます。このページには、クライアントがZIAを介してインターネットにアクセスしているかどうか、およびノードを介してアクセスしているかどうかが表示されます。
