pingが通らないのに生きているEC2はゾンビではなくセキュリティグループの設定が足りない。
あれ？サーバーが死んでるかもしれない。
そう思ったとき、まず初めに行うのがPingコマンドを打つことですよね。
ping サーバーアドレス
このコマンドをポンと打ち、応答が帰ってきたらとりあえず生きている。
応答が帰ってこなかったら、どうやらサーバーが死んでいるか、通信が繋がっていないということになります。
問題の切り分けの第一歩。
つまりPingを確認するというのは、人間の心拍音を確認して生きているかを判断する形になります。
リビングデッドインスタンス
ある日、遠隔地で作業している人の作業用サーバーがほしいということで、AWSでEC2インスタンスを作りました。
Windowsサーバーを入れ、セキュリティグループには作業者の端末からリモートデスクトップでつなげられるよう設定しました。
作業完了の連絡を入れてしばらくのち、遠隔地の人から連絡がきました。
「入ろうとしてるんですけど、、、そもそもサーバー生きてます？」
AWSコンソールを見るとそのサーバーはグリーン。
「ええ。生きていますよ。」
「あれ？ほんとうですか？さっきからPingが通らないんですが。」
「そうなんですか？ステータスはrunningになってるんですけどね。試しにリモートデスクトップで入ってみてくれませんか？」
「わかりました。えーっと・・・、これで・・・あ。入れた。」
デフォルト設定では通らないPing
Pingはとくに何もインストールしなくてもコマンドを打てますし、ポートの指定もありません。
そしてそのサーバーとNW上で繋がっているなら、何らかしらの応答が帰ってくると思いがちです。
今回もリモートデスクトップでつながるように設定したのなら、Pingも繋がるだろうと作業者の方は考え、まずは試しにPingを打って確かめようとしたようです。
しかし、AWSではデフォルト設定ではPingは通りません。
セキュリティグループに明示的にルールを追加する必要があります。
追加する設定値は以下の通りです。
タイプ：すべてのICMP
プロトコル：すべて（自動設定）
ポート範囲：該当なし（自動設定）
送信元：任意の場所
もちろん、送信元はセキュリティによってカスタマイズが必要ですが、このルールを設定すれば、Pingは通るようになります。
EC2はPingの応答まで制御できるのかと驚いた一件でした。