[登壇! JAWS-UG朝会]オンプレADを昇降格したらAWS上のシステムのいろんなところが通信できなくなった話
1. はじめに
みなさん、こんにちは。ひよこインフラエンジニアです。普段はAWSを中心に、既存システムの保守運用や新規システムの設計・構築・テストなどのお仕事をしています。この度2024/6/14(金)に行われたJAWS-UG朝会で登壇をしてきましたので、記録を残したいと思います。
JAWS-UG朝会とは
JAWS-UG朝会とは、AWSユーザによる朝会コミュニティです。夜に開催されている勉強会に参加できない方向けに、月に一度のペースで朝会がオンライン開催されています。
私は6/14(金)に行われた第58回[1]にて、オンプレミスADの移行に起因するネットワークのトラブルをテーマにお話しさせていただきました。「オンプレADを昇降格したらAWS上のシステムのいろんなところが通信できなくなった話」というタイトルで、20分のお時間を頂戴しました。この場を借りて、主催者の皆様、参加者の皆様に御礼申し上げます。
2. 登壇のきっかけ
上記のJAWS-UG朝会では、以前[2]に一度LTを実施しています。前回はオンプレミスADと連携するFSx for Windows File Serverの構築時に苦戦したこととその教訓についてお話させていただきましたが、お時間の都合上、「構築後のテストではまったこと」(格闘日記2～秋のステータス復活編～)についてはカットしていました。また、このテストではFSx以外の場所においてもオンプレとの通信ができなくなるトラブルが発生していたのですが、当時はネットワークやDNS関連の知識が足りず、うまく言語化することができませんでした。そこで、前回カットした部分(FSx)と、他の通信できなくなった部分(Route 53 Resolver)の内容を改めて整理し、LTをすることで理解を深めようと考えました。
前回のLTからほぼ1年近く間が空いていることに加え、トラブル当時の記憶が薄れゆく中果たして発表できるのかという不安もありましたが、前回LTした際に皆さまから温かい反応をいただけたことを思い出し、再挑戦することにしました。
3. 発表内容
資料全体はこちら[3]に掲載しております。
3.1 導入
某プロジェクトで業務チームがテストフェーズに入り、私が所属するAWSチームがテスト支援フェーズを実施していた年の瀬のある日、業務チームから確認依頼が来ました。「先週オンプレミスで動いていたActive Directoryのドメインコントローラを降格させたところ、EC2上から名前解決ができない事態が発生した。確認してほしい。」とのこと。私たちAWSチームは急いで確認することになりました。
赤枠で示していますが、図の右上「お客様拠点」にある既存システムにActive Directoryのドメインコントローラ(以降旧ADと表記)が構築されていました。この端末を新しいサーバー(以降新ADと表記)に移行したのち、AWS上のシステムの様々なところが通信できない、という事態が発生していたのでした。
3.2 原因
業務チームはオンプレのファイアウォールのログを見ながら、AWSチームはVPCフローログを見ながらネットワークの原因箇所を探っていきました。その結果、下記の3つの対処が不足している状態でした。
① Route 53 Resolver RuleのターゲットIPアドレス
② FSx for Windows File ServerのDNSサーバーのIPアドレス
③ FSx for Windows File Serverにアタッチしているセキュリティグループ
① Route 53 Resolver RuleのターゲットIPアドレス
本システムはインターネットへの経路を持たず、オンプレ⇔AWSの名前解決は運用管理アカウントにあるRoute 53 Private Hosted Zoneが担っていました。また、業務アカウント(図では本番アカウントと記載)は自分のVPCのRoute 53 Resolverアウトバウンドエンドポイントを経由して、運用管理アカウントに問い合わせ(DNSクエリ)を投げるという動きをしていました。
リゾルバルールで「オンプレ(AD)の名前解決をしたかったらどこのアカウントの誰に通信すればよいか」という内容を設定しているのですが、このルールに指定するオンプレ(AD)の値が旧ADのIPのままだったため、AWS上の誰も新ADへの行き方を知らない状態になっていました。
② FSx for Windows File ServerのDNSサーバーのIPアドレス
FSx for Windows File Serverは、SMBを介してアクセスできる、信頼性が高くスケーラブルな完全マネージド型のファイルストレージです。本プロジェクトでは、オンプレミスのADと連携するため「自己管理型Microsoft Active Directory」を構築していました。
ファイルシステム構築時に指定するDNSサーバーのIPアドレスが旧ADのIPのままだったことから、オンプレとの通信に失敗し、マネジメントコンソールから確認できるFSxのステータスが構築ミスになってしまっていました。
③ FSx for Windows File Serverにアタッチしているセキュリティグループ
自己管理型Microsoft Active Directoryと連携するFSxを構築するには、FSXにアタッチしているセキュリティグループと、オンプレ側のファイアウォールの双方にいくつかの通信許可設定が必要です。この通信許可が漏れていたことで、FSxが新ADとの通信を完全に確立できていないという状態でした。
3.3 まとめ
オンプレミス環境で稼働中のADを昇降格したところ、AWS上からオンプレミスへの名前解決ができない事態が発生し、原因箇所は下記の3点でした。
① Route 53 Resolver RuleのターゲットIPアドレス
② FSx for Windows File ServerのDNSサーバーのIPアドレス
③ FSx for Windows File Serverにアタッチしているセキュリティグループ
今回の件から得た教訓は、下記の3点です。
① 公式ドキュメントの読み込み
② プロジェクトのドキュメントの読み込み
③ 他チームと作業の認識合わせを十分に行う
教訓
① 公式ドキュメントの読み込み
トラブル発生当時はテスト支援フェーズのため、設計・構築をしたメンバーは既に次のプロジェクトへ移動しており、残ったメンバーはPM・インフラ経験豊富なメンバー1名・AWS SAA保持のクラウド経験のみの新人という状況も相まって、原因特定まで少し時間がかかりました。しかし、AWSのドキュメントを読み込んでRoute53 Resolverとは何かを把握しておくことや、パケットの気持ちになってどこからどうやって通信しに行くのかを理解していれば、時間の節約になったと感じます。
② プロジェクトのドキュメントの読み込み
本プロジェクトでは、詳細設計書(パラメーターシート)がAWSサービスごとに別Exelブックとなっていました。そのため、「ADが降格したらどうなる？」「連携システム先のサーバーが変わったらどうなる？」など、移行を考慮したときにシステムの影響範囲をすぐには特定しづらい作りとなっていました。設計段階から、移行を考慮してシステムを横断的に見れるよう、連携先システムへの理解を深めることや移行手順の整備などが必要です。
③ 他チームと作業の認識合わせを十分に行う
今回は業務チームからチャットをもらうまで、AWSチーム側で早期に事態に気が付くということができませんでした。本番稼働前であっても、自チーム以外の作業予定を把握することや、影響範囲を事前に点検しておくことは重要だと痛感しました。また、チーム間で勤務場所が異なる場合や所属会社が異なる場合は「スケジュール資料の場所を連携しておいたから大丈夫だろう」「定例会議であの人には伝えたしみんなに伝わっているだろう」となりがちなため、密に連携することが必要です。
以上、発表内容でした。
4. おわりに
さて、本記事ではJAWS-UG朝会で登壇しようと思ったきっかけと、登壇内容について振り返りました。実際にLTした後は、「私もAD周りでトラブった思い出が。。。」「AWSでも、IP変わるなどの移行は考慮しておかないとだめ。特にオンプレADのDNSは他の技術者も苦労しているらしい。」「今関わっているプロジェクトでも、他チームの作業について関心が薄いので、気を付けたいと思います」など、たくさんの反応をいただきました。非常に励みになります。また、当日こちらの音声不調にもかかわらず、優しくフォローしてくださった小倉さんをはじめ、ご清聴いただいた参加者の皆様ありがとうございました。
改めまして、この場を借りて主催者の皆様、参加者の皆様に感謝を申し上げます。
最後に、本記事をお読みくださったあなた、ありがとうございました。
それでは、またどこかの勉強会やどこかの記事でお会いしましょう。
Discussion