「セットアップしたマシンで、うまくネットワークに接続できない」「ネットワーク環境に変更を加えたら、突然アクセスできなくなった」といったトラブルは、比較的よく見受けられる。その際には、まずマシンのネットワーク設定が正しく行われているかどうかを確認すべきだろう。本稿では、ホストのネットワーク設定コマンドに着目。その使用方法やうまく通信が行えない場合のトラブルシューティング方法について解説していこう。
ネットワーク設定の基本
ホストにおけるネットワークの設定は、HDDやCD-ROMドライブといった周辺機器と同様にデバイスに依存したものであるため、実装するOSによって異なってくる。だが、その基本的な考え方は同じだと考えていいだろう。特にIPネットワーク環境に限っていえば、設定すべき項目はほぼ同じである。
ネットワークの設定は、大きく下記の3つに分けられる。
(1) ネットワーク・ドライバ・ソフトウェア（ドライバ）のロード
(2) プロトコルスタック（OSのネットワーク機能）の起動
(3) アプリケーションによるネットワーク機能の利用
このうち(3)は、一般的なネットワーク・アプリケーションの利用ということで、本稿で多くは触れない。
(1)の「ドライバ」とは、OSのネットワーク機能と物理的なネットワーク・インターフェイス＊1とを接続するためのソフトウェアだ。ネットワークへの接続があたりまえとなった現在では、多くのドライバは標準機能としてOS上にロードされ、OSとネットワーク・インターフェイスとの仲介の役割を果たしている。ネットワーク・インターフェイスはそれぞれ機種ごとに実装や動作が異なっているが、OSでその違いのすべてをカバーするのは不可能なため、ドライバがそれらを吸収するための機能を提供しているのだ。従って、ドライバのインストールやロード方法は、OSにより大きく異なる。
Windowsでは、「コントロールパネル」→「ハードウェアの追加と削除」で該当するデバイスのプロパティを開くことで、ドライバのインストールや設定が行える。プラグ＆プレイに対応したハードウェアであれば、自動的にインストール作業が完了する。また現在使用されているドライバは、「コントロールパネル」→「ネットワークとダイヤルアップ接続」（または「ネットワーク」）のプロパティなどで確認できる。
Linuxでは、「/lib/modules/OSバージョン番号/net」以下のドライバを「modprobe」コマンドでロードする。あるいは、Windowsと同様にプラグ＆プレイに対応したハードウェアであれば、起動時に自動認識することもできる。
(2)のプロトコルスタックでは、OSごとに設定方法が異なってくる。この際に利用するネットワーク設定コマンドとして、Linuxではifconfigコマンドを用いる。Windowsでは、「コントロールパネル」→「ネットワークとダイヤルアップ接続」（または「ネットワーク」）のプロパティなどから設定が行える。またWindowsでは、「ipconfig」コマンドによって設定確認ができる。
IPネットワークでの設定
「IPアドレス」「サブネットマスク」の設定は必須
プロトコルスタックとしてIPを選択する場合、最低限必要な設定が、「IPアドレス」と「サブネットマスク」だ。場合によってはブロードキャストアドレスの設定も必要になる。
IPアドレスは、ホスト個々で固有な識別番号だ。ホストを特定するのに使用される。一方のサブネットマスクは、IPアドレスのデフォルトのネットワーク番号を特定するために使用される。サブネットマスクを用いることで、IPアドレスからネットワーク番号とホスト番号を特定できる。このネットワーク番号によって、ルーティングの設定とブロードキャストアドレスが決定されるので、サブネットマスクは重要な設定項目となる。つまり、この両者は1セットで考えなければならない。
Linuxなどでは、サブネットマスク以外に、別途ブロードキャストアドレスを設定できる場合もある。そのほか、IPアドレスとルーティングの関係などについては、「連載：ルータの仕組みを学ぼう 第2回 イーサネットとルーティング」を参照してほしい。
IPアドレスの競合に注意
また、ほかのホストと同じIPアドレスを用いてはならない。IPパケットの届け先が複数存在した場合、どちらへ届ければよいかで、ネットワーク全体のルーティングが混乱するからだ。自身だけでなく、ほかのユーザーにも多大な迷惑をかけることになるので、管理者と相談するなど慎重に設定しよう。
画面1 ほかのホストとIPアドレスが競合していることを知らせるダイアログボックス。ホストのネットワーク機能は停止される。もしサーバなどと競合してしまうと、被害の範囲も広くなってしまう。設定は慎重に（画面をクリックすると拡大表示します）
こうしたIPアドレスの競合を避けるために、IPアドレス設定時には「DHCP（Dynamic Host Configuration Protocol）」機能を用いることが多い。DHCPについては別の回で紹介するが、個々のホスト（DHCPクライアント）がDHCPサーバからIPアドレスの割り振りを受けることにより、互いに重複することなく動的にIPアドレス（DNSサーバのIPアドレスなどの設定情報も含む）を取得できるので、設定ミスによる障害を回避できる。
ネットワーク環境のチューニングと確認
サーバ機、あるいはクライアント機において、ホストのさまざまなネットワーク設定値を見直すことで、パフォーマンスが向上する場合がある。ここで、これら設定値が及ぼす影響についても把握できるようにしておこう。
MTUとMSS／RWIN
近年のブロードバンド環境の普及で、MSSやRWIN、MTUなど、主にフレームやパケット・サイズに関する設定値が注目されることが多くなった。ただし、MTU（Max Transfer Unit）やRWIN（Receive WINdow size）などは、ブロードバンド環境だからということにかかわらず、ネットワーク設定では重要なチューニング・ポイントとして理解される。それぞれの意味と関係について整理してみよう＊2。
MTUは、イーサネット・フレーム（またはPPPoEパケットなどデータ・リンク層のフレーム）におけるトレーラ（格納データ）の最大サイズだ。つまり、（ほとんどの場合は）格納できるIPパケットの最大サイズでもあり、フレーム・サイズを決定する要素である。フレームは、実際にルータやホスト間でやりとりされる基本的なデータ単位のため、パフォーマンスに大きく影響しそうなのは理解してもらえるだろう。イーサネットでの最大サイズは1500bytesである。多くのLANでは、この最大値で運用されているはずだ。ただし、経路上のルータなどがサイズを規定していることもあり、それも考慮する必要がある。対してMSS（Maximum Segment Size）は、TCPにおけるセグメントの最大サイズだ。
MTUとMSSは、別のプロトコル・スタックでの話だという点を理解してほしい。MTUは、物理ネットワーク内で直接接続されている機器間で、自身が送信する際のフレーム・サイズだ。一方、MSSは、送受信相手となるホストに対してTCPオプションで通知する、自身が受信可能なTCPセグメントの最大サイズである。本来別々の設定値ではあるのだが、MSSは
MTU−（IPヘッダ・サイズ＋TCPヘッダ・サイズ（標準的には40bytes））
として、OSで自動決定されることが多い。
RWINは、TCPにおける受信バッファである。RWINはどちらかというとWindows用語で、ネットワーク関連では「TCPウィンドウ・サイズ」と呼ばれている。ウィンドウ・サイズは通信の両端がそれぞれ相手に通知し、その単位でACK確認（正常受信確認）を行って、正常に受信できたかを確認する単位だ。つまり、TCPでは互いの受信バッファ・サイズを把握し合って、その単位でまとめて送信して効率を上げているのだ。途中でパケット・ロスなどがあった場合には、このウィンドウ単位で再度データ送信をやり直さなければならない。
一般に、ウィンドウ・サイズはMSSの整数倍とした方が効率は良くなる。無駄がなくなる確率が高いからだ。また、ウィンドウ・サイズは、一般に最大64kbytesまでに制限される（拡張仕様によっては拡大可能）。
ウィンドウ・サイズが大きくなることは、データをまとめて転送できることを意味するので、大きくなればなるほど転送パフォーマンスが上がる傾向になる。特に、低速回線では効果が高い場合も多い。ただし、TCPは喪失パケットの再送機能も前提としており、再送される単位はウィンドウ・サイズとなるので、ネットワーク品質が低いなどの場合には、逆に効率が悪くなってしまう。
Windows 2000／XPやLinuxでは、「スライディング・ウィンドウ」と呼ばれる双方のネゴシエーションによってウィンドウ・サイズを自動調整する仕組みを持っている（「軋轢（あつれき）制御」）。従って、通常はこの自動調整に任せてしまってもあまり問題はないだろう（Windows 98などでは固定的なウィンドウ・サイズやMTU値が選ばれるため、ブロードバンド環境でのチューニングが話題となったようだ）。ただし、明示的に調整することでパフォーマンスが改善される可能性もある。その場合には以下の点に注意しよう。
- ウィンドウ・サイズをMSSの整数倍とする。MSSが1460であれば、「1460×8＝11680bytes」や「1460×44＝64240bytes」（標準のウィンドウ・サイズの最大値近く）など
- ホストでの調整は問題なくても、経路上のルータがMTU値（もしくはMSS値）を別に規定しているために、結果としてMSSとRWINが効率の悪い数値となる場合もある
なお、WindowsではMTUやRWINの明示的な変更のために、レジストリを変更しなければならない。手動で変更してもよいが、Dr.TCPなどのソフトを使っても便利だろう。Linuxの場合には、ifconfigコマンドやrouteコマンドで変更できる。また、これらの設定値の変更は、インターフェイスまたは経路（LinuxでのMSS／ウィンドウ・サイズ）ごとに必要な点にも注意しよう。
MTUとイーサネット・フレームの分割／再構成
チューニングのもう1つの大きなポイントが、イーサネット・フレーム・セグメントの分割／再構成だ。IPパケット（TCPパケット）は、一般にイーサネット・フレームの最大サイズである1500bytes（ヘッダを含む）より大きくなることが多いので、たとえ1つのIPパケットであっても、複数のイーサネット・フレームに分割されることになる。もし、イーサネット・フレーム・サイズが1500bytesなど一定であれば、それほど問題にならないはずだが、実際にはネットワーク経路のすべてにおいてフレーム・サイズは固定的でない。特にPPPoEなど、ほかのデータ・リンク層プロトコルが混在している場合には、ホストやルータのインターフェイスごとに、送出する最大サイズがそれぞれ異なってしまう場合が多い。
あるルータ（またはマルチホーム・ホスト）へ送出されてきたフレームのMTU値と、そのルータから送出する際のMTU値が異なっている場合、ルータはまず元のフレームからデータを取り出し、別のインターフェイスのMTUの方が小さいときには、転送する際にそのMTU値に合うようにデータを再分割しなくてはならない。つまり、それだけスループットが低下することになる。これが、MTU値における分割と再構成の問題だ。送信の開始側でMTUを決定しても、経路上では変化してしまう可能性があることに注意してほしい。これは、イーサネット（またはデータ・リンク層プロトコル）があくまで物理接続された機器間での通信で完結しているからだ。またこれによって、MSSも影響を受けて変更されてしまうことがある。
一般に、機器管理がすべて可能なLAN環境であれば、単純にすべてのルータなどで同じMTU値となるように設定するよう心掛ければいい。おそらく、イーサネットで標準的な最大値である1500bytesとすることで、分割／再構成の問題は起こらなくなるはずだ。さまざまな機器やプロトコルが参加するインターネット上の経路（例えばADSL回線など）ではMTU値がそれぞれ異なっていたり、ブロードバンド・ルータでは固定化されていたりする場合もある。そうしたときにはRWINなどと同様に、調整によりパフォーマンスが向上することも多い。端的には、最初の送出時に経路上最も小さなMTUに合わせれば、分割／再構成は起こらなくなるはずだ。例えば、ADSL業者やISPが提示する推奨MTU値はそうした値である。
MTU値は固定的に決定されるだけでなく、「パスMTU検出（Path MTU Discovery）」（RFC1191）という経路上の最小のMTU値を検出する仕組みもある。
ただし、すべての環境で対応しているわけではない。途中のルータがICMPパケットを破棄するなどの設定の場合には、逆にMTUサイズ以上の大きなデータの通信が不能になるなどの弊害も起こる（PMTUブラックホール（Path MTU Discovery Black Hole）：RFC2923RFC2923）可能性があるが、ネットワークが複雑に接続されている環境などでは、効率化のための有効な手段ともなるだろう。
ネットワーク統計の調査
設定が正しく終了したら、後は実際の正常稼働を確認するだけだ。pingコマンドやtracerouteコマンドでネットワーク疎通やパフォーマンスを計測したり、そのホスト上でNICなどのインターフェイスの使用状況を確認することもできる。
netstatコマンドでは、インターフェイスごと、プロトコル（IP／TCP／UDP／ICMPなど）ごとの送受信パケット数、エラー数などを確認することができる。単にほかのホストとの通信ができないなどの障害時には、原因がネットワークにあるのか、ホストの設定か、インターフェイスの問題か分からないことも多い。netstatコマンドの表示から、パケットの送受信が行えているかどうか、エラー・パケットが記録されていないかどうかなどを確認してみよう。ネットワークの物理的な問題かどうかの切り分けに役立つはずだ。
関連ネットワーク・コマンド／ツール
ipconfig
〜Windowsのネットワーク設定を確認する
ifconfig
〜（IP）ネットワーク環境の確認／設定
netstat
〜ホストのネットワーク統計や状態を確認する
Copyright © ITmedia, Inc. All Rights Reserved.