Virtual WAN + SD-WANを理解するための前提
Virtual WANはSD-WAN/VPN partnerとのautomationを利用し、branch情報のAzure登録、Azure側VPN configuration取得、IPsec tunnel確立を効率化できる。 automationはpartner controller/CPEの責任をAzureへ吸収するものではない。controller availability、license、CPE config、Internet underlayは別failure domain。
branch側にはAzureが到達可能なpublic IP/underlayが必要となる構成があり、NAT/firewall/dual ISP条件をpartner integrationで確認する。 BGP/static prefixesをVPN site/connectionへ正しく登録し、hub route tableへのpropagationとbranch側route advertisementを双方向確認する。
複数branch/dual ISPではtunnel数が急増するため、Virtual WAN VPN gateway scale unit、connection count、aggregate throughputとSD-WAN policyを一体でsizingする。 SD-WAN overlayのapplication-aware routingとVirtual WAN hub routing/routing intentが二重policyになり得るため、どのlayerがpathを決めるか明文化する。
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側経路を証明できない。
仕組み
partner automationはmanual configuration削減に有効だが、生成されたAzure/SD-WAN configをblack boxにせずsite public IP、BGP ASN/prefix、tunnel countをinventoryする。
dual ISP/dual CPEではCPE側SLA policyがどのtunnelへflowを送るかと、Azure側がどのreturn pathを選ぶかを揃える。
branch-to-branch trafficをVirtual WAN transitさせるかSD-WAN provider backboneへ残すかをsite classごとに決め、同prefixのparallel pathを制御する。
routing intentでcentral firewallへprivate trafficをsteerする場合、SD-WAN service chainingと二重inspection/loopにならないか確認する。
provider/controller upgradeとAzure gateway maintenanceを同時にしないようchange calendarを統合し、片underlay failure testを定期実施する。
Packet / route path
同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。
- branch application packetがSD-WAN CPEへ入り、overlay policyがISP/transport/tunnelを選ぶ。
- CPEがpacketをIPsecで暗号化しVirtual WAN VPN gateway endpointへ送る。
- VPN gatewayが復号し、branch-advertised prefixをhub routerへ伝える。
- hub route table/routing intentがdestination VNet/ER/branch/security hopを選ぶ。
- replyはhub→VPN gateway→branch tunnelへ戻り、CPEがsession/applicationへ転送する。
- dual path時はAzure returnがbranch forwardと異なるunderlay/CPEへ戻ってもstateful/security設計が成立するか確認する。
BGP / route state の読み方
| 観測点 | 何を確認するか |
|---|---|
| Branch advertisements | VPN site/BGPでbranch prefixesがhub route tableへpropagateしているか確認する。 |
| Azure advertisements | branch CPEがAzure/remote branch prefixesを受信・FIB installしているかcontroller/routerで確認する。 |
| Overlay policy | SD-WAN path preferenceとAzure hub routingのpreferred pathを同prefixごとに比較する。 |
| Return symmetry | dual CPE/ISPでreturnが別tunnelへ来る場合のsession/state handlingを確認する。 |
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Automation | supported partner integrationがあり大量branch展開なら利用する。 | manual tunnel config driftを減らせる。 |
| Underlay | dual ISP/physical diversityをcritical branchで確保する。 | Virtual WAN gateway冗長性だけではbranch last-mile断を救えない。 |
| Routing | BGP + explicit prefix policyを大規模branchで優先する。 | site追加/撤去のroute lifecycleを自動化しやすい。 |
| Policy ownership | application pathはSD-WAN、Azure transit/securityはhub側など責任を明文化する。 | 二重policyのtroubleshootingを単純化する。 |
確認手順
Azure Portal / provider / edge
- Virtual WAN → VPN sites/connectionsでbranch identity、links/public IP、connection stateを確認する。
- Virtual Hub VPN gatewayでscale/throughput/tunnel/BGP stateを確認する。
- SD-WAN controllerでsite tunnel、underlay SLA、BGP/route、template versionを採取する。
- hub route tables/routing intentとbranch route tableを同一prefixで突合し、failover testを実施する。
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 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>
# VPN site/gatewayとpartner controller双方のread-only stateを同じsite IDで採取する。障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| Azure tunnel down、controller正常 | public IP/NAT/underlay/Azure connection mismatch | Azure connection + CPE IKE log | partner automation stateと実endpointを突合する |
| tunnel upだがbranch prefixなし | BGP/site prefix/propagation | branch advertised + hub route table | tunnel healthとroute healthを分離する |
| dual ISP切替で片方向 | return pathが旧tunnel/CPE | hub route + controller flow + FW state | Azure/SD-WAN両側のconvergenceを確認する |
| routing intent導入後loop | SD-WAN service chainとAzure security steering重複 | path trace + FW/NVA logs | どちらのlayerがinspectionを担当するか一本化する |
変更時の確認と rollback
- 変更前にAzure site/connection/routesとSD-WAN template/policy/tunnel stateを両方exportする。
- automation再pushは生成差分を確認し、全branch同時適用を避ける。
- underlay/path policy rollbackはCPEとAzure route convergenceを両方確認する。
- rollback後はprimary/secondary ISP failoverとbranch↔Azure/remote branchの代表flowを再試験する。