VPN Gateway Monitoring

運用前提: hybrid connectivityはAzure resourceだけで完結しません。Azure / Microsoft edge、connectivity provider・Internet、customer edge、BGP route、VNet effective route、stateful security device、applicationを別failure domainとして観測し、control-planeのSucceededをdata-plane成功の代わりにしません。SKU・limit・availability・preview statusは変わるため、導入時は末尾のcurrent Microsoft Learnも再確認してください。

VPN Gateway Monitoringを理解するための前提

Azure Monitor platform metricsはVPN Gateway resourceから自動収集され、tunnel/throughput/BGPなどの観測に利用できる。 resource metricsだけではremote ISP、on-prem VPN device、内部routing/applicationの障害を完全には見抜けない。end-to-end probeと両端logを併用する。

BGP peers画面ではpeer state、learned routes、advertised routesを確認できる。route数が50を超える場合などPortal表示だけに依存せずexport/CLIを使う。 diagnostic settingsは必要categoryをLog Analytics等へ送るためのcontrol plane設定。設定した時点より前のlogが自動で復元されるわけではない。

alertは単一metric thresholdより、Tunnel state / BGP state / traffic / synthetic connectivityを組み合わせて誤検知と見逃しを減らす。 HA構成ではaggregate healthだけでなくinstance/peer/tunnel単位の偏りを監視し、片系死んだまま冗長性を失っている状態を検出する。

通信や判断の流れを追う

On-premisesVPN / ProviderGateway / HubVNetWorkload

Control plane と data plane

Control planeControl planeはdiagnostic settings、Azure Monitor alert rules、Action Groups、Log Analytics destination、Network Watcher/Connection Monitor設定。これらが存在しても監視対象tunnel/peerを全てcoverしているか別確認が必要。

Data planeData plane healthは実packet、tunnel ingress/egress、BGP route、latency/loss、application transactionで観測する。monitoring pipeline自体の欠損とnetwork障害を区別できるよう複数signalを持つ。

Provider / responsibility boundary

Azure側

VPN Gateway resource、GatewaySubnet、public IP、connection、Local Network Gateway、BGP設定を管理する。

Internet / provider

IPsec packetが通るunderlay。Azure VPN GatewayがSucceededでも、途中のNAT・firewall・ISP品質は別failure domain。

On-premises

VPN deviceのIKE/IPsec proposal、route/BGP、NAT、policy、HA状態を管理する。Azure側だけではremote peerの実転送を証明できない。

仕組み

baselineは「平常時のtunnel ingress/egress、BGP peer count、route count、latency/loss」をconnection/peerごとに保存する。絶対値だけでなく通常範囲を持つ。

Tunnel stateがConnectedでもtraffic=0が異常かどうかは時間帯/standby設計次第。active-activeでは片系だけ極端に偏ることもtrendとして見る。

BGP route countの急減はapplication outage前の先行signalになり得る。peer Connectedのみでalertを閉じない。

diagnostic logはIKE/IPsec/BGP disconnect時刻とremote device logをNTP同期した時刻で相関する。

Connection Monitor等のsynthetic probeはAzure resource healthと独立したend-to-end evidenceとして使い、probe destination自体の可用性も考慮する。

Packet / route path

同一prefix/flowを広告元からdestinationまで追い、connection state・BGP table・effective route・実packetを混同しません。

Azure Monitorがgateway/tunnel metricを収集し、alert ruleがthreshold/dimensionで評価する。
diagnostic settingsがresource logをworkspace/storage/event hubへstreamする。
BGP peer/route dataはPortal/CLI/PowerShellでpoint-in-time evidenceとして取得する。
synthetic probeまたはreal application telemetryがend-to-end reachabilityを観測する。
incident時はAzure metric/log、on-prem VPN/BGP log、effective route、application timestampを同一timelineへ並べる。
復旧判定はresource stateの緑表示ではなく、route countと新規application flowがbaselineへ戻ったことまで確認する。

BGP / route state の読み方

観測点	何を確認するか
Availability signal	Tunnel state/BGP peer stateをconnection/peer単位で監視し、HA片系喪失を検出する。
Routing signal	learned/advertised route countと重要prefixの存在を定期snapshotする。peer upでもprefix欠落を検出する。
Capacity signal	throughput/packet metricsをSKU capacity・平常baselineと比較し、飽和と単なるtraffic増を分ける。
End-to-end signal	代表source→destinationのlatency/loss/application probeを置き、Azure gateway外のfailureも可視化する。

判定ルールAdvertised ≠ Learned ≠ Installed/Effective ≠ Reachable。各段階を別証拠として採取し、どこでprefixが消えたかを特定します。

設計判断

判断点	推奨	理由
Alert scope	gateway全体だけでなく重要connection/tunnel/BGP peer dimensionsを監視する。	aggregate Healthyで片系障害を隠さない。
Log retention	incident調査期間と監査要件に合わせworkspace/archiveを設計する。	障害発生後にdiagnostic settingsを追加しても過去証拠は戻らない。
Route snapshots	重要変更前後と定期的にlearned/advertised routesを保存する。	routing incidentで「何が消えたか」をdiffできる。
Runbook	Tunnel down / BGP down / traffic loss / high utilizationを別runbookにする。	症状ごとに必要証拠とowner(Azure/provider/on-prem)が異なる。

確認手順

Azure Portal / provider / edge

VPN Gateway → Monitoring → Metricsでgateway/tunnel dimensionsと期間を固定して確認する。
Monitoring → BGP peersでpeer state、Routes received、learned/advertised routesを取得する。
Diagnostic settingsで必要resource logsのdestinationとenabled categoryを確認する。
Network Watcher/Connection Monitorまたは既存synthetic monitoringでon-prem↔Azureの代表pathを継続観測する。

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の成功と誤認しない。

Azure CLI — read-only first

az monitor metrics list-definitions --resource <gateway-resource-id> -o table
az monitor diagnostic-settings list --resource <gateway-resource-id> -o jsonc
az network vnet-gateway list-bgp-peer-status -g <rg> -n <gateway> -o table
az network vnet-gateway list-learned-routes -g <rg> -n <gateway> -o table

PowerShell / endpoint — read-only first

Get-AzMetricDefinition -ResourceId <gateway-resource-id>
Get-AzDiagnosticSetting -ResourceId <gateway-resource-id>
Get-AzVirtualNetworkGatewayBgpPeerStatus -ResourceGroupName <rg> -VirtualNetworkGatewayName <gateway>

障害切り分け

症状	疑う点	証拠	次の確認
alertなしだが通信断	監視がgateway stateだけ、remote/application failure	synthetic probe + on-prem logs	監視cover範囲をend-to-endへ拡張する
BGP peerはConnected	重要prefixだけwithdraw/filter	learned/advertised route diff	peer stateからroute contentへ調査を進める
traffic metric急減	実障害か正常なtraffic移動/standby	tunnel別metric + application volume	HA別pathへtrafficが移ったか確認する
incident logがない	diagnostic settings未設定/category不足/retention切れ	diagnostic setting + workspace ingestion	監視pipeline設定自体を修正する

変更時の確認と rollback

alert/log変更前に現行rules、dimensions、diagnostic destinations、retentionをexportする。
新alertは最初にaction抑制/低影響routingで観測し、baselineに合わせthresholdを調整する。
diagnostic setting削除は証拠欠損を生むため、destination移行時はoverlap期間を設ける。
rollback後もテストalertとknown test flowを実施し、monitoring pipelineが実際に通知まで届くことを確認する。