イオンスマートテクノロジー（通称、AST）CTO室SREチーム所属、あおしょんです。
前に下記の記事で弊社のプラットフォーム (Azure) にHVN (HashiCorp Virtual Network) を接続する辛みをご紹介しました。
記事を読んで頂いたありがたい読者様はきっと弊社のシステムが下記の構成でHCP Vaultと連携しているんだろうと思って頂いていると思います。
実際私がそう宣言していますからね！
これは受け入れざる得ないので各スポークとHVNをピアリングすることを我慢しました。
上記の記事を執筆している時点では検証を終えて弊社の実環境へ絶賛導入しようとしている最中でして…全く異なる問題にぶち当たっていました！！！（泣
本記事では（弊社固有かもしれない）HCP Vault導入のために乗り越えないといけない辛い壁とその壁をぶち破るために新たな壁を立てたお話をします。
プライベートIPアドレスとは？
世の中一般的なプライベートIPアドレス
突然ですがプライベートIPアドレスとは何たるかをNTTコミュニケーションズ様の記事でおさらいします。
プライベートIPアドレスに使えるのは「10.0.0.0～10.255.255.255」「172.16.0.0～172.31.255.255」「192.168.0.0～192.168.255.255」の範囲と決められています。
今更こんなこと書いて読み手を馬鹿にしてるのか？と思う読者の方もいらっしゃるかもしれません。ですが辛い壁を説明するにはこのおさらいがどうしても必要になってきます。
弊社のプライベートIPアドレス
次に弊社のプラットフォームで利用しているプライベートIPアドレスの主なレンジをご紹介します。
- 198.18.0.0/16
- 160.243.0.0/16
「あれれ～おかしいぞ～」と某名探偵も引っ掛かりそうですね。
１ポチ目は第一オクテットはtypoかな？第二オクテットは1と8の間の6を書き漏れているのかな？２ポチ目は…んん～～？？
…両レンジとも間違っておりません。
これは弊社のネットワーク設計ではなく各店舗や事務所とも繋がる弊グループのプライベートネットワーク全体で使用されているアドレスレンジとなります。もちろん、RFC1918のプライベートアドレスレンジも使用されていますが基本的にはAzureリソースなどのシステムには上記のアドレスレンジが割り振られます。
HVNとのピアリング
弊グループのプライベートネットワークだけで完結する構成であれば特に問題はありません。ですが今回はHCP Vaultを導入するためにHVNと弊社のVNetをピアリングする必要があります。
そうして壁にぶち当たりました。
CIDR blocks must follow either the RFC1918 specification or the RFC6598 specification.
そう、HVNのルート定義の宛先はRFC1918のプライベートアドレスレンジとRFC6598のシェアードアドレスレンジしか指定出来なかったのです！
実際にHCPのポータルからルート定義を作成する際の注意書きは下記となります。
完全に私の考慮漏れで検証時点では上記を読み落としておりサンドボックス環境で検証していたので普通に一般的なプライベートアドレスレンジ利用していました～…
愛のセッションからのヒント
そんな中、丁度同じ時期に「第44回 Tokyo Jazug Night」にてMicrosoftの真壁さんが「Azureでのv4アドレス枯渇との戦い方」というタイトルでお話をされていました。
Azureと企業ネットワークをつないでコンテナなど新しい挑戦がしたい、
でもアドレス空間には空きがない... そんな悩みをお持ちのあなたに贈る愛のセッションです
私は別件で聴講出来なかった（えっ）のですが、壁にぶち当たっていることをSREチーム内で相談したら真壁さんの愛のセッションのスライドを共有してもらいました。
完全に一致している構成ではありませんが上記のスライドから「HCP Vaultと繋げたいシステムとHVNの間にSNAT用のAzure Firewall（壁）を設置すれば良いのか！」というヒントを頂きました。
また、構成の検討にあたって詳細は下記も参考にしました。
SNAT用Azure Firewall（壁）を設置した構成
では実際に環境構築した構成を社内ドキュメントとして執筆した設計書を抜粋、若干の編集を加えて説明します。
- VNet: System内のあるシステム（上記の図だとVM、以降はシステムと表記）がHVNを宛先とした通信をする際にSNATサービスとしてのAzure Firewallを中継するため、システムが属するサブネットにユーザー定義ルート（User Define Route）を定義する。
- Azure FirewallでシステムからHVN上のHCPのサービス（上記の図だとVault）への通信を許可するネットワーク規則（Network Rule）を定義する。宛先のPort, ProtocolはHCPサービスの要件に応じて必要最小限の設定をする。
- HVNのRoute TableでDestinationをVNet: Azure FirewallのサブネットAzureFirewallSubnet（CIDR: /26）とするルートを作成する。
- システムは弊グループのプライベートネットワークに属するオンプレ（プライベートクラウド含む）やAST管理外のパブリッククラウドのシステムと通信をする可能性がある。そのため、VNet: Azure Firewallは弊グループのプライベートネットワークのアドレスレンジと重複しないRFC6598のシェアードアドレス空間のアドレスレンジを設定する。
- HVNは仕様上、RFC1918のプライベートアドレス空間のアドレスレンジを設定する必要がある。従って弊グループのプライベートネットワークを管理しているグループ会社の部署からRFC1918のプライベートアドレスレンジを懇願して払い出してもらう。
こうしてシステム、というよりもその上のアプリケーションがAzure Firewall（壁）の存在を意識することなくHCP Vaultと連携することを実現出来ました。
おわりに
タイトルの通り本記事では３つの壁が出てきました。
- 辛い壁
- Azure Firewall（壁）
あと１つの壁は何でしょうか？
辛い壁を乗り越えるにあたりご協力頂いた壁様に多大なる感謝を申し上げます。
Discussion