Linuxネットワークのトラブルシューティング(OSI参照モデル)
Linuxネットワークのトラブルシューティングで大事なことは、
障害箇所を「OSI参照モデル」で捉える
ことだと思います。
OSI参照モデルは、各層で完全に独立しています。
ただし、上位の層は下位の層が正しく機能していることが前提です。
レイヤ | 名称 | 説明 | TCP/IPにおける例 | 障害の例 |
---|---|---|---|---|
第7層 | アプリケーション層 | アプリケーション間でのデータの通信を規定 | FTP/Telnet | プログラムのフリーズ |
第6層 | プレゼンテーション層 | セッション間でのデータの表現方法を規定 | 文字符号化方式 | テキストデータの文字化け |
第5層 | セッション層 | 通信の開始~終了までを規定 | HTTPなどの各種プロトコル規定 | 規格に沿っていないプロトコル応答 |
第4層 | トランスポート層 | ネットワーク上の2つのプロセス間での通信方式を規定 | TCP/UDP | 異常なフラグを持ったTCPパケット |
第3層 | ネットワーク層 | ネットワーク同士の通信方式を規定 | IP | IPパケットの破損やルーティングの異常 |
第2層 | データリンク層 | 同じネットワーク内での通信方式などを規定 | ARP | 不正なMACアドレスによる混乱 |
第1層 | 物理層 | 物理的な接続や伝送方式などを規定 | 10/100/1000BASE-T | ネットワークケーブルの異常 |
*TCP/IPにおいては第5,6,7層が厳密に区別されていないので、まとめてアプリケーション層として考えても良いようです
OSI参照モデルで捉えるメリットとしては障害原因の切り分けが楽になる事です。階層を一つずつ調査することで、確実に原因と思われる事項を絞り込んでいくことができます。
調査する順番としては、ネットワーク層から徐々に上の層(トランスポート層、セッション層...)を調査していくのが良いと思います。物理層、データリンク層は後回しにすることが多いです。
例えばpingやtracerouteコマンドを用いた場合、
問題がない => トランスポート層を調べていく
問題がある => ネットワーク層、データリンク層、物理層のいずれかで起きている障害
という具合になります。
ネットワークのトラブル調査が全く分からない方は、OSI参照モデルの各層の役割を把握することから始めると良いでしょう。
以上になります。
参考: