システム運用やシステム構築プロジェクトの推進において、ネットワークの不具合の切り分けができると、結構役に立つため、今回、簡単に不具合対応について記事にしました。

TCP/IPネットワークについて(初めに)

・ネットワークの全体像の把握
最低限、下記のモデルに関する理解をしておいてください。
説明について詳細な技術説明は省いております。
何が書いてあるかわからない場合は、Google検索と併用して読み進めてください。

また、ぜひ記事に対する意見があればよろしくお願い致します。

ネットワークの全体像
レイヤ	OSI参照モデル	TCP/IPプロトコルスタック	簡略な説明
L7	アプリケーション層	アプリケーション層	利用目的
L6	プレゼンテーション層		文字の設定
L5	セッション層		通信の手続き
L4	トランスポート層	トランスポート層	通信品質・稼働サービスの選択
L3	ネットワーク層	インターネット層	最終宛先への通信
L2	データリンク層	ネットワークインターフェース層	一つ隣への通信
L1	物理層	ネットワークインターフェース層	電気、光信号、ケーブル

■ポイント
・データリンク層は物理依存層ともいう
　L2 EthernetのCSMA/CDにより、物理的制約(L1)がある
・アプリケーション層（ネットワークを利用するための目的）を動作させるためにその下のレイヤーがある
・L2はLLC（ロジカルリンクコントロール）副層とMAC（メディアアクセスコントロール）副層に分けられる
・ICMP(InternetControlManagementProtocol)はIPの拡張機能
・階層化(上記のモデル)を行うことで、機能ごとに改修、不具合対応がしやすくしている

上記の理解があると、資料を読みやすいです。
各層の機能については下記を参照
　・ネスペイージス OSI参照モデル 1

不具合の原因切分けについて

前提として、下記のような流れで、不具合原因の切分けを進める。

１．エラーメッセージから切分け

どういったエラーが出ているかで原因がある程度特定ができる場合があるため、
エラーが出ていないかはネットワークに限らず、システムとかかわっていくうえで重要。

例 HTTPステータスコードなど

4XX　→　クライアント側のエラーの可能性が高い

例えば 404 Not Foundはクライアントのアクセスしようとしているファイルが存在しない

5XX →　サーバ側のエラーの可能性が高い

例えば、500 Internal Server Errorはサーバ内部の処理にてエラーが発生して、
処理ができていない場合が多い。

↓他にもたくさんあるので参考までに。

HTTPステータスコード Wiki

例 ICMPのエラーメッセージ

引用:ICMPコード
コード	意味	説明
0	network unreachable	相手ルーターがダウンしてarp解決出来ない等
1	host unreachable	サーバーがダウンしてarp解決出来ない等
3	port unreachable	サーバーまでたどり着いたが、ポートが解放されていない
4	fragmentation needed and DF set	フラグメントが必要だがフラグメント不可ビットが有効
6	destination network unknown	宛先ネットワークがルーティングテーブルに載っていない
13	communication administratively prohibited by filtering	管理上遮断されている

引用元のサイトがわかりやすい。

上記の説明でイメージがつかない場合はサイト閲覧推奨。

ついでに、RFCもどうぞ

ICMP(Internet Control Message Protocol)はIP(Internet Protocol)の拡張機能のようなもの。

不具合対応におけるPingコマンドやTracertなど、ICMPの機能を使用している。

ネットワークにおける問題の診断等を目的として作られている。

また、影響の範囲から不具合の原因がわかる場合もある。

・サービスの利用者全体

　サーバやインフラ起因による、不具合の可能性が高い

・サービスの利用者のうち、特定のユーザのみ

　特定ユーザ(クライアント側)の設定による、不具合の可能性が高い

ネットワークにおいては、特定のサブネットだけで不具合が発生など、そういった可能性もあるので、影響範囲も気にする。

２．ICMPによる切分け

　
ここが本記事のメイン。

ICMP系のWindowsコマンドはテスト用の通信を送ることで、どこまで通信が正常かを切り分けることが可能

対応方法としては下記がある。

１．一番シンプルな通信(IPアドレスで通信をして名前解決をしない等）から機能を増やしていく。

成功しなかった通信の周辺に不具合がある。

２．一番難しい通信(たくさんの機能を使う通信)から、どんどん機能を落としていく。

どこかでうまくいくようになり、そのうまく言った通信との差分の機能に不具合がある。

３．パケットキャプチャによる切り分け

今までのアプローチで切り分けれなかった場合、サーバやクライアント側の設定の問題であったり、
バグであったりする可能性が考えられる。

原因究明としては、パケットキャプチャを行ったり、不具合を複数回再発させて、
同一時間帯に、何かしらログが残っていないかの時間から分析を行う。

今回の記事の範囲外。

※アプリ通信のプロトコルヘッダ構造を覚えるとよい

Windowsコマンドによる不具合切分け

不具合の切り分けをする際には下記のようなコマンドを使用していく。
全て重要なので、どのコマンドでどういうものを確認したら何がわかるかをしっかり理解する。

　ipconfig

　ネットワーク関連の設定を確認できる
　ipconfig /all
　設定が想定通りか事前確認
　※ipconfigでIPアドレスが表示されない場合、LANケーブルが刺さっていない場合がある

　netshコマンドでも設定の確認はできる（例）
　netsh interface ipv4 show address

　ping

　疎通確認ができる
　通常時に返答が返ってくるかを事前に確認しておく必要がある。
　※FWで遮断される可能性がある
　いろんなPingの使い方
　例１　ホスト名による疎通確認
　ping <例 abc>
　確認できるもの：DNSのサフィックス設定による名前解決+IPアドレスによる疎通

　例２　完全修飾ドメイン名による疎通確認
　ping <例 abc.example.co.jp>
　確認できるもの：名前解決+IPアドレスによる疎通

　例３　通信先IPアドレスによる疎通確認
　ping <例 192.168.123.123>
　確認できるもの：IPアドレスによる疎通

　例４　デフォルトゲートウェイに対する疎通確認
　(ipconfigでデフォルトゲートウェイを確認）
　ping <デフォルトゲートウェイIPアドレス>
　確認できるもの：デフォルトゲートウェイの設定（ルーター）

　例５　自分自身のIPアドレスに対する疎通確認
　ping <自身のIPアドレス>
　確認できるもの：自身のNIC（物理的な物）が正常

　例６　ループバックアドレスに対する疎通確認（自分自身）
　ping 127.0.0.1
　確認できるもの：PING.exe（プログラム）の正常性
　

　上記のPingテスト後の動きとして下記が考えられる
　■pingが正常な場合
　ルーティングは問題なし
　telnetでポートの正常性を確認する
　
　■pingが異常な場合
　FWでICMPを遮断している
　→この場合は、netstatを使って実際のサーバ（サービス）に対し確認をし、サービスが稼働している場合穴あけもしくはルーティングの不具合の可能性がある

　※見分け方として、通常時のpingを事前確認しておくと安心

　ルーティングに問題がある
　→この場合はtracertを使用して、どこまで正常なのか確認
　
　

　tracert

　pingでルーティングに問題がある可能性が高いと判断したときに使用するとよい
　tracert <宛先IPアドレス>
　どこまで正常に通信ができているかが確認できる

　■tracertで異常個所がわかったら
　１　どこまで返答が来ているかをもとにその次の経路を特定
　→構成図もしくは構成の理解が必要
　２　異常であろう箇所のネットワーク機器の設定を確認
　→ルーティングテーブル、ACLなど

　telnet

　※WindowsはTCPの接続のみ確認可能
　クライアントからポートの確認ができる
　telnet <接続先のIPアドレス>

　■telnetが正常な場合
　サーバ上のプログラム（通信の途中）で問題が起きている可能性が高い
　→WireSharkなどによる実際の通信のキャプチャが必要

　■telnetが異常な場合
　サーバのデーモン（待ち受けプログラム）と通信できていない可能性が高い
netstatによるポートの待ち受け状況を確認

　netstat

　通信先サーバへアクセスし,サーバ上で実施する。
　netstat
　LISTENしていなければ待ち受けていない
　Linuxの場合はssなどが最近は使われている
　→OSのバージョンなどを確認する
　※プログラムを特定したい場合はプロセスIDを表示するオプションを使用する

　nslookup

　pingなどで名前解決に問題がありそうな場合に確認できる
　■一発で確認する場合
　nslookup <ドメイン名> <ネームサーバ>

　■対話的に確認（詳細な確認など）
　１nslookup
２set type=<レコード名>
　３><ドメイン名>

nslookup はホストファイルの確認はしない
DNSサーバの確認用のコマンド

学習方法について

　細かく学びたい場合は、下記を参考

　・ネスペイージス(無料)
　　なんでも結構詳しく書いてある。
　　分野を絞って、詳細を知りたいときにお勧め。

　・RFC（Request For Comment）(無料)
　　事実上の標準化文書
　　なぜそういう仕様になったかなどの理由がわかる
　　難しい
　　Wikipediaなどにリンクがある

ネットワークプロトコル最強の指南書

比較的ページ数が少なく、とっつきやすい
内容が簡単かつまとまっている
個人的に全体像を素早く理解したいなら、最推奨

マスタリング TCP/IP 入門編

入門といえばこれ
ある程度入門書を読んでいるなら応用からでもOK

ネットワーク技術の教科書

ネットワーク関連で分からないものがあったら辞書として使える
プロトコルごとのフローや、パケット構造、ネットワーク設計に
近しいような知識など幅広く説明がされている

また、ネットワーク設計についても簡単に記載しておりますので、興味があれば下記のサイトを参考にしてください。