Route Analyzer と VPC Reachability Analyzer を使ったネットワーク通信断の原因調査

記事タイトルとURLをコピーする

CI部2課の山﨑です。

AWSを利用している方であればEC2等を構築後に「あれ?通信ができないぞ!?」となって焦った経験があるかと思います。そんな時にEC2にログインせずにAWSのマネージドサービスを使ってどのような調査が可能なのかを検証してみました

今回利用するAWSサービス

今回は以下のサービスを利用して原因調査をします。

  • Route Analyzer
  • VPC Reachability Analyzer

Route Analyzer とは

Route Analyzer は AWS Transit Gateway Network Manager の機能の 1 つで無料で利用可能です。グローバルネットワーク全体の Transit Gateway のルーティング構成を確認する際に役立ちます。Route Analyzer で確認できるのはTransit Gateway ルートテーブルのルート分析のみです。その他、セキュリティグループルールとネットワーク ACL ルール等は分析することができません。利用方法等は以下のブログをご覧ください。

blog.serverworks.co.jp

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

利用方法等は以下のブログをご覧ください。

blog.serverworks.co.jp

VPC Reachability Analyzer の利用前提

  • 送信元・送信先のコンポーネントはそれぞれ同一アカウント内に存在すること
  • 送信元・送信先のコンポーネントはそれぞれ同一リージョン内に存在すること
  • 送信元・送信先のコンポーネントはそれぞれ同一VPC内に存在すること(VPCピアリングで接続されている場合はこの限りではない)

docs.aws.amazon.com

  • 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.

docs.aws.amazon.com

利用料金

VPC Reachability Analyzer は、所与の接続元と接続先の間の接続性を分析するたびに料金が発生します。以下、東京リージョンで利用した場合の料金の例を料金ページから引用します。

VPC Reachability Analyzer で処理する分析あたりの料金: 0.10USD

料金の例

2 つのインスタンス間の接続性を 10 回解析したとします。分析ごとに料金が発生し、 処理する分析あたりの料金は 0.10 USD です。つまり、合計で 1 USD をお支払いいただきます。

aws.amazon.com

検証環境の構成図

今回はTransit Gateway を利用してVPC間通信を可能にする構成としました。

f:id:swx-yamasaki:20210516160636p:plain
構成図

検証前のRoute Analyzerの分析結果

正常に動作しています。

f:id:swx-yamasaki:20210516145055p:plain
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

正常に動作しています。

f:id:swx-yamasaki:20210516150918p:plain
A → Transit Gateway

Transit Gateway → B

正常に動作しています。

f:id:swx-yamasaki:20210516150936p:plain
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 ルートテーブルの設定に誤りがある

f:id:swx-yamasaki:20210516160601p:plain
ケース1

Route Analyzer

戻り通信で異常が発生していることが分かります。具体的にはTransit Gateway ルートテーブル(tgw-rtb-05c9fa8db5415ce07) に問題があることが確認できます。

f:id:swx-yamasaki:20210516155247p:plain
Route Analyzer

VPC Reachability Analyzer

A → Transit Gateway

正常に動作しています。

f:id:swx-yamasaki:20210516160130p:plain
A → Transit Gateway

Transit Gateway → B

正常に動作しています。

f:id:swx-yamasaki:20210516160148p:plain
Transit Gateway → B

調査結果

  • Transit Gateway ルートテーブル(tgw-rtb-05c9fa8db5415ce07) で戻り通信用のルートを追加する必要がある。

ケース2:送信先インスタンスのSecurity Groupの設定に誤りがある

f:id:swx-yamasaki:20210516160715p:plain
ケース2

Route Analyzer

正常に動作しています。

f:id:swx-yamasaki:20210516160844p:plain
Route Analyzer

VPC Reachability Analyzer

A → Transit Gateway

正常に動作しています。

f:id:swx-yamasaki:20210516161059p:plain
A → Transit Gateway

Transit Gateway → B

異常が発生していることが分かります。

f:id:swx-yamasaki:20210516161835p:plain
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ルートテーブルの設定に誤りがある

f:id:swx-yamasaki:20210516163052p:plain
ケース3

Route Analyzer

正常に動作しています。

f:id:swx-yamasaki:20210516162519p:plain
Route Analyzer

VPC Reachability Analyzer

A → Transit Gateway

正常に動作しています。

f:id:swx-yamasaki:20210516163019p:plain
A → Transit Gateway

Transit Gateway → B

異常が発生していることが分かります。

f:id:swx-yamasaki:20210516165030p:plain
Transit Gateway → B

エラー内容を見るとSecurity Group(sg-073c4d556bf048ea0)のInbound通信ルールに問題があると書かれているのでSecurity Groupを確認しますがルールに問題はありません。

f:id:swx-yamasaki:20210516165320p:plain
Security Group

そこでインスタンスAからインスタンスBにRDP接続をしてみます。

f:id:swx-yamasaki:20210516165520p:plain
RDP接続

Route Analyzer の分析結果が正常かつSecurity Groupに問題がなければRDP接続は成功するはずですが失敗してしまいました。

VPC Flow Logs を確認

ここまでの調査内容を整理すると以下の通りです

  • インスタンスAからTransit Gateway への到達性確認は成功
  • Transit Gateway からインスタンスBへの到達性確認に失敗
  • インスタンスBのSecurity Group のInbound通信の許可ルールは正しい

そこでTransit Gateway からインスタンスBのENI まで通信が到達しているのかどうかを確認してみます。

f:id:swx-yamasaki:20210516182507p:plain
VPC Flow Logs(赤線の通信を確認)

VPC Flow Logs(eni-00d044a268a1e59b2)

ログを確認すると送信元(172.16.10.82) から 送信先(172.16.0.89) への通信、つまりTransit Gateway Attachment のENIからインスタンスBのENIに向けて3389ポートの通信がACCEPT(転送)されているため問題なさそうです。

f:id:swx-yamasaki:20210516171319p:plain
VPC Flow Logs(eni-00d044a268a1e59b2)

VPC Flow Logs(eni-09234fd609f3aa6d2)

ログを確認すると送信元(10.0.20.236) から 送信先(172.16.0.89) への通信、つまりインスタンスA のENIからインスタンスBのENIに向けて3389ポートの通信がACCEPT(転送)されていることが分かります。つまり、Transit Gateway からインスタンスBのENI まで通信が到達しています。

f:id:swx-yamasaki:20210516172145p:plain
VPC Flow Logs(eni-09234fd609f3aa6d2)

同様に送信元(172.16.0.89) から 送信先(10.0.20.236) への通信、つまりインスタンスB のENIからインスタンスAのENIに向けての戻り通信を確認してみます。すると戻り通信のログが記録されていないことが分かります。

f:id:swx-yamasaki:20210516172514p:plain
VPC Flow Logs(eni-09234fd609f3aa6d2)戻り通信

Security Group はステートフルな仮想ファイアーウォールなので意図的に制御していない限りは通信が戻れないことはないはずです。そこでVPCルートテーブルに戻り通信用のルートが存在するかを確認してみると、戻り通信用のルートが設定されていないことが分かります。

f:id:swx-yamasaki:20210516173006p:plain
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

左から順番に

  1. VPC FlowLogsのバージョン(2)
  2. アカウントID(111111111111)
  3. ENI ID
  4. 送信元IPアドレス(10.0.20.236)
  5. 送信先IPアドレス(172.16.0.89)
  6. 送信元ポート(49795)
  7. 送信先ポート(3389)RDP通信
  8. プロトコル番号(6)TCPプロトコル
  9. パケット数(3)
  10. バイト数(152)
  11. 開始時刻(Unix時間)2021年05月16日 16:49:46
  12. 終了時刻(Unix時間)2021年05月16日 16:49:48
  13. 通信可否(ACCEPT = 許可された通信、REJECT = 許可されていない通信)
  14. ログ(OK = 正常にCloudWatch Logsに記録。NODATA = NICと通信したトラフィックはない。SKIPDATA = 一部のフローログレコードはキャプチャウィンドウ中にスキップされた。これは、内部的なキャパシティー制限、または内部エラーが原因である可能性があり

docs.aws.amazon.com

おまけ-その2-

異なるVPC間の通信(VPCピアリングを利用)をVPC Reachability analyzerで分析

VPCピアリングを使ってピアリングしたVPC間の通信をVPC Reachability Analyzer で分析するとどのように表示されるのか確認してみました。VPCピアリングについては過去にブログを書いていますので具体的な利用方法はこちらをご覧ください

blog.serverworks.co.jp

f:id:swx-yamasaki:20210518003636p:plain
VPC Peering

VPC Reachability Analyzer

これまで分析結果として表示されなかったVPCルートテーブルが表示されました。VPCピアリングでピアリングしたVPC間の通信を分析する際は送信先のVPCへのルートテーブルが適切に設定されているかどうかも分析してくれることが分かりました。

f:id:swx-yamasaki:20210518003742p:plain
VPC Reachability Analyzer

同一VPC内の通信をVPC Reachability analyzerで分析

同一VPC内の通信をVPC Reachability Analyzer で分析するとどのように表示されるのか確認してみました。

VPC Reachability Analyzer

これまで分析結果として表示されなかったVPCルートテーブルが表示されました。同一VPC内の通信を分析するとVPCルートテーブルが適切に設定されているかどうかも分析してくれることが分かりました。

f:id:swx-yamasaki:20210518113313p:plain
VPC Reachability Analyzer

まとめ

Route Analyzerの守備範囲

Transit Gatewayを経由する通信がありTransit Gateway ルートテーブルの妥当性を分析、確認したい時に有効です。

f:id:swx-yamasaki:20210517145145p:plain
Route Analyzerの守備範囲

VPC Reachability Analyzerの守備範囲

VPCピアリングをしている場合を除き、同一VPC内のコンポーネント間のネットワーク到達性確認をしたい時に有効です。

f:id:swx-yamasaki:20210517145834p:plain
VPC Reachability Analyzerの守備範囲

調査対象別 利用可能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をチェックする等の措置を取らないと原因を特定することができないケースがあることが分かったためその点だけは少し不便に感じました。