Azure Peering か VNet 間 VPN か — ルーティングの前に決める

Azure には二つの仮想ネットワークをつなぐ方法が少なくとも二通りあり、同じオブジェクトの入れ替え可能な設定ではありません。Peering はゲートウェイなしで Microsoft のバックボーン上で VNet を接続します。VNet 間 VPN は、自分でデプロイし、サイズを決め、監視する二つのゲートウェイの間に IPsec の関係を置きます。判断は三つの条件に集約され、ルートを追加する前にその三つすべてに答えられないなら、選んだことのないモデルの回避策を作ろうとしています。

モデルを決める三つの条件

第一は、要件のどこかに自分が所有し指し示せる IPsec 境界が必要かどうかです。第二は、アドレス空間がきれいで、二つの VNet が互いに話すだけでよいかどうかです。第三は、推移的な経路とゲートウェイの請求を誰が持つかです。この順に答えてください。第二がどれほど魅力的に見えても、第一が Peering を排除することがあるからです。

両モデルに共通するのは厳格なアドレス規則です。VNet のアドレス空間は重複してはいけません。Peering も VNet 間 VPN も、同一の範囲を一意にするためのサポートされた方法ではなく、重複には別の接続種別ではなくマッピング設計か再設計が必要です。

条件 1: 自分が所有する IPsec 境界は必要か

Peering は Azure のプライベートなバックボーンでトラフィックを運び、peered 接続自体に VPN ゲートウェイを必要としません。これは転送についての記述であり、監査担当者に「IPsec を運用しています」と渡せる暗号化の記述ではありません。要件が顧客設定のトンネル、特定の IKE ポリシー、または自分が管理する機器で終端する境界を名指しするなら、バックボーンがどれほどプライベートでも Peering はそれを満たしません。

VNet 間 VPN はその境界を提供します。二つのゲートウェイ、IPsec/IKE の関係、共有キー、そしてそれに伴う運用面のすべてです。トンネルの状態、ゲートウェイの容量、SKU の上限、トンネルが上がっていることを示す監視を引き継ぎます。要件がまさにその境界を指す場合の正解であり、その境界は Peering の概要 で Peering とは別の接続種別として説明されています。

逆方向にも同じだけ注意してください。「VNet 間に暗号化が必要」は多くの場合ワークロード自身の TLS で満たされ、そのときゲートウェイは後ろに要件のないコストです。仕組みを選ぶ前に、監査担当者が読む一文を書いてください。

条件 2: トポロジは直接か、何かが通過する必要があるか

Peering は推移的ではありません。ハブに peered された二つの VNet は、それだけで互いに接続されるわけではなく、片方向で動くように見えるルートは通常、片側だけで Connected に達した Peering です。両側が存在し、両方が Connected を示す必要があり、トラフィックが静かに消えたときに最初に確認するのはそこです。

要件がハブ経由のオンプレミス到達性なら、ゲートウェイ トランジットは特定の役割を持つ別設計です。ハブがゲートウェイを所有し、スポークの Peering がゲートウェイ トランジットを許可し、スポークは転送トラフィックを許可する必要があります。これらは Peering 上のプロパティであり、VNet をつなぐことの自動的な結果ではありません:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

有効なルート テーブルが「経路は存在するか」への正直な答えです。プラットフォームが実際に使う次ホップの種類を示すので、設定されているように見えて接続されていない Peering は、謎ではなく欠落した、または誤ったルートとして現れます。

条件 3: 推移経路と請求を誰が持つか

追加のホップにはすべて所有者がいます。Peering では、新しい VNet は両側に新しい Peering ペアを意味し、トランジットのためにはトラフィックを転送し続けるハブと、そこを指し続けるルート テーブルが要ります。VPN では、新しい VNet は別のゲートウェイ、または既存のゲートウェイ上の別の接続を意味し、監視すべき容量の上限が付きます。

コストは同じ形をたどりますが同じ費目ではありません。Peering の課金は接続とデータ転送で、VPN はゲートウェイ時間と独自の転送課金を加えます。実際に一年動かすトポロジの総額を比較してください。二本目のトンネルと監視を含め、今日の一本の接続の価格ではありません。誰も請求しない作業も入れてください。鍵を回し、トンネルの状態を見て、ゲートウェイが再起動した午前三時のアラートに答える人が要ります。通常この費目が議論を決めます。見積もりに決して現れない唯一の費目だからです。

どちらを選んでも三つのフローを試してください。意図したもの、拒否されたままでなければならないもの、ハブのゲートウェイや Peering が落ちている復旧ケースです。幸せな経路だけを説明するモデルは検証されたのではなく、実演されただけです。

選択をそれ自身の主張と突き合わせる

モデル、境界、所有者を名指しする一文を書き、デプロイされた状態がそれと一致するか確認します。Peering なら、両方の Peering 状態が Connected、有効なルートが宛先プレフィックスの Peering 次ホップを示す、経路にゲートウェイがない、の三つです。VNet 間 VPN なら、両方の接続が Connected、両方のゲートウェイで鍵とポリシーが一致、次ホップが仮想ネットワーク ゲートウェイであるルート、の三つです。

確認が一文と食い違うなら、まず一文を直してください。こうした設計の混乱の多くは、誰も説明していない混成から来ます。ワークロードのサブネットに Peering、一つの旧サービスに VPN、そして静かにどちらかを優先するルート テーブルです。