概要

昨日までアクセスできていた検証用EC2のWebサーバに、今朝突然アクセスできなくなりました。
原因は直感的にわかってしまったのですが、せっかくなら段階的なアプローチでトラブルシューティングしてみようと思ったので、その記録を残します。

環境

サーバ

マシン：Amazon EC2
OS：Ubuntu 22.04
WEBサーバ：Nginx
ロードバランサ：設置していません。

クライアント端末

WSL2 Ubuntu 22.04
自宅にて操作しています。

症状

Webサーバに対してcurlを実行すると、Connection timed outとなります。
昨日まではアクセスできていたにもかかわらず、です。
※IPはxxx.xxx.xxx.xxxとマスクしています。

$ curl -v xxx.xxx.xxx.xxx:80
*   Trying xxx.xxx.xxx.xxx:80...
* connect to xxx.xxx.xxx.xxx port 80 failed: Connection timed out
* Failed to connect to xxx.xxx.xxx.xxx port 80 after 133792 ms: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to xxx.xxx.xxx.xxx port 80 after 133792 ms: Connection timed out

調査方針

OSI 低レイヤーから開始し、上位レイヤーへ順を追って調査していきます。
こちらによると、ボトムアップ方式と呼ばれる手法になります。

調査開始

EC2の低レイヤーはAWSによって管理されており操作ができないので、AWS Health Dashboardにて障害情報を確認します。

特に障害情報は出ていないので、L3レイヤーを調査します。
クライアントからEC2のIPに対して疎通できるか確認します。

$ ping xxx.xxx.xxx.xxx
PING xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx) 56(84) bytes of data.
^C
--- xxx.xxx.xxx.xxx ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9442ms

疎通できていないので、L3レイヤーの問題だとわかりました。
パケットがどこまで届いているかを確認するため、tracerouteを実行します。

$ sudo traceroute -q 1 -I xxx.xxx.xxx.xxx
結果省略

自宅の回線事情が表示されるので結果は省略しましたが、ISP機器まではパケットが到達していたため、クライアント側ではなくサーバ側の問題だとわかりました。
また、yahooのトップページに対してcurlを実行した結果、ステータスコード200が返ってくることからもサーバ側固有で発生している問題だとわかります。

$ curl -s https://www.yahoo.co.jp -o /dev/null -w '%{http_code}\n'
200

サーバのIPアドレス関連の設定が怪しい、ということでセキュリティグループのインバウンドルールを確認してみます。

自宅のグローバルIPが現在許可されていますが、本当にそのIPで正しいのか確認してみます。
inet-ip.infoというWebサイトに対してcurlを実行すると(又はブラウザアクセスすると)グローバルIPが得られます。

$ curl inet-ip.info

得られたグローバルIPが昨日まで割り当てられたIPと異なっていました。
IPを再設定したところ、無事Webサーバにアクセスできるようになりました。

所感

私はISPと固定IP契約を結んでいないので、動的にIPが変わる可能性があるのは知っていましたが、今までまったく変わったことが無かったです。
本当に変わるんだなあということを実感しました。
また、IPが違うという基本的な原因だったものの、トラブルシューティング練習が出来て良かったです。

参考