動画と記事で学ぶ / 試験・障害対応
Pingが通らないときの確認を初学者向けに説明。要求と応答、タイムアウトと到達不能、IP・ARP・往路と復路、FW、業務通信を順に切り分けます。
ここからは、記事でゆっくり確かめましょう。図や操作の例を見ながら、気になるところから読み進めてください。
Pingが返らないと、まずケーブルを疑いたくなります。でも、原因は端末設定、経路、FW、相手の応答などにもあります。「返らなかった」を一つの故障名にせず、要求と返事がどこまで進んだかを追います。
例ではPCが172.27.81.15、GWが172.27.81.1、サーバーが172.27.92.25です。構成図で機器の位置を押さえ、端末の条件から往路・復路、目的のサービスまで順に見ていきましょう。
どのPCから、どのIPへ試したかを残す
同じPingでも、Wi-Fi、有線、VPNのどれを使うかで送信元や経路が変わります。試験を比べる前に、送信元PCのIP、宛先IP、実行時刻、回数、表示結果をそろえます。
名前を指定した場合には、名前からIPを調べる処理も含まれます。まずIPを指定した結果と分ければ、Pingの要求を送る前に止まったのか、送った後の往復で止まったのかを調べられます。
用語の補足：名前解決って何？
app.example.testのような名前から、接続に使うIPアドレスなどを調べることです。DNSはそのための仕組みです。名前が引けない場合と、引いたIPへ通信できない場合を分けて調べます。
Windowsの確認例：
ipconfig /all
route print -4
ping -4 -n 4 172.27.81.1
ping -4 -n 4 172.27.92.25下のWindows例は、端末設定と経路を読み、GWとサーバーへIPv4のPingを4回ずつ試します。-4はIPv4、-n 4は回数です。別OSでは指定方法が違うため、同じ書き方をそのまま使いません。
127.0.0.1は自分自身へのループバックです。そこへ成功しても、ケーブルの先まで届いたとは言えません。まず、どこからどこまで試した結果なのかを残すことが、調査の範囲を狭める準備になります。
仕様の確認：Microsoft：pingの確認方法。
表示された結果で、次の確認を選ぶ
タイムアウトは、時間内に期待する返事を受け取れなかった結果です。途中で要求が止まったのか、相手が返さなかったのか、返事が戻らなかったのかは、この表示だけでは分かりません。
「宛先ホストに到達できません」なら、届かないという通知を出した相手も読みます。通知元が自端末ならARPや出口、途中のルーターならその先の経路などが次の候補になります。
| 表示の例 | 分かること | 次に調べるもの |
|---|---|---|
| Request timed out / 要求がタイムアウト | 時間内にEcho Replyを得られなかった | 要求と応答の観測位置 |
| Destination host unreachable / 宛先ホストに到達できません | 端末や途中装置が到達不能を通知した | 誰が通知したか、経路・ARP |
| ホスト名を見つけられない | 送信前の名前解決で失敗している可能性 | DNS設定、名前、IP指定の結果 |
| Reply / 応答あり | その条件でICMPの往復が成立 | 損失、応答時間、実際の業務通信 |
ホスト名を見つけられない表示は、送信前の名前解決で止まった可能性があります。入力した名前とDNS設定を読み、IP指定での結果と比べます。タイムアウトと同じ症状として扱わないことが大切です。
応答があるなら、その条件でICMPの往復は成立しています。応答時間が遅い場合も、すぐに帯域不足と決めず、同じ時間帯・端末・宛先で繰り返すかを見ます。表は表示から次の確認を選ぶための案内です。
端末設定から、同じLANの接続までを見る
遠いサーバーへ届かないときは、PCのIP・マスク・経路とリンクを読みます。同じLANの相手やGWへの結果を比べると、失敗している範囲を調べられます。相手がPingへ応答する設定かも前提にします。
別LANのサーバーへ送る例では、PCが最初に渡す相手はGWです。ARPで調べるのも172.27.81.1のMACです。端末のARP表に最終宛先サーバーが載っていないだけでは、異常とは言えません。
| 確認点 | コマンドや証跡 | 判断すること |
|---|---|---|
| 端末IPとマスク | ipconfig /all、ip -4 address | 想定VLAN・アドレス範囲と一致するか |
| 使用する経路 | route print -4、ip route get | VPNや別NICへ流れていないか |
| リンク状態 | NIC表示、Cisco show interfaces | 物理リンクが成立するか |
| 隣接のARP | arp -a、ip neigh | 同一網の相手かGWのMACを解決できるか |
GWのARPが解決しないなら、GWのIP、接続ポート、VLAN、GW側の口を照合します。IPが同じ範囲でも、別VLANへ入っていると同じLAN内のやり取りができない場合があります。
VPNや複数のアダプターがあるなら、宛先へどの出口を選んだかまで経路表で確かめます。設定画面の値を読んだことと、今回その経路を使ったことを分けると、想定外の出口を見つけやすくなります。
要求の道と、応答の戻り道を調べる
PingはEcho RequestとEcho Replyの往復です。PCからサーバーへの経路が正しくても、サーバーからPCへ戻る経路がなければ成功しません。構成図へ、行く道と戻る道を別々にたどります。
R1とFWの間は172.27.94.0/30です。機器の位置を確かめ、各地点で宛先へ向かう経路と、送信元へ戻る経路を読みます。一方向の経路が見えたところで終えないためです。
用語の補足：ICMPとポート番号の関係は？
ICMPはIP通信の状態通知などに使う仕組みです。PingのEcho Request／Replyは、TCPやUDPのポート番号を使いません。FWのTCP/443の許可と、Pingの許可は別条件です。
Ciscoの確認例：
show ip route 172.27.92.25
show ip arp
show ip route 172.27.81.15
NATで送信元が変わる場合は、相手がどのIPへ応答するかも変わります。変換前後の見え方を、その記録を取った場所に対応させます。PCのIPだけを全地点へ当てはめると、応答を見落とすことがあります。
tracertやtracerouteの途中の*は、その試験への返事が得られなかった表示です。その装置で業務通信が必ず止まった証拠ではありません。経路やキャプチャと合わせて、確認できた区間を読んでいきます。
FWとパケットの記録で、止まった区間を狭める
両端などで記録できるなら、同じ試験のRequestとReplyを探します。PCで要求が見え、サーバーで見えないなら、まずその間が調査候補です。サーバーで要求を見つけたら、返事を出したかへ進めます。
IPv4のEcho RequestはICMP Type 8、ReplyはType 0です。TCP／UDPのポート番号は使いません。FWではIPとICMPの種類、方向、必要ならNAT前後を許可条件へ対応させます。
| 観測 | 次の仮説 |
|---|---|
| 宛先側でRequestが見えない | 往路の経路・ACL・NAT、または観測漏れ |
| Requestは見えるがReplyが出ない | 宛先OSのFW、応答設定、負荷 |
| Replyは出るが端末へ届かない | 戻り経路・復路FW・NAT |
| 端末でReplyを観測しても試験が失敗 | 送信元や識別子の対応、端末側処理 |
要求は届くが返事が出ないなら、相手のOSのFWや応答設定などを調べます。返事が出ているのにPCで見えないなら、復路の経路やFWが候補になります。表は、最後に確認できた場所から候補を選ぶ考え方です。
記録にないことを直ちに「通っていない」と決めず、取得場所、時刻、フィルター、ログの記録条件も確かめます。FWを全面停止する前に、今回のICMP条件と必要な許可範囲を特定します。
仕様の確認：RFC 792：ICMP Echo。
Pingが通った後は、使いたいサービスを試す
Pingが通れば、今回のICMP Echoの往復を確認できました。次は使いたいサービスです。WebならTCP接続、その後のTLSや画面操作は別の段階として試します。
下のTest-NetConnectionはTCP/443への接続試験です。Pingだけ成功して、この試験は失敗する場合もあります。逆に、Pingを拒否してWebを許可する構成もあるので、Pingをすべての通信の代表にはできません。
PowerShellのTCP試験例：
Test-NetConnection 172.27.92.25 -Port 443復旧後は、最初に失敗した端末と同じ宛先・回数で再試験し、目的の操作まで戻ります。条件を変えた成功だけでは、最初の症状が直ったか比べにくいからです。
報告には、要求を見た場所、応答を見た場所、まだ調べていない区間を残します。原因を特定できていなくても、この境界が伝われば次の人が調査を続けられます。Pingの結果を、確認できた範囲として説明することが切り分けの基本です。
このテーマを続けて学ぶ
