エンベーダー

  1. ホーム
  2. 記事一覧
  3. 【Part 1/4】AWSの環境構築で学ぶトラブルシューティング【VPC Peering】

2023.11.21

【Part 1/4】AWSの環境構築で学ぶトラブルシューティング【VPC Peering】

本記事で学べること

本記事は「AWSの環境構築で学ぶトラブルシューティング」シリーズの第1回目となっています。

本シリーズは、実際に手を動かしながらWSの環境構築とその過程でトラブルが起こった場合の対処方法や問題の特定方法などを体系的に学べる内容になっています。また、トラブルシューティングのセクションでは、遭遇した問題の問題の特定方法や解決方法について解説します。

今回は、異なるVPCにいるインスタンス間同士の通信を行える環境を構築します。VPCピアリングを用いて、インターネットを介さない安全な通信を実現する方法を学習します。

AWSは触ったことはあるけど該当のサービスは触ったことがないという方、トラブルシューティングの方法を学習したいという方は、ぜひシリーズを通して学習していきましょう。

「AWSの環境構築で学ぶトラブルシューティング」シリーズはこちら

https://envader.plus/article/260

環境構築のゴール

本記事における、環境構築のゴールを以下の図にまとめました。異なるVPCにいるインスタンス間をプライベートIPアドレスで通信が行えるようにすることがゴールです。

環境構築

まず、以下の図のような環境を2つ構築します。実際には異なる3つのAZに配置していますが、図では省略しています。

VPCの作成

1つ目は以下の設定で作成してください。なお、名前タグは任意の名前で構いません。ここで作成した名前タグに合わせて他の機能の設定も行っていきます。

設定項目入力/選択項目
作成するリソースVPCなど
名前タグの自動生成自動生成にチェック, networking-1
IPv4CIDRブロック10.0.0.0/16
IPv6CIDRブロックIPv6CIDRブロックなし
テナンシーデフォルト
AZの数3
パブリックサブネットの数3
プライベートサブネットの数3
NATゲートウェイなし
VPCエンドポイントなし
DNSオプションDNSホスト名を有効化, DNS解決を有効化の双方にチェック

2つ目のVPCは、先ほど作成した1つ目のVPCと以下の2点だけ変更して同様に作成してください。

設定項目入力/選択項目
名前タグの自動生成自動生成にチェック, networking-2
IPv4CIDRブロック172.16.0.0/16

セキュリティグループの作成

※ここでの設定は、あくまで学習目的用の設定です。本番環境などの設定ではないということをご理解ください。

作成した2つのVPC用のセキュリティグループを作成します。

  • networking-1-vpc用のセキュリティグループ

    設定項目入力/選択項目
    セキュリティグループ名networking-1-sg
    説明networking-1-sg
    vpcnetworking-1-vpcを選択
    インバウンドルールすべてのトラフィック（タイプ）, Anywhere-IPv4（リソースタイプ）を追加

  • networking-2-vpc用のセキュリティグループ

    設定項目入力/選択項目
    セキュリティグループ名networking-2-sg
    説明networking-2-sg
    vpcnetworking-2-vpcを選択
    インバウンドルールすべてのトラフィック（タイプ）, Anywhere-IPv4（リソースタイプ）を追加

キーペアの作成

ローカルからEC2にアクセスするためのSSHキーを作成します。EC2 Instance Connectを使用する場合はこちらのセクションは飛ばして構いません。

  • SSHキーの作成

    ローカルで以下のコマンドを実行後、エンターを3回押します。

    $ ssh-keygen -t ed25519 -f local-key

...
The key's randomart image is:
+--[ED25519 256]--+
|      =X@@o.+o   |
|    ..*.X=*.     |
|   o +.O+O       |
|  . o.E.++o      |
|     oo.S. .     |
|     o  . o      |
|      .  o       |
|       ...       |
|      .oo        |
+----[SHA256]-----+

  • キーペアのインポート

    まず、作成した公開鍵の値をクリップボードにコピーします。

    $ ls ~/.ssh
local-key local-key.pub

$ cat ~/.ssh/local-key.pub
# 出力された値をコピー

    AWSマネージメントコンソールから、キーペアセクションにいき、キーペアをインポートします。

    設定項目入力/選択項目
    名前local-key
    キーペアファイルid_ed25519.pubの値を貼り付けする

インスタンスを起動

作成した2つのVPC内に設置するインスタンスを作成します。各VPCのパブリックサブネットに1つのインスタンスを作成します。

EC2 Instance Connectを使用する場合はキーペアは無しでインスタンスを作成してください。

  • networking-1-vpcに設置するインスタンス

    設定項目入力/選択項目
    名前networking-1-ec2-public
    AMIUbuntu Server 22.04 LTS
    インスタンスタイプt2.micro
    キーペアlocal-key
    VPCnetworking-1-vpc
    サブネットpublic1
    パブリックIPの自動割り当て有効化
    セキュリティグループnetworking-1-sg

  • networking-2-vpcに設置するインスタンス

    1つ目のインスタンスと異なる箇所だけ表示します。

    設定項目入力/選択項目
    名前networking-2-ec2-public
    VPCnetworking-2-vpc
    セキュリティグループnetworking-2-sg

インスタンス情報

作成した環境の情報を以下にまとめました。通信コマンドを実行する際には、インスタンスに紐付いたIPアドレスに対して実行しますので、どこに対して通信しているのか分からなくなった場合に参照してください。

インスタンス名呼称パブリックIPアドレスプライベートIPアドレス
networking-1-ec2-public1-ec252.69.129.4810.0.10.186
networking-2-ec2-public2-ec254.238.78.203172.16.0.85

以後の説明では、networking-1-ec2-publicは1-ec2、networking-2-ec2-publicは2-ec2と簡略化して呼称します。

ネットワークトラブル

主なネットワークトラブルには以下のようなものが考えられます。

ネットワークトラブル行うべきこと
インターネットや特定のネットワークリソース（ウェブサイト、サーバーなど）への接続が正常に行われていないネットワーク接続の確認
ネットワーク通信に遅延が発生しているネットワーク遅延の特定
ネットワーク通信でパケットロスが発生しているパケットロスの原因分析
データパケットのルート（経路）が不明ネットワーク経路の確認
ネットワークホップでの遅延の特定各ホップでの遅延時間の確認

上記の表にあるようなネットワークトラブルのトラブルシューティングには、pingやtracerouteを使用します。

  • ping

    pingコマンドは、ホスト同士のネットワークの疎通状況を確認するために使用されます。また、ネットワーク遅延（レイテンシ）やパケットロスも測定します。pingは、ICMP（Internet Control Message Protocol）エコーリクエストとエコーリプライメッセージを使用して、指定したホストとの接続性をテストします。

  • traceroute（Windowsではtracert）

    tracerouteコマンドは、ローカルホストからリモートホストまでのネットワークパスを表示するために使用されます。このコマンドは、パケットが目的地に到達するまでに通過する中間ホスト（ルーターなど）のリストを提供します。これにより、ネットワークの問題がどこで発生しているのかを特定するのに役立ちます。

通信先のパブリックIPに対してpingを実行する

まず初めに、1-ec2にSSH接続します。インスタンスに接続するためのコマンドはインスタンスの接続 → SSHクライアントの例:という箇所にコマンドが用意されています。ローカルの作成した秘密鍵のあるディレクトリ（~/.ssh）から実行してください。

pingでネットワークの接続を確認します。送信元は1-ec2、送信先は2-ec2のパブリックIPです。

$ ping 54.238.78.203

ping 54.238.78.203
PING 54.238.78.203 (54.238.78.203) 56(84) bytes of data.
64 bytes from 54.238.78.203: icmp_seq=1 ttl=63 time=0.439 ms
64 bytes from 54.238.78.203: icmp_seq=2 ttl=63 time=0.568 ms
64 bytes from 54.238.78.203: icmp_seq=3 ttl=63 time=0.522 ms
64 bytes from 54.238.78.203: icmp_seq=4 ttl=63 time=0.531 ms
64 bytes from 54.238.78.203: icmp_seq=5 ttl=63 time=0.620 ms
64 bytes from 54.238.78.203: icmp_seq=6 ttl=63 time=0.564 ms
64 bytes from 54.238.78.203: icmp_seq=7 ttl=63 time=0.506 ms
64 bytes from 54.238.78.203: icmp_seq=8 ttl=63 time=0.519 ms
64 bytes from 54.238.78.203: icmp_seq=9 ttl=63 time=0.490 ms
64 bytes from 54.238.78.203: icmp_seq=10 ttl=63 time=0.431 ms

--- 54.238.78.203 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9209ms
rtt min/avg/max/mdev = 0.431/0.519/0.620/0.054 ms

pingコマンドの結果は、10個のパケットが送信され、すべて正常に受信され、パケットロスは0％です。これは、1-ec2から2-ec2のパブリックIP 54.238.78.203へのネットワーク接続が正常であることを示しています。

通信先のパブリックIPに対してtracerouteを実行する

tracerouteではネットワークの接続の評価やパケットがインターネットを通じて目的地までどのように移動するかを確認することができます。

通信できることが確認できた通信を、tracerouteで確認します。送信元は1-ec2、送信先は2-ec2です。tracerouteは、通信できなかった場合は何も出力されないので、パブリックIPに対してのみ実行します。

$ traceroute 54.238.78.203

traceroute to 54.238.78.203 (54.238.78.203), 64 hops max
  1   244.5.0.11  2.206ms  8.130ms  8.384ms
  2   54.238.78.203  0.493ms  0.368ms  0.362ms

tracerouteの結果は、目的のIP（54.238.78.203）まで1ホップ（転送・中継設備の数）で到達し、ホップからの応答時間が比較的短いです。これは、目的IPまでの経路が効率的であり、ネットワークに大きな遅延がないことを示しています。

通信先のプライベートIPに対してpingを実行する

次は、2-ec2のプライベートIPに対してpingを実行します。

$ ping 172.16.0.85

PING 172.16.0.85 (172.16.0.85) 56(84) bytes of data.

--- 172.16.0.85 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8173ms

pingコマンドの結果は、9個のパケットが送信されましたが受信されたパケットは0個で、パケットロスが100％です。これは、1-ec2から2-ec2のプライベートIP 172.16.0.85へのネットワーク接続が正常ではないことを示しています。

通信が届かなかった原因は、2つのインスタンスが異なるVPCにいるためです。通信を行いたいインスタンスが異なるVPCにいる場合、通常、プライベートIPで通信することはできません。

VPCピアリングを利用する

VPCピアリングを使用すると、異なるVPCにいるインスタンス間のプライベートIPアドレスでの通信を可能にします。現在の環境にVPCピアリングを導入していきます。

  • VPCピアリングの設定

    「ピアリング接続を作成」をクリック

    設定項目大枠設定項目入力/選択項目
    名前networking-peering
    ピアリング接続するローカルVPCを選択VPC IDnetworking-1-vpc
    ピアリング接続するもう一方のVPCを選択自分のアカウント自分のアカウント
    ピアリング接続するもう一方のVPCを選択リージョンこのリージョン
    ピアリング接続するもう一方のVPCを選択VPC IDnetworking-2-vpc

    VPCピアリングは別のAWSアカウントとも接続可能なため、承諾操作が必要です。作成後、アクション → リクエストを承認 を実行してください。

  • ルーティングの設定

    1-ec2から2-ec2に通信を送る場合、ルートテーブルに設定を追加する必要があります。

    1-ec2に紐付けられているサブネット情報からルートテーブルページに行き、以下のルートを追加します。

    設定項目入力/選択項目
    送信先172.16.0.0/16
    ターゲットピアリング接続 → networking-peering

    この設定は、1-ec2から2-ec2が所属するVPC（172.16.0.0/16）宛の通信はnetworking-peeringというピアリング接続を使用する、という意味です。この設定により、1-ec2から2-ec2宛に通信がルーティングされるようになります。

通信先のプライベートIPに対してpingを送る

1-ec2から2-ec2のプライベートIPに通信を送る設定を行ったので、再度2-ec2のプライベートIPに対してpingを実行します。

$ ping 172.16.0.85

PING 172.16.0.85 (172.16.0.85) 56(84) bytes of data.

--- 172.16.0.85 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5116ms

VPCピアリングを適用し、異なるVPC間に存在するインスタンス同士をプライベートIPで通信できるように設定したにも関わらず、1-ec2から2-ec2へのpingが失敗しました。

トラブルシューティング

現在、pingを実行して分かった情報だけだと、以下の図のようにどこで問題が起こったのか分かりません。

まずはどこで問題が起こっているのか特定することが必要です。まずは1-ec2から2-ec2への通信が正しく届いているか確認します。この確認にはtcpdumpコマンドが有効です。

tcpdumpは、ネットワークパケットをキャプチャして分析するためのコマンドラインツールです。tcpdumpを使用して、特定のインスタンスが他のインスタンスからの通信を受信しているか確認できます。

別のターミナルないしはブラウザを開き、2-ec2にSSH接続し、tcpdumpを実行します。

# 2-ec2で実行
$ sudo tcpdump -n icmp

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

実行すると、ネットワークパケットをキャプチャする状態、つまり通信を待ち受ける状態になります。この状態の2-ec2に対し、1-ec2からpingを送ります。

# 1-ec2で実行
$ ping 172.16.0.85

ping実行後、2-ec2でログが流れ始めます。

$ sudo tcpdump -n icmp

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
01:48:34.948270 IP 10.0.10.186 > 172.16.0.85: ICMP echo request, id 6, seq 1, length 64
01:48:34.948295 IP 172.16.0.85 > 10.0.10.186: ICMP echo reply, id 6, seq 1, length 64
01:48:35.960765 IP 10.0.10.186 > 172.16.0.85: ICMP echo request, id 6, seq 2, length 64
01:48:35.960791 IP 172.16.0.85 > 10.0.10.186: ICMP echo reply, id 6, seq 2, length 64
01:48:36.984817 IP 10.0.10.186 > 172.16.0.85: ICMP echo request, id 6, seq 3, length 64
01:48:36.984844 IP 172.16.0.85 > 10.0.10.186: ICMP echo reply, id 6, seq 3, length 64
01:48:38.008769 IP 10.0.10.186 > 172.16.0.85: ICMP echo request, id 6, seq 4, length 64
01:48:38.008808 IP 172.16.0.85 > 10.0.10.186: ICMP echo reply, id 6, seq 4, length 64
01:48:39.032712 IP 10.0.10.186 > 172.16.0.85: ICMP echo request, id 6, seq 5, length 64
01:48:39.032736 IP 172.16.0.85 > 10.0.10.186: ICMP echo reply, id 6, seq 5, length 64
01:48:40.056771 IP 10.0.10.186 > 172.16.0.85: ICMP echo request, id 6, seq 6, length 64
01:48:40.056795 IP 172.16.0.85 > 10.0.10.186: ICMP echo reply, id 6, seq 6, length 64

12 packets captured
12 packets received by filter
0 packets dropped by kernel

10.0.10.186は1-ec2のプライベートIPアドレス、172.16.0.85は2-ec2のプライベートIPアドレスです。

tcpdumpの結果から確認できることは、1-ec2から2-ec2へ通信が送信され、その通信を応答しており、1-ec2から2-ec2への通信は問題ない、ということが確認できました。

トラブルシューティングの結果

ここまでのトラブルシューティングで、以下の図のように問題のある箇所を狭めることができました。

次に問題視するべきは、1-ec2から送られたpingを返してはいるが、そのpingはルートテーブルに適切に返されているのか？という部分です。ルーティングの設定では、1-ec2から2-ec2宛の通信の設定は行いましたが、2-ec2から1-ec2宛の設定は行っていませんでした。それが原因ではないか？と問題を特定することができます。

では、2-ec2から1-ec2宛の通信の設定も適切に行えるように設定します。2-ec2に紐付けられているサブネット情報からルートテーブルページに行き、以下のルートを追加します。

項目値
送信先10.0.0.0/16
ターゲットピアリング接続 → networking-peering

再度通信先のプライベートIPに対してpingを実行する

2-ec2に紐付いたルートテーブルを設定したので、1-ec2から2-ec2のプライベートIPに対してpingを送ります。

$ ping 172.16.0.85

PING 172.16.0.85 (172.16.0.85) 56(84) bytes of data.
64 bytes from 172.16.0.85: icmp_seq=1 ttl=64 time=0.486 ms
64 bytes from 172.16.0.85: icmp_seq=2 ttl=64 time=0.467 ms
64 bytes from 172.16.0.85: icmp_seq=3 ttl=64 time=0.454 ms
64 bytes from 172.16.0.85: icmp_seq=4 ttl=64 time=0.467 ms
64 bytes from 172.16.0.85: icmp_seq=5 ttl=64 time=0.438 ms

--- 172.16.0.85 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4103ms
rtt min/avg/max/mdev = 0.438/0.462/0.486/0.015 ms

今度は問題なくpingが返ってきており、パケットロスもなく、異なるVPC間でもプライベートIPで通信が行えていることが確認できました。無事、環境構築することができました。

本記事の片付け

VPCピアリングは作成自体は無料ですが、データ転送の際に料金が発生します。不要なコストを削減するために、VPCピアリングを削除する手順について解説します。

  • VPCピアリングの削除

    VPCのページからピアリング接続セクションへいきます。networking-peeringを選択し、アクション → ピアリング接続を削除を選択します。「関連するルートテーブルエントリを削除」を選択し、「削除」と入力し、ピアリング接続を削除します。

まとめ

本記事ではAWSで環境構築を行いながら、通信に関するトラブルシューティングを実践しました。特に、通信の問題が発生した場合の効果的な問題解決のための切り分け方に焦点を当てました。

環境構築に限らず何らかのトラブルが起こった場合はどこに問題が起こったのかを特定することは非常に難易度が高いです。トラブルシューティングのレベルを上げるためには様々な事象に出会い、解決するしかありません。

引き続き本シリーズを学習していただき、トラブルシューティングのレベルを上げていきましょう。

【番外編】USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話

IT未経験者必見 USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話

プログラミング塾に半年通えば、一人前になれると思っているあなた。それ、勘違いですよ。「なぜ間違いなの？」「正しい勉強法とは何なの？」ITを学び始める全ての人に知って欲しい。そう思って書きました。是非読んでみてください。

「フリーランスエンジニア」

近年やっと世間に浸透した言葉だ。ひと昔まえ、終身雇用は当たり前で、大企業に就職することは一種のステータスだった。しかし、そんな時代も終わり「優秀な人材は転職する」ことが当たり前の時代となる。フリーランスエンジニアに高価値が付く現在、ネットを見ると「未経験でも年収400万以上」などと書いてある。これに釣られて、多くの人がフリーランスになろうとITの世界に入ってきている。私もその中の1人だ。数年前、USBも知らない状態からITの世界に没入し、そこから約2年間、毎日勉学を行なった。他人の何十倍も努力した。そして、企業研修やIT塾で数多くの受講生の指導経験も得た。そこで私は、伸びるエンジニアとそうでないエンジニアをたくさん見てきた。そして、稼げるエンジニア、稼げないエンジニアを見てきた。

「成功する人とそうでない人の違いは何か？」

私が出した答えは、「量産型エンジニアか否か」である。今のエンジニア市場には、量産型エンジニアが溢れている！！ここでの量産型エンジニアの定義は以下の通りである。

比較的簡単に学習可能なWebフレームワーク（WordPress, Rails）やPython等の知識はあるが、ITの基本概念を理解していないため、単調な作業しかこなすことができないエンジニアのこと。

多くの人がフリーランスエンジニアを目指す時代に中途半端な知識や技術力でこの世界に飛び込むと返って過酷な労働条件で働くことになる。そこで、エンジニアを目指すあなたがどう学習していくべきかを私の経験を交えて書こうと思った。続きはこちらから、、、、

note記事3000いいね超えの殿堂記事 今すぐ読む

エンベーダー編集部

エンベーダーは、ITスクールRareTECHのインフラ学習教材として誕生しました。 「遊びながらインフラエンジニアへ」をコンセプトに、インフラへの学習ハードルを下げるツールとして運営されています。

RareTECH 無料体験授業開催中！ オンラインにて実施中！ Top10%のエンジニアになる秘訣を伝授します！ RareTECH講師への質疑応答可
ロードマップ贈呈中！インフラエンジニアを目指す方、必見 特典を受け取る

関連記事

2020.02.25

完全未経験からエンジニアを目指す爆速勉強法

USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話

  • キャリア・学習法
  • エンジニア

2024.07.29

インフラ・クラウドエンジニア必見！AzureとAWSのRBACの違いを徹底解説

クラウドサービスを利用する上で、セキュリティとアクセス管理は非常に重要です。特にAzureとAWSは、それぞれ独自のRBAC（ロールベースアクセス制御）を提供しており、その違いを理解することが求められます。本記事では、初心者インフラ・クラウドエンジニアに向けて、AzureとAWSのRBACの違いを詳しく解説します。

  • AWS
  • Azure
  • サイバーセキュリティ
  • インフラエンジニア

2024.06.23

ECSコンテナのAmazon Linux 2からAmazon Linux 2023へのブルーグリーンデプロイメント実践

この記事では、新人のAさんとベテランのBさんが協力してAmazon ECSのEC2起動タイプを使用し、Amazon Linux 2ベースのコンテナイメージからAmazon Linux 2023ベースのコンテナイメージへのブルーグリーンデプロイメントを実現する過程を紹介します。

  • AWS

2024.04.17

Terraform活用法: AWS EC2 Auto ScalingGroupを構築してみよう

こちらの記事では、Amazon EC2 Auto Scalingの機能を[Terraform](https://www.terraform.io/)で実装する方法を解説します。

  • AWS
  • ハンズオン
  • Terraform