Skip to content

MS_AzureVirtualNetwork

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 2 revisions

Azureの仮想ネットワーク

概要

≒ Azure Virtual Network (VNET)

詳細

ネットワーク

オーバーレイ・ネットワーク

VFP（Virtual Filtering Platform） と呼ばれる仕組みで実装されている。

アンダーレイ・ネットワーク

オーバーレイ・ネットワーク下で動作する物理ネットワーク。

移行メモ（略語）: 元ページは「VPF（Virtual Packet Filtering）」と
表記しているが、Azure のホスト側 SDN データプレーンの正式名称は
VFP（Virtual Filtering Platform） である。
Microsoft の論文（NSDI'17 "VFP: A Virtual Switch Platform for
Host SDN in the Public Cloud"）で公表されている。

実装としては、Hyper-Vの仮想スイッチ拡張として動作し、
VXLAN によるカプセル化でテナントを分離している
（Hyper-V ネットワークの仮想化を参照）。

動作上の問題

主要な 4 つの問題。

# 問題
1 IP アドレス固定は OS から行わない（Azure 側で静的割り当てにする）
2 NIC は、通常、1 枚挿し ＋ NSG（2 枚挿しも可能だが）
3 NLBが動作しない（VFP は NLB と組み合わせ不可能）
4 VFP は MSCS/WSFCの仮想 IP と組み合わせ不可能
  • 4 の対処
    • ILB（Internal Load Balancer）を利用する。
    • 共有ディスク型クラスタから、AlwaysOn などの
      レプリケーション型クラスタへ。

補足（この 4 点が「クラウドは違う」の核心）: いずれも
**「OS から見た IP と、実際のネットワークが一致しない」**ことに起因する。

問題 理由
OS から IP を固定するな Azure の DHCP が正。OS 側で固定すると再起動で通信不能になる
NLBが動かない NLB は同一 MAC を複数ノードで名乗るが、VFP が偽装として弾く
WSFC の仮想 IP が動かない 仮想 IP の Gratuitous ARP が VFP を通らない

オンプレの構成をそのまま持ち込むと必ず踏むため、
**クラウドでは「ロードバランサーを使う」**のが原則になる。
これは AWS（ENI / セキュリティ グループ）でも事情は同じである。

その他の問題。

  • ILB の NSG が機能しない問題
  • SNAT ポートの枯渇問題
    以下の②、③のケースで SNAT ポートを使用する。
    • ①：仮想マシン（パブリック IP アドレス無し）
    • ②：仮想マシンにパブリック IP アドレスを付与
    • ③：仮想マシンに ELB（External Load Balancer）を付与
      SKU が Standard だと、SNAT ポートを調整可能らしい。
  • Azure サービスの送信元が、パブリック IP アドレスにならない問題
    • 異なるリージョンの場合、インターネットを経由するのでパブリック IP。
    • 同じリージョンの場合、アンダーレイ・ネットワークを経由するのでプライベート IP。

補足（SNAT ポート枯渇は定番の障害）: 外向き通信が多いアプリで
突然接続できなくなるという障害の主犯である。

  • 既定の SNAT ポートはインスタンスあたり 1024 個程度（構成による）。
  • TIME_WAIT が 4 分間ポートを掴むため、
    短時間に大量の外部 API 呼び出しをすると枯渇する。
対策 内容
NAT Gateway を使う 最も確実。ポート数が大幅に増える（現在の推奨）
接続を使い回す HttpClient を使い捨てにしない（HttpClientの利用方法を参照）
送信規則で明示配分 Standard LB の送信規則でポート数を割り当てる

2 番目はアプリ側の定番の実装ミスでもあり、
HttpClient を using で毎回破棄していると
ソケットが枯渇する（クラウドに限らない問題）。

サブネッティング

VNET 内をサブネッティングできる（Azureのサブネッティング）。

ルーティング

Gateway Subnet

  • VPN Gateway を作成する際の
    VPNルータの VM と IP アドレスが存在する Subnet
  • 1 VNET、1 Gateway Subnet になるので注意

User Defined Route (UDR)

VNET のデフォゲ（ルータ）のルーティング・テーブルの設定。

VNETに接続する。

方式 用途
VPN Gateway（VPN Gateway） インターネット経由の暗号化トンネル
Azure ExpressRoute 専用線。帯域と SLA が保証される
Azure Peering Service ISP 経由の経路最適化
仮想ネットワーク ピアリング VNET 同士を接続
Azure Private Link / Endpoint PaaS を VNET 内の私設 IP で利用
OA-LANとAzureのVNETの分離 業務 LAN との分離設計

インバウンドとアウトバウンド

FgCF 関連

FgCF (Financial-grade Cloud Fundamentals)

オンプレ延伸の構築

  • VPN Gateway
  • 専用線（Azure ExpressRoute / Azure Peering Service）

境界型（Hub & Spoke）構成

  • 技術
  • Hub に配置するモノ
    • 各種ゲートウェイと踏み台、若しくは Azure Bastion
    • DNS/DHCP、運用管理サーバ
  • Hub Ex
    • Hub に必要な IP アドレスが増えていく。
    • その際、仮想ネットワーク ピアリングで Hub を拡張する。

代表的な構成パターン。

パターン 内容
オンプレ延伸型 Hub & Spoke 構成
オンプレ連携型 上記 + Spoke にインバウンド + WAF
浮島型 上記から Hub & Spoke のピアリングを切断。データ連携はストレージ等で

補足（Hub & Spoke が定石である理由）: 共通機能（ゲートウェイ・
ファイアウォール・踏み台・DNS）を Hub に集約し、
システムごとの VNET を Spoke として繋ぐ。

利点 内容
コスト 高価な ExpressRoute Gateway を 1 つで共用できる
ガバナンス 出入口が Hub の 1 箇所に集まる。監査しやすい
分離 Spoke 同士は既定で通信できない（ラテラル ムーブメント対策）

最後の点が重要で、「1 つの Spoke が侵害されても
他の Spoke に横展開されない」という設計になる。
Azure の推奨アーキテクチャ（Cloud Adoption Framework）でも
標準の型とされている。

ゼロトラスト型構成

オンプレ延伸型の境界型（Hub & Spoke）構成の Hub から、
個別の Hub & Spoke を Azure Private Link / Endpoint で接続。

PaaS・SaaSの閉域化

手段 内容
VNET Injection VNET 上に PaaS を組み込む形で配置。使えるサービスが限定的で高価
Azure Private Link / Endpoint VNET 上に Endpoint を引き込む。廉価で主要な方法
Azure Service Endpoint 同上（経路のみ。IP はパブリックのまま）
Azure Firewall PaaS への外向き通信のロックダウン。高価

補足（Private Endpoint と Service Endpoint の違い）: 混同されやすいので
整理しておく。

Service Endpoint Private Endpoint
PaaS の IP パブリックのまま VNET 内の私設 IP
経路 Azure バックボーン経由 同左
オンプレから使えるか 不可 可（VPN / ExpressRoute 経由）
DNS 変更不要 プライベート DNS ゾーンが必要
課金 無料 有料

「オンプレから閉域で PaaS を使いたい」なら Private Endpoint 一択。
ただし DNS の設計が要る点が導入時の主な難所になる。

参考

Microsoft Learn

Tags: 移行, インフラストラクチャ, クラウド, Azure, 通信技術

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

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally