Azureにおける IPv4アドレス枯渇との戦い方 Toru Makabe Sr. Cloud Solution Architect Microsoft

Agenda • IPv4アドレスが足りない • 解決のアイデア • 実装例1: Private Link サービス • 実装例2: Carrier-Grade NATアドレス空間の活用

お断り IPv6の話はしません

IPv4アドレスが足りない 企業におけるプライベートIPv4アドレス空間

「空いてません」 Azure Container Apps 環境でのネットワーク | Microsoft Learn （注）これは従量課金のみの環境 の条件です。ワークロードプロ ファイル環境では、/27

プライベートIPv4アドレスが足りない • 大企業、歴史のある企業では特に足りない • グループ内の企業/組織間接続、吸収合併の歴史、etc • クラウドで完結しない企業システムは多い • オンプレに必要なデータがある • アドレス枯渇が挑戦の足を引っ張っている • アドレスが足りず、クラウド上に新しい環境が作れない、もしくは設計の強い制約となる • 特にコンテナ環境で顕著 • 技術的ノウハウがない、ビジネス環境を読めない状況での試行錯誤ができない • 妥協して小さなレンジで切る -> ビジネスの成長で業務量増える -> でも拡張できない • 誰かを責めても解決しない • ネットワーク担当者も困っている

解決のアイデア

基本的な考え方 • 大抵は、既存ネットワークに全アドレスを公開する必要はない • WebサーバやAPIエンドポイントなど限られたアドレスを公開できればよい • 新環境（Landing Zone）の通信の多くはそのネットワークに閉じる（East-West） • ならば、公開/非公開ネットワークを分けるといいのでは • 公開すべきアドレスに絞った公開ネットワークを、既存アドレス空間に追加する • それとは別に、自由に設計できる非公開ネットワークに新環境を作る • 公開/非公開ネットワーク間でNAT/プロキシする • 昨今、拡充/公開されたサービスやノウハウを活用する • Private Linkサービス • Private DNS Resolver • Carrier-Grade NATアドレス空間（RFC 6598 - 100.64.0.0/10）の活用

Landing Zone B Landing Zone A 概念図 オンプレミス Hub ・ ・ ・ 閉域網 既存アドレス空間 同一Landing Zone外の既存 ネットワークに、このアド レス空間を伝えない 受信/送信エンドポイ ントとなるサービス を配置する オンプレミス、 Landing Zone間の転送 や名前解決を支える サービスを配置する

実はMS Learnで紹介されている手法です Azure での IPv4 枯渇の防止 - Azure Architecture Center | Microsoft Learn

Private Link サービスで解決する 実装例1

Private Linkサービスとは Azure Private Link サービスとは | Microsoft Learn Private Linkはマネージドサービス向けで一般的 だが、実はユーザーが”Private Linkサービス”を作 り、非ピアリングVNetへのNATに使える

Any prefix!! 広大!! 浪漫!! Azure での IPv4 枯渇の防止 - Azure Architecture Center | Microsoft Learn 俺たちは自由だ!! 俺たちは自由だ!!

だがしかし “NIC によってバックエンド プールが構成されている Standard Load Balancer でのみサポートされます。 IP アドレスによってバックエン ド プールが構成されている Standard Load Balancer ではサポートさ れていません。” Azure Private Link サービスとは | Microsoft Learn NICバックエンドのみということは、実質、VM相手にしか使えないのですか…? （注）AKSの内部ロードバランサーなど、Load Balancerがユーザーに見えている一部のマネージドサービスでは使えます

安心してください 挟めますよ Azure Application Gateway の Private Link | Microsoft Learn Application Gatewayを挟み、非VMも ターゲットにできる

送信方向もPrivate Linkサービスで解決 送信方向にもPrivate Link サービスを作り、経路を 定義する SNATできるVM （NVA）を作る Azure での IPv4 枯渇の防止 - Azure Architecture Center | Microsoft Learn

この実装案の考慮点 • 受信に絞れれば、とてもお手軽 • 送信は若干面倒 • NVAを構築維持する必要がある • マネージドサービス志向なら、「グッとこない」選択肢 • Private Linkサービスではなく、VNet間をピアリングして、Private SNATできるマネージド サービス（Azure Firewallなど）を使えないものか

Carrier-Grade NATアドレス空間で解決する 実装例2

Landing ZoneのVNet間をピアリングする Azure での IPv4 枯渇の防止 - Azure Architecture Center | Microsoft Learn Non-routable LZの存在は、このVNetだけが 知っている（経路を伝搬させない）

受信方向の転送 Azure での IPv4 枯渇の防止 - Azure Architecture Center | Microsoft Learn Application Gatewayなどの リバースプロキシを置く

送信方向の転送 Azure での IPv4 枯渇の防止 - Azure Architecture Center | Microsoft Learn SNATにマネージドサービス （Azure Firewall）を使う

Non-routable LZのアドレス空間はどうする? Azure での IPv4 枯渇の防止 - Azure Architecture Center | Microsoft Learn ？ ？ • 既存ネットワークで使われて ない空間（Routable LZから の経路が衝突しないように） • 設計の自由度が高く、ビジネ ス成長に対応し、試行錯誤で きる広い空間 • 既存ネットワークで使ってい なければ、複数のNon- routable LZで重複できる でも…そんな空間ありますか?

RFC 6598 (100.64.0.0/10) RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space (rfc-editor.org) • 背景: ISPなどネットワークプロバイダが IPv4アドレス枯渇に対応するため、NATの ための広い空間が必要だった • Azureにおいても、100.64.0.0/10はプライ ベートアドレス空間として扱われ、イン ターネットへルーティングされない • 100.64.0.0 ～ 100.127.255.255 (4,194,304) • 広大!! 浪漫!! 既存ネットワークでまだこのアドレス空間を 使っていなければ（ルーティングしていなけ れば）、Non-routable LZ空間として活用する 手があります

DNS Forwarding Rulesets Landing Zone B Landing Zone A サンプル実装 (Azure Container Apps) (Fake)On-prem Hub VNet2VNet VPN DNS Peering Peering 10.0.0.0/16 10.10.0.0/16 10.1.0.0/16 10.2.0.0/16 100.64.0.0/16 100.64.0.0/16 Peering Peering VM vnetexample.corp. onpremexample.corp. Zone Forward vnetexample.corp. -> Hub Resolver onpremexample.corp. -> On-prem DNS vnetexample.corp. -> Hub Resolver torumakabe/aca-on-nonroutable-spoke (github.com)

DNS Forwarding Rulesets Landing Zone B Landing Zone A LZ -> LZ (Fake)On-prem Hub VNet2VNet VPN DNS Peering Peering 10.0.0.0/16 10.10.0.0/16 10.1.0.0/16 10.2.0.0/16 100.64.0.0/16 100.64.0.0/16 Peering Peering VM vnetexample.corp. onpremexample.corp. Zone Forward vnetexample.corp. -> Hub Resolver onpremexample.corp. -> On-prem DNS vnetexample.corp. -> Hub Resolver 0.0.0.0/0をLZのAzure Firewallに向ける 0.0.0.0/0をHubのAzure Firewallに向ける vnetexample.corp ゾーンに はLZ AppGWのフロントエン ドIPをAレコードとして登録

DNS Forwarding Rulesets Landing Zone B Landing Zone A LZ -> オンプレミス (Fake)On-prem Hub VNet2VNet VPN DNS Peering Peering 10.0.0.0/16 10.10.0.0/16 10.1.0.0/16 10.2.0.0/16 100.64.0.0/16 100.64.0.0/16 Peering Peering VM vnetexample.corp. onpremexample.corp. Zone Forward vnetexample.corp. -> Hub Resolver onpremexample.corp. -> On-prem DNS vnetexample.corp. -> Hub Resolver

DNS Forwarding Rulesets Landing Zone B Landing Zone A オンプレミス -> LZ (Fake)On-prem Hub VNet2VNet VPN DNS Peering Peering 10.0.0.0/16 10.10.0.0/16 10.1.0.0/16 10.2.0.0/16 100.64.0.0/16 100.64.0.0/16 Peering Peering VM vnetexample.corp. onpremexample.corp. Zone Forward vnetexample.corp. -> Hub Resolver onpremexample.corp. -> On-prem DNS vnetexample.corp. -> Hub Resolver

この実装の注意点 • 100.64.0.0/10を使うAzureのサービスがないか要確認 • VNet Injectionできるサービスに限られるが… • 例: Azure Container Appsのワークロードプロファイル環境では、以下のアドレスが予約さ れる • 100.100.0.0/17 • 100.100.128.0/19 • 100.100.160.0/19 • 100.100.192.0/19 • あればそのアドレスを避けて設計する • SNATするため、パケットのソースIPアドレスは変わる • Azure FirewallのアプリケーションルールでHTTP/HTTPS(TLSインスペクション)を指定する と、X-Forwarded-Forヘッダーを差し込める • ですが、そもそもソースIP見て何するの?という議論はしましょう

FAQ • Application Gatewayが話せないプロトコルはどう扱いますか • NGINXなど別のプロキシをRoutable LZに作る • 少数なら処理ノードをRoutable LZに作る • Azure FirewallのPrivate DNATに期待する（注: 現時点で公式なアナウンスはありません） • DNAT for all IP connections · Community (azure.com) • ただし、役割分担など運用面では考慮点あり（例: Firewallの運用をインフラ専門の別チームが担当する場合、 アプリケーションのエンドポイント追加/変更に迅速、柔軟に対応できるか?） • Non-routable LZ内VMへのSSHはどうしますか • Routable LZへAzure Bastion Hostを作る

Questions?

Thank you