Zenn
🐟

AWSで疎通ができない際にはパケットの気持ちになってみよう

2023/01/09に公開
AWS
network
tech

みなさんはAWSで疎通ができない場合はどうするでしょうか？
最近はAWS App RunnerやAWS Amplifyの登場でVPCなどのネットワークをあまり意識せずともアプリケーションを動作させることができるようになりました。
今回はVPCやEC2を利用したアーキテクチャでの疎通ができない場合にはパケットの気持ちになってみませんか？というススメになります。
※この記事ではIPパケット/TCPパケットなどをまとめてパケットとしており、MTUやパケット分割などは考慮していません。

前提知識として持っておいた方が良いこと

AWSに限らない、標準的に利用されている以下知識が不足している場合には、マスタリングTCP/IP 入門編の該当部分を一読しておくことをオススメします。

  • TCP/IP階層
  • DNS, HTTP, HTTPSなどの基本的なプロトコル
  • ルーティング(ルートテーブル)
  • NAT(NAPT)

AWSに限った話で言うと、AWS Summit Online 2020で講演された、「パケットの気持ちになって辿る Amazon VPC のルーティング」を理解できるレベルのAWSに関する知識があると良いと思います。

加えて、TGW, Route 53, CloudFrontなどがシステムで利用されている場合は該当サービスに関する基本的な理解は必要です(サービスの概要説明ができるレベル)

パケットの気持ちになるために

ネットワーク構成(通信経路)

パケットの気持ちになるためには、まず以下のようなネットワーク構成を基にして通信経路を確認しましょう。
ネットワーク構成がない場合には、想定される通信経路をメモ程度で良いので記載しましょう。

ネットワーク構成(例)：

①〜⑦はSpoke VPC Aに存在するEC2インスタンスからInternet(https://example.com/)へのアウトバウンド通信をする際の通信経路を示しています。

通信経路メモ(例)：
Spoke VPC A EC2 --> TGW --> Inline Inspection VPC --> TGW --> Central Egress VPC --> NAT GW --> Internet(https://example.com/)

パケットの気持ちになる

パケットの気持ちになることは設計構築/運用など様々な場面で重要なことだと考えています。
疎通確認をする際には、どの程度パケットの気持ちになれているか？ によって確認スピードが大きく変わってくると思います。
とは言え、いきなりパケットの気持ちになって通信経路を巡るのは大変かと思いますので、以下3つのポイントを意識しつつ通信経路を巡りましょう。

  1. 送信元IP, 送信元ポート, プロトコル, 送信先IP, 送信先ポート
  2. ルートテーブル(ネクストホップ)
  3. SecurityGroup(SG), Network Access Control List(NACL)

1. 送信元IP, 送信元ポート, プロトコル, 送信先IP, 送信先ポート

パケットとして「ルートテーブル(ネクストホップ), SG, NACL」と関わっていくために必要な情報です。
パケットの中にはチェックサムなど他にも情報が含まれていますが、最低限この5つの情報は頭に入れながらパケットの気持ちになりましょう。

送信元IP, 送信元ポート, プロトコル, 送信先IP, 送信先ポート(例):

※送信元ポートはアプリケーションによって65535が割り当てられたと仮定

送信元IP: 10.0.1.100
送信元ポート: 65535
プロトコル: TCP
送信先IP: 93.184.216.34
送信先ポート: 443

2. ルートテーブル(ネクストホップ)

どのルートテーブルを参照するのか？ , ネクストホップはどこか？ を意識しましょう。
ルートテーブルはSubnetやTGW Attachmentごとに割り振られています。
割り振られているルートテーブルにネクストホップがない場合には、パケットの旅はそこで終了となってしまいます。

3. SecurityGroup(SG), Network Access Control List(NACL)

ルートテーブル(ネクストホップ)がわかればパケットが次に進むべき道(通信経路)がわかります。
通信経路上にはSGやNACLが存在しますので、1.で確認した情報を基にSGやNACLで通信が拒否されていないか(許可されているか)を確認しましょう。

ネットワーク構成(例) ①を例にパケットの気持ちになってみる

  • Ⅰ. クライアント(アプリケーション)で名前解決が行われ、パケットに1.の情報が渡されます。
    Spoke VPC AのEC2からInternet上のhttps://example.com/にアクセスする際には名前解決が行われます。OS種別や設定によって名前解決方法(名前解決順序)が変わって来ますが、まずは名前解決ができないことにはパケットがEC2から出ていけません(IP直接通信の場合を除く)
    ※EC2からどのような通信を行うのかにもよりますが、大抵の場合はnslookupやpingなどのコマンドを用いることで名前解決できていること確認可能かと思います。
  • Ⅱ. パケットはEC2に紐づいているENI(Elastic Network Interface)からSpoke VPC A Route Tableを参照して、ネクストホップであるTGWへTGW ENIを経由すれば良いことがわかります。
    ※ルートテーブルのDestination:0.0.0.0/0, Target:tgw-xxxxxがネクストホップとなります
  • Ⅲ. パケットはEC2 ENIに紐づいているSG, Spoke VPC A内のサブネットに紐づいているNACLで通信が拒否されていないか(許可されている)を確認されつつ、"EC2 ENI --> TGW ENI --> TGW"の経路でTGWにパケットが旅をします。

上記がざっくりとした①のパケットがどのようにTGWまで到達するかの解説となります。
②〜⑦も同様に、1.~3.に記載した内容を基にパケットの気持ちとなって旅をすることができます。
パケットの旅が道半ばで終わっている場合(疎通ができない場合)には、1.~3.を意識してパケットの旅路(通信経路)を一つ一つなぞっていくことで原因を特定することができます。

番外編(VPC Reachability Analyzer)

VPC内接続かつ、対応リソースである場合はVPC Reachability Analyzerを利用することで、パケットの気持ちにならずとも、以下に関する一般的な問題を診断してもらえます。
※VPC Reachability Analyzerは実際に通信をせずに、「最小の通信経路パス」or「通信を通すために設定変更するべきポイント」を診断してくれます。

一般的な問題
  • セキュリティグループ(SG)設定
  • ネットワークアクセスコントロールリスト(NACL)設定
  • ルートテーブル設定
対応リソース: AWS公式ドキュメント Source and destination resources
  • Instances
  • Internet gateways
  • Network interfaces
  • Transit gateways
  • Transit gateway attachments
  • VPC endpoints
  • VPC peering connections
  • VPN gateways

おわりに

パケットの気持ちになってみませんか？というススメでしたが、皆さんいかがだったでしょうか？
障害発生していない場合など、通常時はパケットの気持ちになって通信経路を巡ってみる方は少ないのでは(?)と個人的に思っております。
しかし、通常時でもパケットの気持ちになって通信経路を巡っておくことで、通信障害発生した際の障害復旧時間が小さくなると思います。
普段パケットの気持ちになったことがあまりない方はこれを機会にパケットの気持ちになってみませんか？
この記事が誰かの学びのきっかけとなれば幸いです。

Discussion