ネットワーク障害の切り分け順番｜通信できない原因チェックリスト

通信できないときは、事象と影響範囲を固定してから、物理、L2、L3、ACL・ファイアウォール、端末・アプリケーションの順に確認します。全案件で開始点が完全に同じとは限りませんが、下位層から観測事実を積み上げると、推測による設定変更を減らせます。

本文には、そのまま記録欄として使える12項目のチェックリスト、切り分けフロー、正常時・異常時のshowコマンド例、復旧・切り戻し・エスカレーションの判断基準を掲載します。

ネットワーク障害はどの順番で切り分ける？

最初に「誰から誰へ、何が、いつから、どこまで影響しているか」を確定し、その後に物理、L2、L3、セキュリティ、端末・アプリケーションの順で確認します。直前変更が明確なら変更点を優先して構いませんが、関連する下位層の状態も同時に保存します。

事象・範囲・直前変更を固定
          |
          v
[物理] Link / Error / 電源 / 配線
          |
          v
[L2] VLAN / Trunk / STP / MAC
          |
          v
[L3] IP / Mask / ARP / Route / 復路
          |
          v
[制御] ACL / FW / NAT / Session
          |
          v
[端末・アプリ] DNS / Port / Service / Host FW

この順番の目的は、OSI参照モデルを暗唱することではなく、正常な区間と異常な区間の境界を一つずつ確定することです。各段階で期待値、実測値、判断を記録します。

そのまま使える通信障害チェックリスト12項目

次の12項目を上から確認し、結果欄へ「正常・異常・未確認」と証跡の保存先を記録します。環境によって不要な項目は、未実施ではなく「対象外」と理由を残してください。

物理・インターフェースでは何を見る？

LEDやリンク upだけで正常とは判断しません。速度・Duplex、CRC、Input エラー、Output drop、光レベル、LAGメンバー、ケーブル接続先を、正常時と同じ時間幅で比較します。

# Cisco IOS系の参照例。機種・OSで表示は異なる
show interfaces status
show interfaces GigabitEthernet1/0/10
show interfaces counters errors
show etherchannel summary

L2はVLAN・Trunk・STP・MACをどう確認する？

端末ポートのAccess VLAN、上位リンクのAllowed VLAN、Native VLAN、STPの転送状態、MAC学習先を一続きで確認します。VLANが片側だけ定義されている、Trunk許可から漏れている、STPで想定外ポートがBlockingになると、リンク upでも通信できません。

1. 対象端末のVLAN IDと接続ポートを確定する
2. Access/Trunk設定とAllowed VLANを確認する
3. VLANごとのSTP状態を確認する
4. 端末MACをAccessから上位方向へ追う
5. MACが途中で消える区間の設定・リンクを調べる

L3はIP・ARP・経路・復路をどう確認する？

送信元のIP・マスク・Gatewayから、同一サブネットか別サブネットかを判断します。別サブネットならGatewayのARP、各L3機器の最長一致経路、ネクストホップの解決、宛先から送信元への復路を順に追います。

show ip arp 192.0.2.10
show ip route 198.51.100.20
show ip cef 198.51.100.20 detail
traceroute 198.51.100.20 source 192.0.2.1

VRFやポリシー Based ルーティングがある環境では、グローバル テーブルだけを見ても実転送と一致しません。対象VRF・送信元を指定し、NATやトンネルを含む場合は変換前後のアドレスを通信フローへ書き込みます。

ACL・ファイアウォール・NATはどう確認する？

通信要件を送信元、宛先、プロトコル、ポート、方向へ分解し、実際に照合されるポリシー、Hit カウンター、セッション、NAT変換、Drop ログを確認します。Pingが通ってもTCP/443が通るとは限らず、反対にICMP拒否でも業務通信が正常な設計はあります。

端末・DNS・アプリケーションはどう確認する？

ネットワーク区間が正常なら、端末FW、Proxy、DNS、待受ポート、サービス、証明書、アプリログを確認します。IPアドレス宛では成功し、FQDNで失敗するなら、まずDNS回答と接続先IPの差を確認します。

# Windows
nslookup app.example.com
Test-NetConnection app.example.com -Port 443

# Linux/macOS
dig app.example.com
nc -vz app.example.com 443
curl -vk https://app.example.com/

注意：業務環境でのポート scan、debug、パケットキャプチャは許可範囲と負荷を確認してから実行します。

復旧・切り戻し・エスカレーションはどう判断する？

原因候補、影響、復旧見込み、変更リスクを並べ、サービス復旧を優先するか、原因保存を優先するかを責任者と判断します。無承認の複数変更は避け、一操作ごとに結果を確認します。

障害切り分けで避けるべき失敗

よくある失敗は、影響範囲を取らずに機器を再起動する、複数設定を同時に変える、片側の経路だけで正常とする、取得時刻のないログを並べる、Ping成功だけで業務復旧とすることです。

代わりに、仮説ごとに観測点を一つ決め、実行前後の差を残します。設定変更が必要なら、目的、対象行、期待結果、中止条件、切り戻しを先にレビューしてください。

まとめ：12項目を上から確認し、異常区間を狭める

ネットワーク障害は、事象・直前変更を固定し、物理、L2、L3、ACL/FW/NAT、端末・アプリの順で確認します。12項目の結果を正常・異常・未確認で記録すると、担当交代やエスカレーションでも調査を継続できます。

復旧後は疎通だけで終えず、業務応答、監視、冗長性、既存通信、ログを確認し、原因と再発防止まで記録してください。

この記事の執筆・監修者

けんと＠設計構築チャンネル

ネットワーク設計構築エンジニア／インフラ転職コンパス編集者

30歳未経験からネットワークエンジニアへ。金融系・オフィス系ネットワークの設計構築経験をもとに、工程・技術・求人選びを具体的に解説しています。

YouTube 設計構築チャンネル Xで現場発信を見る