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.3k
Azureにおける IPv4アドレス枯渇との戦い方
※リンクを効かせたい場合はダウンロードしてください
Toru Makabe
October 23, 2023
Tweet
Share
More Decks by Toru Makabe
See All by Toru Makabe
しみじみ語る Microsoftの考える プラットフォームエンジニアリング
torumakabe
3
1.1k
30分でわかる 「クラウドアプリケーション10の設計原則」
torumakabe
9
1k
AKSのアップデートを手なずけろ! まず理解 そして実践
torumakabe
3
2.1k
コスト最適化by オーナーシップ ~俺たちはQuick Winで満足しない~
torumakabe
3
760
俺とAzureとTerraform ~2024新春バージョン~
torumakabe
5
1.7k
"クラウドアプリケーション 10の設計原則" をもっと楽しむ
torumakabe
24
8.5k
Radius概要
torumakabe
4
1.1k
Azure Developer CLI Deep Dive
torumakabe
3
890
Other Decks in Technology
See All in Technology
Qiita埋め込み用スライド
naoki_0531
0
5.6k
30分でわかる「リスクから学ぶKubernetesコンテナセキュリティ」/30min-k8s-container-sec
mochizuki875
3
380
大規模言語モデルとそのソフトウェア開発に向けた応用 (2024年版)
kazato
2
480
Opcodeを読んでいたら何故かphp-srcを読んでいた話
murashotaro
0
370
深層学習と3Dキャプチャ・3Dモデル生成(土木学会応用力学委員会 応用数理・AIセミナー)
pfn
PRO
0
420
OPENLOGI Company Profile
hr01
0
58k
I could be Wrong!! - Learning from Agile Experts
kawaguti
PRO
8
2.8k
WantedlyでのKotlin Multiplatformの導入と課題 / Kotlin Multiplatform Implementation and Challenges at Wantedly
kubode
0
140
知っててうれしい HTTP Cookie を使ったセッション管理について
greendrop
1
110
Bring Your Own Container: When Containers Turn the Key to EDR Bypass/byoc-avtokyo2024
tkmru
0
730
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
1
5k
When Windows Meets Kubernetes…
pichuang
0
200
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.3k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
490
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Rails Girls Zürich Keynote
gr2m
94
13k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.9k
Designing for Performance
lara
604
68k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.2k
BBQ
matthewcrist
85
9.4k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
113
50k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
A Philosophy of Restraint
colly
203
16k
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