Skip to content

MS_AzureVNetPeering

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azureの仮想ネットワーク ピアリング

概要

  • VNET ピアリング
  • Azure の仮想ネットワーク同士を、Azure のバックボーン・ネットワークを使用して接続する機能

詳細

特徴

以下のリソース無しで簡単に接続が可能。

補足（VNET ピアリングが安い理由）: ゲートウェイが不要という点は、
費用と性能の両方で効いてくる。

VNET ピアリング VNET 間 VPN（V2V）
必要なリソース 無し VPN Gateway × 2（時間課金）
帯域 VM の NIC の上限まで Gateway の SKU の上限（ボトルネック）
遅延 低い（バックボーン直結） 高い（暗号化・GW 経由）
課金 転送データ量のみ（受信・送信とも） GW の時間課金＋転送量
暗号化 無し（バックボーン内） IPsec

同一テナント内の VNET 同士を繋ぐなら、原則ピアリングである。
VPN Gateway を挟む理由はほぼ無い。

ただし、アドレス空間が重複していると接続できないという
絶対的な制約がある（Azureのサブネッティング）。
ここは後から直せないため、IP 設計の段階で押さえておく必要がある。

ただし、2ホップ通信ができない。

  • Spoke 同士の接続のためには、
    • 別のピアリングを定義する（メッシュ状になる）。
    • Azure Firewallのパケット・フォワーダを使用する。
  • HUB → Spoke → DMZ とした時、
    • DMZ から HUB への侵入を抑止できる。
    • ただし、DMZ → HUB 直ではない、段階的な攻撃は可能。
    • 故に、Azure Private Link / Endpointの方が安全。

移行メモ（正誤）: 原典の「２ポップ通信」は
「2 ホップ通信」の誤りであるため修正した。

補足（「推移的でない」が VNET ピアリング最大の性質）: この制約は
ハブ＆スポーク構成を設計するうえで決定的に重要である。

【VNET ピアリングは推移的（transitive）ではない】

  Spoke1 ←──ピアリング──→ Hub ←──ピアリング──→ Spoke2
     └──────────── ✕ 通信できない ────────────┘

オンプレのルーティングの感覚では
「Hub を経由して届くはず」と考えてしまうが、届かない。
ピアリングは1 対 1 の直結でしかない。

Spoke 間を通信させる手段は 3 つある。

手段 内容 欠点
フル メッシュ Spoke 同士も直接ピアリング N×(N-1)/2 本になり管理不能に
Hub に NVA / Azure Firewall UDR（ルート テーブル）で Hub の Firewall に向け、そこで転送 Firewall の費用（高い）
Azure Virtual WAN マネージドのハブ。推移的ルーティングを提供 別サービスの契約

本文が「Azure Firewall のパケット フォワーダ」と言うのは 2 つ目の方法である。

そして、この制約はセキュリティ上の利点でもある。
本文が「DMZ から HUB への侵入を抑止できる」と述べているとおり、
意図しない経路が自然に塞がっている（デフォルト拒否）。
フル メッシュにすると、この利点を捨てることになる。

「段階的な攻撃は可能」という指摘は、
Spoke を踏み台にして、そこからピアリング先へ進む攻撃を指す。
経路の存在自体を消す Private Link の方が
攻撃面が小さい、というのが本文の結論である。

異なるAzureリージョン間でも接続が可能

グローバル VNET ピアリング

異なるAzureサブスクリプション間でも接続が可能

https://learn.microsoft.com/ja-jp/azure/virtual-network/create-peering-different-subscriptions?tabs=create-peering-portal

補足（サブスクリプション／テナントを跨ぐ場合の要点）: 跨いだ接続は可能だが、
両側で操作が必要という点に注意が要る。

条件 内容
両側で作成する ピアリングは双方向に 2 つ定義して初めて Connected になる（後掲の手順）
権限 相手側の VNET に対する Network Contributor 相当の権限が要る
テナントを跨ぐ場合 相手テナントにゲスト ユーザとして招待されるか、相手に作業してもらう
アドレス重複 不可（同一テナントと同じ）

「片側だけ作って繋がらない」というのは最も多い躓きどころで、
後掲の「状態確認」で peeringState が
Initiated のままであればこれが原因である。

接続方法

ポータル

→ 参考

IaC化

  • Azure PowerShell
    → 参考
  • Azure CLI → 参考
    参考先は Bash での例だったので、以下、Windows の CMD で Temp ファイルを使用する方法。

    • ID を取得

      • VNET1

        az network vnet show --resource-group [既存のRG名] --name [既存のVNET1名] --query id --out tsv > d:\temp_cmd_result.txt
set /p vNet1Id= 0<d:\temp_cmd_result.txt
del d:\temp_cmd_result.txt
echo %vNet1Id%

      • VNET2

        az network vnet show --resource-group [既存のRG名] --name [既存のVNET2名] --query id --out tsv > d:\temp_cmd_result.txt
set /p vNet2Id= 0<d:\temp_cmd_result.txt
del d:\temp_cmd_result.txt
echo %vNet2Id%

    • 接続
      単方向という概念はない模様（必ず双方向定義する）

      • VNET1 → VNET2

        az network vnet peering create ^
--name [VNET1 → VNET2のVNETピアリング名] ^
--resource-group [VNET1のRG名] ^
--vnet-name [VNET1の名称] ^
--remote-vnet %vNet2Id% ^
--allow-vnet-access

      • VNET2 → VNET1

        az network vnet peering create ^
--name [VNET2 → VNET1のVNETピアリング名] ^
--resource-group [VNET2のRG名] ^
--vnet-name [VNET2の名称] ^
--remote-vnet %vNet1Id% ^
--allow-vnet-access

    • 状態確認
      両方の接続が完了すると、peeringState が Initiated → Connected になる。

      • VNET1 → VNET2

        az network vnet peering show ^
--name [VNET1 → VNET2のVNETピアリング名] ^
--resource-group [VNET1のRG名] ^
--vnet-name [VNET1の名称] ^
--query peeringState

      • VNET2 → VNET1

        az network vnet peering show ^
--name [VNET2 → VNET1のVNETピアリング名] ^
--resource-group [VNET2のRG名] ^
--vnet-name [VNET2の名称] ^
--query peeringState

補足（--allow-* オプションの意味）: 例では
--allow-vnet-access のみを指定しているが、
ハブ＆スポーク構成では残り 3 つのオプションが要点になる。

オプション 意味 ハブ側 スポーク側
--allow-vnet-access 相手 VNET との通信を許可 ○ ○
--allow-forwarded-traffic 相手から転送されてきた（NVA 経由の）通信を受け入れる ○ ○
--allow-gateway-transit 自分の GW を相手に使わせる ○（ハブ側） ✕
--use-remote-gateways 相手の GW を使う ✕ ○（スポーク側）

後半 2 つがゲートウェイ トランジットであり、
これにより

オンプレ ══[ExpressRoute/VPN]══ Hub VNET（GW を持つ）
                                    ↕ ピアリング（gateway transit）
                                Spoke VNET（GW 無し）← オンプレから到達できる

という構成が可能になる。
スポークごとに GW を立てる必要が無くなるため、
費用面での効果が非常に大きい
（Azureの課金の「Gateway 系」）。

前掲の「2 ホップ通信ができない」の例外がこれで、
GW 経由のオンプレ通信だけは推移的に扱える。
ただし Spoke ⇔ Spoke は依然として通らない。

補足（CMD での一時ファイル利用について）: 本文の
「Temp ファイルを使用する方法」は CMD の制約を回避する定番の手だが、
PowerShell を使えば一時ファイルは不要である。

$vNet1Id = az network vnet show -g <RG> -n <VNET1> --query id -o tsv
$vNet2Id = az network vnet show -g <RG> -n <VNET2> --query id -o tsv
az network vnet peering create --name peer1to2 -g <RG> --vnet-name <VNET1> `
    --remote-vnet $vNet2Id --allow-vnet-access

CMD でも、FOR /F を使えばファイルを介さずに済む。

for /f "usebackq delims=" %i in (`az network vnet show -g RG -n VNET1 --query id -o tsv`) do set vNet1Id=%i

なお、恒久的な構成管理としては
Bicep / ARM テンプレートで宣言的に書くのが望ましい
（Azureによる基盤開発法）。

参考

Microsoft Docs

チュートリアル

VNet ピアリングを使用して仮想ネットワークを接続する

Tags: 移行, インフラストラクチャ, クラウド, セキュリティ, 通信技術, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally