Claude が書いた記事
Azure VNet 暗号化の裏側 ── SmartNIC が境界で全自動暗号化
VNet 暗号化をポチッと ON にすると VM 間通信が暗号化される ── VM は何も設定してないのに、いつ・どこで暗号化されるんや？ SmartNIC が境界で DTLS を全自動でかける仕組みを、eSwitch のハードオフロードの続きとして掘った学習ログ。
俺の最初の疑問
Azure の VNet 暗号化を、ポータルでポチッと ON にするだけで、VNet 内の VM 間通信が暗号化されるらしい。でも VM の中では何も設定してへん。いつ、どこで暗号化されてるんや？ vNIC で受け取った後か？
まず一言でいうと
暗号化してるのは VM やなくて、ホストの SmartNIC。VM が送った平文パケットを、物理ネットに出る境界で SmartNIC が DTLS でカプセル化して暗号化し、受信側ホストの SmartNIC が復号してから VM に渡す。VM / OS は暗号化を一切意識せず、CPU 負荷もほぼゼロ。Microsoft のドキュメントも VM 間を “creating a DTLS tunnel” で暗号化する、と明記している (MS Learn)。
これは前の記事の eSwitch / VFP のハードオフロード の応用や。あそこで「eSwitch はフロー単位で暗号化などをハードでやる」と裏取りした ── その暗号化の具体例が、この DTLS。
どこで暗号化されるのか
物理的なエンドポイントは ホストの SmartNIC。流れを追うとこうなる。
だから「VM が受け取った後に復号」やない ── VM の VF に届く前に、もう平文に戻ってる。なぜ VM 内でなく境界の SmartNIC かというと、(a) VM の CPU を食わない、(b) SmartNIC のハード暗号回路でラインレート処理できるから。ここが AccelNet 必須の理由や。SR-IOV で VF が SmartNIC に直結してないと、境界でハード処理させられない (この直結の仕組みは eSwitch 記事を参照)。
SmartNIC はどうやって「暗号化する」と判断するのか
SmartNIC が空気を読んでるんやない。Azure の SDN コントロールプレーンが、事前に SmartNIC のハードへ「このフローは DTLS 暗号化せよ」というルールを焼いている。ソフトが決めた論理を、ホスト OS を介して SmartNIC の物理シリコンにプログラミングする、というバケツリレーや:
- コントロールプレーン → ホスト OS の VFP … VNet 暗号化を ON にした瞬間、コントローラーが「対応 VM の名簿 ＋ 暗号化ポリシー」を、その VM が載る物理ホストの VFP (仮想スイッチ拡張) に配る。
- VFP → SmartNIC のシリコン … VFP は「これは CPU で処理せずハードに丸投げ」と判断し、ルールを SmartNIC の FPGA 上の GFT (Generic Flow Table) に焼く。前の eSwitch 記事 の VFP ハードオフロードと同じ機構で、Azure の筋肉はこの FPGA / GFT や (Firestone et al., NSDI 2018)。
こうしておくと、本番では VM からパケットが飛んだ瞬間、SmartNIC がハードで GFT を一瞬照合し、一致したフローだけ DTLS 暗号化して送り出す ── CPU を一切経由せず、ワイヤーレートで。
そして粒度は VNet でなく VM (NIC) 単位。ここが一番の勘どころや。
もし VNet を一括で暗号化してしまうと、非対応 VM 宛てまで DTLS 化されて相手が復号できず、通信が全滅する。だから実際は「対応 VM (NIC) と 対応 VM (NIC) の間だけ狙い撃ちで DTLS 化」に翻訳される。
混乱しやすいポイント
① VNet 単位で ON、でも適用は VM ペア単位
「対応 SKU ＋ AccelNet」を満たす VM 同士だけ自動暗号化。非対応 VM 宛ては平文で、通信は切れない (上の図)。
② 既存 VM は停止 / 開始が要る
VNet 暗号化を ON にしても、起動中の既存 VM は即座には始まらん。停止 (割当解除) → 開始で、SmartNIC に暗号化フローを焼き直させる必要がある (MS Learn: “start/stop of existing virtual machines is required”)。
③ カバー範囲は「VNet 内の VM ↔ VM」だけ
暗号化されるのは VM の private IP 間 (同一 VNet / ピアリング先) の通信だけ。インターネット向け・PaaS・オンプレ向けは対象外や。ExpressRoute Gateway とは併用すると通信が壊れ、App Gateway / Azure Firewall とも併用できない、といった制約もある (MS Learn)。
で、なんで顧客はこれを欲しがるのか
仕組みを知るほど「クラウド SDN の内部なんて誰が覗けるんや」と思う。それでも需要はある。
- ゼロトラスト: Microsoft のインフラのバグ (SDN の誤ルーティングで他人のホストにパケットが漏れる等) すら想定した保険。
- コンプライアンス: 金融・政府・医療の監査基準が「データセンター内でも暗号化」を要求する。技術的な安全性の説明より「暗号化のチェックボックスに ✓」が要る。
- タダで性能が落ちない: 従来 IPsec の CPU 負荷・遅延・鍵管理の地獄が無い。ON にしない理由がない。
用語の早見表
| 言葉 | つまり何の話？ |
|---|---|
| VNet 暗号化 | 同一 / ピアリング VNet の VM 間トラフィックを、ホストの SmartNIC が DTLS で自動暗号化する Azure の機能 |
| DTLS | UDP の上で TLS の暗号化をやる版。VNet 暗号化のトンネルに使われる (解説) |
| SmartNIC | 暗号化回路を積んだ高機能 NIC。境界でハード暗号化・復号する物理エンドポイント |
| VFP | Virtual Filtering Platform。ホスト OS の仮想スイッチ拡張。ルールを SmartNIC にハードオフロードする |
| AccelNet | Accelerated Networking。VNet 暗号化の必須条件。VM に SR-IOV の VF を割り当て、vSwitch をバイパスして SmartNIC に直結する |
| SR-IOV | 1 枚の NIC を複数の VF に分割し、VM に直結する仕組み。仮想スイッチをバイパスする |
| VF | Virtual Function。SR-IOV で VM に割り当てる NIC の口。AccelNet の高速パス (暗号化がかかる) はこれ。synthetic な vNIC は予備 |
| フローテーブル | SmartNIC 上の「条件 → アクション」の表。コントロールプレーンが暗号化ルールを焼く先 |
| MACsec | IEEE 802.1AE。Azure が DC 間の物理リンクで常時かける L2 暗号化。VNet 暗号化とは別物 |
で、VNet 暗号化を入れるか、どこまでを基盤に任せるんや？
- 基盤 (SmartNIC) に任せるか / 別の層でやるか。 VNet 暗号化がカバーするのは「同一 / ピアリング VNet の VM ↔ VM (private IP)」だけ。判断軸は「守りたい通信がこの範囲に収まるか」。インターネット / PaaS / オンプレ向けや、アプリの end-to-end はカバー外なので、そこは TLS など別の層が要る。
- 責任境界: SmartNIC が守るのは VNet 内の VM 間リンクまで。それを越える暗号化はアプリや別機能の責任。制約 (AccelNet 必須、ExpressRoute Gateway・App Gateway・Firewall と併用不可) を踏めるかも判断軸に入る。
これに答えられると強い ── 「とりあえず全部 ON」でなく、どの通信をどの層 (基盤の DTLS / アプリの TLS / DC 間の MACsec) で守るかを、地図で言える側に立てる。
この記事の続きとして、未来の自分が次に掘るといいトピック。
- MACsec (IEEE 802.1AE) ── Azure が DC 間の物理リンクで常時かける L2 暗号化。VNet 暗号化 (DTLS) との住み分けで「どの層で守るか」の地図が完成する。
- Geneve / VXLAN オーバーレイ ── VNet が多重カプセル化でマルチテナントを分離する仕組み。今回の DTLS の内側にある層。
- Confidential Computing ── 通信でなく「使用中のデータ」を VM の中で守るアプローチ。基盤に任せる VNet 暗号化とは守る対象が違う。