[Day5] Azure のネットワークがさっぱり分からん

# Microsoft Azure Tech Advent Calendar 2018 の 5 日目です。

今回は、インフラ野郎が大好きな Azure のネットワークについて整理してみたいと思います。

4 種類の Azure ネットワーク

Azure  のネットワークは、大きく 4 種類に分かれます。

  • Private IP (Azure VNET) のネットワーク: VNET 内に展開される VM 等
  • Public IP (VNET 外) のネットワーク: VNET 外に配置される各種 PaaS や、VM の Public IP 等
  • Azure 基板側のネットワーク: バックボーン ネットワークや、物理サーバー用 (ユーザーからは見えない部分)
  • Azure 外に存在するネットワーク: Azure DNS や Traffic Manager、CDN、FrontDoor 等

ざっくり図にすると、こんな感じになります。

# よくある誤解

たまに Azure Storage や SQL Database 等の PaaS に対して VPN 接続したいという話を聞きますが、VPN 接続出来るのは VNET のみですので、Public IP の世界に接続したい場合には ExpressRoute の Microsoft Peering が必要です。(もしくは、App Service Environment や SQL Database Managed Instance のように VNET 内に専用のインスタンスを建てられる上位プランを使用する必要があります。)

また、Azure のサービスであっても、Azure データセンター外の Public IP からサービスを提供する Azure DNS, Traffic Manager, CDN, FrontDoor 等のサービスについては、VPN でも ExpressRoute 経由でもアクセスすることが出来ません。(これらは Internet 経由のアクセスを前提としたサービスなので、閉域環境で使う事を想定されていません) くわえて、内部的にこれらを使っているもの (例えば Azure Portal とか) に対しても、ExpressRoute 経由で閉域だけで接続するといったことは出来ませんので気をつけましょう。

物理的なネットワーク構成

Microsoft が世界中に保有するバックボーン ネットワークや、Azure データセンター内のネットワーク アーキテクチャについては、多少情報が古いものも混じってますが以下が参考になります。使用しているスイッチやルーターの名称まで記載されているものもあるので、インフラ野郎は隅から隅まで目を通すと興味深いかと思います。

# 以下、上記から拝借。

Microsoft 所有の Global Network の全体像。水色が自社所有、濃い青が借用、点線が計画中のもの。

Azure の各リージョンは Microsoft の Global Network (WAN) に接続され、世界中の Edge から Internet や ExpressRoute で接続されます。

各リージョンには複数のデータセンターがあり、RNG (Regional Network Gateway) で束ねられています。

データセンター内は、Quantum 10 (Q10) のアーキテクチャが採用され、以下の様な機器が使用されているらしいです。

VNET の仕組み

IaaS ユーザーの方からすると、先のような概念的な話よりも、Azure VNET の方が身近かと思います。

が、VNET の仕組みをきちんと理解した上で使っている人は少ないのではないかと思うので改めて。

Azure では、数百万台規模の物理サーバーが世界中に存在しています。VM はリージョン内のどこかの物理サーバー上でホストされますが、同一 VNET 内の VM 間の通信はどのように行われているかを考えるには、Azure 基板側のアンダーレイ ネットワークと、VNET 側のオーバーレイ ネットワークを意識する必要があります。

ここでは、以下の図のように 2 台の物理サーバー上に 2 つの VNET (A, B) が存在している場合を考えます。VNET A の 10.0.0.4 -> 10.0.0.5 宛に通信する場合は、物理サーバー上で一度カプセル化されてアンダーレイ ネットワーク上でルーティングされます。

# VNET A と B は論理的に分離されているので、別 VNET に同一の Private IP を持つ VM が乗っていても問題は起きません。

VFP の仕組み

こうした Azure の SDN を支えているのが、Hyper-V の Virtual Switch で動作する VFP (Virtual Filtering Platform) です。

詳しいことは Windows Server 2016 等の HNV 系のドキュメントや、Microsoft Research の論文を読むと理解が深まります。

論文内の画像を抜粋しつつ、かいつまんで説明すると、Hyper-V の仮想スイッチ上でフィルター ドライバーの用に振る舞い、Ingress / Egress のトラフィックに対しての処理を行うのが VFP です。

VFP ではどのような処理が行われるかというと、以下の図のように大きく 4 種類の処理があります。

  • VNET: 前述のアンダーレイ・オーバーレイ ネットワーク間のカプセル化 (encap / decap) を担います。
  • NAT: Public IP で受信したパケットを VNET 内の Private IP に変換したり、LB 経由の通信の NAT を担います。
  • ACLs: Network Security Group (NSG) の機能に該当するものです。
  • Metering: 各種メトリックのデータ取得を担います。課金メーターもこのレイヤーで行っています。

# ちなみに、上図の略称はそれぞれ以下の通り

  • PA: Physical Address (基盤側の IP アドレス)
  • CA: Customer Address (VNET 内の Private IP アドレス)
  • VIP: Virtual IP (Public IP のこと)
  • DIP: Dynamic IP (Private IP のこと)

VNET 内の通信を行う場合

では、もう少し噛み砕いて見てみましょう。(Metering は通信に直接関係しないので省略)

10.0.0.4 の VM からパケットが出て行く際は、10.0.0.4 -> 10.0.0.5 の通信として NIC および Subnet のNSG 送信規則で評価が行われます。その後カプセル化が行われ、送信元の物理サーバーの PA -> 宛先 IP の VM をホストする物理サーバーの PA (192.0.2.1 -> 192.0.2.2) のように Azure 基盤のネットワーク上をルーティングされます。

受信側ではカプセル化を解除するとともに、そのパケットが自身のホストするどの VM / VNET 宛なのかを判断し、Subnet および NIC の NSG で受信規則に基づいて評価を行います。

Azure VM 間で通信をする際、通常ここまで意識はしませんが、実は裏では VFP が頑張ってくれています。

VM の Public IP 宛の通信の場合 (LB 宛もほぼ同等)

続いて、Azure VM の Public IP 宛に通信が来た場合を考えてみます。

Internet 側からパケットが届きますが、VFP は Public IP と Private IP の対応を知っているため、宛先 IP を DNAT して VM に渡します。

反対に、戻りのパケットでは SNAT をして Src IP を Public IP に書き換えてから出ていきます。

なお、NSG の評価は受信方向の通信であれば Public IP や LB の NAT 処理後、送信方向の通信であれば NAT 処理前に行われるので、VM の Private IP のまま評価されます。

# たまに、Public IP 宛に届いた通信を NSG でブロックしようとする人がいますが、そんなことはできません。

UDR を設定した場合の挙動

次に、仮想アプライアンス (NVA) を構築する場合などで、全ての宛先 (0.0.0.0/0) 宛の通信を NVA へ向けるような UDR を設定した場合を考えてみます。

前述の 10.0.0.4 -> 10.0.0.5 宛の通信と似ていますが、送信元の物理サーバー上でカプセル化が行われる際、UDR を向けた NVA がホストされている物理サーバーの PA 宛として Azure 基盤側でルーティングが行われます。

この辺りは SDN 特有で、慣れないと混乱しますが、分からなくなったら落ち着いて図にするのが吉です。

Azure ネットワーク、ムズカシイネ。

その他、Azure のネットワークを理解するうえで参考になる資料

1 comment for “[Day5] Azure のネットワークがさっぱり分からん

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください