システム運用やシステム構築プロジェクトの推進において、ネットワークの不具合の切り分けができると、結構役に立つため、今回、簡単に不具合対応について記事にしました。
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はサーバ内部の処理にてエラーが発生して、
処理ができていない場合が多い。
↓他にもたくさんあるので参考までに。
例 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
ネットワーク技術の教科書
ネットワーク関連で分からないものがあったら辞書として使える
プロトコルごとのフローや、パケット構造、ネットワーク設計に
近しいような知識など幅広く説明がされている
また、ネットワーク設計についても簡単に記載しておりますので、興味があれば下記のサイトを参考にしてください。