Azure Virtual WANを理解するための前提
Azure Virtual WANは複数regionのMicrosoft-managed virtual hubsをtop-level Virtual WAN resourceで管理し、branch VPN、P2S、ExpressRoute、VNet transit等を統合する。 Standard Virtual WANではhub間がfull meshで接続され、VNet/branch/ER/P2S間transitを提供する。Basicは主にS2S VPN用途で機能範囲が限定される。
virtual hubは通常のcustomer-managed VNetではなくMicrosoft-managed infrastructure。hub router/gatewaysのroute propagation modelを前提に設計する。 connectionsはhub route tableへassociateし、1つ以上のroute tablesへpropagateする。このassociation/propagationが実traffic pathを決める中心。
routing intentでprivate/Internet trafficをAzure Firewallやsupported NVA/SaaS security solutionへ送るpolicyをcentralizeできる。 SD-WAN partner automationはbranch情報upload、Azure config download、IPsec establishmentを自動化できるが、partner/CPE側はAzure外のfailure domainとして残る。
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側経路を証明できない。
仕組み
Standard/Basicは単なるperformance tierではなくfeature modelが違う。将来ER/P2S/VNet transit/security integrationが必要なら初期tier選定で考慮する。
hub route tableのassociationは「そのconnectionから出たpacketが参照するtable」、propagationは「そのconnectionのrouteをどのtableへ広げるか」という役割を分けて理解する。
Default/None/custom route tablesとlabelsを使い、segmentation/shared services/inspection pathを設計する。意図せぬpropagationで隔離domainが繋がらないようroute matrixを持つ。
route mapsは広告routeのfilter/aggregation/AS-PATH/community変更に使えるが、適用connection typeと制限をcurrent guidanceで確認する。
routing intentはprivate/Internet traffic classをcentral securityへ送る強力なpolicy。既存custom route table/NVA pathとの相互作用を移行前に検証する。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- branch/VNet/ER/P2S connectionからpacketがnearest/connected virtual hubへ入る。
- connectionにassociatedされたhub route tableでdestination routeをlookupする。
- routeはconnected/propagated/static/intentによってnext connection/security hopを示す。
- destinationが別hub配下ならStandard Virtual WANのinter-hub transitでMicrosoft backboneを通る。
- routing intentがprivate/Internet classへ設定されていればsupported firewall/NVA/SaaS pathへsteerされる。
- destination connectionへ転送後、reply側も同じroute/intent policyでreturn pathが成立し、stateful inspectionがある場合はsymmetryを確認する。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Association | 各connectionがどのhub route tableを参照するか一覧化する。誤associationは全く別segmentのrouteを選ばせる。 |
| Propagation | connectionのprefixがどのroute tables/labelsへpropagateするか確認する。reachability不足/過剰の両方が起こり得る。 |
| Inter-hub | remote hub/branch prefixがpropagatedされているか、hub router route tableとconnection statusを確認する。 |
| Security steering | routing intent/secure hubがある場合、private/Internet trafficのreturnも同じinspection pathを通るか確認する。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Tier | 複数接続種別/transit/security integrationが必要ならStandardを基準にする。 | BasicからStandardへの要件差を後工程で発見するとtopology migrationが発生する。 |
| Segmentation | route table association/propagation matrixを設計書として管理する。 | GUIのconnection一覧だけでは意図したreachability boundaryが読めない。 |
| Hub placement | latency、region failure、branch location、ER peering locationを基に複数hubを配置する。 | hub数はrouting/resiliency/costすべてへ影響する。 |
| Security | routing intent導入前に既存NVA/UDR/DNS pathとの互換とsymmetryを検証する。 | central steeringは広いblast radiusを持つ。 |
確認手順
Azure Portal / provider / edge
- Virtual WAN → Hubsでhub state、region、routing status、gateway deploymentsを確認する。
- Virtual hub → Route tablesでDefault/None/custom tablesとroutes、labelsを確認する。
- ConnectionsでVNet/branch connectionのassociated/propagated route tablesを確認する。
- Routing Intent/Security configurationとAzure Monitor/Insightsでpathとhealthを検証する。
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 vwan show -g <rg> -n <vwan> -o jsonc
az network vhub list -g <rg> -o table
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 tableGet-AzVirtualWan -ResourceGroupName <rg> -Name <vwan>
Get-AzVirtualHub -ResourceGroupName <rg> -Name <hub>
# Az.Networkのcurrent Virtual WAN cmdletsでconnections/route tablesもread-only確認する。障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| 1 connectionだけ到達不可 | association/propagation誤り、connection state | connection config + hub route table | hub全体障害と決める前に対象connectionのroute matrixを見る |
| segment間が意図せず到達 | 過剰propagation/label共有 | route table contents + propagation labels | security ruleより先にrouting segmentationを確認する |
| Firewall導入後片方向 | routing intentとreturn route/NVA asymmetry | hub route + firewall log + destination route | forward/returnのsecurity steeringを揃える |
| remote hub prefixが消えた | inter-hub/hub routing/connection failure | hub status + route tables + route count | source/destination両hubでprefix propagationを追う |
変更時の確認と rollback
- 変更前にhub/connection/route table/labels/routing intentをexportし、reachability matrixを保存する。
- propagation/association変更は1 connectionずつ行い、expected route diffを確認してから拡大する。
- routing intent導入は限定hub/traffic classから検証し、既存security pathへ戻す手順を用意する。
- rollback後はroute tableだけでなくbranch↔VNet、VNet↔VNet、ER↔VNet等の代表flowを再試験する。