概要
昨日までアクセスできていた検証用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が違うという基本的な原因だったものの、トラブルシューティング練習が出来て良かったです。
参考