この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
どうも、情シスの徳道＠上越オフィスです。今回はネットワークネタです。
唐突ですが、会社を代表するグローバルIPアドレスって多くの場合は本社の固定グローバルIPアドレス（プロバイダに依存）ではないでしょうか。
ゼロトラストが叫ばれて久しいですが、弊社のようにお客さまの環境を保守するサービスを行っている場合、やはり境界防御として接続元のグローバルIPアドレスを指定して許可されることが多いです。
地方オフィスが増えてくると特定の環境への接続許可をしてもらうIPアドレスの登録も増えてきます。VPN接続で本社など特定拠点経由での接続を行っていたとしても、プロバイダに依存することになったり冗長化が大変だったりしますね。
弊社では数年前からAWSのElastic IP経由で変化しない&冗長化されたグローバルIPアドレスからAWSに接続する社内ネットワークを構築してきました。
今回はクラスメソッドの基幹ネットワークがどのような構成になっているのかを紹介したいと思います（2020年12月現在）。
変化しないグローバルIPアドレスを求めて
クラスメソッドでは社内で通称「Elastic Gate」と名付けられた、AWSのElastic IPを活用した固定IPアドレスを運用してきました。
具体的にはNTTクラウドゲートウェイ アプリパッケージ+Direct Connectを用いて、拠点のLANからIPv6のIP-IP接続したEC2経由でインターネットに出ていく構成です。
構成要素技術は以下の記事をご覧ください。
以前の社内基幹ネットワーク構成
以前のネットワーク構成図
以前の構成のインターネット向け通信経路について説明します。
インターネットへの通信は各オフィスルーターおよびVPC内の各ルートテーブルで以下の3つの経路を制御しています。
※記号は上図の外部への経路を表します。
本社と基幹VPCからのインターネットアクセス
- 経路Ａ：すべてのインターネット通信（保守対象AWSを含む）：本社のWAN（１個の固定IPアドレス）を経由
本社以外の地方オフィス
- 経路Ｂ：保守対象AWS：CloudGateway～ElasticGate VPCを経由（２個の固定IPアドレス）を経由
- 経路C：その他インターネット通信：各拠点のWAN（各オフィスにつき１個の固定IPアドレス）を経由
保守対象AWSでは以下の3つのIPアドレスを許可してもらえれば、どの拠点からでもアクセス可能になることがわかると思います。
- 本社のWAN 固定IPアドレス
- 「ElasticGate VPC」主系の固定IPアドレス
- 「ElasticGate VPC」副系の固定IPアドレス
この構成をとることでオフィスが増えたり変更になってグローバルIPアドレスが変わっても、保守対象のAWSの許可IPアドレスを変更しなくともよくなります。
なお、「ElasticGate VPC」への通信を「保守対象のAWS」だけに絞り込んでいるのはコスト削減のためです。グローバルの固定IPアドレスを経由する必要がない通信、特に動画や大容量データの転送はそのままオフィスルーターのWANから通信してもらえばその分のCloudGatewayやVPCの通信費用は掛からないので。
この構成が抱える問題点
この構成は従来のVPCの構成を変更せずにグローバルIPアドレスを追加出来た半面、以下の問題がありました。
- 拠点増加とともに外部接続サービスの接続費用が無視できなくなってきた
- 外部接続サービスの性質上、NTT Flet's以外の回線を選択できない
- 通信経路が複雑でわかりにくい
また、従来の社内LANに追加する形で構築したため過去からの問題点は依然として解消されていません。
- 本社のWAN障害でVPC Privateサブネット（VPN、プロキシのリモート通信を含む）のインターネット向け通信が止まってしまう
- 本社のWAN更新で固定IPアドレスが変更されると保守対象AWSの設定変更が生じる
そのため、これらを解消すべくElastic Gate バージョン2、ということで見直しを行い、更新した構成を紹介します。
更新した基幹ネットワークの全体構成
※この構成は記事執筆時点（2020年12月現在）のものです。
現在のネットワーク構成図
いかがでしょう？ずいぶんさっぱりしたと思います。このくらいシンプルになるんですね。
今回、オフィスとのサイト間VPN接続には今回は2019年にサービス開始されたTransitGatewayをアタッチしてみました。将来的に海外リージョンなど別VPCを複数接続をするために拡張性を持たせたものです。
全てのオフィスと本社と基幹VPCからのインターネットアクセス
- 経路A：保守対象AWSと基幹VPCからのインターネット通信：NAT Gateway～Elastic IPを経由（２個の固定IPアドレス）を経由
- 経路B：その他インターネット通信：各拠点のWAN（各オフィスにつき１個の固定IPアドレス）を経由
保守対象AWSでは2つのElasticIPだけを許可してもらえれば、どの状況からでもアクセス可能です。
- 「Elastic IP1」の固定IPアドレス
- 「Elastic IP2」の固定IPアドレス
もちろん、オフィスが増えたり減ったり回線を変更したりしても保守対象AWSの許可IPアドレスをメンテナンスする必要はありません。
高速な光回線の選択肢が広がることも潜在的なメリットですね（実際に本社は2020年にNuroBizに光回線を変更しています）。
また仮にオフィスがすべて無くなった（！）としてもリモートワークでVPN接続できれば保守業務を継続することが可能です。
この構成になって問題点はすべて解消
3つあった経路のパターンは2つに集約され、保守対象AWSへの通信は本社を含めすべてElasticIPの2個の固定IPアドレスに集約され、単純化しました。
保守対象AWS向けの通信は切替当時でおよそ500GBあり、外部接続サービスやEC2インスタンスが減ったことで40～50％程度のコスト削減効果がありました。
VPCの数が少ないならば通常の仮想プライベートゲートウェイを利用するとさらにコストは削減できると思います。
基幹ネットワーク変更作業のポイント
せっかくなので、変更設計から実際の作業でのトピックスも遺しておきたいと思います。
なお、オフィス側のルーターはすべてYAMAHA RTX1210として記載しています。
変更作業の実施計画と事前調整
まず、保守対象AWSへのアクセス作業が移行期間中はほぼできなくなるので、変更作業の実行は年末年始の会社休日に作業予定1日、予備1日で確保しました。
この作業日の2日は弊社の保守サービスが停止することを社内外に告知しておかないといけません（だいじ）。
応答時間の個体差、不具合発生による時間ロスは必ずありますし、最悪は切り戻しになることもちゃんと考慮しておきましょう。
PoCはちゃんとやっておこう
理論上はできることが分かっていても、いざ実機・実際のSaaSでの動作の時間や手順確認のため、仮の環境でテストしておくことも重要です。
今回は2つのPoCを実施しています。
- 変更後の構成でElasticIPから通信ができること
- 既存の仮想プライベートゲートウェイ → TransitGatewayへの変更が動作すること
１．変更後の構成でElasticIPから通信ができること
- テスト用VPC作成、IPアドレスレンジだけ異なる同一セグメント構成（例：10.0.0.0/16）
- Private側の通信テスト用のEC2（Ping応答/ssh接続できれば良いもの）
- アベイラビリティゾーンを分けてPublicセグメントにNAT Gateway 配置
- NAT GatewayにElasticIPを設定
- オフィスのテスト回線にサイト間VPNでカスタマーゲートウェイ作成
- Transit Gatewayを作成
- テスト用VPCにAttachment
- テスト用カスタマーゲートウェイにAttachment
- 各Privateセグメントのルートテーブル（IPアドレスは例です）
- 送信先 ＞ ターゲット
- 0.0.0.0/0 > NAT Gateway（同じアベイラビリティゾーン）
- 10.0.0.0/16 > VPC local
- 172.16.0.0/24 > Transit Gateway
【Privateサブネットのルートテーブルサンプル】
- TransitGatewayのルートテーブル
- 0.0.0.0/0 > VPCのTrasit Gateway Attachment
- 10.0.0.0/16 > VPCのTrasit Gateway Attachment
- 172.16.0.0/24 > サイト間VPNのTrasit Gateway Attachment
【Transit Gatewayのルートテーブルサンプル】
- オフィスルータのStaticRouteを設定
- デフォルトゲートウェイ > PPPoE
- cman.jp、checkip.amazonaws.comのグローバルIPアドレス > Tunnel1、2
【YAMAHA ルーターのコンフィグサンプル（ルーティング部分のみ）】
ip route default gateway pp 1
ip route 10.0.0.0/16 gateway tunnel 1 keepalive 1 gateway tunnel 2 weight 0 < VPCのサブネットIPアドレスレンジ
ip route 52.204.109.97/32 gateway tunnel 1 keepalive 1 gateway tunnel 2 weight 0 < checkip.amazonaws.comのIPアドレス
ip route 52.206.184.85/32 gateway tunnel 1 keepalive 1 gateway tunnel 2 weight 0 < checkip.amazonaws.comのIPアドレス
ip route 34.200.69.241/32 gateway tunnel 1 keepalive 1 gateway tunnel 2 weight 0 < checkip.amazonaws.comのIPアドレス
<省略＞
ip keepalive 1 icmp-echo 5 5 169.254.xx.xx < Tunnel1のKeep Alive、1がダウンしたら2へルーティング- テスト項目
- オフィスLANのPCからcman.jpにアクセス：オフィスのグローバルIPアドレスが表示される
- オフィスLANのPCからcheckip.amazonaws.comにアクセス：ElasticIPのIPアドレスが表示される
- オフィスLANのPCとVPC内のEC2インスタンスでPing疎通ができる
- VPC内のEC2インスタンスからcman.jpにアクセス：ElasticIPのIPアドレスが表示される
- VPC内のEC2インスタンスからcheckip.amazonaws.comにアクセス：ElasticIPのIPアドレスが表示される
この構成で、テスト項目がクリアできることが確認できました。
２．既存の仮想プライベートゲートウェイ → TransitGatewayへの変更が動作すること
こちらについての詳細はこちらをご覧ください。
Virtual Private GatewayとのVPN接続をTransit Gatewayに移行できるようになりました
１と同様の構成で、サイト間VPNをTransit GatewayにAttachmentせず、従来の仮想プライベートゲートウェイとカスタマーゲートウェイで構築しておきます。
前述の記事の内容に沿って、切り替えを行います。
- テスト項目
- サイト間VPNが仮想プライベートゲートウェイ → TransitGatewayに切り替わり、AVAILABEになること
- Tunnel1、2がUpする
- BGPルーティングがEstablishedになる
- オフィスLANのPCとVPC内のEC2インスタンスでPing疎通ができる
ここで、やっぱりPoCをしておいてよかったなぁ、と思うところが。
弊社のサイト間VPNはBGPルーティングをしているのですが、TransitGatewayとPrivateサブネットのルートテーブル変更だけではBGPがアップしませんでした！
原因はBGPのAS番号が古く、Transit Gatewayに変更した場合に新しいAS番号にしないといけなかったことがわかりました。
そのため、切り替え手順には以下のルーター側設定を追加するように改めています。
【変更前のルーター側BGP設定】
bgp neighbor 1 10124 169.254.xx.xx hold-time=30 local-address=169.254.xx.xx
bgp neighbor 2 10124 169.254.xx.xx hold-time=30 local-address=169.254.xx.xx
bgp import 10124 static filter 1【Transit Gatewayに変更した際のルーター側BGP設定】
bgp neighbor 1 64512 169.254.xx.xx hold-time=30 local-address=169.254.xx.xx
bgp neighbor 2 64512 169.254.xx.xx hold-time=30 local-address=169.254.xx.xx
bgp import 64512 static filter 1【BGPの設定は忘れずにOFF→ON→REFRESH！】
bgp use off
bgp use on
bgp configure refreshこれで意図した動作ができるようになりました。
ルーター側の設定準備もぬかりなく
保守対象AWSのグローバルIPアドレス向けの静的ルーティングは各拠点のルーターのIP-IPトンネルに向けられていました。
これを通常のサイト間VPNのトンネルに向けなおします。その設定は数百行（！）になるため、事前にリモートのコンソールで流し込みができるように各拠点向けに作成済みとしておきます。
【トンネルの宛先変更】
ip route 54.64.0.0/13 gateway tunnel 3 keepalive 1 gateway tunnel 4 weight 0
ip route 54.72.0.0/13 gateway tunnel 3 keepalive 1 gateway tunnel 4 weight 0
↓
ip route 54.64.0.0/13 gateway tunnel 1 keepalive 1 gateway tunnel 2 weight 0
ip route 54.72.0.0/13 gateway tunnel 1 keepalive 1 gateway tunnel 2 weight 0レビューは有識者でちゃんとやっておこう
これはもちろんのことですが、PoCの結果を手順に落とし込み、手順をそのままトレースすればいいようにしておきます。
避難訓練ではないですが、「訓練は本番のように、本番は訓練のように」ですね。
その際にレビューアとしては権限を持つステークホルダーであることも大切ですが、必ずテクニカルに精通された方に依頼しましょう。
そうでないと、そもそも誤りの指摘漏れが発生したり、説明がレビュー時間がとても長くなったりしますので…。
ステークホルダーの方が「この人がOKなら」というレベルの方を選定しましょう。
出来れば2～3名の方に、別の視点で見てもらうことがおすすめです。
チェックポイントごとに切り戻しを考えておく
作業手順を作るうえではあるポイント単位でチェックをし、NGなら元の構成に切り戻すことを必ず考慮しましょう。
今回の場合であれば以下のポイントで切り戻し手順を用意しました。
- クラウド側の設定完了時点
- 本社の設定完了時点
- 各オフィスの最初の1か所の設定完了時点
切り戻しが容易で、リスクの少ないところから着手するように作業順番を構成することも重要ですね。
複数の作業者が関わる場合、それまでの作業を確認するポイントを設けるべきでしょう。
・・・以上がスムーズに構成変更作業を行うために最低限ケアしておくべき、と思うところです。
さいごに
いかがでしたか？社内の基幹ネットワークシステムを公開されている企業はあまり多くないと思います。
弊社ではこうした情報もセキュリティ認証規格に抵触しない範囲でどんどんディスクローズしていきます。
まだまだレガシーを残しているところ、運用コストがかかっているところがあるのも事実で、これが最適だとは言えない部分もあります。
リモートワーク主体に対応できる、エンドポイントに重きを置いた仕組みに見直しを続けているので、そうしたトピックをまた紹介し続けていこうかと思います。
その時にまたお目にかかりましょう。
アノテーションでは仲間を募集しています
クラスメソッドの情報システム運用はアノテーションが担当しています。
クラスメソッド関連会社のアノテーション株式会社では一緒に働くメンバーを募集中です。 多様な働き方や顧客を支えるため、「らしく働く、らしく生きる」をスローガンにAWSでのインフラ基盤を中心に「オペレーション・エクセレンス」を担える企業を目指しています。 少しでもご興味ありましたら下記ページにてご確認ください。