Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Azureにおける IPv4アドレス枯渇との戦い方
Search
Toru Makabe
October 23, 2023
Technology
4
2.7k
Azureにおける IPv4アドレス枯渇との戦い方
※リンクを効かせたい場合はダウンロードしてください
Toru Makabe
October 23, 2023
Tweet
Share
More Decks by Toru Makabe
See All by Toru Makabe
Microsoft Build 2025 技術/製品動向 for Microsoft Startup Tech Community
torumakabe
2
280
しみじみ語る Microsoftの考える プラットフォームエンジニアリング
torumakabe
3
1.5k
30分でわかる 「クラウドアプリケーション10の設計原則」
torumakabe
9
1.2k
AKSのアップデートを手なずけろ! まず理解 そして実践
torumakabe
3
2.8k
コスト最適化by オーナーシップ ~俺たちはQuick Winで満足しない~
torumakabe
3
3.7k
俺とAzureとTerraform ~2024新春バージョン~
torumakabe
6
2.6k
"クラウドアプリケーション 10の設計原則" をもっと楽しむ
torumakabe
24
8.9k
Radius概要
torumakabe
4
1.2k
Azure Developer CLI Deep Dive
torumakabe
3
1k
Other Decks in Technology
See All in Technology
Абьюзим random_bytes(). Фёдор Кулаков, разработчик Lamoda Tech
lamodatech
0
340
Liquid Glass革新とSwiftUI/UIKit進化
fumiyasac0921
0
210
PHP開発者のためのSOLID原則再入門 #phpcon / PHP Conference Japan 2025
shogogg
4
770
BrainPadプログラミングコンテスト記念LT会2025_社内イベント&問題解説
brainpadpr
1
160
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
26k
mrubyと micro-ROSが繋ぐロボットの世界
kishima
2
300
あなたの声を届けよう! 女性エンジニア登壇の意義とアウトプット実践ガイド #wttjp / Call for Your Voice
kondoyuko
4
450
250627 関西Ruby会議08 前夜祭 RejectKaigi「DJ on Ruby Ver.0.1」
msykd
PRO
2
300
AWS テクニカルサポートとエンドカスタマーの中間地点から見えるより良いサポートの活用方法
kazzpapa3
2
550
Tech-Verse 2025 Keynote
lycorptech_jp
PRO
0
120
生成AI時代 文字コードを学ぶ意義を見出せるか?
hrsued
1
470
Amazon Bedrockで実現する 新たな学習体験
kzkmaeda
2
560
Featured
See All Featured
Site-Speed That Sticks
csswizardry
10
660
Designing Experiences People Love
moore
142
24k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
A Tale of Four Properties
chriscoyier
160
23k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Fireside Chat
paigeccino
37
3.5k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Done Done
chrislema
184
16k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
Transcript
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