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.5k
Azureにおける IPv4アドレス枯渇との戦い方
※リンクを効かせたい場合はダウンロードしてください
Toru Makabe
October 23, 2023
Tweet
Share
More Decks by Toru Makabe
See All by Toru Makabe
しみじみ語る Microsoftの考える プラットフォームエンジニアリング
torumakabe
3
1.3k
30分でわかる 「クラウドアプリケーション10の設計原則」
torumakabe
9
1.1k
AKSのアップデートを手なずけろ! まず理解 そして実践
torumakabe
3
2.4k
コスト最適化by オーナーシップ ~俺たちはQuick Winで満足しない~
torumakabe
3
3.4k
俺とAzureとTerraform ~2024新春バージョン~
torumakabe
5
2k
"クラウドアプリケーション 10の設計原則" をもっと楽しむ
torumakabe
24
8.7k
Radius概要
torumakabe
4
1.1k
Azure Developer CLI Deep Dive
torumakabe
3
980
Other Decks in Technology
See All in Technology
Go の analysis パッケージで自作するリファクタリングツール
kworkdev
PRO
1
410
チームビルディング「脅威モデリング」ワークショップ
koheiyoshikawa
0
130
新卒エンジニア研修の試行錯誤と工夫/nikkei-tech-talk-31
nishiuma
0
190
問題解決に役立つ数理工学
recruitengineers
PRO
7
1.8k
Engineering Managementのグローバルトレンド #emoasis / Engineering Management Global Trend
kyonmm
PRO
6
980
コード品質向上で得られる効果と実践的取り組み
ham0215
2
200
3/26 クラウド食堂LT #2 GenU案件を通して学んだ教訓 登壇資料
ymae
1
200
caching_sha2_passwordのはなし
boro1234
0
210
技術的負債を正しく理解し、正しく付き合う #phperkaigi / PHPerKaigi 2025
shogogg
7
1.8k
製造業の会計システムをDDDで開発した話
caddi_eng
3
930
React Server Componentは 何を解決し何を解決しないのか / What do React Server Components solve, and what do they not solve?
kaminashi
6
1.2k
Symfony in 2025: Scaling to 0
fabpot
2
170
Featured
See All Featured
Rails Girls Zürich Keynote
gr2m
94
13k
Visualization
eitanlees
146
15k
Raft: Consensus for Rubyists
vanstee
137
6.8k
Done Done
chrislema
183
16k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
25k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
How to Think Like a Performance Engineer
csswizardry
22
1.5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
118
51k
Thoughts on Productivity
jonyablonski
69
4.5k
Producing Creativity
orderedlist
PRO
344
40k
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