Virtual WAN Routing Intentを理解するための前提
Routing Intentはvirtual hubでInternet trafficとPrivate trafficにrouting policyを定義し、supported security solutionへsteerする機能。 1 virtual hubあたりInternet policyとPrivate policyをそれぞれ最大1つのintentとして扱い、対象traffic classの広いblast radiusを理解する。
Private traffic policyはbranch/VNet/ER等のprivate prefixes間transitをsecurity hopへ集約できるが、existing custom route tables/NVA pathとの相互作用を確認する。 Internet traffic policyはegress path/DNS/proxy/NATまで変える可能性があるため、Web到達性だけでなくAzure platform/identity dependenciesも検証する。
supported next hopはAzure Firewall、NGFW NVA、SaaS security solution等current support matrixに従う。任意VM applianceを同じrouting intent targetとみなさない。 routing intent有効化後もdestination/return routeとstateful security deviceのsession symmetryを実packetで確認する。
Control plane と data plane
Provider / responsibility boundary
Virtual WAN、virtual hub、connections、route tables、routing intent / route map等を管理する。
Microsoft-managed virtual hub router / gatewaysがbranch・ER・P2S・VNet間のtransitを処理する。通常のcustomer-managed hub VNetとは運用モデルが異なる。
SD-WAN controller、CPE、ER provider、remote userなど外側のfailure domain。Azure側connection stateだけではbranch側経路を証明できない。
仕組み
Routing Intentは個別prefixの小さなUDR置換ではなく、hub全体のtraffic classをcentral securityへ送るpolicy。scopeを誤ると広域outageを起こす。
Private policy導入時はbranch↔VNet、VNet↔VNet、ER↔VNet、inter-hubなど代表flowを列挙し、既存direct transitがinspection pathへ変わることを確認する。
Internet policyではSNAT/public IP、FQDN filtering、TLS inspection、DNS proxy等security appliance側機能との依存を確認する。
custom route tables/route mapsと併用する場合、policyによるroute injection/steering後のeffective hub routesをbefore/afterで比較する。
migrationは全hub同時ではなく、対象hub/traffic classを限定し、observabilityとrollbackを先に作る。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- source connectionからprivate/Internet trafficがvirtual hub routerへ入る。
- hub routing policyがtraffic classを判定し、configured security next hopへsteerする。
- Azure Firewall/NVA/SaaS solutionがpolicyに基づきinspect/filter/NATする。
- 許可trafficがhub routingへ戻りdestination connection/Internetへ転送される。
- replyもpolicyに従いsecurity solutionを通る必要があり、NAT/session stateとreturn routeを確認する。
- failure時はsecurity target health、hub route、connection route、applicationを分け、単に「Virtual WAN障害」とまとめない。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Intent state | Private/Internet policyがどのtargetへ設定されているか、hubごとにinventoryする。 |
| Route changes | enable前後でhub route tableのprefix/next hopをdiffし、予期しないroute injection/removalを検出する。 |
| Return path | security targetからsource prefixへのrouteとhubへの再注入を確認する。stateful deviceでは同一sessionが両方向通るかを見る。 |
| Egress | Internet policy時はSNAT public IP/DNS/proxy pathを確認し、client側から見えるsource/latencyもbaseline比較する。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Private policy | east-west/on-prem transitをcentral inspectするsecurity requirementがある場合に有効化する。 | 全private trafficへ影響するためpolicy scopeを明確化する。 |
| Internet policy | central egress/filtering要件がある場合に採用する。 | NAT/DNS/identity dependencyまで変える可能性がある。 |
| Target | current supported Azure Firewall/NVA/SaaS integrationから選ぶ。 | unsupported applianceをforce-fitして運用不能にしない。 |
| Migration | hub/traffic class単位の段階cutover + immediate rollbackを設計する。 | routing controlのblast radiusが大きい。 |
確認手順
Azure Portal / provider / edge
- Virtual Hub → Routing Intent / Routing PoliciesでPrivate/Internet policyとnext hopを確認する。
- Route tablesでenable前後のroute/next hopを比較する。
- Azure Firewall/NVA/SaaS側でsession/NAT/security logsを同時確認する。
- branch/VNet/ER/Internetの代表flowを双方向で試験し、DNSとapplicationも含めて確認する。
Verification discipline
- subscription / resource group / resource ID / region / connection名を固定し、同名resourceの取り違えを防ぐ。
- control-planeのProvisioningStateだけで完了判定せず、peer/session/route/metricと実packetの結果を別々に保存する。
- advertised route・learned route・effective routeを混同しない。各段階で「誰が誰へ何を広告し、最終的にどのFIBへ入ったか」を確認する。
- 変更前後で同一source/destination/protocolを再試験し、既存sessionの継続を新規flowの成功と誤認しない。
az network vhub show -g <rg> -n <hub> -o jsonc
az network vhub route-table list -g <rg> --vhub-name <hub> -o table
az network vhub connection list -g <rg> --vhub-name <hub> -o jsoncGet-AzVirtualHub -ResourceGroupName <rg> -Name <hub>
# Routing IntentはPortal/current Az.Network referenceでtargetとpolicy stateをread-only確認する。障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| 有効化直後に広範囲通信断 | unsupported target/route injection/return path | intent state + route diff + security logs | policyをrollbackしbefore routesへ戻す |
| 行きだけFW logあり戻りなし | return route/asymmetry/NAT | FW session + destination route | replyが同security pathへ戻るか確認する |
| Internetだけ一部service失敗 | DNS/proxy/TLS/identity/platform endpoint | FW logs + DNS + target endpoint test | IP reachabilityとL7 dependencyを分離する |
| 一部connectionだけbypass | association/propagation/unsupported path | hub route + connection config | intent scopeとroute table exceptionを確認する |
変更時の確認と rollback
- enable前にhub route tables、connection matrix、security resource config、代表flow baselineを保存する。
- 最初は片traffic class/限定hubで適用し、privateとInternetを同時変更しない。
- rollbackはintent disableだけでなくroute table/connection/security policyがbefore stateへ戻ったことを確認する。
- rollback後はnegative/positive security testとend-to-end application testを再実行する。
What changed recently
2026-08-27更新のcurrent guidanceではrouting policiesがAzure Firewallだけでなくsupported NGFW NVA / SaaS security solutionを含む形で整理されています。導入時はtarget別support matrixを必ず確認します。