CI部2課の山﨑です。
AWSを利用している方であればEC2等を構築後に「あれ？通信ができないぞ！？」となって焦った経験があるかと思います。そんな時にEC2にログインせずにAWSのマネージドサービスを使ってどのような調査が可能なのかを検証してみました
- 今回利用するAWSサービス
- 検証環境の構成図
- 検証方法
- ケース1：Transit Gateway ルートテーブルの設定に誤りがある
- ケース2：送信先インスタンスのSecurity Groupの設定に誤りがある
- ケース3：VPCルートテーブルの設定に誤りがある
- おまけ-その1-
- おまけ-その2-
- まとめ
今回利用するAWSサービス
今回は以下のサービスを利用して原因調査をします。
- Route Analyzer
- VPC Reachability Analyzer
Route Analyzer とは
Route Analyzer は AWS Transit Gateway Network Manager の機能の 1 つで無料で利用可能です。グローバルネットワーク全体の Transit Gateway のルーティング構成を確認する際に役立ちます。Route Analyzer で確認できるのはTransit Gateway ルートテーブルのルート分析のみです。その他、セキュリティグループルールとネットワーク ACL ルール等は分析することができません。利用方法等は以下のブログをご覧ください。
VPC Reachability Analyzer とは
VPC Reachability Analyzer はAWSが提供しているネットワーク診断ツールでVPC 内の 2 つのエンドポイント間、または複数の VPC 間で、通信の到達性に関する問題を解決することが可能です。送信元(Source)と送信先(destination)に設定可能なコンポーネントは以下の通りです。
- Instances
- Internet gateways
- Network interfaces
- Transit gateways
- VPC endpoints
- VPC peering connections
- VPN gateways
利用方法等は以下のブログをご覧ください。
VPC Reachability Analyzer の利用前提
- 送信元・送信先のコンポーネントはそれぞれ同一アカウント内に存在すること
- 送信元・送信先のコンポーネントはそれぞれ同一リージョン内に存在すること
- 送信元・送信先のコンポーネントはそれぞれ同一VPC内に存在すること（VPCピアリングで接続されている場合はこの限りではない）
- VPC Reachability Analyzer ではTransit Gateway ルートテーブルの到達性を確認することができないためRoute Analyzer を利用すること。
Reachability Analyzer analyzes subnet and gateway route tables, but not transit gateway route tables. To analyze the routes in your transit gateway route tables, use Route Analyzer. For more information, see Route Analyzer in the Amazon VPC Transit Gateways guide.
2022年3月25日にアップデートがありました（2022年5月14日（土）追記）
2022年3月25日にアップデートでSource、Destination、中間経路のコンポーネントとして、Transit GatewayとTransit Gateway Route Table を指定することができるようになりました。
このアップデートにより、送信元・送信先のコンポーネントは必ずしも同一アカウントである必要性はなくなりましたので、より柔軟に疎通確認ができるようになります。
You can specify transit gateways and transit gateway route tables as sources, destinations, and intermediate path components.
利用料金
VPC Reachability Analyzer は、所与の接続元と接続先の間の接続性を分析するたびに料金が発生します。以下、東京リージョンで利用した場合の料金の例を料金ページから引用します。
VPC Reachability Analyzer で処理する分析あたりの料金: 0.10USD
料金の例
2 つのインスタンス間の接続性を 10 回解析したとします。分析ごとに料金が発生し、 処理する分析あたりの料金は 0.10 USD です。つまり、合計で 1 USD をお支払いいただきます。
検証環境の構成図
今回はTransit Gateway を利用してVPC間通信を可能にする構成としました。
検証前のRoute Analyzerの分析結果
正常に動作しています。
検証前のVPC Reachability Analyzerの分析結果
VPC Reachability Analyzer ではTransit Gateway を経由する通信の到達性確認はできません。そのため今回は以下のように2つの視点で到達性確認を行いました。
- VPC(10.0.0.0/16)のプライベートサブネットに存在するインスタンス（以降、Aと表記する）からTransit Gateway への到達性
- Transit Gateway からVPC(172.16.0.0/16)のプライベートサブネットに存在するインスタンス（以降、Bと表記する）から への到達性
A → Transit Gateway
正常に動作しています。
Transit Gateway → B
正常に動作しています。
検証方法
今回は以下の3つのケースを想定し、 Route Analyzer と VPC Reachability Analyzer を使って原因調査を行ってみます
- ケース1：Transit Gateway ルートテーブルの設定に誤りがある
- ケース2：送信先インスタンスのSecurity Groupの設定に誤りがある
- ケース3：VPCルートテーブルの設定に誤りがある
前提条件
Route Analyzer を利用する際の送信元・送信先の設定は以下とする。
- 送信元：VPC(10.0.0.0/16)内のEC2インスタンス(windows2016-private-a(10.0.20.236/32))
- 送信先：VPC(172.16.0.0/16)内のEC2インスタンス(windows2016-private-sub-a(172.16.0.89/32))
ケース1：Transit Gateway ルートテーブルの設定に誤りがある
Route Analyzer
戻り通信で異常が発生していることが分かります。具体的にはTransit Gateway ルートテーブル(tgw-rtb-05c9fa8db5415ce07) に問題があることが確認できます。
VPC Reachability Analyzer
A → Transit Gateway
正常に動作しています。
Transit Gateway → B
正常に動作しています。
調査結果
- Transit Gateway ルートテーブル(tgw-rtb-05c9fa8db5415ce07) で戻り通信用のルートを追加する必要がある。
ケース2：送信先インスタンスのSecurity Groupの設定に誤りがある
Route Analyzer
正常に動作しています。
VPC Reachability Analyzer
A → Transit Gateway
正常に動作しています。
Transit Gateway → B
異常が発生していることが分かります。
分析結果は以下のようなJSON形式で表示され、Security Group(sg-073c4d556bf048ea0)に異常があることが分かります。
{
"direction": "ingress",
"explanationCode": "ENI_SG_RULES_MISMATCH",
"networkInterface": {
"arn": "arn:aws:ec2:ap-northeast-1:111111111111:network-interface/eni-09234fd609f3aa6d2",
"id": "eni-09234fd609f3aa6d2"
},
"securityGroups": [
{
"arn": "arn:aws:ec2:ap-northeast-1:111111111111:security-group/sg-073c4d556bf048ea0",
"id": "sg-073c4d556bf048ea0"
}
],
"subnet": {
"arn": "arn:aws:ec2:ap-northeast-1:111111111111:subnet/subnet-0f444068dff9621ab",
"id": "subnet-0f444068dff9621ab"
},
"vpc": {
"arn": "arn:aws:ec2:ap-northeast-1:111111111111:vpc/vpc-0c7801b0b660fc11f",
"id": "vpc-0c7801b0b660fc11f"
}
}
調査結果
- Security Group(sg-073c4d556bf048ea0)のInbound通信ルールで適切な許可ルールを付与する必要がある。
ケース3：VPCルートテーブルの設定に誤りがある
Route Analyzer
正常に動作しています。
VPC Reachability Analyzer
A → Transit Gateway
正常に動作しています。
Transit Gateway → B
異常が発生していることが分かります。
エラー内容を見るとSecurity Group(sg-073c4d556bf048ea0)のInbound通信ルールに問題があると書かれているのでSecurity Groupを確認しますがルールに問題はありません。
そこでインスタンスAからインスタンスBにRDP接続をしてみます。
Route Analyzer の分析結果が正常かつSecurity Groupに問題がなければRDP接続は成功するはずですが失敗してしまいました。
VPC Flow Logs を確認
ここまでの調査内容を整理すると以下の通りです
- インスタンスAからTransit Gateway への到達性確認は成功
- Transit Gateway からインスタンスBへの到達性確認に失敗
- インスタンスBのSecurity Group のInbound通信の許可ルールは正しい
そこでTransit Gateway からインスタンスBのENI まで通信が到達しているのかどうかを確認してみます。
VPC Flow Logs(eni-00d044a268a1e59b2)
ログを確認すると送信元(172.16.10.82) から 送信先(172.16.0.89) への通信、つまりTransit Gateway Attachment のENIからインスタンスBのENIに向けて3389ポートの通信がACCEPT(転送)されているため問題なさそうです。
VPC Flow Logs(eni-09234fd609f3aa6d2)
ログを確認すると送信元(10.0.20.236) から 送信先(172.16.0.89) への通信、つまりインスタンスA のENIからインスタンスBのENIに向けて3389ポートの通信がACCEPT(転送)されていることが分かります。つまり、Transit Gateway からインスタンスBのENI まで通信が到達しています。
同様に送信元(172.16.0.89) から 送信先(10.0.20.236) への通信、つまりインスタンスB のENIからインスタンスAのENIに向けての戻り通信を確認してみます。すると戻り通信のログが記録されていないことが分かります。
Security Group はステートフルな仮想ファイアーウォールなので意図的に制御していない限りは通信が戻れないことはないはずです。そこでVPCルートテーブルに戻り通信用のルートが存在するかを確認してみると、戻り通信用のルートが設定されていないことが分かります。
調査結果
- VPCルートテーブル(rtb-021ab122f4f50d879)にインスタンスAへの戻り通信用のルートを追加する必要がある。
おまけ-その1-
ケース3ではVPC Flow Logsも調査したのでVPC Flow Logsの見方を以下、記載します。
VPC Flow Logsの出力単位
VPC FlowLogsはENI単位でログストリームが出力されます。そのため以下のようにENIを利用するサービスであれば送受信トラフィックを確認することが可能です。
- Elastic Load Balancing
- Amazon RDS
- Amazon ElastiCache
- Amazon Redshift
- Amazon WorkSpaces
- NAT ゲートウェイ
- トランジットゲートウェイ
- EC2
VPC Flow Logsの見方
ログの一例
2 111111111111 eni-09234fd609f3aa6d2 10.0.20.236 172.16.0.89 49795 3389 6 3 152 1621151386 1621151388 ACCEPT OK
左から順番に
- VPC FlowLogsのバージョン（2）
- アカウントID（111111111111）
- ENI ID
- 送信元IPアドレス（10.0.20.236）
- 送信先IPアドレス（172.16.0.89）
- 送信元ポート（49795）
- 送信先ポート（3389）RDP通信
- プロトコル番号（6）TCPプロトコル
- パケット数（3）
- バイト数（152）
- 開始時刻（Unix時間）2021年05月16日 16:49:46
- 終了時刻（Unix時間）2021年05月16日 16:49:48
- 通信可否（ACCEPT ＝ 許可された通信、REJECT ＝ 許可されていない通信）
- ログ（OK ＝ 正常にCloudWatch Logsに記録。NODATA ＝ NICと通信したトラフィックはない。SKIPDATA ＝ 一部のフローログレコードはキャプチャウィンドウ中にスキップされた。これは、内部的なキャパシティー制限、または内部エラーが原因である可能性があり
おまけ-その2-
異なるVPC間の通信(VPCピアリングを利用)をVPC Reachability analyzerで分析
VPCピアリングを使ってピアリングしたVPC間の通信をVPC Reachability Analyzer で分析するとどのように表示されるのか確認してみました。VPCピアリングについては過去にブログを書いていますので具体的な利用方法はこちらをご覧ください
VPC Reachability Analyzer
これまで分析結果として表示されなかったVPCルートテーブルが表示されました。VPCピアリングでピアリングしたVPC間の通信を分析する際は送信先のVPCへのルートテーブルが適切に設定されているかどうかも分析してくれることが分かりました。
同一VPC内の通信をVPC Reachability analyzerで分析
同一VPC内の通信をVPC Reachability Analyzer で分析するとどのように表示されるのか確認してみました。
VPC Reachability Analyzer
これまで分析結果として表示されなかったVPCルートテーブルが表示されました。同一VPC内の通信を分析するとVPCルートテーブルが適切に設定されているかどうかも分析してくれることが分かりました。
まとめ
Route Analyzerの守備範囲
Transit Gatewayを経由する通信がありTransit Gateway ルートテーブルの妥当性を分析、確認したい時に有効です。
VPC Reachability Analyzerの守備範囲
VPCピアリングをしている場合を除き、同一VPC内のコンポーネント間のネットワーク到達性確認をしたい時に有効です。
調査対象別 利用可能AWSサービス
以上、検証結果を踏まえてネットワーク通信断の原因調査で利用可能なAWSサービスを調査対象の通信別でまとめてみます。
| 調査対象 | 利用サービス |
|---|---|
| 同一VPC内の通信 | VPC Reachability Analyzer VPC FlowLogs |
| 異なるVPC間の通信(VPCピアリングを利用) | VPC Reachability Analyzer VPC FlowLogs |
| 異なるVPC間の通信(Transit Gatewayを利用) | Route Analyzer VPC Reachability Analyzer VPC FlowLogs |
今回はRoute Analyzer と VPC Reachability Analyzer を使ってネットワーク通信断の原因調査をしてみました。いずれもAWSコンソール上で原因調査が完結するためとても便利でしたが、異なるVPC間の通信(Transit Gatewayを利用)の調査をVPC Reachability Analyzer を使って行う場合は調査するルートによっては今回の検証のようにVPC Flow Logsをチェックする等の措置を取らないと原因を特定することができないケースがあることが分かったためその点だけは少し不便に感じました。
山﨑 翔平 (Shohei Yamasaki) 記事一覧はコチラ
2019/12〜2023/2までクラウドインテグレーション部でお客様のAWS導入支援を行っていました。現在はIE（インターナルエデュケーション）課にて採用周りのお手伝いや新卒/中途オンボーディングの業務をしています。2023 Japan AWS Top Engineers/2023 Japan AWS Ambassadors
