Ping の送信はできるけど受信ができない、という場合に確認すべきポイントをまとめてみました。
Windows/Linux等の端末系とルータ等のNW機器で視点が異なります。
原因 (対向が Windows / Linux の場合)
Windows ファイアウォール、もしくはウィルス対策ソフトのファイアウォール機能により、ICMP Echo Request の受信を拒否しています。
PCでファイアウォール機能を使っていると、Ping (ICMP Echo Request) の送信と、その返り(ICMP Echo Reply) の受信はできるが、相手からのPing (ICMP Echo Request) の受信ができない、といった事象が発生します。
なお、送信に対する返りパケットが許可されるのは、ステートフル・インスペクションの機能によるものです。
ステートフル・インスペクションの仕組みについては以下をご参照下さい。
https://milestone-of-se.nesuke.com/nw-basic/fw/stateful-inspection
対策
Windows ファイアウォール、もしくはウィルス対策ソフトのファイアウォール機能を確認し、ファイアウォール機能の無効化、もしくは、ICMP Echo Request の受信許可を設定します。
下記の例では、Windows ファイアウォールで ICMP Echo Request の受信許可を設定します。
- コントロールパネルから Windowsファイアウォールを選択
- 詳細設定をクリック
- 「ファイルとプリンターの共有(エコー要求 - ICMPv4 受信)」をダブルクリック
- 「接続を許可する(L)」のラジオボタンにチェックし、「OK」を押下
以上です。
原因 (対向がルータ/L3スイッチの場合)
例えば以下のような NW 構成で、RT1 と RT3 が互いに Ping を打ち合うケースを考えます。
このとき、PC1 と PC3 で Ping できる状態であり、かつ RT1 から RT3 への Ping が通るのに、RT3 から RT1 への Ping が通らないケースがあります。
それは、RT3 から RT1 へのルーティングが無い場合です。Ping の往路 (Echo Request) の送信元IPが送出インタフェースのIPアドレスになるのに対し、Ping の復路 (Echo Reply) の送信元IPは、Echo Request の宛先IPになる、という性質があるため、このようなことになります。
このとき Echo Reply は、行き場を失い RT1 で破棄されるか、RT1 にデフォルトルートが存在していればそのルートに向かって飛んでいきます。
対策
RT1 に 10.1.23.0/24 宛のスタティックルートを追加します。
RT1# ip route 10.1.23.0 255.255.255.0 10.1.12.2
もしくは、このルートを書かずとも、RT3 の Ping コマンドで送信元IPを指定すれば通ります。
RT3> ping 10.1.1.1 source 10.1.3.3
コメント
ありがとう、助かったよ!
ええんやで