はじめに

今回は、Terraformを使ってデフォルトのWindowsサーバーを構築した際に、セキュリティグループでICMPを許可したにもかかわらず、Pingが通らないというエラーが発生しました。

結論として、原因はWindowsサーバー側のファイアウォール設定でICMP（Ping）がブロックされていたことです。

この記事では、一連の切り分け調査から解決までの手順を簡潔にまとめています。同じような問題に直面した方の参考になれば幸いです。

困っていたこと

デフォルトのWindowsサーバーを構築し、疎通確認のためにローカルのMacBook端末からPingコマンドを発行しました。

しかし、以下のようにPing応答がないというエラーが発生しました。

実際のコマンド結果

➜  myproject git:(main) ✗ ping xx.xx.xx.xx
PING xx.xx.xx.xx (xx.xx.xx.xx): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
^C
--- xx.xx.xx.xx ping statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss
➜  myproject git:(main) ✗

エラーの内容

現象: Request timeout for icmp_seq メッセージが連続して表示され、応答が返ってきません。
統計:
- 8 packets transmitted: 合計8回パケットを送信しました。
- 0 packets received: 応答パケットが1つも返ってきていません。
- 100.0% packet loss: すべてのパケットが失敗しています。

前提条件

AWS側のセキュリティグループ設定では、すべてのICMPをインバウンドルールで許可しています。
Windowsサーバー側は、OSが起動している状態です。
また、ローカル環境やネットワーク経路上でICMPがブロックされていないことも確認済みです。

切り分け調査を開始

1つの障害やうまくいかないポイントが発生した際には、原因を切り分け、順序立てて調査を進めることが重要です。

今回のケースでは、主に以下の原因が考えられます。

セキュリティグループ（SG）がICMPをブロック

原因: AWSセキュリティグループがICMP（ping）を許可していない。
対策: SGで以下を設定：
- タイプ: ICMP - IPv4
- 送信元: 0.0.0.0/0（または必要な範囲）。

ターゲットサーバーが停止中

原因: インスタンスが停止または障害発生。
対策: AWSコンソールでインスタンスの状態を確認し、起動する。

ネットワーク障害

原因: ローカルまたは経路上でICMPがブロックされている。
対策:
- ping 8.8.8.8 でネットワークを確認。
- traceroute <IP> で経路を調査。

WindowsサーバーのファイアウォールがICMP (ping) をブロック

原因: Windowsサーバーのファイアウォール設定でICMP（ping）がブロックされている。
対策:
- 受信ルールを確認・有効化:
  - 「Windows Defender ファイアウォール」→「詳細設定」→「受信の規則」から、
    「ファイルおよびプリンターの共有（エコー要求 - ICMPv4-In）」を有効にする。
コマンドで有効化:

netsh advfirewall firewall add rule name="Allow ICMPv4" protocol=icmpv4:8,any dir=in action=allow

ファイアウォールのICMP (ping) ブロックを解除してみた

方法としては、コントロールパネルからWindows Defenderのファイアウォール設定を開き、画面操作で許可することも可能ですが、今回はコマンドプロンプトを使用して対応します。

コマンドプロンプトでの確認

管理者権限でコマンドプロンプトを開く
- 「スタート」→「cmd」と入力→「管理者として実行」を選択。
Ping応答を有効にするためのコマンド
- 以下のコマンドを入力して設定を完了させます。

netsh advfirewall firewall add rule name="Allow ICMPv4" protocol=icmpv4:8,any dir=in action=allow

設定が有効かを確認するコマンド
- 念のため、以下のコマンドを実行してルールが有効になっていることを確認してください。

netsh advfirewall firewall show rule name="Allow ICMPv4"

再度、Pingコマンドを実行してみた

ローカルのMacBook端末からPingコマンドを再度実行し、正常に疎通できることを確認しました。

実際のコマンド結果

➜  myproject git:(main) ✗ ping xx.xx.xx.xx
PING xx.xx.xx.xx (xx.xx.xx.xx): 56 data bytes
64 bytes from xx.xx.xx.xx: icmp_seq=0 ttl=120 time=15.926 ms
64 bytes from xx.xx.xx.xx: icmp_seq=1 ttl=120 time=16.956 ms
64 bytes from xx.xx.xx.xx: icmp_seq=2 ttl=120 time=16.700 ms
64 bytes from xx.xx.xx.xx: icmp_seq=3 ttl=120 time=17.351 ms
64 bytes from xx.xx.xx.xx: icmp_seq=4 ttl=120 time=16.482 ms
64 bytes from xx.xx.xx.xx: icmp_seq=5 ttl=120 time=16.610 ms
64 bytes from xx.xx.xx.xx: icmp_seq=6 ttl=120 time=20.125 ms
64 bytes from xx.xx.xx.xx: icmp_seq=7 ttl=120 time=16.714 ms
64 bytes from xx.xx.xx.xx: icmp_seq=8 ttl=120 time=20.454 ms
^C
--- xx.xx.xx.xx ping statistics ---
9 packets transmitted, 9 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 15.926/17.480/20.454/1.545 ms

今回の原因調査は比較的シンプルでしたが、問題がAWS側にあるのか、それともOS側にあるのかをしっかりと見極めて切り分けを行うことが重要です。

まとめ

ここまでお読みいただきありがとうございました。障害対応や切り分け調査は、経験による部分が大きいと感じています。

私自身、初めて取り組んだ際には、どこでどのようにエラーが発生しているのか全く分からず、迷子になった記憶があります。

ネットワークの問題はどの分野においても難しく、切り分けには時間と労力がかかるものです。

しかし、こうした経験を積み重ね、アウトプットを続けることで、自分自身のスキル向上につなげていきたいと思います。