概要
Pingが通らない時に確認すべき項目について説明します。
ping とは
送信元からパケットを送信し、宛先からの応答が返ってくるか確認するコマンド。
前提
以下の様にPC ⇔ L2switch ⇔ Router という物理接続で説明します。
物理的に確認すべき項目
まずは物理的にサーバ落ちていないか、ケーブルが刺さっているか、linkupしているかを確認します。
これらのどれか1つでもうまくいってない場合はどうあがいてもPingが通ることはありません。時間を無駄にしないためにもまずは物理的な確認から行いましょう。
- サーバが起動している事の確認
- switch や routerが起動している事の確認
- PCにLANケーブルが刺さっている事の確認
- switch や routerにLANケーブルが刺さっている事の確認
- PCのLANポートがlinkupしている事の確認
- switch や routerのLANポートがlinkupしている事の確認
サーバが起動している事の確認
サーバが起動していないとパケットを受け取れません。
サーバダウンしていたら起動しましょう。
switch や routerが起動している事の確認
サーバの場合と同様です。
PCにLANケーブルが刺さっている事の確認
LANケーブルが繋がっていないとパケットの伝送が出来ません。
switch や routerにLANケーブルが刺さっている事の確認
サーバの場合と同様です。
PCのLANポートがlinkupしている事の確認
ケーブルが繋がっていてもPortがlinkupしていなければパケットの伝送が出来ません。
ランプ状態を見るのが確実ですが、以下のコマンドでportがlinkupしているか確認出来ます。
linuxの場合はnmcli device
コマンドを使います。
以下の場合だとenp4s0
とeno1
がlinkupしています。
ibsen@ibsen-02:~$ nmcli device
DEVICE TYPE STATE CONNECTION
enp4s0 ethernet 接続済み network1
eno1 ethernet 接続済み network2
windowsの場合はnetsh interface ipv4 show interface
コマンドを使います。
PS C:\Users\cross> netsh interface ipv4 show interface
Idx Met MTU 状態 名前
--- ---------- ---------- ------------ ---------------------------
1 75 4294967295 connected Loopback Pseudo-Interface 1
15 25 1500 connected イーサネット 5
switch や routerのLANポートがlinkupしている事の確認
サーバの場合と同様です。
ランプ状態を見るのが確実です。
物理的に問題ない場合に確認すべき項目
物理的に問題がない場合は以下の可能性が考えられます。
- 送信元PC、宛先PCのIP設定が誤ってる
- 送信元PCのルートテーブルに必要なルートがない
- routerのルートテーブルに必要なルートがない
- 宛先PCのFirewallでパケットが破棄されている
- 宛先PCには届いているが戻りのパケットの送信元のPCが破棄している
そのためどれに該当するのか切り分けを行う必要があります。
送信元PC、宛先PCのIP設定を確認する
IPアドレス、サブネットマスク、デフォルトゲートウェイの設定が誤っていないか確認する。
windowsではipconfig
コマンド、linuxではip a
で確認しましょう。
traceroute(tracert)で経由ルートを確認する
まずはルートテーブルが正しく設定されているか確認します。
そのためにwindowsではtraceroute
コマンドでlinuxではtracert
コマンドを使います。
送信元PC(192.168.10.1)で宛先PC(192.168.20.1)への経路を確認した例を以下に記載します。
PS C:\Users\zuki> tracert 192.168.20.1
192.168.20.1 へのルートをトレースしています。経由するホップ数は最大 30 です
1 <1 ms <1 ms <1 ms 192.168.10.253
2 * * * 要求がタイムアウトしました。
3 8 ms 7 ms 8 ms 192.168.10.254
4 8 ms 7 ms 8 ms 192.168.20.253
5 * * * 要求がタイムアウトしました。
6 * * * 要求がタイムアウトしました。
7 * * * 要求がタイムアウトしました。
8 * * * 要求がタイムアウトしました。
9 * * * 要求がタイムアウトしました。
10 * * * 要求がタイムアウトしました。
11 * * * 要求がタイムアウトしました。
12 * * * 要求がタイムアウトしました。
13 * * * 要求がタイムアウトしました。
14 * * * 要求がタイムアウトしました。
15 * * * 要求がタイムアウトしました。
16 * * * 要求がタイムアウトしました。
17 * * * 要求がタイムアウトしました。
18 * * * 要求がタイムアウトしました。
19 * * * 要求がタイムアウトしました。
20 * * * 要求がタイムアウトしました。
21 * * * 要求がタイムアウトしました。
22 * * * 要求がタイムアウトしました。
23 * * * 要求がタイムアウトしました。
24 * * * 要求がタイムアウトしました。
25 * * * 要求がタイムアウトしました。
26 * * * 要求がタイムアウトしました。
27 * * * 要求がタイムアウトしました。
28 * * * 要求がタイムアウトしました。
29 * * * 要求がタイムアウトしました。
30 * * * 要求がタイムアウトしました。
トレースを完了しました。
上記の例であれば192.168.20.253
までパケットが届いているのでそれまでの機器のルートテーブルは問題ないので以下の事が考えられます。
192.168.20.253
のルートテーブルに必要なルート設定がない- switchはルーティング設定が出来ない機器がほとんどなのでこの可能性は低い
宛先PC(192.168.20.1)
でICMPパケットを破棄している送信元PC(192.168.10.1)
で戻りのICMPパケットを破棄している
別のパターンでは
PS C:\Users\zuki> tracert 192.168.20.1
192.168.20.1 へのルートをトレースしています。経由するホップ数は最大 30 です
1 <1 ms <1 ms <1 ms 192.168.10.253
2 * * * 要求がタイムアウトしました。
3 8 ms 7 ms 8 ms 192.168.10.254
4 * * * 要求がタイムアウトしました。
5 * * * 要求がタイムアウトしました。
6 * * * 要求がタイムアウトしました。
7 * * * 要求がタイムアウトしました。
8 * * * 要求がタイムアウトしました。
9 * * * 要求がタイムアウトしました。
10 * * * 要求がタイムアウトしました。
11 * * * 要求がタイムアウトしました。
12 * * * 要求がタイムアウトしました。
13 * * * 要求がタイムアウトしました。
14 * * * 要求がタイムアウトしました。
15 * * * 要求がタイムアウトしました。
16 * * * 要求がタイムアウトしました。
17 * * * 要求がタイムアウトしました。
18 * * * 要求がタイムアウトしました。
19 * * * 要求がタイムアウトしました。
20 * * * 要求がタイムアウトしました。
21 * * * 要求がタイムアウトしました。
22 * * * 要求がタイムアウトしました。
23 * * * 要求がタイムアウトしました。
24 * * * 要求がタイムアウトしました。
25 * * * 要求がタイムアウトしました。
26 * * * 要求がタイムアウトしました。
27 * * * 要求がタイムアウトしました。
28 * * * 要求がタイムアウトしました。
29 * * * 要求がタイムアウトしました。
30 * * * 要求がタイムアウトしました。
トレースを完了しました。
上記のような場合では192.168.10.254
まで届いているので
192.168.20.254
のルートテーブルに必要なルート設定がない
上記の可能性が非常に高いです。
このようにtraceroute(tracert)コマンドを使うことでおおよその問題個所を特定することが出来ます。
tcpdumpでパケットが届いているか確認する
tcpdumpコマンドでパケットをキャプチャする事が出来ます。
※windowsの場合はnetsh trace start capture=yes
でキャプチャが出来ます。
$ tcpdump src host 192.168.10.1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
**16:46:01.706990 IP 192.168.10.1 > PC3: ICMP echo request, id 1, seq 159, length 40**
このコマンドを経由するルート上で使うことでパケットが届いているのか確認することが出来ます。
ルートテーブルに設定を追加する
上記の様にルートテーブルに正しい設定が入ってない場合意図しないルートにパケットが伝送される可能性があります。
そうならないために適切なルートを設定する必要があります。
ルートテーブルはPC、ルーター、一部のswitchに設定することが出来ます。
以下の例ではPCのルートテーブルにルートを追加する方法を記載します。
windows
route add -p 192.168.20.0 mask 255.255.255.0 192.168.10.254
説明:ping 192.168.20.1 や ping 192.168.20.254 のようなパケット送信がある場合は192.168.10.254
にパケットを送信する
linux
#host単位でルートを設定
route add -host 192.168.20.1 gw 192.168.10.254
説明:ping 192.168.20.1 のようなパケット送信がある場合は192.168.10.254
にパケットを送信する
#net単位でルートを設定
route add -net 192.168.20.0/24 gw 192.168.10.254
説明:ping 192.168.20.1 や ping 192.168.20.254 のようなパケット送信がある場合は192.168.10.254
にパケットを送信する
また、route(route print)コマンドで現在のルートテーブルを表示することが出来る。
PS C:\Users\asaka\OneDrive\Documents\git> route print
===========================================================================
インターフェイス一覧
18...62 e9 aa 13 be fd ......Microsoft Wi-Fi Direct Virtual Adapter
4...62 e9 aa 13 ae ed ......Microsoft Wi-Fi Direct Virtual Adapter #2
6...60 e9 aa 13 9e dd ......MediaTek Wi-Fi 6 MT7921 Wireless LAN Card
1...........................Software Loopback Interface 1
===========================================================================
IPv4 ルート テーブル
===========================================================================
アクティブ ルート:
ネットワーク宛先 ネットマスク ゲートウェイ インターフェイス メトリック
0.0.0.0 0.0.0.0 192.168.11.1 192.168.11.29 35
127.0.0.0 255.0.0.0 リンク上
127.0.0.1 331
127.0.0.1 255.255.255.255 リンク上
127.0.0.1 331
127.255.255.255 255.255.255.255 リンク上
127.0.0.1 331
192.168.11.0 255.255.255.0 リンク上 192.168.11.29 291
192.168.11.29 255.255.255.255 リンク上 192.168.11.29 291
192.168.11.255 255.255.255.255 リンク上 192.168.11.29 291
224.0.0.0 240.0.0.0 リンク上
127.0.0.1 331
224.0.0.0 240.0.0.0 リンク上 192.168.11.29 291
255.255.255.255 255.255.255.255 リンク上
127.0.0.1 331
255.255.255.255 255.255.255.255 リンク上 192.168.11.29 291
===========================================================================
固定ルート:
なし
PS C:\Users\asaka\OneDrive\Documents\git>
firewallのパケット許可設定
PS C:\Users\zuki> tracert 192.168.20.1
192.168.20.1 へのルートをトレースしています。経由するホップ数は最大 30 です
1 <1 ms <1 ms <1 ms 192.168.10.253
2 * * * 要求がタイムアウトしました。
3 8 ms 7 ms 8 ms 192.168.10.254
4 8 ms 7 ms 8 ms 192.168.20.253
5 * * * 要求がタイムアウトしました。
6 * * * 要求がタイムアウトしました。
7 * * * 要求がタイムアウトしました。
8 * * * 要求がタイムアウトしました。
9 * * * 要求がタイムアウトしました。
10 * * * 要求がタイムアウトしました。
11 * * * 要求がタイムアウトしました。
12 * * * 要求がタイムアウトしました。
13 * * * 要求がタイムアウトしました。
14 * * * 要求がタイムアウトしました。
15 * * * 要求がタイムアウトしました。
16 * * * 要求がタイムアウトしました。
17 * * * 要求がタイムアウトしました。
18 * * * 要求がタイムアウトしました。
19 * * * 要求がタイムアウトしました。
20 * * * 要求がタイムアウトしました。
21 * * * 要求がタイムアウトしました。
22 * * * 要求がタイムアウトしました。
23 * * * 要求がタイムアウトしました。
24 * * * 要求がタイムアウトしました。
25 * * * 要求がタイムアウトしました。
26 * * * 要求がタイムアウトしました。
27 * * * 要求がタイムアウトしました。
28 * * * 要求がタイムアウトしました。
29 * * * 要求がタイムアウトしました。
30 * * * 要求がタイムアウトしました。
トレースを完了しました。
上記のような場合はPCのfirewallでパケットが破棄されている可能性があります。
まずはfirewallのログを確認しましょう。
linux(CentOSの場合)
firewallログを出力する設定
firewall-cmd --set-log-denied=all
firewall-cmd --reload
firewallログを確認する方法
cat /var/log/messages
windows11の場合
firewallログを出力する設定
- firewallを開く
- 「ローカルコンピュータのセキュリティ…」を右クリックして、プロパティを開く
- 「ログ」の「カスタマイズ」をクリック
- 「破棄されたパケット」と「正常なパケット」を記録する様に設定し、「OK」
firewallログを確認する方法
4で設定したファイルを管理者権限で開いたメモ帳で確認する
終わりに
基本的な流れは
- 物理的な配線を確認
- 各端末のIP,subnet,デフォルトGWを確認
- ルートを確認
- Firewallを確認
という流れになると思います。
Networkの問題はハマったときに時間がごっそり持っていかれますが上記の流れで作業すれば6割の問題は解決できると思います。
今はリモートワークが主流なので現地まで行って配線確認するのは怠いですが1番に確認しましょう。
コメント