パート I TCP/IP ネットワークの設定と管理

Part 1 では、Solaris 実装の TCP/IP を実行するネットワークの設定方法について説明します。ここでは、読者が UNIX に関する十分な知識を持ち、ローカル UNIX システムの管理についてある程度の経験を積んでいることを前提として、説明を進めます。ネットワーク管理の経験はなくてもかまいません。

• 「ネットワーク管理者の責任」

• 「Solaris ネットワークを形成するハードウェアの種類」

• 「インターネットプロトコル群の概要」

• 「IP アドレス指定方針の設計」

• 「ネームサービスの選択」

• 「ホスト構成モードの決定」

• 「TCP/IP 構成ファイル」

• 「ネットワーク構成手順」

• 「ルーティングプロトコル」

• 「ルータの構成」

• 「一般的な障害追跡方法」

• 「ソフトウェア検査の実行」

第 1 章 ネットワーク管理の概要

この章では、ネットワーク管理者の役割を紹介します。新しくネットワーク管理者になった方にとっては、必要な作業の概略を理解するためにこの章の内容が役立ちます。また、この章には、このマニュアルを読むときに必要になるネットワークの基礎概念も示してあります。すでに経験を積んだネットワーク管理者は、この章をとばして次の章に進んでもかまいません。

• 「ネットワークの設計」

• 「ネットワークの保守」

• 「ネットワークの拡張」

• 「TCP/IPとは何か」

• 「Solaris ネットワークを形成するハードウェアの種類」

• 「情報が転送される仕組 : パケット」

• 「情報を送受信する主体 : ホスト」

ネットワーク管理者の責任

一般に、ネットワーク管理者の作業には次の 4 つの分野があります。

• ネットワークの設計と計画

• ネットワークの設定

• ネットワークの保守

• ネットワークの拡張

各作業分野は、ネットワークのライフサイクルの中の個々のフェーズに対応しています。ネットワーク管理者は、これらのすべてのフェーズに責任を持つ場合もあり、また、ネットワークの保守などのような特定の分野だけを専門的に受け持つ場合もあります。

ネットワークの設計

ネットワークのライフサイクルの最初のフェーズには、ネットワークの設計という作業が含まれますが、一般にこれは新規のネットワーク管理者が行う作業ではありません。ネットワークの設計では、組織のニーズを最大限に満たすようなネットワークの種類を選定することが必要になります。規模の大きいサイトでは、熟練したネットワーク設計者、つまり、ネットワークのソフトウェアとハードウェアの両方を熟知している経験豊富なネットワーク管理者が、この作業を担当します。

ネットワーク設計に関連した各種の要素については、第 3 章「ネットワークの計画」で説明します。

ネットワークの設定

新しいネットワークの設計が終わったら、ネットワーク管理の次のフェーズは、ネットワークの設定と構成です。このフェーズでは、ネットワークの物理的な部分を形成するハードウェアをインストールし、そして、ファイルまたはデータベース、ホスト、ルータ、ネットワーク構成サーバを構成します。

このフェーズに属する作業は、ネットワーク管理者の主要な責任のひとつです。所属組織が非常に大規模で、すでに十分なネットワーク構造が整っている場合を除いて、ネットワーク管理者はこの作業を避けて通ることはできません。

ネットワークのライフサイクルのこのフェーズに関連した作業の説明は、第 4 章「ネットワーク上での TCP/IP の構成」に収めてあります。

ネットワークの保守

ネットワーク管理の第 3 のフェーズには、管理者の責任のもっとも大きい部分を占める日常的な作業が含まれます。この種の作業には次のものがあります。

• ネットワークへの新規マシンの追加

• ネットワークのセキュリティ

• NFS(R) 、ネームサービス、電子メールなどのネットワークサービスの管理

• ネットワーク上の問題に関する障害追跡

第 4 章「ネットワーク上での TCP/IP の構成」に、既存のネットワーク上に新しいホストを設定する方法についての説明があります。第 6 章「TCP/IP の障害追跡」には、ネットワーク上の問題を解決するためのヒントを収めてあります。ネットワークサービスについての詳細は、 『NFS の管理』、『Solaris ネーミングの管理』、『NIS+ への移行』、『メールシステムの管理』を参照してください。セキュリティ関係の作業については、『Solaris のシステム管理』を参照してください。

ネットワークの拡張

ネットワークが安定し正常に動作する期間が長くなるにつれて、ネットワークの機能とサービスの拡張を望む組織の要求が大きくなってきます。始めのうちは、新しいホストを追加することによってネットワーク人口を増やし、共有ソフトウェアを追加することによってネットワークサービスを拡張することができます。しかし、最終的には、単一のネットワークではこれ以上効率的に運営できないような限界点に達することになります。そうなったときが、ネットワーク管理サイクルの第 4 のフェーズである拡張作業にとりかかるときです。

ネットワークの拡張については、選択肢がいくつかあります。

• 新規のネットワークを設定し、ルータとして働くマシンを使ってそのネットワークを既存のネットワークに接続して、インターネットワークを作る

• ユーザの自宅またはリモートサイトでマシンの構成を行い、それらのマシンが電話回線を介してネットワークに接続できるようにする

• ネットワークをインターネットに接続して、ネットワークのユーザが、世界中の他のシステムから情報を検索できるようにする

• UUCP 通信の構成を行い、ユーザがリモートマシンとの間でファイルと電子メールを交換できるようにする

第 5 章「ルータの構成」は、インターネットを設定するための手順を収めてあります。パート II には、可搬コンピュータ用のネットワーク接続の設定方法の説明があります。パート III は、UUCP を使って、ユーザのマシンと他の UUCP システムとの間で情報を交換する方法についての説明があります。

TCP/IPとは何か

ネットワーク通信プロトコルは、ネットワークの中でソフトウェアとハードウェアがどのように対話するかを規定した正式の規則です。ネットワークが正しく働くためには、情報が目的の宛先に誤解のない形式で伝送されることが必要です。 ネットワークの機能を働かせるために、異なる種類のネットワーキング用ソフトウェアとハードウェアが対話することが必要になったことから、設計者たちは通信プロトコルという概念を考案しました。

Solaris オペレーティングシステムには、ユーザの組織でのネットワーク操作に必要なソフトウェアが含まれています。このネットワーキングソフトウェアは、総称的に TCP/IP と呼ばれる通信プロトコル群を実装しています。TCP/IP は、多くの主要な国際標準化機構により標準として認定されており、世界中で使用されています。TCP/IP は複数の規格の集まりですから、多くの異種コンピュータで実行可能であり、これを用いることで、Solaris オペレーティングシステムを実行する異機種システム混在ネットワークを容易に設定できます。

TCP/IP は、多くの異なる種類のコンピュータ、オペレーティングシステム、ネットワークに対して、サービスを提供します。ネットワークの種類は、イーサネット、FDDI、トークンリングなどのローカルエリアネットワークから、T1 (デジタル専用線)、X.25、ATM などの広域ネットワークに至るまで、広範囲にわたっています。

TCP/IP を使用することで、複数のローカルエリアネットワークから成る 1 つのネットワークを構築できます。また、TCP/IP を使用すれば、事実上どのようなポイントツーポイントディジタル回線を用いても、広域ネットワークを構築することができます。

TCP/IP とそのプロトコルファミリについては、 第 2 章「TCP/IP プロトコル群」で詳しく説明します。

Solaris ネットワークを形成するハードウェアの種類

ローカルエリアネットワーク (LAN) という用語は、たとえば 1 つのビルまたは 2 つの隣接するビルのように、比較的狭い空間に限定されている単一のコンピュータネットワークを指します。ローカルエリアネットワークには、ハードウェアとソフトウェアの両方の構成要素があります。ハードウェアの観点から見ると、基本的な Solaris LAN は、なんらかの形のローカルエリアネットワークメディアに接続された複数のコンピュータで構成されます。

ローカルエリアネットワークメディア

コンピュータネットワーク用に使用するケーブル配線や電気配線をネットワークメディアと言います。図 1-1 は、イーサネットメディアを介して相互に接続されている 4 つのコンピュータを示しています。Solaris LAN 環境では、イーサネットが最もよく使われるローカルエリアネットワークメディアです。Solaris LAN で使用できるその他のローカルエリアネットワークメディアには、FDDI とトークンリングがあります。

図 1-1 Solaris ローカルエリアネットワーク

コンピュータとそのコネクタ

TCP/IP ネットワーク上のコンピュータは、ネットワークメディアに接続するために 2 種類のコネクタを使用します。それは、シリアルポートと、ネットワークインタフェース上のポートです。

シリアルポート

どのコンピュータにも、シリアルポートが少なくとも 2 つはあり、これらはコンピュータにプリンタやモデムを接続するためのコネクタとして使用されます。シリアルポートは CPU ボードに装備されている場合もありますが、新たに購入しなければならない場合もあります。システムにモデムを接続して PPP 接続や UUCP 接続を確立するときは、これらのポートを使用します。PPP と UUCP はネットワークメディアとして電話回線を使用することができるので、事実上の広域ネットワークサービスを提供します。

ネットワークインタフェース

ネットワークへの接続ができるようにするためにコンピュータに内蔵されているハードウェアを、ネットワークインタフェースと言います。多くのコンピュータには始めからネットワークインタフェースがインストールされていますが、そうでない場合は、別にネットワークインタフェースを購入する必要があります。

LAN メディアの種類別に、それぞれ異なるネットワークインタフェースが定められています。たとえば、イーサネットをネットワークメディアとして使用したいのであれば、ネットワークの一員となる各ホストにイーサネットインタフェースをインストールしておくことが必要です。イーサネットケーブルを接続するために使用するボード上のコネクタを、イーサネットコネクタと言います。たとえば FDDI の使用を計画しているのであれば、予定している各ホストが FDDI ネットワークインタフェースを備えていなければなりません (その他のネットワークメディアの場合も同様です)。

このマニュアルでは、ホストのデフォルトのネットワークインタフェースを一次ネットワークインタフェースと呼びます。

ネットワークハードウェアのインストールについては、このマニュアルでは取り扱いません。シリアルポートの構成方法については、 『Solaris のシステム管理』

を、ネットワークメディアのインストールの手順については、それに付属しているマニュアルを参照してください。

ネットワークソフトウェアが情報を転送する仕組

ネットワークソフトウェアの設定は複雑な作業です。そこで、まず、設定しようとしているネットワークソフトウェアがどのようにして情報を転送するかを理解しておくことが重要です。

図 1-2 に、ネットワーク通信に関係のある基本的な要素を示します。

図 1-2 ネットワーク上での情報の転送

この図では、あるコンピュータがネットワークメディアを介して、同じメディアに接続している別のコンピュータにパケットを送信しています。

情報が転送される仕組 : パケット

ネットワークを介して転送する情報の基本単位をパケットと言います。パケットの構成は通常の手紙によく似ています。

どのパケットにもヘッダがあり、これは手紙の封筒に当たります。ヘッダには、受取人と送信元のアドレスに加えて、パケットがプロトコル群の各層を移送されるときにそのパケットをどのように扱うかを指示する情報が含まれています。

パケットのメッセージ部は手紙の本体に相当します。パケットに含めることのできるデータのバイト数には制限があり、これは使用しているネットワークメディアによって異なります。したがって、電子メールメッセージなどのような代表的な通信は、いくつかのパケットフラグメントに分割されることがあります。

情報を送受信する主体 : ホスト

経験を積んだ Solaris ユーザなら、もちろん「ホスト」という言葉はよくご存じのことでしょう。この言葉は、しばしば「コンピュータ」または「マシン」の同義語として使われます。TCP/IP の視点から見れば、ネットワーク上に存在する実体は、ルータとホストの 2 つだけです。

ルータは、ネットワークから別のネットワークへとパケットを転送するマシンです。これを行うには、ルータは少なくとも 2 つのネットワークインタフェースを備えていることが必要です。ネットワークインタフェースが 1 つしかないマシンは、パケットを転送できません。このようなマシンはホストとみなされます。ネットワーク上に設定するマシンは、ほとんどがホストになります。

複数のネットワークインタフェースを持ち、しかもルータとして働かないマシンがある場合があります。この種のマシンをマルチホームホストと呼びます。マルチホームホストは、備えているネットワークインタフェースを用いて複数のネットワークに直接的に接続されます。しかし、1 つのネットワークから別のネットワークへとパケットを転送する働きはしません。

あるホストが通信を開始したとき、それを送信側ホスト、または単に送信者と呼びます。たとえば、あるホストのユーザが rlogin を入力するか、または他のユーザに電子メールメッセージを送ると、そのホストは通信を開始します。通信の宛先となるホストを、受信側ホスト、または単に受信者と呼びます。たとえば、rlogin への引数として指定されたリモートホストは、そのログイン要求の受信者です。

各ホストは、ネットワーク上の他の対等ホストに自身を識別させるための、下記の 3 つの特性を備えています。

• ホスト名

• インターネットアドレス。このマニュアルでは IP アドレスと呼んでいる

• ハードウェアアドレス

ホスト名

ホスト名 は、ローカルマシンの名前と所属組織の名前を組み合わせたものです。多くの組織では、ユーザが各自のマシンのホスト名を選定します。sendmail や rlogin などのプログラムは、ネットワーク上のリモートマシンを指定するときにホスト名を使用します。ホスト名に関する説明は、 『Solaris のシステム管理』に収めてあります。

マシンのホスト名は、一次ネットワークインタフェースの名前にもなります。この概念は、ネットワークデータベースを設定したりルータを構成したりするときに重要な意味を持ちます。

ネットワークを設定するときは、そのネットワークに関与するすべてのマシンのホスト名を入手する必要があります。ネットワークデータベースを設定するときに、 第 4 章「ネットワーク上での TCP/IP の構成」の説明に従ってホスト名を使用します。

IP アドレス

「IP アドレス」は、TCP/IP ネットワーク上で各マシンが持っている 2 種類のアドレスの 1 つで、そのマシンをネットワーク上の他の対等ホストに識別させるためのものです。このアドレスには、特定のホストがネットワーク上のどこに位置しているかを、対等ホストに知らせる役割もあります。ネットワーク上のマシンに Solaris オペレーティング環境をインストールしてある場合は、インストールの時に IP アドレスを指定したことを覚えていることでしょう。IP アドレス指定は TCP/IP の重要な局面の 1 つであり、これについては、「IP アドレス指定方針の設計」で詳しく説明します。

ハードウェアアドレス

ネットワーク上の各ホストはハードウェアアドレスを持っており、これもそのホストを他の対等ホストに識別させるために使用されます。このアドレスは、製造元でマシンの CPU またはネットワークインタフェースに物理的に割り当ててあります。ハードウェアアドレスはどれも一意なものです。

このマニュアルでは、ハードウェアアドレスをイーサネットアドレスという言葉で表しています。イーサネットは、Solaris ベースのネットワーク上で最も一般的に使われているネットワークメディアなので、このマニュアルでは、Solaris ホストのハードウェアアドレスがイーサネットアドレスであるものと想定して、説明を進めます。FDDI など他のネットワークメディアを使用している場合は、そのメディアに付属しているマニュアルの中の、ハードウェアアドレス指定に関する部分を参照してください。

ローカルエリアネットワークの境界を越える - 広域ネットワーク

ネットワークが正常に働く状態が続くうちに、他の企業、専門研究機関、所属の LAN 上にない他の組織の情報にアクセスすることが必要になる場合があります。このような情報を入手しようとするユーザは、広域ネットワーク (WAN) を介して通信することが必要になります。WAN は地理的に広い範囲を対象とするもので、ディジタル専用線または電話回線、X.25、ISDN サービスなどのネットワークメディアを使用します。

WAN の代表的な例としてインターネットがあります。インターネットは、TCP/IP の本来の開発目的となっていた各 WAN の後継者となった世界規模の公共ネットワークです。WAN のその他の例としてはエンタプライズネットワークがあります。これは、1 つの企業の個々の事業所同士を、1 つの国の全域、場合によっては 1 つの大陸の全域にわたるようなネットワークによって結ぶものです。つまり、1 つの組織が独自の WAN を構築することが可能です。

ネットワーク管理者は、ローカルネットワークのユーザが WAN にアクセスできるような処置をとることが必要になる場合もあります。TCP/IP と UNIX のコミュニティでは、最もよく使われている公共ネットワークはインターネットです。インターネットに直接接続する方法については、このマニュアルでは説明しません。これについては、役立つ書籍がコンピュータ関係の書店にたくさんそろっています。

セキュリティ

LAN を WAN に接続することには、セキュリティに関するある程度のリスクが伴います。ときには、自分のネットワークを無許可のアクセスから保護したり、データと資源へのアクセスを制御したりすることが必要になります。セキュリティの概要については、『Solaris のシステム管理』に説明があります。詳細な説明は、William R. Cheswick および Steven M. Bellovin 共著の『Firewalls and Internet Security』(Addison Wesly, 1994) に出ています。

米国の majordomo@greatcircle.com に対して、テキストの中に subscribe firewalls を含ませて申し込むことで、情報を入手することもできます。ダイジェスト版の方を望む場合は、テキストの中に firewalls_digest を入れてください。

TCP セッションにおけるラージウィンドウのサポート

TCP セッションのラージウィンドウは、RFC1323 に記述されたサポートを提供します。このサポートは、一般的な上限値の 65,535 バイトより大きなウィンドウを使用することで、ATM や衛星ネットワークなどの広帯域または遅延ネットワークのパフォーマンスを改善するように設計されています。

サポートするデータ量の増大が顕著なのは、65,535 バイトから約 1 ギガバイトに上限値が拡張された TCP セッションです。

TCP セッションのラージウィンドウでは、多数の TCP 構成パラメタがサポートされます。これらのパラメタにより、システム管理者は拡張された送受信ウィンドウサイズと RFC1323 タイムスタンプオプションを使用できます。その際に、アプリケーションを修正する必要はありません。システム全体か特定のホストやネットワークに対して、パラメタを変更できます。このことが特に有効なのは、使用するバッファサイズの拡張機能を持たない ftp や rcp などの標準的なネットワークユーティリティを使用する場合です。

TCP ラージウィンドウのパラメタ

構成パラメタは、TCP デバイスを示す /dev/tcp に関連付けられ、ndd(5) による検査と変更が可能です。通常、これらのパラメタは、システムのブート時に init(1M) が実行するシェルスクリプトの 1 つに設定されます (新規スクリプトの追加方法については、init.d(4) を参照してください)。

使用可能なパラメタとそれぞれの意味は下記のとおりです。

tcp_xmit_hiwat

接続の送信バッファスペースにデフォルト値 (8K) を指定します。

tcp_recv_hiwat

接続の受信バッファスペース (受信データ用に割り当てられたバッファスペースの量。公示されている受信ウィンドウの最大サイズ) にデフォルト値 (8K) を指定します。

tcp_wscale_always

パラメタがゼロ以外であれば、リモートシステムへの接続時にウィンドウスケールオプションが必ず送信されます。パラメタがゼロであれば、64K より大きな受信ウィンドウをユーザが要求した場合に (限って) 送信されます。デフォルトはゼロです。

このパラメタの値にかかわらず、ウィンドウスケールオプションが必ず接続肯定応答に含まれるのは、接続システムがそのオプションを使用した場合です。

tcp_tstamp_always

パラメタがゼロ以外であれば、リモートシステムへの接続時にタイムスタンプオプションが必ず送信されます。デフォルトはゼロです。

このパラメタの値にかかわらず、タイムスタンプオプションが必ず接続肯定応答 (および以降の全パケット) に含まれるのは、接続システムがそのオプションを使用した場合です。

tcp_tstamp_if_wscale

パラメタがゼロ以外であれば、リモートシステムへの接続時にタイムスタンプオプションが送信されるのは、64K より大きな受信ウィンドウをユーザが要求した場合 (つまり、ゼロ以外のスケールを指定したウィンドウスケールオプションを使用している場合) です。デフォルトはゼロです。

tcp_max_buf

SO_SNDBUF または SO_RCVBUF オプション付きでユーザが指定できるバッファサイズの最大値を指定します。この値より大きなバッファの使用を試みると、EINVAL を返して失敗します。デフォルトは 256K です。アプリケーションに必要な最大バッファサイズよりもずっと大きな値をパラメタに指定するのはお勧めできません。障害や悪影響の原因となっているアプリケーションが、カーネルメモリを不当に大きく消費しかねないからです。

tcp_host_param

このパラメタは、IP アドレス、ネットワーク、サブネットワーク、および指定されたホストとの接続に使用される特定の TCP パラメタのデフォルト値をテーブルにしたものです。テーブルを表示するには、以下のように ndd コマンドを使用します。

example# ndd /dev/tcp tcp_host_param
Hash HSP     Address         Subnet Mask     Send       Receive    TStamp
027 fc31eea4 129.154.000.000 255.255.255.000 0000008192 0000008192      0
131 fc308244 129.154.152.000 000.000.000.000 0000032000 0000032000      0
133 fc30bd64 129.154.152.006 000.000.000.000 0000128000 0000128000      1

テーブルの各要素は、ホスト、ネットワーク (サブネットマスクのオプション付き)、サブネットのどれかに加えて、デフォルトの送信バッファスペースと受信バッファスペース、タイムスタンプを使用するかどうかを示すフラグを表示します。

テーブル内で指定されているデフォルト値は、アクティブな接続とパッシブな接続 (connect() と listen()) の両方に使用できます。ホストアドレス全体、サブネット、ネットワークの順で、検出された最適な一致が使用されます。サブネットの認識が有効に動作するためには、サブネットのネットワークにサブネットマスクを指定するエントリがなければなりません。

上のテーブルの例が示す内容は、以下のとおりです。

• ホスト 129.154.152.6 との接続では、128,000 バイトの送受信バッファサイズと、タイムスタンプを使用します。

• サブネット 129.154.152 にある他のホストと接続するための送受信バッファサイズは、32,000 バイトです。

• ネットワーク 129.154 にある他のホストと接続するための送受信バッファサイズは、8,192 バイトです。

テーブルの要素を追加または削除するには、以下のように ndd を使用します。

ndd -set /dev/tcp tcp_host_param '<command>'

 
lt;ipaddr>	[ mask <ipmask>] [ sendspace <integer> ]
				[ recvspace <integer> ] [ timestamp { 0 | 1 } ]

または

<ipaddr> delete

たとえば、上のテーブルを作成するには、次のように指定します。

example# ndd -set /dev/tcp tcp_host_param '129.154.0.0
mask 255.255.255.0 sendspace 8192 recvspace 8192'
            
 
example# ndd -set /dev/tcp tcp_host_param
'129.154.152.0 sendspace 32000 recvspace 32000'
           
 
example# ndd -set /dev/tcp tcp_host_param
'129.154.152.6 sendspace 128000 recvspace 128000 
timestamp 1'
 

削除するには、次のように指定します。

 
example# ndd -set /dev/tcp tcp_host_param '129.154.152.6 delete'
	 
example# ndd -set /dev/tcp tcp_host_param '129.154.152.0 delete'
 
example# ndd -set /dev/tcp tcp_host_param '129.154.0.0	 delete'
 

ネットワークとサブネットを指定するには、ホストビットをゼロにしておきます。エントリ追加用の構文は、既存エントリの修正にも使用できます。

tcp_host_param テーブルからの送受信スペースの値が使用されるのは、それらの値がユーザが設定した (または、tcp_xmit_hiwat と tcp_recv_hiwat から取得した) 値よりも大きい場合に限られます。したがって、スループット向上のためにユーザが大きな値を指定することが可能で、それらの値が誤って縮小されることはありません。

tcp_host_param テーブルのタイムスタンプ値が 1 の場合、接続を開始したときに選択したホストにタイムスタンプオプションが送信されます。ただし、値が 0 の場合でも、tcp_tstamp_always と tcp_tstamp_if_wscale オプションの設定により、タイムスタンプオプションが送信されることがあります。

第 2 章 TCP/IP プロトコル群

この章では、Solaris 実装の TCP/IP ネットワークプロトコル群を紹介します。この章の情報は、まだあまり TCP/IP に慣れていないネットワーク管理者を対象としています (ネットワークの基本概念の紹介については、第 1 章「ネットワーク管理の概要」 を参照してください)。TCP/IP の経験のあるネットワーク管理者の場合は、この章をとばして、行いたい作業に該当する章に進んでもかまいません。

• 「プロトコル層と OSI モデル」

• 「TCP/IP プロトコルアーキテクチャモデル」

• 「標準 TCP/IP サービス」

• 「データのカプセル化と TCP/IP プロトコルスタック」

インターネットプロトコル群の概要

この節では、TCP/IP を構成するプロトコルについて詳しく紹介します。ここに示す情報は純粋に概念的なものですが、各プロトコルの名前とそれぞれの働きは分かるはずです。TCP/IP 関係の書籍は、どれもここに示す概念を理解していることを前提として書かれているので、この情報は重要です。

TCP/IP は、インターネットプロトコル群を形成するネットワークプロトコルの集合を示すニックネームとして使われています。多くの書籍では、「インターネット」という用語は、プロトコル群と広域ネットワークの両方を表すものとして使われています。このマニュアルでは、「TCP/IP」は特にインターネットプロトコル群を表し、「インターネット」は広域ネットワークとそれを運営する組織を表すものとします。

TCP/IP ネットワークと他のネットワークとを相互接続するには、一意な IP ネットワーク番号を入手する必要があります。このマニュアルを執筆した時点では、IP ネットワーク番号は、InterNIC と呼ばれる組織により割り当てられていました。

ネットワーク上のホストがインターネットドメイン名システム (DNS) に参加する場合は、一意なドメイン名を入手し登録する必要があります。InterNIC は、いくつかのトップレベルのドメイン、たとえば .com (商業)、.edu (教育)、.gov (政府) などのドメインの傘下にあるドメイン名の登録も行なっています。InterNIC については、第 3 章「ネットワークの計画」で詳しく説明します (DNS についての詳細は、『Solaris ネーミングの管理』を参照してください)。

プロトコル層と OSI モデル

ほとんどのネットワークプロトコル群は層の連なりとして構築されていますが、これはしばしば総称的にプロトコルスタックと呼ばれます。各層はそれぞれ特定の目的のために設計されていて、送信側ホストと受信側ホストの両方に存在しています。一方のマシンの特定の層が、相手のマシンの対等プロセスが送受信するオブジェクトとまったく同じものを送受信するように設計されています。このような動作は、問題の層の上下の層で進行していることとはまったく独立して行われます。つまり、ホストの各層は、同じマシンの他の層から独立して、他のホストの同じ層と協調して働きます。

OSI 参照モデル

ほとんどのネットワークプロトコル群が層の形に構造化されているとみなされるのは、国際標準化機構 (ISO) が設計した開放型相互接続 (OSI) 参照モデルの結果です。OSI モデルは、ネットワーク活動が 7 つの層から成る構造を持ち、それぞれの層に 1 つまたは複数のプロトコルが関連付けされるものと規定しています。層は、連携するネットワーク相互間でのすべての種類のデータ転送に共通するデータ転送操作を表します。

OSI 参照モデルのプロトコル層は、通常は表 2-1 に示すように、上 (層 7) から下 (層 1) へ並べて表します。

OSI モデルにより定義されている動作は純粋に概念的なものであり、特定のネットワークプロトコル群に特有のものではありません。たとえば、OSI ネットワークプロトコル群は、OSI 参照モデルの 7 つの層をすべて実装しています。TCP/IP は、OSI モデルの層のいくつかを使用し、その他を合併しています。その他のネットワークプロトコル、たとえば SNA では、8 番目の層が追加されています。

TCP/IP プロトコルアーキテクチャモデル

TCP/IP は、いくつかの OSI 層を合併して 1 つの層にしていたり、またまったく使わない層があったりするため、このモデルに直接対応しているとは言えません。表 2-2 は、Solaris 実装の TCP/IP の層を示しています。最上位の層 (アプリケーション) から最下位の層 (物理ネットワーク) まで並べてあります。

この表は、TCP/IP プロトコルの層、対応する OSI モデルの層、そして、TCP/IP プロトコルスタックの各レベルで使用できるプロトコルの例を示しています。通信トランザクションに関与する各ホストは、それぞれ独自の実装によるプロトコルスタックを実行します。

物理ネットワーク層

物理ネットワーク層は、ネットワークに使用するハードウェアの特性を規定します。たとえば、通信メディアの物理特性を規定します。TCP/IP の物理層はハードウェア規格を意味しています。たとえば、イーサネットネットワークメディアの仕様である IEEE 802.3 や、標準ピンコネクタの仕様である RS-232 などです。

データリンク層

データリンク層は、パケットのネットワークプロトコルの種類を識別します。この場合は TCP/IP です。また、この層には、エラー制御と「フレーミング」の働きもあります。データリンク層の例としては、イーサネット IEEE 802.2 フレーミングと、ポイントツーポイントプロトコル (PPP) フレーミングがあります。

インターネット層

この層はネットワーク層とも呼ばれるもので、ネットワークに対してパケットを受け入れたり、配送したりします。この層には、強力なインターネットプロトコル (IP)、ARP プロトコル、ICMP プロトコルが組み込まれています。

IP プロトコル

IP プロトコルとそれに関連したルーティングプロトコルは、おそらく TCP/IP 群全体の中で最も重要なものです。IP は次の機能を受け持ちます。

• IP アドレス指定 - IP アドレス指定の規則は IP プロトコルの一部です (IP アドレス指定については、第 3 章「ネットワークの計画」で詳しく説明します)。

• ホスト間通信 - IP は、受信側ホストの IP アドレスに基づいてパケットが進む経路を決定します。

• パケット形式設定 - IP は、パケットを IP データグラムと呼ばれる単位に組み立てます。データグラムについては、「インターネット層」で詳しく説明します。

• フラグメント化 - パケットが大きすぎてネットワークメディアを介して転送できないときは、送信側ホストの IP は、パケットを小さいフラグメントに分割します。受信側ホストの IP は、これらのフラグメントを組み立てて元のパケットに戻します。

ARP プロトコル

アドレス解決プロトコル (ARP) は、データリンク層とインターネット層の間に概念的に存在するものです。ARP は、イーサネットアドレス (48 ビット長) を既知の IP アドレス (32 ビット長) にマッピングし、IP はこの情報に基づいてデータグラムを正しい受信側ホストに向けることができます。

ICMP プロトコル

インターネット制御メッセージプロトコル (ICMP) は、ネットワークエラー条件の検出とその報告を担当するプロトコルです。ICMP は以下の事項について報告します。

• 取りこぼしたパケット (パケットの到着が速すぎて処理が間に合わない場合)

• 接続障害 (宛先ホストに到達できない場合)

• リダイレクト (送信側ホストに別のルータを使用するよう指示)

第 6 章「TCP/IP の障害追跡」に、エラー検出のために ICMP を使用するオペレーティングシステムコマンドに関する詳しい情報を収めてあります。

トランスポート層

TCP/IP トランスポート層プロトコルは、パケットが正しい順序でエラーなしに到着するようにするために、データ受領の肯定応答を交換し、失われたパケットがあれば転送しなおします。この種類の通信を「終端間」通信と呼びます。このレベルのトランスポート層プロトコルは、トランスミッションコントロールプロトコル (TCP) とユーザデータグラムプロトコル (UDP) です。

TCP プロトコル

TCP は、物理的な回線で接続されているのと同じようにしてアプリケーション相互間の通信ができるようにします。TCP は、独立したパケットの形ではなく、文字単位で転送されているような形でデータを送信します。この転送では、まず開始ポイントで接続がオープンされ、次にバイト順序ですべてのデータが転送され、そして終了ポイントで接続がクローズされます。

TCP は、転送するデータにヘッダを添付します。このヘッダには、送信側マシン上のプロセスが受信側マシン上の対等プロセスに接続できるようにするための、多数のパラメータが含まれています。

TCP は、送信側ホストと受信側ホストとの間に終端間接続を確立することにより、パケットが宛先に到達したことを確認します。したがって、TCP は、「信頼性の高い接続指向型」プロトコルとみなすことができます。

UDP プロトコル

もう 1 つのトランスポート層プロトコルである UDP は、データグラム配送サービスを提供します。受信側ホストと送信側ホストとの間で接続が達成されているかどうかを検査する手段は提供しません。UDP は接続の確立と検査の行程を省略するので、少量のデータを送信するアプリケーションにとっては、TCP よりも効率的です。

アプリケーション層

アプリケーション層は、誰でも使用できる標準的なインターネットサービスとネットワークアプリケーションを定義します。これらのサービスとトランスポート層の両方の働きにより、データの送受信が行われます。アプリケーション層のプロトコルにはさまざまのものがあり、そのうちのいくつかは、すでに使用しているでしょう。下に、この種のプロトコルの例をいくつか挙げておきます。

• 標準 TCP/IP サービス。たとえば、ftp、tftp、telnet コマンドなど

• UNIX "r" コマンド。たとえば、 rlogin や rsh など

• ネームサービス。たとえば、NIS+ やドメインネームシステム (DNS) など

• ファイルサービス。たとえば NFS など

• SNMP (ネットワーク管理用プロトコルの一種。Simple Network Mamagement Protocol の略)

• RIP と RDISC ルーティングプロトコル

標準 TCP/IP サービス

• FTP と匿名 FTP - ファイル転送プロトコル (FTP) は、リモートネットワークとの間でファイルを転送します。このプロトコルには、ftp コマンド (ローカルマシン) と in.ftpd デーモン (リモートマシン) が含まれています。ユーザは、リモートホストの名前とファイル転送コマンドのオプションを、ローカルホストのコマンド行に指定します。すると、リモートホストの in.ftpd デーモンが、ローカルホストからの要求を処理します。rcp とは違って、ftp は、リモートコンピュータが UNIX ベースのオペレーティングシステムを実行していなくても働きます。匿名 FTP を認めるように設定されている場合を除いて、ftp 接続を行うときにはリモートコンピュータにログインする必要があります。

  現在では、インターネットに接続されている各種の匿名 FTP サーバから、さまざまの豊富な資料や情報を入手できます。これらのサーバは大学その他の研究機関により設定されたもので、ある種のソフトウェア、研究報告、その他の情報をパブリックドメインに公開しています。この種のサーバにログインするときには、ログイン名として anonymous を使用します。「匿名 (anonymous) FTP サーバ」という言葉はこれに由来しています。

  匿名 FTP の使用法と匿名 FTP サーバの設定については、このマニュアルでは説明しません。しかし、たとえば『The Whole Internet User's Guide & Catalog』など、匿名 FTP について詳しく説明している多数の書籍が市販されています。FTP を使って標準マシンに到達するための方法については、 『Solaris のシステム管理』に説明があります。ftp(1) のマニュアルページには、コマンドインタプリタにより呼び出されるものも含めて、すべての ftp コマンド・オプションに関する説明があります。 ftpd(1M) のマニュアルページには、in.ftpd デーモンが提供するサービスに関する説明があります。

• Telnet - Telnet プロトコルは、端末と端末指向プロセスが、TCP/IP を実行するネットワーク上で通信できるようにします。このプロトコルは、telnet プログラム (ローカルマシン上の) と in.telnet デーモン (リモートマシン上の) として実装されます。Telnet は、2 つのホストが文字単位または行単位で通信できるようなユーザインタフェースを提供します。アプリケーションにはコマンドのセットが含まれていますが、これについては、telnet(1) のマニュアルページに詳しい説明があります。

• TFTP - 簡易ファイル転送プロトコル (tftp) は ftp に似た機能を備えていますが、ftp の対話型接続を確立する機能はありません。したがって、ユーザは、ディレクトリの内容を表示したり、ディレクトリを変更したりすることはできません。これは、ユーザが、コピーしたいファイルのフルネームを知っていなければならないことを意味します。tftp のコマンドセットについては、tftp(1) のマニュアルページに説明があります。

UNIX "r" コマンド

UNIX "r" コマンドを使用すると、ユーザは、指定したリモートホストで実行したいコマンドを、各自のローカルマシンで発行することができます。この種のコマンドには次のものがあります。

• rcp

• rlogin

• rsh

これらのコマンドの使い方についての説明は、 『Solaris ユーザーズガイド (上級編)』と、rcp(1)、rlogin(1)、rsh(1) の各マニュアルページに出ています。

ネームサービス

Solaris 実装の TCP/IP では、NIS+ と DNS の 2 つのネームサービスが使用できます。

• NIS+ - NIS+ は、ホスト名から IP アドレスとイーサネットアドレスへのマッピング、パスワードの検査など、ネットワーク管理サービスに対する集中制御の機能を提供します。詳細は、 『Solaris ネーミングの管理』を参照してください。

• ドメインネームシステム - ドメインネームシステム (DNS) は、ホスト名から IP アドレスへのサービスを提供します。また、メール管理用のデータベースとしての働きもします。このサービスの詳細は、 『Solaris ネーミングの管理』 を参照してください。in.named(1M) のマニュアルページも参照してください。

ファイルサービス

NFS アプリケーション層プロトコルは、Solaris オペレーティングシステム用のファイルサービスを提供します。NFS サービスについての完全な説明は、『NFS の管理』 に収めてあります。

ネットワーク管理

SNMP (ネットワーク管理用プロトコルの一種。Simple Network Management Protocol) を使用すると、ネットワークのレイアウトを表示し、主要マシンの状態を表示し、さらに、その他の複雑な統計情報をグラフィカルユーザインタフェースを持つソフトウェアから得ることができます。多くの企業が、SNMP を実装するネットワーク管理パッケージを提供しています。SunNet Manager^TM はその一例です。

ルーティングプロトコル

TCP/IP ネットワーク用の 2 つのルーティングプロトコルとして、RIP (Routing Information Protocol) と RDISC (Router Discovery Protocol) があります。これらのプロトコルについては、 第 5 章「ルータの構成」で説明します。

TCP/IP プロトコルがデータ通信を行う方法

ユーザが TCP/IP アプリケーション層プロトコルを使用するコマンドを発行すると、一連のイベントが発生します。ユーザのコマンドまたはメッセージは、ローカルマシン上の TCP/IP プロトコルスタックを通過し、ネットワークメディアを通り、そして受信側のプロトコルに到達します。送信側ホストの各層のプロトコルにより、オリジナルのデータに情報が付加されていきます。

ユーザのコマンドがプロトコルスタックを通過していくとき、送信側ホストの各層のプロトコルは、受信側ホストのそれぞれの対等プロトコルとの間で対話します。 図 2-1 に、この対話がどのように行われるかを示します。

図 2-1 TCP/IP スタックを通過するパケット

データのカプセル化と TCP/IP プロトコルスタック

パケットは、ネットワーク上を転送される情報の基本単位で、少なくとも、送信側ホストと受信側ホストのアドレスが入ったヘッダと、転送するデータが入ったボディーが含まれています。パケットが TCP/IP プロトコルスタックを通過するとき、各層のプロトコルは、基本ヘッダにフィールドを追加したり、そこからフィールドを削除したりします。送信側ホストのプロトコルがパケットヘッダにデータを追加する場合、その動作をデータのカプセル化と呼びます。また、変更後のパケットを表す言葉は、図 2-1 に示すように層によって異なります。

この節では、ユーザがコマンドを発行するかまたはメッセージを送信してから、それを受信側ホストの該当のアプリケーションが受け取るまでの、パケットのライフサイクルを要約して示します。

アプリケーション層 - ユーザが通信を開始

パケットの履歴は、あるホストのユーザが、リモートホストへのアクセスを必要とするようなメッセージを送信するかコマンドを発行した時点から始まります。そのコマンドまたはメッセージに関連付けられているアプリケーションプロトコルは、対応する TCP か UDP のどちらかのトランスポート層プロトコルで取り扱えるように、パケットの形式を設定します。

図 2-1 に示したように、ユーザが、リモートホストにログインするために rlogin コマンドを発行したとします。rlogin コマンドは TCP トランスポート層プロトコルを使用します。TCP は、コマンド内の情報を含むデータをバイトストリーム形式で受け取るものと仮定しています。したがって、rlogin はこのデータを TCP ストリームとして送信します。

しかし、すべてのアプリケーション層プロトコルが TCP を使用するわけではありません。あるユーザが、リモートホストのファイルシステムをマウントしようとして、NIS+ アプリケーション層プロトコルを開始したとします。NIS+ は UDP トランスポート層プロトコルを使用します。したがって、このコマンドを含むパケットは、UDP が仮定しているような方法に形式化する必要があります。この種類のパケットをメッセージと言います。

トランスポート層 - データのカプセル化の開始

データがトランスポート層に到着すると、この層のプロトコルはデータのカプセル化行程を開始します。最終的な結果は、TCP と UDP のどちらが情報を処理したかによって異なります。

TCP のセグメンテーション

TCP はしばしば「接続指向型」プロトコルと呼ばれますが、これは、このプロトコルが、受信側ホストにデータが正常に到達したかどうかを確認するからです。 図 2-1 に、TCP プロトコルが rlogin コマンドからのストリームをどのように受け取るかを示してあります。TCP は、アプリケーション層から受け取ったデータをセグメントに分割し、各セグメントにヘッダを添付します。

セグメントヘッダには、送信側と受信側のポート、セグメント順序に関する情報、そして、検査合計と呼ばれるデータフィールドが含まれています。両方のホストの TCP プロトコルがこの検査合計データを使用して、データがエラーなしに転送されたかどうかを判別します。

TCP 接続の確立

TCP は、受信側ホストでデータ受信の準備が整っているかどうかを判別するためにも、セグメントを使用します。送信側 TCP は、接続を確立するために、受信側ホストで実行されている対等 TCP プロトコルに SYN と呼ばれるセグメントを送ります。受信側 TCP は ACK と呼ばれるセグメントを戻して、セグメントを正しく受信したことを知らせます。送信側 TCP は新たな ACK セグメントを送信して、それからデータの送信を開始します。このような制御情報の交換を「3 相ハンドシェーク」と呼びます。

UDP パケット

UDP は「コネクションレス」プロトコルです。TCP の場合と異なり、UDP は、受信側ホストにデータが到達したかどうかを確認しません。そのかわりに、UDP は、アプリケーション層から受け取ったメッセージを「UDP パケット」に形式化します。UDP は、各パケットにヘッダを付加します。ヘッダには、送信側ホストと受信側ホストのポート、パケットの長さを示すフィールド、そして検査合計が含まれています。

送信側 UDP プロセスは、受信側ホストの対等 UDP プロセスにパケットを送ろうとします。アプリケーション層は、受信側 UDP プロセスが、パケットを受信したことを示す肯定応答を戻すかどうかを判別します。UDP は受領の通知を必要としません。UDP は 3 相ハンドシェークを使用しません。

インターネット層

図 2-1 に示したように、TCP と UDP はどちらもセグメントとパケットを下位のインターネット層に送り、セグメントとパケットはそこで IP プロトコルにより処理されます。IP は、セグメントとパケットを IP データグラムと呼ばれる単位に形式化して、配送の準備を整えます。次に、IP はデータグラムの IP アドレスを判別して、受信側ホストへの効率的な配送ができるようにします。

IP データグラム

IP は、TCP または UDP が付加した情報に付け加える形で、セグメントまたはパケットのヘッダに「IP ヘッダ」を付加します。IP ヘッダには、送信側ホストと受信側ホストの IP アドレス、データグラムの長さ、データグラムのシーケンス番号が含まれます。これらの情報が付加されるのは、データグラムがネットワークパケットとしての許容バイトサイズを超過し、フラグメント化が必要になった場合に備えてのことです。

データリンク層 - フレーミングの実施

PPP などのデータリンク層プロトコルは、IP データグラムをフレームの形に形式化します。これらのプロトコルは、第 3 のヘッダとフッタを付加することにより、データグラムを「フレーミング」します。フレームヘッダには、フレームがネットワークメディアを通過するときのエラーを検査するための、巡回冗長検査 (CRC) フィールドが含まれています。次に、データリンク層は物理層にフレームを渡します。

物理ネットワーク層 - フレームの転送準備

送信側ホストの物理ネットワーク層は、フレームを受け取ると、IP アドレスをネットワークメディアに合わせたハードウェアアドレスに変換します。次に、物理ネットワーク層は、フレームをネットワークメディアに送り出します。

受信側ホストでのパケットの取り扱い

受信側ホストに到着したパケットは、送信側ホストのときと逆の順序で TCP/IP プロトコルスタックを通過します。 図 2-1 にこの経路を示してあります。受信側ホストの各プロトコルは、送信側ホストの対等プロトコルがパケットに付加したヘッダ情報を取り除きます。この処理の順序を以下に示します。

1. 物理ネットワーク層はフレーム形式のパケットを受け取ります。パケットの CRC を計算し、データリンク層にフレームを送ります。

2. データリンク層はフレームの CRC が正しいかどうかを検査し、フレームヘッダと CRC と取り除きます。最後に、データリンクプロトコルは、インターネット層にフレームを送ります。

3. インターネット層はヘッダの情報を読み、転送の種別を識別して、それがフラグメントであるかどうかを判別します。その転送がフラグメントである場合は、IP は、フラグメントを組み立て直して、オリジナルのデータグラムに戻します。そして、IP ヘッダを取り除いてから、データグラムをトランスポート層プロトコルに渡します。

4. トランスポート層 (TCP と UDP) はヘッダを読んで、どのアプリケーション層プロトコルにデータを渡すかを判断します。次に、TCP または UDP は、自分に関連するヘッダを取り除き、メッセージまたはストリームを受信アプリケーションに送ります。

5. アプリケーション層はメッセージを受け取り、送信側ホストから要求された操作を行います。

TCP/IP とインターネットについてもっと詳しく知るには

TCP/IP とインターネットについては、膨大な量の情報が出版されています。このマニュアルで説明されていない特別な情報が必要なときは、以下に挙げる情報源から必要な情報を入手できるものと考えられます。

市販のコンピュータ関係書籍

地域の図書館やコンピュータ関係の書店に、TCP/IP とインターネットに関する多数の書籍がそろっています。中でも特にお勧めしたいのは次の書籍です。

• Craig Hunt 著『TCP/IP Network Administration』 - この書籍には、異種 TCP/IP ネットワークの管理について、ある程度の理論と、大量の実践的情報が収められています。

• W. Richard Stevens 著『TCP/IP Illustrated, Volume I』 - この書籍では、TCP/IP のプロトコルが詳細に解説されています。これは、TCP/IP に関する技術的な背景知識を必要とするネットワーク管理者、そしてネットワークプログラマにとって最適です。

• Ed Krol 著『The Whole Internet User's Guide & Catalog』 - この書籍は、インターネットを介して情報を検索するためのさまざまなツールの使用に関心がある方にとって最適です。

RFC と FYI

1969 年以来、インターネットプロトコル群に携わる開発者たちは、それぞれのプロトコルと関連の主題を、RFC (コメント要求 = Requests for Comments) と呼ばれる文書の形で記述してきました。多くの RFC は特定の TCP/IP プロトコルの仕様であり、そのプロトコルを実装するソフトウェアが従う必要のある規格を記述しています。ほかに、インターネット、そのトポロジ、そしてその運営組織について記述した RFC もあります。さらに、DNS などのような TCP/IP アプリケーションの管理方法を説明する RFC もあります。

RFC がパブリックドメインに公開されるには、IAB (Internet Architecture Board) より承認されることが必要です。一般に、RFC の中の情報は開発者やその他の高度の専門知識を備えた読者を対象としていますが、すべてがそうであるとは限りません。

最近になって、RFC のサブセットとして FYI (For Your Information) 文書が発行されるようになりました。FYI には、インターネット規格を取り扱うような情報は含まれていません。むしろ、インターネットのもっと一般的な性格に関する情報を扱うものです。FYI には、たとえば、TCP/IP の入門書や資料の目録、あらゆるインターネット関連のソフトウェアツールを網羅した要覧、インターネットと一般的なネットワーキングに関する用語集などが含まれています。

このマニュアルでも、また Solaris 2.6 システム管理者セットに含まれる他のマニュアルでも、随所で関連の RFC が参照されています。

RFC の入手方法

InterNic Directory and Database Service には、RFC の蓄積が維持されています。インターネットに接続している場合は、次のようにしてオンラインで RFC を検索できます。

• ftp を用いる場合は、InterNic ディレクトリおよびデータベースサーバ ds.internic.net に要求を送ります。要求の形式は次のとおりです。

  rfc/rfc.rfcnum.txt または rfc/rfc.rfcnum.ps

  rfcnum は、入手したい RFC の番号です。たとえば、RFC 1540 を PostScript(R) 形式で検索したいのであれば、rfc/rfc.1540.ps という要求を出します。

• 電子メールを用いる場合は、米国の mailserv@ds.internic.net に電子メールを送ります。これは自動サーバなので、要求メッセージのボディーは次の形式を備えていることが必要です。

  document-by-name rfcrfcnum.txt

  end

  または

  document-by-name rfcrfcnum.ps

  end

• World Wide Web ブラウザを用いる場合は、URL http://ds.internic.net/ds/dspg1intdoc.html を指定します。ホームページは次のとおりです。http://ds.internic.net

RFC のオンラインインデックスを必要とする場合は、 document-by-name rfc-index という要求を含んだメッセージを、米国の ds.internic.net に電子メールで送ってください。

インターネットは急速に成長しているので、上記に示したアドレスは、このマニュアルをお読みになるときには変更されている場合があります。

第 3 章 ネットワークの計画

この章では、コスト効率のよい整然とした方法でネットワークを構築するために解決しておく必要のある事項について説明します。これらの事項を解決してしまえば、ネットワークを設定し引き続き管理するための計画を立てることができます。

• 「ネットワークの設計」

• 「IP アドレス指定方針の設計」

• 「ネットワークの登録」

• 「ネットワーク上の実体への名前付け」

• 「ルータの追加」

• 「ネットワークトポロジ」

まだ TCP/IP の基本事項に慣れていない方は、第 2 章「TCP/IP プロトコル群」を参照してください。

ネットワークの設計

ネットワークのライフサイクルの最初のフェーズはネットワークの設計です。このフェーズでは、まず、組織のニーズを満たす最適のネットワークの種類を決定することから始めます。計画段階で行う決定には、たとえば次のように、ネットワークハードウェアに関連したものがいくつかあります。

• ネットワークがサポートするホストマシンの数

• 使用するネットワークメディアの種類。たとえば、イーサネット、トークンリング、FDDI など

• ネットワークトポロジ、すなわちネットワークハードウェアの物理的なレイアウトと接続

• ネットワークがサポートするホストの種類。スタンドアロン、ディスクレス、データレス

これらの要因に基づいて、ローカルエリアネットワークのサイズを決定できます。

ネットワークハードウェアの計画については、このマニュアルでは説明しません。詳細は、ハードウェアに付属しているマニュアルを参照してください。

ネットワーク計画に関する要因

ハードウェア計画を完成してしまったら、次に、ソフトウェアに重点を置いたネットワーク計画に着手することができます。

この計画工程では次のような手順が必要になります。

1. ネットワーク番号を入手し、必要なら、ネットワークドメインを InterNIC に登録します。

2. IP ネットワーク番号を受け取ったら、ホストに適用する IP アドレス指定方針を考えます。

3. ネットワークを形成するすべてのマシンの IP アドレスとホスト名を含むリストを作成します。これは、ネットワークデータベースの構築の際に利用できます。

4. ネットワークでどのネームサービスを使用するかを決定します。使用できるのは、NIS、NIS+、DNS、または、ローカルな /etc ディレクトリにあるネットワークデータベースのどれかです。

5. ネットワークに必要なら、管理作業を分担するための区分を設定します。

6. ネットワークがルータを必要とするような規模のものかどうかを判断し、必要なら、ルータをサポートするようなネットワークトポロジを作成します。

7. ネットワークに必要なら、サブネットを設定します。

以下第 3 章「ネットワークの計画」では、上記の要因を念頭に置きながらネットワークの計画を立てる方法について説明します。

IP アドレス指定方針の設定

サポートを予定しているマシンの数によって、このサイトでのネットワーク設定の現段階で行う決定実行のいくつかが影響を受けます。組織によっては、1 つの階または 1 つのビルの中にある数十台のスタンドアロンマシンから成る小さいネットワークが必要な場合もあります。逆に、複数のビルに散在する 1000 以上ものホストを持つネットワークの設定が必要な場合もあります。このような大きい配置の場合は、ネットワークをサブネットと呼ばれる小区分に細分することが必要になることもあります。予定されているネットワークのサイズは、次の事項に影響を与えます。

• 適用するネットワーククラス

• 受領するネットワーク番号

• ネットワークで使用する IP アドレス指定方針

ネットワーク番号を入手し、IP アドレス指定方針を確立することは、ネットワーク管理の計画フェーズでの最も重要な作業の 1 つです。

IP アドレス番号のパーツ

TCP/IP を実行する各ネットワークは、それぞれ一意なネットワーク番号を持っていて、そのネットワーク上のすべてのマシンがそれぞれ一意な IP アドレスを持っていることが必要です。ネットワークを登録し、ネットワーク番号を入手するには、その前に、IP アドレスの構造を理解しておくことが重要です。

IP アドレスは、特定のマシンのネットワークインタフェースを一意なものとして識別する 32 ビットの番号です。IP アドレスは一般に 10 進数字で表され、ピリオドで区切った 4 つの 8 ビットフィールドの形式をとります。個々の 8 ビットフィールドは、それぞれ IP アドレスの 1 バイトを表します。このような形式で IP アドレスのバイトを表す方式を、「ドット化 10 進形式」と呼びます。

IP アドレスのバイトは、さらに、ネットワーク部とホスト部の 2 つの部分に分かれます。図 3-1 に、129.144.50.56 という典型的な IP アドレスの構成パーツを示します。

図 3-1 IP アドレス番号のパーツ

ネットワーク部

ネットワーク部は、ネットワークに割り当てられている一意な番号を示します。これは、割り当てられているネットワーククラスも識別します。 図 3-1 では、ネットワーク部は IP アドレスの 2 バイトを占めています。

ホスト部

IP アドレスのこの部分は、管理者が各ホストに割り当てる番号です。この番号は、ネットワーク内でこのマシンを一意なものとして識別します。ネットワーク上の各ホストについて、アドレスのネットワーク部は同じで、ホスト部は違っていなければならないという点に注意してください。

サブネット番号 (オプション)

多数のホストを持つローカルネットワークは、いくつかのサブネットに分割されることがあります。ネットワークをサブネット化することにした場合は、サブネットにサブネット番号を割り当てる必要があります。IP アドレスのホスト番号部の一部のビットをネットワーク識別子として使用することで、IP アドレス空間の有効率を最大限にすることができます。ネットワーク識別子として使用した場合、アドレスの指定した部分がサブネット番号になります。サブネット番号は、ネットマスクを使って作成します。ネットマスクは、IP アドレスのネットワーク部とサブネット部を選択するビットマスクです (詳細は、「ネットワークマスクの作成」を参照してください)。

ネットワーククラス

ネットワーク上での IP アドレス指定に関する計画の第 1 ステップは、最も妥当なネットワーククラスを決定することです。それが済んだら、きわめて重要な第 2 のステップ、つまり、InterNIC アドレス指定機関からのネットワーク番号の入手に移ることができます。

現在、TCP/IP ネットワークには 3 つのクラスがあります。32 ビットのアドレス空間は、ネットワーク部のビット数が多かったり少なかったりするなど、クラスによって使い方が異なります。3 つのクラスとは、クラス A、クラス B、クラス C です。

クラス A ネットワーク番号

クラス A ネットワーク番号では、IP アドレスの最初の 8 ビットが「ネットワーク部」として使用されます。残りの 24 ビットは、下の 図 3-2 に示すように、IP アドレスのホスト部です。

図 3-2 クラス A アドレスのバイト割り当て

クラス A ネットワーク番号の最初のバイトに割り当てられる値の範囲は、1 〜 127 です。たとえば、75.4.10.4 という IP アドレスがあるとします。最初のバイトの 75 という値は、このホストがクラス A ネットワーク内にあることを示しています。残りのバイトの 4.10.4 はホストアドレスを形成します。クラス A の番号の場合、InterNIC が割り当てるのは、最初の 1 バイトだけです。残りの 3 バイトをどのように使用するかは、そのネットワーク番号の所有者の自由です。クラス A のネットワークとして存在可能なのは 127 個だけです。この範囲内の各番号が、それぞれ最大 16,777,214 個のホストを収容できます。

クラス B ネットワーク番号

クラス B ネットワーク番号では、16 ビットがネットワーク番号に使用され、16 ビットがホスト番号に使用されます。クラス B ネットワーク番号の最初のバイトの値の範囲は、128 〜 191 です。129.144.50.56 の番号の場合、最初の 2 バイトの 129.144 は InterNIC により割り当てられるネットワークアドレスです。残りの 2 バイトの 50.56 はホストアドレスで、これはネットワーク番号の所有者が任意に割り当てることができます。図 3-3 に、クラス B のアドレスを示します。

図 3-3 クラス B アドレスのバイト割り当て

一般に、クラス B は、多数のホストを備えたネットワークを持つ組織に割り当てられます。

クラス C ネットワーク番号

クラス C ネットワーク番号では、24 ビットがネットワーク番号に使用され、8 ビットがホスト番号に使用されます。クラス C ネットワーク番号は、ホスト数が少ない、つまり最大ホスト数が 254 台程度のネットワークに適しています。クラス C ネットワーク番号は、IP アドレスの最初の 3 バイトを占めます。ネットワーク番号の所有者が自由に割り当てることができるのは、4 番目のバイトだけです。図 3-4 に、クラス C アドレスのバイトを示します。

図 3-4 クラス C アドレスのバイト割り当て

クラス C ネットワーク番号の最初のバイトの値の範囲は、192 〜 223 です。第 2 と第 3 のバイトの値の範囲は、どちらも 1 〜 255 です。典型的なクラス C アドレスは、たとえば 192.5.2.5 のようになります。最初の 3 バイトの 192.5.2 がネットワーク番号です。最後のバイト、つまり 5 がホスト番号です。

ネットワーク番号の管理

所属している組織に複数のネットワーク番号が割り当てられているか、またはサブネットを使用している場合は、組織内でネットワーク番号を割り当てる総括責任者 (人または部門) を指名してください。この責任者が、割り当てられたネットワーク番号のプールを管理する権限を保持し、ネットワーク、サブネット、ホスト番号を必要に応じて割り当てます。問題の発生を避けるために、組織内に重複したネットワーク番号や無秩序なネットワーク番号が生じることのないように注意してください。

IP アドレス指定方針の設計

ネットワーク番号を受け取ったら、IP アドレスのホスト部をどのように割り当てるかについて、計画を立てることができます。

表 3-1 は、IP アドレス空間がどのようにネットワークアドレス空間とホストアドレス空間に分かれるかを示しています。どのクラスについても、「範囲」の欄は、ネットワーク番号の最初のバイトの 10 進数値の範囲を示しています。「ネットワークアドレス」は、IP アドレスの中でネットワーク部の働きをするバイト数を示し、xxx が 1 バイトを表しています。「ホストアドレス」は、アドレスのホスト部として働くバイト数を示します。たとえばクラス A ネットワークアドレスの場合は、最初の 1 バイトがネットワーク番号で、残りの 3 バイトがホスト番号です。クラス C ネットワークの場合は、この関係が逆になります。

IP アドレスの最初のバイトの数値は、ネットワークがクラス A、B、C のどれであるかを示す値で、常に InterNIC が割り当てます。残りの 3 つのバイトの値の範囲は、どれも 0 〜 255 です。番号 0 と 255 は予約されています。ネットワーク管理者は、割り当てられているネットワーク番号に応じて、各バイトに 1 〜 254 の範囲内の番号を指定することができます。

表 3-2 は、IP アドレスのどのバイトがインターネットから割り当てられ、ホストへの割り当てが可能な各バイトにどの範囲の値を指定できるかを示しています。

ネットワークインタフェースへの IP アドレスの適用法

「ネットワークインタフェース」 で説明したように、ネットワークに接続するには、コンピュータはネットワークインタフェースを少なくとも 1 つは備えていることが必要です。そして、各ネットワークインタフェースは、それぞれ一意な IP アドレスを持っていなければなりません。管理者がホストに与えた IP アドレスはそのホストのネットワークインタフェースに割り当てられます。このインタフェースは、一次ネットワークインタフェースと呼ばれることがあります。あるマシンに第 2 のネットワークインタフェースを追加した場合は、それにも一意な IP アドレスが必要です。第 5 章「ルータの構成」で説明したように、第 2 のネットワークインタフェースを追加すると、マシンの機能がホストからルータに変わります。ホストに第 2 のネットワークインタフェースを追加し、しかもルーティング機能を無効にした場合は、そのホストはマルチホームホストとみなされます。

/devices ディレクトリには、各ネットワークインタフェースのデバイス名、デバイスドライバ、関連のデバイスファイルが入っています。ネットワークインタフェースのデバイス名には、たとえば le0 または smc0 などがあります。これらは、よく使われる 2 つのイーサネットインタフェースのデバイス名です。

このマニュアルでは、イーサネットネットワークインタフェースを持つマシンを想定して説明を進めます。別のネットワークメディアを使用する予定の場合は、そのネットワークインタフェースのマニュアルの中の構成に関する情報を参照してください。

ネットワーク上の実体への名前付け

割り当てられたネットワーク番号を受け取り、ホストの IP アドレスを指定してしまったら、次に行う作業は、ホストに名前を割り当て、ネットワーク上のネームサービスをどのように扱うかを決めることです。これらの名前は、最初にネットワークを設定するときに使用するほか、後日ルータや PPP を用いてネットワークを拡張するときにも使用します。

TCP/IP は、ネットワーク上の特定のマシンを見つけるときに、そのマシンの IP アドレスを使用します。しかし、人間にとっては、マシンに意味のある名前が付いている方が、識別しやすくて便利です。したがって、TCP/IP プロトコル (そして Solaris オペレーティングシステム) では、マシンを一意なものとして識別するために、IP アドレスとホスト名の両方が必要です。

TCP/IP の視点から見れば、ネットワークは名前付けられた実体の集合です。ホストは名前付けられた 1 個の実体です。ルータも名前付けられた 1 個の実体です。さらに、ネットワークも名前付けられた 1 個の実体です。ネットワークがインストールされているグループや部門にも、名前を付けることができます。部課、地区、会社も同様です。理論的には、ネットワークとそのマシンを識別するために使用できる名前の階層については、事実上まったく制限はありません。これらの名前付けられた実体を総称してドメインと呼びます。

ホスト名の管理

多くのサイトでは、各ユーザがそれぞれのマシンの名前を選定しています。サーバにも少なくとも 1 つのホスト名が必要で、このホスト名は一次ネットワークインタフェースの IP アドレスに関連付けられます。

ネットワーク管理者は、自己の管轄ドメイン内のすべてのホスト名が一意なものであることを確認する必要があります。たとえば、ネットワーク内の "fred" というマシンが複数の IP アドレスを持っていてもかまいませんが、ネットワーク内に "fred" という名前を持つマシンが 2 つあってはなりません。

ネットワークの計画を立てるときは、IP アドレスとそれぞれのホスト名のリストを作って、設定工程中に各マシンに簡単にアクセスできるようにしてください。このリストは、すべてのホスト名が一意かどうかを検査するために役立ちます。

ネームサービスの選択

Solaris オペレーティングシステムでは、4 種類のネームサービスのどれでも任意に選択して使用できるようになっています。4 つのネームサービスとは、ローカルファイル、NIS、NIS+、DNS です。ネームサービスは、ネットワーク上のマシンに関する重要な情報、たとえばホスト名、IP アドレス、イーサネットアドレスなどを保持しています。

ネットワークデータベース

オペレーティングシステムをインストールするときに、その手順の一環として、サーバマシン、クライアントマシン、スタンドアロンマシンのホスト名と IP アドレスを入力します。Solaris インストールプログラムは、hosts データベースと呼ばれるネットワークデータベースにこの情報を入れます。hosts データベースは、ネットワーク上での TCP/IP の動作に必要な情報が含まれている一組のネットワークデータベースの 1 つです。これらのデータベースは、管理者が自己のネットワーク用として選択したネームサービスにより読み取られます。

ネットワークデータベースの設定は、ネットワーク構成の重要な部分です。したがって、ネットワーク計画工程の一環として、どのネームサービスを使用するかを決定する必要があります。ネームサービスの使用の決定は、ネットワークを管理ドメインとして編成するかどうかにも影響を与えます。ネットワークデータベースのセットについては、第 4 章「ネットワーク上での TCP/IP の構成」に詳しい説明があります。

ネームサービスとしての NIS、NIS+、DNS の使用

NIS、NIS+、DNS ネームサービスは、ネットワーク内のいくつかのサーバ上にネットワークデータベースを維持します。これらのネームサービスとそれぞれの設定方法については、『Solaris ネーミングの設定と構成』 に詳しい説明があります。「名前空間」と「管理ドメイン」の概念に関する詳しい説明も出ています。ネームサービスを NIS から NIS+ に変更する場合は、 『NIS+ への移行』を参照してください。これらのマニュアルは、ネットワークでこれらのネームサービスのどれを使用するかを決める際の参考として役立ちます。

ネームサービスとしてのローカルファイルの使用

NIS、NIS+、DNS のどれも実装しない場合は、ネットワークはローカルファイルを使ってネームサービスの機能を提供します。「ローカルファイル」とは、ネットワークデータベースが使用するためのものとして /etc ディレクトリに入っている一連のファイルのことです。このマニュアルに示す手順では、特に断らない限り、ネームサービスとしてローカルファイルを使用しているものとします。

ネットワーク用のネームサービスとしてローカルファイルを使用することに決めた場合、後日別のネームサービスを設定することもできます。

ドメイン名

多くのネットワークでは、ホストとルータが管理ドメインの階層の形で編成されます。NIS、NIS+、DNS のどれかのネームサービスを使用する場合は、所属組織のドメイン名として、全世界の中で一意な名前を選択する必要があります。ドメイン名が一意であることを確認するには、そのドメイン名を InterNIC に登録することが必要です。特に、DNS の使用を予定している場合は、この処置が重要です。

ドメイン名は階層構造を備えています。一般に、新規のドメインは、既存の関連ドメインの下に配置されます。たとえば、子会社のドメイン名はその親会社のドメイン名の下に配置されます。特に他との関連性のない組織のドメイン名は、既存の最上位ドメインのどれかの下に直接配置できます。

最上位ドメインの例としては次のようなものがあります。

• .com - 民間企業 (世界規模)

• .edu - 教育機関 (世界規模)

• .gov - アメリカ政府機関

• .fr - フランス

組織を識別する名前は、一意なものであるという条件を満たしていれば、ネットワーク管理者が任意に選択できます。

管理作業の分化

管理作業の分化の目的は、サイズと制御に関する事項を解決することにあります。ネットワーク内のホストとサーバの数が増えるに従って、管理作業はますます複雑になります。このような状況に対処するための方法としては、管理部門を増設することが考えられます。そのためには、特定のクラスのネットワークを増設するか、または既存のネットワークをサブネットに分割します。ネットワーク管理の作業を分化するかどうかを決める要因には、次のものがあります。

• ネットワークの規模

  数百台のホストから成る単一のネットワークにおいて、すべてのホストが物理的に同じ場所にありしかも同じ管理サービスを必要とするものである場合は、1 つの管理部門だけで対処できるでしょう。これに対して、マシン数がもっと少ない場合でも、ネットワークが多数のサブネットに分割されていて、しかも地理的に広い範囲に散在しているとすれば、複数の管理部門を設立する方が効率的になります。

• ネットワーク上のユーザのニーズが共通しているかどうか

  たとえば、1 つのビル内だけに限定され比較的少数のマシンをサポートするネットワークがあるとします。そして、このネットワークのマシンがいくつかのサブネットワークに分割され、各サブネットワークがそれぞれ大幅にニーズの異なるユーザのグループをサポートしているとします。このような場合は、各サブネットごとに管理部門を設けるとよいでしょう。

  管理作業の分化については管理作業の分化については、『Solaris ネーミングの管理』に詳しい説明があります。

ネットワークの登録

Solaris ネットワーク上のマシンに IP アドレスを割り当てるには、その前に InterNIC からネットワーク番号を入手する必要があります。さらに、管理ドメインの使用を予定している場合は、管理ドメインを InterNIC に登録することも必要です。

InterNIC と InterNIC Registration Services

InterNIC は、インターネットのユーザに以下の情報を提供するための本部組織として、1993 年に創立されました。

• インターネットの運営方針

• インターネットへのアクセス方法。これには研修サービスも含まれる

• インターネットのユーザが利用できる資源。たとえば、匿名 FTP サーバ、Usenet ユーザグループなど

InterNIC には、ユーザが TCP/IP ネットワークを登録する InterNIC Registration Services という組織も含まれています。InterNIC Registration Services は、ネットワークを入手しドメインを登録するためのテンプレートを提供しています。登録については、次の 2 つの点に注意してください。

• ネットワーク番号は InterNIC が割り当てる

ネットワークを他の既存の TCP/IP ネットワークに接続する予定がなくても、勝手なネットワーク番号を割り当てることはしないでください。

サブネット番号は InterNIC が割り当てるものではありません。この番号は、割り当てられたネットワーク番号と、ネットワーク管理者が指定する番号を組み合わせたものとなります。これについては、「サブネット化とは」で説明します。

• ドメイン名は、InterNIC ではなくネットワーク管理者が決めて、それを InterNIC に登録する

InterNIC への連絡方法

InterNIC Registration Services には次の方法で連絡できます。

• 郵便

  宛先は次のとおりです。

     Network Solutions 
     Attn: InterNIC Registration Services
     505 Huntmar Park Drive 
     Herndon, Virginia 22070

• 電話

  電話番号は、米国の 703-742-4777 です。電話サービスの利用可能時間は、米国東部標準時で午前 7 時から午後 7 時までです。

• 電子メール

  次の米国の宛先にネットワーク登録に関する電子メールを送ります。 Hostmaster@rs.internic.net

• Gopher と WAIS インタフェースを用いた匿名 FTP または Telnet 照会 rs.internic.net に接続します (このマニュアルでは、匿名 FTP と Telnet については説明しませんが、コンピュータ関係の書店にこれらの事項に関する書籍がそろっています)。

ルータの追加

TCP/IP から見た場合、ネットワーク上に存在するのは、2 つの種類の実体、つまりホストとルータだけです。すべてのネットワークがホストを持っていることが必要ですが、ルータはすべてのネットワークに必要なわけではありません。ルータを使用するかどうかは、ネットワークの物理的なトポロジによって異なります。この節では、ネットワークトポロジとルーティングの概念を紹介します。この概念は、既存のネットワークに別のネットワークを追加しようとするときに、重要な意味を持ちます。

ネットワークトポロジ

ネットワークトポロジは、複数のネットワークの相互関係を示します。ルータは、ネットワークを相互に接続する実体です。TCP/IP の視点から見れば、ルータは複数のネットワークインタフェースを備えた任意のマシンです。しかし、マシンをルータとして働かせるためには、第 5 章「ルータの構成」の説明に従って、そのルータを正しく構成しておくことが必要です。

複数のネットワークをルータにより接続することで、より大きなインターネットワークを作ることができます。ルータは、隣接する 2 つのネットワーク間でパケットの受け渡しをするように構成する必要があります。さらに、隣接するネットワークを越えた位置にあるネットワークに、パケットを渡す機能も備えていることが必要です。

図 3-5 に、ネットワークトポロジの基本部分を示します。最初の図は、2 つのネットワークを 1 台のルータで接続した単純な構成です。2 番目の図は、3 つのネットワークを 2 台のルータで相互接続した構成を示しています。最初の例では、ネットワーク 1 とネットワーク 2 がルータ R で連結されて、より大きなインターネットワークが作られています。2 番目の例では、ルータ R1 がネットワーク 1 とネットワーク 2 を接続し、ルータ R2 がネットワーク 2 とネットワーク 3 を接続して、ネットワーク 1、2、3 から成る 1 つのネットワークが作られています。

図 3-5 基本的なネットワークトポロジ

ルータは、ネットワークを連結してインターネットワークを作り、宛先ネットワークのアドレスに基づいて、ネットワーク相互間でパケットをルーティングします。インターネットワークがもっと複雑になると、パケットをどこに送るかについての各ルータでの決定の回数もそれにつれて増加します。

複雑さの度合の増加を示す例として、図 3-6 のような場合が考えられます。この例では、ネットワーク 1 とネットワーク 3 が、ルータ R3 により直接接続されています。このような冗長な手段を使用する目的は、信頼性にあります。ネットワーク 2 がダウンしても、ルータ R3 はネットワーク 1 と 3 の間の送信経路を提供することができます。すべてが同じネットワークプロトコルに従っていれば、ネットワークをいくつでも相互接続して、互いに通信させることができます。

図 3-6 ネットワーク間のパスの追

ルータがどのようにパケットを転送するか

ネットワーク上でのルーティングに関する決定は、パケットヘッダに含まれている受信側 IP アドレスのネットワーク部に基づいて行われます。このアドレスにローカルネットワークのネットワーク番号が含まれている場合は、その IP アドレスを持つホストに直接パケットが送られます。ネットワーク番号がローカルネットワークではない場合は、パケットはローカルネットワーク上のルータに送られます。

ルータは、ルーティングテーブル内にルーティング情報を維持します。このテーブルには、ルータが接続されているネットワーク上のホストとルータの IP アドレスが含まれています。また、それらのネットワークを指すポインタも含まれています。ルータは、パケットを受け取ると、ルーティングテーブルを調べて、ヘッダ内の宛先アドレスがテーブルにリストされているかどうかを確認します。テーブルにその宛先アドレスが含まれていない場合は、ルータは、ルーティングテーブルにリストされている他のルータにパケットを転送します。ルータについての詳細は、 第 5 章「ルータの構成」を参照してください。

図 3-7 は、2 つのルータにより接続された 3 つのネットワークのネットワークトポロジを示しています。

図 3-7 相互接続された 3 つのネットワーク

ルータ R1 は、ネットワーク 192.9.200 とネットワーク 192.9.201 と接続しています。ルータ R2 は、ネットワーク 192.9.201 とネットワーク 192.9.202 を接続しています。ネットワーク 192.9.200 のホスト A がネットワーク 192.9.202 のホスト B にメッセージを送るとすると、その操作は次の手順で行われます。

1. ホスト A は、ネットワーク 192.9.200 にパケットを送り出します。パケットヘッダには、受信側ホスト B の IP アドレスである 192.9.202.10 が含まれています。

2. ネットワーク 192.9.200 には、192.9.202.10 の IP アドレスを持つマシンはありません。したがって、ルータ R1 がパケットを受け取ります。

3. ルータ R1 は自己のルーティングテーブルを調べます。ネットワーク 192.9.201 には、アドレスが 192.9.202.10 であるマシンはありません。ただし、ルーティングテーブルにはルータ R2 がリストされています。

4. R1 は「次の中継」ルータとして R2 を選択し、パケットを R2 に送ります。

5. R2 はネットワーク 192.9.201 を 192.9.202 に接続しているので、ホスト B に関するルーティング情報を保持しています。そこで、ルータ R2 はパケットをネットワーク 192.9.202 に転送し、ホスト B がそのパケットを受け取ります。

第 4 章 ネットワーク上での TCP/IP の構成

ネットワーク管理の第 2 のフェーズでは、ネットワークを設定します。ここで行う作業は、ネットワークの物理部分を形成するハードウェアの組み立てと、TCP/IP の構成です。この章では、TCP/IP の構成方法を次の事項に分けて説明します。

• ネットワーク上の各マシンについてのホスト構成モードの決定

• ネットワークのサブネットマスクの設定 (オプション)

• ローカルファイルモードで実行されるマシン上での TCP/IP の構成

• ネットワーク構成サーバの構成

• ネットワーククライアントモードで実行されるマシン上での TCP/IP の構成

• ネットワーク用に選択したネームサービスに基づくネットワークデータベースの編集

• ネームサービススイッチファイルの構成

• 「TCP/IP の構成の前に」

• 「ホスト構成モードの決定」

• 「TCP/IP 構成ファイル」

• 「hosts データベース」

• 「ネットワークマスクの作成」

• 「ネットワークデータベースへのネームサービスの影響」

• 「nsswitch.conf ファイル - 使用するネームサービスの指定」

• 「ネットワーク構成手順」

• 「標準 TCP/IP サービスの構成」

TCP/IP の構成の前に

TCP/IP ソフトウェアを構成する前に、以下のことをしておく必要があります。

1. ネットワーク設計者の場合は、ネットワークトポロジを設計します。(詳細は、「ネットワークトポロジ」を参照してください)。

2. インターネットのアドレス指定機関からネットワーク番号を入手します。( 「ネットワーククラス」を参照してください)。

3. 設計したトポロジに従ってネットワークハードウェアを組み立て、ハードウェアが働くことを確認します。(ハードウェアのマニュアルと、 「ネットワークトポロジ」を参照してください)。

4. ネットワークインタフェースとルータが必要とする構成ソフトウェアがあれば、それを実行します。(ルータについては、 第 3 章「ネットワークの計画」と第 5 章「ルータの構成」を参照。購入したネットワークインタフェースをマシンにインストールしてある場合は、ソフトウェア構成要件についてそのインタフェースのマニュアルを参照してください)。

5. ネットワークに対する IP アドレス指定方針の計画を立てます。これには、必要に応じてサブネットアドレス指定も含まれます。(「IP アドレス指定方針の設計」を参照してください)。

6. ネットワークに含まれるすべてのマシンに、IP 番号とホスト名を割り当てます。(「IP アドレス指定方針の設計」を参照してください)。

7. ネットワークでどのネームサービス、つまり NIS、NIS+、DNS、またはローカルファイルのどれを使用するかを決定します。(『Solaris ネーミングの管理』を参照してください)。

8. 必要なら、ネットワークで使用するドメイン名を選択します。(『Solaris ネーミングの管理』を参照してください)。

9. 予定しているネットワーク上の少なくとも 1 台のマシンにオペレーティングシステムをインストールします。 『Solaris のインストール (上級編)』を参照してください。

ホスト構成モードの決定

ネットワーク管理者が行う主要な作業の 1 つに、ホストとルータ (必要な場合) で実行できるように TCP/IP を構成する作業があります。これらのマシンは、2 つの情報源から構成情報を入手するように設定できます。それは、ローカルマシン上のファイルと、ネットワーク内の他のマシンにあるファイルです。構成情報には次のものがあります。

• マシンのホスト名

• マシンの IP アドレス

• マシンが所属するドメイン名

• デフォルトルータ

• マシンのネットワークで使用しているネットマスク

TCP/IP 構成情報をローカルファイルから入手するマシンの状態を、ローカルファイルモードで稼動していると言います。TCP/IP 構成情報をリモートマシンから入手するマシンの状態を、ネットワーククライアントモードで稼動していると言います。

ローカルファイルモードで実行するマシン

ローカルファイルモードで実行するマシンは、TCP/IP 構成ファイルのローカルコピーを備えていることが必要です。これらのファイルについては、「TCP/IP 構成ファイル」で説明します。このマシンが専用のディスクを備えていることが望ましいのですが、不可欠というわけではありません。

ほとんどのサーバはローカルファイルモードで実行します。主な必要条件は次のとおりです。

• ネットワーク構成サーバ

• NFS サーバ

• NIS、NIS+、または DNS サービスを提供するネームサーバ

• メールサーバ

また、ルータはローカルファイルモードで実行する必要があります。

印刷サービス専用として働くマシンは、ローカルファイルモードで実行する必要はありません。個々のホストをローカルファイルモードで実行する方がよいかどうかは、ネットワークの規模によって異なります。

ネットワークがきわめて小さい場合は、個々のホストのファイルを維持する作業は比較的簡単です。しかし、数百のホストから成るネットワークの場合は、そのネットワークがいくつかの管理サブドメインに分割されていたとしても、この作業は困難なものとなります。したがって、規模の大きいネットワークの場合は、ローカルファイルモードを使用しても一般に効率は上がりません。ただし、ルータとサーバは自給自足の性格を持つものであり、したがってローカルファイルモードで構成する方が効率的です。

ネットワーク構成サーバ

ネットワーク構成サーバは、ネットワーククライアントモードで構成されているホストに、TCP/IP 構成情報を提供するマシンです。この種のサーバは、次の 3 つのブートプロトコルをサポートしています。

• RARP - 逆アドレス解決プロトコル (RARP) は、既知のイーサネットアドレス (48 ビット) を IP アドレス (32 ビット) にマッピングします。つまり、ARP と逆のことを行います。ネットワーク構成サーバで RARP を実行すると、ネットワーククライアントモードで実行されているホストが、各自の IP アドレスと TCP/IP 構成ファイルをサーバから入手できるようになります。RARP サービスは、in.rarpd デーモンを使って使用可能にできます。詳細は、 in.rarpd(1M) のマニュアルページを参照してください。

• TFTP - 簡易ファイル転送プロトコル (TFTP) は、リモートマシン間でファイルを転送するアプリケーションです。in.tftpd デーモンが TFTP サービスを実施し、その結果、ネットワーク構成サーバとそれぞれのネットワーククライアントとの間のファイル転送が可能になります。

• bootparams - bootparams プロトコルは、ディスクレスクライアントが必要とするブート用パラメータを提供します。このサービスを実施するのは rpc.bootparamd デーモンです。

ネットワーク構成サーバは、NFS ファイルサーバとしても使用できます。

ホストのどれかをネットワーククライアントとして構成する場合は、ネットワーク内のマシンの少なくとも 1 つをネットワーク構成サーバとして構成する必要があります。ネットワークをサブネット化する場合は、ネットワーククライアントを持つ各サブネットについて、ネットワーク構成サーバが少なくとも 1 つは必要です。

ネットワーククライアントであるマシン

ネットワーク構成サーバから自己の構成情報を入手するホストの状態を、ネットワーククライアントモードで「稼動中」であると言います。ネットワーククライアントとして構成したマシンでは、TCP/IP 構成ファイルのローカルコピーは不要です。

ネットワーククライアントモードを使用すると、大規模ネットワークの管理が大幅に簡素化されます。個々のホストで行う構成作業が最小限の量で済み、ネットワーク上のすべてのマシンが確実に同じ構成標準に従ったものとなります。

完全なスタンドアロンシステムからディスクレスマシンやデータレスマシンに至るまで、すべての種類のコンピュータについて、ネットワーククライアントマシンを構成できます。ルータとサーバもネットワーククライアントモードで構成できますが、これらのマシンではローカルファイルモードの方がよい選択です。ルータとサーバは、できる限り自給自足型にしておかねばなりません。

ディスクレスブート

システムをディスクレスブートに設定する方法は、 『Solaris のシステム管理』 で説明してあります。

混合構成

システムは高い柔軟性を備えているため、すべてをローカルホストモードに構成したり、すべてをネットワーククライアントモードに構成するような、どちらか一方に限定する必要はありません。そのよい例がルータとサーバで、これらは常にローカルモードで構成するのが最適です。ホストについては、必要に応じてローカルモードとネットワーククライアントモードを任意に組み合わせて使用できます。

サンプルネットワーク

図 4-1 は、ネットワーク番号が 192.9.200 である架空のネットワークのホストを示しています。このネットワークにはネットワーク構成サーバが 1 つあり、それは sahara というマシンです。このマシンは、ディスクレスクライアント ahaggar にサービスを提供します。tenere と nubian の 2 つのマシンはそれぞれ独自にディスクを備えており、ローカルファイルモードで働きます。マシン faiyum もディスクを持っていますが、これはネットワーククライアントモードで働きます。

最後に、マシン timbuktu はルータとして構成されています。このマシンには 2 つのネットワークインタフェースが組み込まれており、それぞれの名前は、ネットワーク 192.9.200 用が timbuktu で、ネットワーク 192.9.201 用が timbuktu-201 です。どちらのネットワークも、組織ドメイン deserts.worldwide.com に含まれています。このドメインは、ローカルファイルをネームサービスとして使用します。

この章の中のほとんどの例では、図 4-1 に示すネットワークをベースとして使用しています。

図 4-1 サンプルネットワーク内のホスト

TCP/IP 構成ファイル

ネットワーク上の各マシンは、以下に示す TCP/IP 構成ファイルとネットワークデータベースから自己の TCP/IP 構成情報を入手します。

• /etc/hostname.interface ファイル

• /etc/nodename ファイル

• /etc/defaultdomain ファイル

• /etc/defaultrouter ファイル (オプション)

• hosts データベース

• netmasks データベース (オプション)

Solaris インストールプログラムは、インストール工程の一環として上記のファイルを作成します。これらのファイルは、「TCP/IP 構成ファイル」の説明に従って手操作で編集することもできます。hosts と netmasks データベースは、Solaris ネットワークで使用できるネームサービスが読み取るネットワークデータベースのうちの 2 つです。ネットワークデータベースの概念については、「ネットワークデータベースと nsswitch.conf ファイル」で詳しく説明します。

/etc/hostname.interface ファイル

このファイルは、ローカルホスト上のネットワークインタフェースを定義します。ローカルマシンには、/etc/hostname.interface ファイルが少なくとも 1 つ必要です。このファイルは、Solaris インストールプログラムが作成します。ファイル名の中の interface のところには、一次ネットワークインタフェースのデバイス名が入ります。

このファイルにはエントリが 1 つだけ入っています。それは、ネットワークインタフェースに結び付いているホスト名か IP アドレスのどちらかです。たとえば、ahaggar というマシンの一次ネットワークインタフェースが smc0 であるとすると、/etc/hostname.interface ファイルの名前は /etc/hostname.smc0 となります。そして、このファイルには ahaggar というエントリが入っています。

複数のネットワークインタフェースがある場合

マシンが複数のネットワークインタフェースを備えている場合は、2 番目以降のネットワークインタフェース用の /etc/hostname.interface ファイルを、ネットワーク管理者が追加作成する必要があります。これらのファイルはテキストエディタを使って作成します。Solaris インストールプログラムは、追加のファイルは作成しません。

たとえば、図 4-1 に示したマシン timbuktu について考えてみましょう。このマシンは 2 つのネットワークインタフェースを備えていて、ルータとして働きます。一次ネットワークインタフェース le0 は、ネットワーク 192.9.200 に接続されています。その IP アドレスは 192.9.200.70 で、ホスト名は timbuktu です。Solaris 一次ネットワークインタフェース用として、/etc/hostname.le0 というファイルを作成し、そのファイルにホスト名 timbuktu を入れます。

第 2 のネットワークインタフェースは le1 で、これはネットワーク 192.9.201 に接続されています。このインタフェースは物理的にはマシン timbuktu にインストールされていますが、別の IP アドレスを持つ必要があります。したがって、ネットワーク管理者が、このインタフェース用に /etc/hostname.le1 ファイルを作成する必要があります。このファイルに入れるエントリは、ルータ名の timbuktu-201 です。

/etc/nodename ファイル

このファイルにはエントリが 1 つ入っています。それは、ローカルマシンのホスト名です。たとえば、マシン timbuktu では、/etc/nodename ファイルには timbuktu というエントリが入ります。

/etc/defaultdomain ファイル

このファイルにはエントリが 1 つ入っています。それは、ローカルホストのネットワークが属している管理ドメインの完全指定のドメイン名です。ネットワーク管理者は、この名前を Solaris インストールプログラムに指示すること、また後日このファイルを編集することができます。

図 4-1 では、ネットワークはドメイン deserts.worldwide に属しており、このドメインは .com ドメインとして分類されています。したがって、/etc/defaultdomain には、deserts.worldwide.com というエントリが入ります。ネットワークドメインについての詳細は、『Solaris ネーミングの管理』を参照してください。

/etc/defaultrouter ファイル

このファイルには、直接ネットワークに接続されている各ルータについてのエントリが入っています。このエントリは、ネットワーク間のルータとして働くネットワークインタフェースの名前です。

図 4-1 で、ネットワークインタフェース le1 は、マシン timbuktu をネットワーク 192.9.201 に接続しています。このインタフェースには、timbuktu-201 という一意な名前が付いています。したがって、ネットワーク 192.9.201 にあってローカルファイルモードで構成されているマシンについては、timbuktu-201 という名前が /etc/defaultrouter にエントリとして入れられます。

hosts データベース

hosts データベースには、ネットワーク上のマシンの IP アドレスとホスト名が入っています。NIS、NIS+、DNS のどれかのネームサービスを使用している場合は、hosts データベースは、ホスト情報用として指定されているデータベースに維持されます。たとえば、NIS+ を実行するネットワークでは、hosts データベースはホストテーブルに維持されます。

ネームサービスとしてローカルファイルを使用している場合は、hosts データベースは /etc/inet/hosts ファイルに維持されます。このファイルには、一次ネットワークインタフェースのホスト名と IP アドレス、マシンに備わっている他のネットワークインタフェース、そして、このマシンが知っている必要がある他のネットワークアドレスが入っています。

BSD ベースのオペレーティングシステムとの互換性を確保するために、/etc/hosts ファイルは /etc/inet/hosts へのシンボリックリンクになっています。

/etc/inet/hosts ファイルの形式

/etc/inet/hosts ファイルには、次のような基本構文を使用します (構文の詳しい説明については、hosts(4) のマニュアルページを参照してください)。

IP-address hostname [nicknames] [#comment]

IP-address には、ローカルホストが認識する必要のある各インタフェースの IP アドレスが入ります。

hostname には、設定時にマシンに割り当てたホスト名と、ローカルホストが認識しなければならない増設ネットワークインタフェースに割り当てたホスト名が入ります。

[nickname] は、ホストのニックネームが入るオプションのフィールドです。

[# comment] は、コメントを入れることができるオプションのフィールドです。

初期 /etc/inet/hosts ファイル

Solaris インストールプログラムを実行すると、プログラムは初期 /etc/inet/hosts ファイルを作成します。このファイルには、ローカルホストにとって必要最小限のエントリが入っています。それは、ループバックアドレス、IP アドレス、ホスト名です。

たとえば、図 4-1 に示したマシン ahaggar については、Solaris インストールプログラムは次のような /etc/inet/hosts ファイルを作成します。

例 4-1 マシン ahaggar 用の/etc/inet/hosts ファイル

127.0.0.1     localhost         loghost    #loopback address
192.9.200.3   ahaggar                      #host name

ループバックアドレス

例 4-1 では、IP アドレス 127.0.0.1 はループバックアドレスです。ループバックアドレスはローカルマシンが使用する予約済みネットワークインタフェースで、これによりプロセス間通信が可能になり、ローカルマシンは自分自身にパケットを送ることができます。「ifconfig コマンド」で説明するように、ループバックアドレスは、構成とテストのために ifconfig コマンドにより使用されます。TCP/IP ネットワーク上のすべてのマシンは、IP アドレス 127.0.0.1 を、ローカルホスト用に用いなければなりません。

ホスト名

IP アドレス 192.9.200.3 と名前 ahaggar は、ローカルマシンのアドレスとホスト名です。これらは、マシンの一次ネットワークインタフェースに割り当てられます。

複数のネットワークインタフェース

マシンには複数のネットワークインタフェースを持つものがあり、これらはルータまたはマルチホームホストとなります。マシンに接続される増設ネットワークインタフェースごとに、専用の IP アドレスとそれに割り当てる名前が必要です。ルータまたはマルチホームホストを構成するときは、この情報を手作業でルータの /etc/inet/hosts ファイルに追加する必要があります。(ルータとマルチホームホストの設定についての詳細は、第 5 章「ルータの構成」を参照してください)。

例 4-2 は、図 4-1 に示したマシン timbuktu 用の /etc/inet/hosts ファイルです。

例 4-2 マシン timbuktu 用の /etc/inet/hosts ファイル

 127.0.0.1          localhost      loghost
 192.9.200.70       timbuktu       #This is the local host name
 192.9.201.10       timbuktu-201   #Interface to network 192.9.201

timbuktu は、この 2 つのインタフェースを使ってネットワーク 192.9.200 と 192.9.201 を、ルータとして接続します。

ネームサービスの hosts データベースに対する影響

NIS、NIS+、DNS の各ネームサービスは、ホスト名とアドレスを 1 つまたは複数のサーバに維持します。これらのサーバは、各サーバのネットワーク上のすべてのホストとルータ (もしあれば) に関する情報を含む hosts データベースを保持しています。これらのサービスについては、『Solaris ネーミングの管理』を参照してください。

ローカルファイルがネームサービスを提供する場合

ローカルファイルをネームサービスとして使用するネットワークでは、ローカルファイルモードで実行されているマシンは、各自の /etc/inet/hosts ファイルを調べて、ネットワーク上の他のマシンの IP アドレスとホスト名を入手します。したがって、/etc/inet/hosts ファイルには以下の事項が含まれていることが必要です。

• ループバックアドレス

• ローカルマシン (一次ネットワークインタフェース) の IP アドレスとホスト名

• このマシンに接続している増設ネットワークインタフェース (もしあれば) の IP アドレスとホスト名

• ローカルネットワーク上のすべてのホストの IP アドレスとホスト名

• このマシンが認識する必要のあるルータ (もしあれば) の IP アドレスとホスト名

• このマシンでホスト名を使って参照したいマシンの IP アドレス

例 4-3 に、ローカルファイルモードで実行されるマシンである tenere の /etc/inet/hosts ファイルを示しています。このファイルには、192.9.200 ネットワーク上のすべてのマシンの IP アドレスとホスト名が含まれているという点に注意してください。また、192.9.200 ネットワークを 192.9.201 ネットワークに接続するためのネットワークインタフェースの IP アドレスと、インタフェース名 timbuktu-201 も含まれています。

ネットワーククライアントとして構成されているマシンは、ローカル /etc/inet/hosts ファイルから、自己のループバックアドレスと IP アドレスを入手します。

例 4-3 ローカルファイルモードで実行されるマシン用の /etc/inet/hosts ファイル

netmasks データベース

ネットワーク構成の一環として netmasks データベースを編集する必要があるのは、ネットワークをサブネット化してある場合だけです。netmasks データベースは、各ネットワークとそれに対応するサブネットマスクのリストからなっています。

サブネットを作成するときは、新規の各ネットワークはそれぞれ独立した物理ネットワークであることが必要です。単一の物理ネットワークにサブネット化を適用することはできません。

サブネット化とは

サブネット化は、限られた 32 ビット IP アドレス指定空間を最大限に活用し、大規模ネットワークでのルーティングテーブルの大きさを減らすための方法の 1 つです。どのようなアドレスクラスの場合も、サブネット化によってホストアドレス空間の一部をネットワークアドレスに割り当て、ネットワーク数を増やすことができます。新規のネットワークアドレスに割り当てられるホストアドレス空間の部分を、サブネット番号と言います。

IP アドレス空間を有効活用できることのほかに、サブネット化には管理上の利点もいくつかあります。ネットワークの数が増えるに伴って、ルーティングはきわめて複雑になってきます。たとえば、小規模の組織なら、個々のローカルネットワークにクラス C の番号を割り当てることができます。しかし、組織が成長するにつれて、多数の異なるネットワーク番号を管理することは、非常に複雑な作業になってきます。このような場合の改善策の 1 つとして、組織内の主要部門に対してそれぞれクラス B のネットワーク番号を割り当てる方法が考えられます。たとえば、エンジニアリング部門に対して 1 つ、オペレーション部門に対して 1 つというように番号を割り当てます。その上で、サブネット化によって得られたネットワーク番号を使って、個々のクラス B ネットワークをさらに多くのネットワークに分割できます。これによって、ルータ間でやりとりしなければならないルーティング情報の量も減少します。

ネットワークマスクの作成

サブネット化工程の一環として、ネットワーク全体のネットマスクを選択することが必要になります。ネットマスクは、ホストアドレス空間の中で、どの位置の何個のビットがサブネット番号を表し、どの位置の何個のビットがホスト番号を表すかを決定します。完全な IP アドレスは 32 ビットで構成されることを思い出してください。ホストアドレス空間を表すために使用できるビット数は、アドレスクラスによって異なりますが、最大 24 ビット、最小 8 ビットです。ネットマスクは netmasks データベース内に指定します。

サブネットの使用を予定している場合は、TCP/IP を構成する前にネットマスクを決定する必要があります。その後で、「ネットワークにサブネットを追加する方法」に示す手順を実施します。ネットワーク構成の一環としてオペレーティングシステムをインストールすることを予定している場合は、Solaris インストールプログラムは、ネットワークのネットマスクを指定するよう求めます。

「IP アドレス番号のパーツ」で説明したように、32 ビットの IP アドレスは、ネットワーク部とホスト部からなっています。32 ビットは 4 個のバイトに分かれます。各バイトは、ネットワーククラスに応じて、ネットワーク番号かホスト番号のどちらかに割り当てられます。

たとえば、クラス B の IP アドレスでは、左側の 2 バイトがネットワーク番号に割り当てられ、右側の 2 バイトがホスト番号に割り当てられます。クラス B の IP アドレス 129.144.41.10 の場合、右側の 2 バイトをホストに割り当てることができます。

サブネット化を行う場合は、ホスト番号に割り当てるバイトの中の一部のビットを、サブネットアドレスとして使用する必要があります。たとえば、ホストアドレス空間が 16 ビットであれば、65,534 個のホストのアドレス指定が可能です。3 番目のバイトをサブネットアドレス用に使用して、4 番目のバイトをホストアドレス用に使用するとすれば、最大 254 のネットワークのアドレスと、それぞれについて最大 254 ずつのホストのアドレスを指定できます。

ホストアドレスのバイトのどのビットがサブネットアドレスに使用され、どのビットがホストアドレスに使用されるかは、サブネットマスクによって決まります。サブネットマスクは、バイトの中のどのビットをサブネットアドレス用とするかを選択するために使用します。ネットマスクのビットは連続していなければなりませんが、バイトの境界に整列している必要はありません。

ネットマスクは、ビット単位の論理積演算子を使って IP アドレスに適用できます。この演算によって、アドレスのネットワーク番号とサブネット番号の位置が選択されます。

ネットマスクを説明するには、2 進数表現の視点から見るのが最も簡単です。2 進数と 10 進数は計算機を使って換算できます。以下の例では、ネットマスクの 10 進数形式と 2 進数形式の両方を示してあります。

ネットマスク 255.255.255.0 を IP アドレス 129.144.41.101 に適用した場合、結果の IP アドレスは 129.144.41.0 になります。

129.144.41.101 & 255.255.255.0 = 129.144.41.0

2 進数形式では、この演算は次のようになります。

11111111.11111111.11111111.00000000 (ネットマスク)

AND

10000001.10010000.00101001.01100101 (IP アドレス)

これで、システムは、ネットワーク番号 129.144 の代わりにネットワーク番号 129.144.41 を捜すようになります。129.144.41 の番号を持つネットワークがあれば、システムはそれを見つけ出します。IP アドレス空間の 3 番目のバイトには最大 254 個の値を割り当てることができるので、サブネット化によって、254 個のネットワーク用のアドレス空間を作ることができます。サブネット化を使用しなければ、ネットワークは 1 つだけです。

ネットワークを 2 つだけ追加するためのアドレス空間を確保したいとすれば、次のようなサブネットマスクを使用します。

255.255.192.0

このネットマスクの結果は次のようになります。

11111111.11111111.1100000.00000000

ホストアドレス用に使用できるビットが、まだ 14 ビット残っています。全桁 0 と全桁 1 は予約済みなので、少なくとも 2 ビットをホスト番号用として確保する必要があります。

/etc/inet/netmasks ファイルの編集

ネットワークで NIS または NIS+ を実行する場合は、これらのネームサービスを提供するサーバは netmasks データベースを保持しています。ローカルファイルをネームサービスとして使用するネットワークの場合は、この情報は /etc/inet/netmasks ファイル内に維持されます。

BSD ベースのオペレーティングシステムとの互換性を確保するために、/etc/netmasks ファイルが /etc/inet/netmasks へのシンボリックリンクとなっています。

例 4-4 に示すのは、クラス B ネットワークの場合のサンプルの /etc/inet/netmasks ファイルです。

例 4-4 クラス B ネットワークの場合の /etc/inet/netmasks ファイル

 ## The netmasks file associates Internet Protocol (IP) address
 # masks with IP network numbers.
 #
 # 	network-number	netmask
 #
 # Both the network-number and the netmasks are specified in
 # "decimal dot" notation, e.g:
 #
 #        128.32.0.0   255.255.255.0
          129.144.0.0  255.255.255.0

このファイルが存在しない場合は、次の構文を使って作成してください。

network-number	netmask-number

詳細は、netmasks(4) のマニュアルページを参照してください。

ネットマスク番号を作成するときは、InterNIC から割り当てられたネットワーク番号 (サブネット番号ではない) とネットマスク番号を、/etc/inet/netmasks ファイルに入力します。各サブネットマスクはそれぞれ単独の行に入れてください。

例:

128.78.0.0	    255.255.248.0

/etc/inet/hosts ファイルに、ネットワーク番号の記号名を入力することもできます。そうすれば、ネットワーク番号の代わりにこれらのネットワーク名を、コマンドへのパラメータとして使用できます。

ネットワークにサブネットを追加する方法

サブネットを使用していないネットワークをサブネット化するには、次の手順を使用します。

1. 新しいサブネットトポロジについて決定します。これには、ルータに関する考慮事項や、サブネット上でのホストの位置などが含まれます。

2. すべてのサブネットアドレスとホストアドレスを割り当てます。

3. 手作業で TCP/IP を構成している場合は、/etc/inet/netmasks ファイルを修正します。そうでない場合は、Solaris インストールプログラムにネットマスクを与えます。

4. すべてのホストで、新しいホストアドレスを反映するように /etc/inet/hosts ファイルを修正します。

5. すべてのマシンをリブートします。

ネットワークデータベースと nsswitch.conf ファイル

ネットワークデータベースは、ネットワークを構成するために必要な情報を提供するファイルです。ネットワークデータベースには次のものがあります。

• hosts

• netmasks

• ethers

• bootparams

• protocols

• services

• networks

構成工程の一環として、ネットワークをサブネット化する場合は、hosts データベースと netmasks データベースを編集します。マシンをネットワーククライアントとして構成するには、bootparams と ethers の 2 つのネットワークデータベースを使用します。残りのデータベースはオペレーティングシステムが使用するもので、編集が必要になることはほとんどありません。

ネットワークデータベースではありませんが、nsswitch.conf ファイルも、関連のネットワークデータベースとともに構成する必要があります。nsswitch.conf は、特定のマシンに、NIS、NIS+、DNS、ローカルファイルのどのネームサービスを使用するかを指定します。

ネットワークデータベースへのネームサービスの影響

ネットワークデータベースがとる形式は、ネットワーク用として選択するネームサービスの種類によって異なります。たとえば、hosts データベースには、少なくとも、ローカルマシンとそのマシンに直接接続されているネットワークインタフェースのホスト名と IP アドレスだけは入っています。しかし、ネットワークで使用するネームサービスの種類によっては、その他の IP アドレスとホスト名も hosts データベースに入ることがあります。

ネットワークデータベースは次のように使用されます。

• ローカルファイルをネームサービスとして使用するネットワークは、/etc/inet ディレクトリと /etc ディレクトリの中のファイルを使用する

• NIS+ は NIS+ テーブルと呼ばれるデータベースを使用する

• NIS は NIS マップと呼ばれるデータベースを使用する

• DNS はホスト情報が入ったレコードを使用する

DNS のブートファイルとデータファイルは、直接的にはネットワークデータベースに対応していません。

図 4-2 に、これらのネームサービスにより使用される hosts データベースの形式を示します。

図 4-2 ネームサービスが使用する hosts データベースの形式

表 4-1に、ネットワークデータベースをリストし、ローカルファイル、NIS+、NIS により各データベースがどのように使用されるかを示します。

このマニュアルでは、ローカルファイルをネームサービスとして使用するネットワークで使用されるものとして、ネットワークデータベースの説明を進めます。hosts データベースに関する情報は、「hosts データベース」に収めてあり、netmasks データベースに関する情報は、「netmasks データベース」に収めてあります。NIS、DNS、NIS+ でのネットワークデータベースの対応付けについては、『Solaris ネーミングの管理』を参照してください。

nsswitch.conf ファイル - 使用するネームサービスの指定

/etc/nsswitch.conf ファイルは、ネットワークデータベースの検索順序を定義します。Solaris インストールプログラムは、インストール工程でネットワーク管理者が指定するネームサービスに基づいて、ローカルマシン用のデフォルトの /etc/nsswitch.conf ファイルを作成します。"None" オプションを指定して、ローカルファイルをネームサービスとして使用することを指示した場合は、結果の nsswitch.conf ファイルは、例 4-5 のようになります。

例 4-5 ローカルファイルをネームサービスとして使用するネットワーク用の nsswitch.conf ファイル

# /etc/nsswitch.files:
#
# An example file that could be copied over to /etc/nsswitch.conf;
# it does not use any naming service.
#
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file contains "switch.so" as a
# nametoaddr library for "inet" transports.

passwd:          files
group:           files
hosts:           files
networks:        files
protocols:       files
rpc:             files
ethers:          files
netmasks:        files	
bootparams:      files
publickey:       files
# At present there isn't a 'files' backend for netgroup; the
# system will figure it out pretty quickly,
# and won't use netgroups at all.
netgroup:        files
automount:       files
aliases:         files
services:        files
sendmailvars:    files

このファイルについては、nsswitch.conf(4) のマニュアルページに詳しい説明があります。基本構文は次のとおりです。

database name-service-to-search

database フィールドには、オペレーティングシステムが検索するさまざまの種類のデータベースを指定できます。たとえば、passwd や aliases などのようにユーザに影響を与えるデータベースでも、またネットワークデータベースでも指定できます。ネットワークデータベースの場合の name-service-to-search パラメータの値は、files、nis、nis+ のどれかです (hosts データベースの場合は、検索するネームサービスとして dns の値もとることができます)。nis+ と files のように、複数のネームサービスを指定することもできます。

例 4-5 にサーチオプションとして示されているのは、files だけです。したがって、ローカルマシンは、/etc ディレクトリと /etc/inet ディレクトリに入っているファイルから、ネットワークデータベース情報のほか、セキュリティと自動マウントに関する情報を入手します。

nsswitch.conf の変更

/etc ディレクトリには、Solaris インストールプログラムが作成した nsswitch.conf ファイルが入っています。そのほかに、次のネームサービス用のテンプレートファイルも入っています。

• nsswitch.files

• nsswitch.nis

• nsswitch.nis+

あるネームサービスから別のネームサービスに変更したい場合は、対応するテンプレートを nsswitch.conf にコピーすることができます。また、nsswitch.conf ファイルを選択的に編集して、個々のデータベースを見つけるために検索するデフォルトのネームサービスを変更することができます。

たとえば、NIS を実行するネットワークでは、ディスクレスクライアントについての nsswitch.conf ファイルの変更が必要な場合があります。bootparams データベースと ethers データベースの検索順序では、最初のオプションとして files、そして次に nis が指定されていることが必要です。例 4-6 に、正しい検索順序を示します。

例 4-6 NIS を実行するネットワークでのディスクレスクライアント用の nsswitch.conf

## /etc/nsswitch.conf:#
.
.
passwd:        files nis
group:         file nis

# consult /etc "files" only if nis is down.
hosts:         nis    [NOTFOUND=return] files
networks:      nis    [NOTFOUND=return] files
protocols:     nis    [NOTFOUND=return] files
rpc:           nis    [NOTFOUND=return] files
ethers:        files  [NOTFOUND=return] nis
netmasks:      nis    [NOTFOUND=return] files	
bootparams:    files  [NOTFOUND=return] nis
publickey:     nis    netgroup:         nis

automount:     files nis
aliases:       files nis

# for efficient getservbyname() avoid nis
services:      files nis
sendmailvars:  files

ネームサービススイッチについての詳細は、『Solaris ネーミングの管理』 を参照してください。

bootparams データベース

bootparams データベースには、ネットワーククライアントモードでブートするように構成されているディスクレスのクライアントとマシンが使用する情報が入っています。ネットワーククライアントを持つネットワークの場合は、このデータベースの編集が必要になります。(手順については、「ネットワーククライアントの構成」を参照してください)。このデータベースは、/etc/bootparams ファイルに入力した情報をもとにして構築されます。

このデータベースの詳しい構文は、bootparams(4) のマニュアルページに収めてあります。基本構文は次のとおりです。

machine-name file-key-server-name:pathname

個々のディスクレスまたはネットワーククライアントマシンについて、エントリが 1 つずつあります。各エントリに入っている情報は、クライアントの名前、キーのリスト、サーバの名前、そしてパス名です。

各エントリの最初の項目は、クライアントマシンの名前です。その次は、キー、サーバ名、パス名をタブ文字で区切ったリストです。最初の項目以外は、すべてオプションです。このデータベースには、すべてのクライアントに一致するワイルドカードエントリを含めることができます。次に例を示します。

例 4-7 bootparams データベース

myclient   root=myserver : /nfsroot/myclient  ¥
swap=myserver : /nfsswap//myclient ¥
dump=myserver : /nfsdump/myclient

この例の dump=: は、ダンプファイルを捜さないようにディスクレスホストに指示します。

bootparams のワイルドカードエントリ

ディスクレスクライアントをサポートするように bootparams データベースを編集するときには、ほとんどの場合、ワイルドカードエントリを使用する方が便利です。ワイルドカードエントリは次のとおりです。

*  root=server:/path dump=:

アスタリスク (*) ワイルドカードは、このエントリが、bootparams データベース内で明示的に指定されていないすべてのクライアントに適用されることを示します。

ethers データベース

ethers データベースは、/etc/ethers ファイルに入力した情報をもとにして構築されます。このデータベースは、ホスト名をイーサネットアドレスに関連付けます。ethers ネットワークの作成が必要になるのは、RARP デーモンを実行する場合、つまり、ネットワーククライアントまたはディスクレスマシンを構成する場合だけです。

RARP は、このファイルを使って、イーサネットアドレスを IP アドレスにマップします。RARP デーモン in.rarpd を実行するときは、ethers ファイルを設定し、このデーモンを実行するすべてのホストにこのファイルを維持して、ネットワークに対する変更が反映されるようにする必要があります。

このデータベースの詳しい構文は、ethers(4) のマニュアルページに収めてあります。基本構文は次のとおりです。

Ethernet-address hostname #comment

Ethernet-address は、ホストのイーサネットアドレスです。

hostname は、ホストの公式名です。

#comment は、ファイル内のエントリに付加したい任意の注意書きです。

イーサネットアドレスは装置の製造元から提供されます。マシンの電源を入れたときにイーサネットアドレスが表示されない場合は、ハードウェアのマニュアルを調べてください。

ethers データベースにエントリを追加するときは、ホスト名が、ニックネームではなく、hosts データベース内の一次名に一致していることを確かめてください (例 4-8)。

例 4-8 ethers データベース内のエントリ

8:0:20:1:40:16  fayoum
8:0:20:1:40:15  nubian 
8:0:20:1:40:7   sahara    # This is a comment
8:0:20:1:40:14  tenere 

その他のネットワークデータベース

残りのネットワークデータベースについては、編集が必要になることはほとんどありません。

networks データベース

networks データベースは、ネットワーク名をネットワーク番号に関連付けて、一部のアプリケーションが番号の代わりに名前を使用し表示できるようにします。networks データベースは、/etc/inet/networks ファイルの中の情報をもとにして作られます。このデータベースには、このネットワークがルータを介して接続されるすべてのネットワークの名前が入っています。

初期 networks データベースは、Solaris インストールプログラムが設定します。このデータベースを更新する必要があるのは、既存のネットワークトポロジに新たなネットワークを追加した場合だけです。

/etc/inet/networks の詳しい構文は、networks(4) マニュアルページに収めてあります。基本構文は次のとおりです。

network-name network-number nickname(s) # comment

network-name は、ネットワークの公式名です。

network-number は、InterNIC から割り当てられた番号です。

nickname は、ネットワークの認識のために使用されるその他の名前です。

#comment は、ファイル内のエントリに付加したい任意の注意書きです。

networks ファイルを維持することは大変重要です。netstat プログラムは、このデータベース内の情報を使って状態テーブルを作成します。

例 4-9 に /etc/networks ファイルのサンプルを示します。

例 4-9 /etc/networks ファイル

#ident	"@(#)networks	1.4	92/07/14 SMI"	/* SVr4.0 1.1	*/
#
# The networks file associates Internet Protocol (IP) network
numbers with network names. The format of this file is:
#
# 	network-name		 	 network-number		 	 nicnames . . .

# The loopback network is used only for intra-machine
communication
#loopback		 	 127

# Internet networks
#
arpanet     10	   arpa  # Historical
ucb-ether   46	   ucbether
#
# local networks

eng   193.9.0  #engineering
acc   193.9.1  #accounting
prog  193.9.2  #programming

protocols データベース

protocols データベースには、システムにインストールされている TCP/IP プロトコルとそれぞれの番号のリストが入っています。このデータベースは、Solaris インストールプログラムが自動的に作成します。このファイルについて管理作業が必要になることは、ほとんどありません。

protocols データベースには、システムにインストールされている TCP/IP プロトコルの名前が含まれています。詳しい構文は、protocols(4) マニュアルページに収めてあります。例 4-10 に、/etc/inet/protocols ファイルの例を示します。

例 4-10 /etc/inet/protocols ファイル

#
# Internet (IP) protocols
#
ip    0   IP    # internet protocol, pseudo protocol number
icmp  1   ICMP  # internet control message protocol
tcp   6   TCP   # transmission control protocol
udp  17   UDP   # user datagram protocol

services データベース

services データベースには、TCP サービスと UDP サービスの名前と、それぞれのよく知られているポート番号のリストが入っています。このデータベースは、ネットワークサービスを呼び出すプログラムにより使用されます。Solaris インストールプログラムは、services データベースを自動的に作成します。このデータベースについては、通常は管理作業が必要になることはありません。

詳しい構文は、services(4) のマニュアルページに収めてあります。 例 4-11 に、典型的な /etc/inet/services ファイルからの抜粋を示します。

例 4-11 /etc/inet/services ファイル

#
# Network services
#
echo      7/udp
echo      7/tcp
discard   9/udp     sink null
discard   11/tcp
daytime   13/udp
daytime   13/tcp
netstat   15/tcp
ftp-data  20/tcp
ftp       21/tcp
telnet    23/tcp
time      37/tcp    timeserver
time      37/udp    timeserver
name      42/udp    nameserver
whois     43/tcp    nickname

ネットワーク構成手順

オペレーティングシステムのソフトウェアをインストールするときに、同時にネットワークのソフトウェアもインストールされます。そのときに、いくつかの IP 構成パラメータを対応するファイルに格納して、ブート時に読み取れるようにしておく必要があります。

ここで必要な手順は、単にネットワーク構成ファイルを作成または編集するというだけのことです。構成情報がどのようにマシンのカーネルに対して使用可能にされるかは、構成ファイルがローカルに格納されているか (ローカルファイルモード)、それともネットワーク構成サーバから構成ファイルを入手するか (ネットワーククライアントモード) によって異なります。

ネットワーク構成時に指定するパラメータには、次のものがあります。

• すべてのマシンの各ネットワークインタフェースの IP アドレス

• ネットワーク上の各マシンのホスト名。ホスト名は、ローカルファイルまたはネームサービスデータベースに入力できる

• マシンが常駐している NIS、NIS+、または DNS ドメイン名 (該当する場合)

• デフォルトのルータアドレス。これを指定するのは、各ネットワークにルータが 1 つしか接続していないような単純なネットワークトポロジの場合か、または、ルータが、RDISC (Router Discovory Protocol) や RIP (Routing Information Protocol) などのルーティングプロトコルを実行しない場合だけである。(これらのプロトコルについての詳細は、第 5 章「ルータの構成」を参照してください)

• サブネットマスク (サブネットを持つネットワークの場合に限り必要)

この章には、ローカル構成ファイルの作成と編集に関する詳しい情報を収めてあります。ネームサービスデータベースの処理については、『Solaris ネーミングの管理』を参照してください。

ローカルファイルモードの場合のホストの構成方法

ローカルファイルモードで働くマシン上の TCP/IP を構成するための手順は、次のとおりです

1. スーパーユーザになり、/etc ディレクトリに移動します。

2. マシンのホスト名を /etc/nodename ファイルに入力します。

   たとえば、ホストの名前が tenere であるとすれば、このファイルに tenere と入力します。

3. 各ネットワークインタフェースについて、/etc/hostname.interface という名前のファイルを作成します

   (一次ネットワークインタフェースについては、Solaris インストールプログラムが自動的にこのファイルを作成します)。

   詳細は、「/etc/hostname.interface ファイル」を参照してください。

4. /etc/hostname.interface ファイルに、インタフェース IP アドレスかインタフェース名を入力します。

   たとえば、hostname.ie1 という名前のファイルを作成し、ホストのインタフェースの IP アドレスか、ホスト名を入力します。

5. /etc/inet/hosts ファイルを編集して、以下のものを追加します。

   1. ローカルマシンに増設したネットワークインタフェースに割り当てた IP アドレスと、各インタフェースのホスト名

      一次ネットワークインタフェースとループバックアドレスについてのエントリは、すでに Solaris インストールプログラムにより作成されています。

   2. /usr ファイルシステムを NFS マウントする場合は、ファイルサーバの IP アドレス

   ---

   注 -

   Solaris インストールプログラムは、ローカルマシン用のデフォルトの /etc/inet/host を作成します。このファイルが存在していない場合は、「hosts データベース」の説明に従って作成してください。

   ---

6. 完全指定のドメイン名を、/etc/defaultdomain ファイルに入力します。

   たとえば、ホスト tenere がドメイン deserts.worldwide.com に所属しているとします。その場合は、/etc/defaultdomain に deserts.worldwide.com を入力します。詳細は、 「/etc/defaultdomain ファイル」を参照してください。

7. ルータの名前を、/etc/defaultrouter に入力します。

   詳細は、「/etc/defaultrouter ファイル」を参照してください。

8. デフォルトのルータの名前とその IP アドレスを、 /etc/inet/hosts に入力します。

   上記以外にも、使用できるルーティングオプションがいくつかあります。 「ネットワーククライアントモードの場合のホストの構成方法」の中の、ルーティングオプションについての説明を参照してください。これらのオプションは、ローカルファイルモード構成にも適用できます。

9. ネットワークをサブネット化する場合は、ネットワーク番号とネットマスクを、/etc/inet/netmasks ファイルに入力します。

   NIS または NIS+ サーバを設定してある場合は、サーバとクライアントが同じネットワーク上にあれば、サーバ上の該当のデータベースにネットマスク情報を入力できます。

10. ネットワーク上の各マシンをリブートします。

ネットワーク構成サーバの設定

いくつかのホストをネットワーククライアントとして構成することを予定している場合は、ネットワーク上のマシンの少なくとも 1 つは、ネットワーク構成サーバとして構成する必要があります (方法については、 「ネットワーク構成サーバ」を参照してください)。

ネットワーク構成サーバの設定には、次のような操作が必要です。

1. ネットワーク構成デーモンが動作するようにします。

   • in.tftpd

   • in.rarpd

   • rpc.bootparamd

2. 構成サーバ上のネットワーク構成ファイルを編集し保守します。

   「ネットワーク構成サーバの設定方法」では、ネットワーク構成サーバをすでにローカルファイルモード用として設定してあるものとします。

ネットワーク構成サーバの設定方法

1. スーパーユーザになり、予定しているネットワーク構成サーバのルートディレクトリに移動します。

2. ディレクトリ /tftpboot を作成することにより、in.tftpd デーモンが動作するようにします。

   # mkdir /tftpboot

   これで、マシンは、TFTP、bootparams、RARP のサーバに構成されます。

3. 2. で作成したディレクトリに対するシンボリックリンクを作成します。

   # ln -s /tftpboot/. /tftpboot/tftpboot

4. inetd.conf ファイルにある tftp の行を有効にします。

   /etc/inetd.conf のエントリが次のようになっていることを確認してください。

   tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot

   これによって、/tftpboot に格納されたファイル以外のファイルを inettftpd() で検索できなくなります。

5. hosts データベースを編集して、ネットワーク上のすべてのクライアントのホスト名と IP アドレスを追加します。

6. ethers データベースを編集して、ネットワーククライアントモードで実行するネットワーク上のすべてのホストについてエントリを作成します。

7. bootparams データベースを編集します。

   「bootparams データベース」を参照してください。ワイルドカードエントリを作成するか、または、ネットワーククライアントモードで実行するすべてのホストについてエントリを作成します。

8. サーバをリブートします。

ディスクレスクライアント、インストールサーバ、ブートサーバを設定する方法については、『Solaris のインストール (上級編)』を参照してください。

ネットワーククライアントの構成

ネットワーククライアントは、各自の構成情報をネットワーク構成サーバから入手します。したがって、あるホストをネットワーククライアントとして構成するときは、このネットワーク用として、ネットワーク構成サーバが少なくとも 1 つは設定されていることを確認してください。

ネットワーククライアントモードの場合のホストの構成方法

ネットワーククライアントモードで構成する必要のある各ホストについて、次のことを行います。

1. スーパーユーザになります。

2. ディレクトリを調べて、/etc/nodename ファイルがあるかどうかを確認します。それがある場合は、削除してください。

   /etc/nodename を削除すると、システムは hostconfig プログラムを使用して、ネットワーク構成サーバから、ホスト名、ドメイン名、ルータアドレスを入手するようになります。「ネットワーク構成手順」を参照してください。

3. /etc/hostname.interface ファイルが存在していない場合は、それを作成します。

   そのファイルが空であることを確かめてください。/etc/hostname.interface ファイルが空であれば、システムは、ネットワーク構成サーバから IP アドレスを入手します。

4. /etc/inet/hosts ファイルに、ループバックネットワークインタフェースのホスト名と IP アドレス以外のものが入っていないことを確認します。

   (「ループバックアドレス」を参照してください)。このファイルには、ローカルマシン (一次ネットワークインタフェース) の IP アドレスとホスト名が入っていてはいけません。

   例外: ディスクレスクライアント (NFS マウントされたルートファイルシステムを持つマシン) の場合は、クライアントのルートファイルシステムを提供するサーバの名前と IP アドレスを入力します (通常はこれはネットワーク構成サーバですが、必ずそうだというわけではありません)。

5. /etc/defaultdomain ファイルがあるかどうかを調べます。ある場合は、それを削除します。

   hostconfig プログラムは、自動的にドメイン名を設定します。hostconfig プログラムが設定したドメイン名を上書きしたいときは、/etc/defaultdomain に代わりのドメイン名を入力します。

6. クライアントの /etc/nsswitch.conf の中の検索順序が、ネットワークのネームサービスの要件を満たしていることを確認します。

ネットワーククライアント用のルータの指定方法

1. ネットワーク上にルータが 1 つしかなく、ネットワーク構成サーバが自動的にそのルータの名前を指定するようにしたい場合は、ネットワーククライアントが /etc/defaultrouter ファイルを持っていないことを確認します。

2. 次の手順に従って、ネットワーク構成サーバが設定したデフォルトのルータの名前を上書きします。

   1. ネットワーククライアント上に /etc/defaultrouter を作成します。

   2. デフォルトのルータとして指定してあるマシンのホスト名と IP アドレスを入力します。

   3. 指定したデフォルトのルータのホスト名と IP アドレスを、ネットワーククライアントの /etc/inet/hosts に追加します。

3. ネットワークに複数のルータがある場合は、ネットワーククライアント上に /etc/defaultrouter を作成し、それを空のままにしておきます。

/etc/defaultrouter を作成し、それを空のままにしておくと、2 つの動的ルーティングプロトコル、つまり、ICMP RDISC (Router Discovory Protocol) か RIP (Routing Information Protocol) のどちらか一方が実行されます。システムは、まず in.rdisc プログラムを実行します。このプログラムは、ルータ検出プロトコルを実行しているルータを捜します。該当するルータが見つかった場合は、in.rdisc はそのまま実行を続け、RDISC プロトコルを実行するルータを追跡し続けます。

RDISC プロトコルに応答しているルータがないと判断した場合は、システムは RIP を使用し、in.routed デーモンを実行してルータを追跡します。

ネットワーククライアントのインストールの後で

各ネットワーククライアントマシン上のファイルを編集し終わったら、ネットワーク構成サーバで次の作業を行います。

1. ethers データベースと hosts データベースにそのホストのエントリを追加します。

2. bootparams データベースにそのホストのエントリを追加します。

   操作を簡単にするために、bootparams データベースには、各ホストのエントリを個別に入力する代わりに、ワイルドカードを入力することができます。その例については、「bootparams データベース」を参照してください。

3. サーバをリブートします。

標準 TCP/IP サービスの構成

telnet、ftp、rlogin などのサービスは、inetd デーモンによって開始されます。このデーモンは、ブート時に自動的に実行されます。ネームサービスの順序を nsswitch.conf の中で指定したように、TCP/IP のサービスは、/etc/inetd.conf ファイルの中で inetd -t フラグを使って構成できます。

たとえば、inetd を使用して、着信したすべての TCP 接続 (リモートログインと telnet) の IP アドレスをログに記録できます。ログ記録を行うには、実行中の inetd を終了し、次のように入力します。

# /usr/sbin/inetd -t -s

t スイッチは、inetd に TCP 接続トレースを開始させます。

inetd(1M) と inetd.conf(4) のマニュアルページを参照してください。

ネームサービスについての詳細は、『Solaris ネーミングの管理』と『Solaris ネーミングの設定と構成』を参照してください。

ブート行程の概要

以下の情報は参考用です。この情報はネットワークブート行程の概要を要約して示すもので、構成時にどのようなことが起こるかを全体的にとらえるのに役立ちます。

起動スクリプトの名前は、リリースが変わるときに変更されることがあります。

1. ホストでオペレーティングシステムを起動します。

2. カーネルは、ブート行程の一環として /sbin/init を実行します。

3. /sbin/init は、/etc/rcS.d/S30rootusr.sh 起動スクリプトを実行します。

4. /etc/rcS.d/S30rootusr.sh 起動スクリプトは、ディスクレスとデータレスの操作のための最小限のホスト構成とネットワーク構成の確立など、いくつかのシステム起動作業を行います。また、このスクリプトは、/usr ファイルシステムもマウントします。

   1. ローカルデータベースファイルに、必要な構成情報 (ホスト名と IP アドレス) が含まれている場合は、スクリプトはそれを使用します。

   2. ローカルホスト構成ファイル内に必要な情報がない場合は、/etc/rcS.d/S30rootusr.sh は、RARP を使用してホストの IP アドレスを入手します。

5. ドメイン名、ホスト名、デフォルトのルータアドレスがローカルファイルに含まれている場合は、マシンはそれらを使用します。ローカルファイルに構成情報が含まれていない場合は、システムは bootparams プロトコルを使用して、ホスト名、ドメイン名、デフォルトのルータアドレスを入手します。必要な情報が、ホストと同じネットワーク上にあるネットワーク構成サーバから入手可能でなければなりません。これは、この時点ではまだインターネットワーク通信が存在していないからです。

6. /etc/rcS.d/S30rootusr.sh が作業を完了し、その他のいくつかのブート手続きが実行されると、次に /etc/rc2.d/S69inet が実行されます。このスクリプトは、ネームサービス (NIS、NIS+、または DNS) の開始の前に完了しておく必要のある起動作業を実行します。これらの作業には、IP の構成、ドメイン名のルーティングと設定などがあります。

7. S69inet の作業が完了すると、/etc/rc2.d/S71rpc が実行されます。このスクリプトは、NIS、NIS+、DNS のどれかのネームサービスを起動します。

8. /etc/rc2.d/S71rpc の実行の後で、/etc/rc2.d/S72inetsvc が実行されます。このスクリプトは、ネームサービスの存在の有無に応じて異なるサービスを起動します。S72inetsvc は inetd デーモンも起動します。このデーモンは、telnet などのユーザサービスを管理します。

ブート行程についての詳細は、『Solaris のシステム管理』を参照してください。

第 5 章 ルータの構成

この章では、ルーティングプロトコルについて説明し、特に TCP/IP ネットワーク上でのルータの構成のための手順を示します。ルータとは、複数のネットワークインタフェースを持ち、1 つのネットワークから別のネットワークへとパケットを送信するマシンです。最も一般的なルータの種類としては、カードスロットに増設ネットワークインタフェースを持つコンピュータと、各種のメーカから販売されている専用ルータの 2 種類があります。

この章では、ルーティングの原理については説明しません。その説明は、「ネットワークトポロジ」に収めてあります。また、「ルータがどのようにパケットを転送するか」には、ルーティングに関する基本事項の説明があります。サブネットの作成方法については、「netmasks データベース」を参照してください。

• 「ルーティングプロトコル」

• 「マシンをルータとして構成する方法」

• 「マルチホームホストの作成」

ルーティングプロトコル

Solaris システムソフトウェアは 2 つのルーティングプロトコルをサポートしています。それは、RIP (Routing Information Protocol) と ICMP RDISC (Router Discovery Protocol) です。RIP と RDISC は、どちらも標準 TCP/IP プロトコルです。

ルーティング情報プロトコル (RIP)

RIP はルーティングデーモン in.routed により実現されるもので、このデーモンはマシンのブート時に自動的に起動されます。s オプションを指定した in.routed をルータで実行すると、in.routed は、到達可能なすべてのネットワークへの送信経路をカーネルルーティングテーブルに組み入れ、すべてのネットワークインタフェースを経由する「到達可能性」を通知します。

q オプションを指定した in.routed をホストで実行した場合は、in.routed はルーティング情報を抽出しますが、到達可能性は通知しません。ホストでは、ルーティング情報は次の 2 つの方法で抽出できます。

• S フラグ (大文字の S は「スペース節約モード」) を指定しない場合、in.routed は、ルータで実行したときと同様にフルルーティングテーブルを作成します。

• S フラグを指定すると、in.routed は、使用可能な各ルータについてデフォルトの送信経路を 1 つずつ示す最小核テーブルを作成します。

ICMP ルータ検索 (RDISC) プロトコル

ホストは、RDISC を使用してルータからルーティング情報を入手します。したがって、ホストが RDISC を実行しているときは、各ルータは、ルータ相互間でのルーティング情報の交換のために、RIP などのような別のプロトコルも実行していることが必要です。

RDISC は in.rdisc により実現されます。in.rdisc は、ルータとホストの両方で実行していることが必要です。通常は、in.rdisc をホストで実行すると、同じく in.rdisc を実行している各ルータについてのデフォルトの送信経路に入ります。in.rdisc を実行しているホストは、RIP だけを実行しているルータは検索しないので、注意してください。また、ルータが in.rdisc (in.routed ではなく) を実行しているときは、ルータごとに異なる優先項目を持つように構成すると、ホストができるだけ効率的なルータを選択できるようになります。rdisc(1M) のマニュアルページを参照してください。

ルータの構成

TCP/IP がルータに求める第 1 の必要条件は、 「ネットワークインタフェース」 で説明したように、マシンが少なくとも 2 つのネットワークインタフェースを備えていなければならないということです。ネットワークインタフェースのどれか 1 つが使用可能な状態にあれば、ルータは自動的に RDISC プロトコルと RIP プロトコルで「情報交換」します。これらのプロトコルは、絶えずネットワーク上でのルータの状態を追跡し、ネットワーク上のホストにルータを通知します。

ルータを物理的にネットワークにインストールしてしまったら、 「ローカルファイルモードの場合のホストの構成方法」 の説明に従って、ルータをローカルファイルモードで働くように構成します。これで、ネットワーク構成サーバがダウンしても、ルータが確実にブートされるようになります。ホストと違って、ルータには構成を要するインタフェースが 2 つあるということを忘れないでください。

ルータの両方のネットワークインタフェースの構成

ルータは、複数のネットワーク間のインタフェースを提供するものなので、ルータの各ネットワークインタフェースカードに、それぞれ一意な名前と IP アドレスを割り当てる必要があります。これで、各ルータは、その一次ネットワークインタフェースのホスト名と IP アドレスに加えて、増設した各ネットワークインタフェースについて少なくとも 1 つずつ、一意な名前と IP アドレスを持つことになります。

マシンをルータとして構成する方法

ルータとして構成したりマシンでスーパーユーザになり、次のようにします。

1. インストールされている各ネットワークインタフェースについて、/etc/hostname.interface ファイルを作成します。

   たとえば、hostname.ie0 と hostname.ie1 を作成します (詳細は、「/etc/hostname.interface ファイル」を参照してください)。

2. 対応するインタフェース用として選択したホスト名を各ファイルに入力します。

   たとえば、hostname.ie0 ファイルに timbuktu という名前を入力し、hostname.ie1 ファイルに timbuktu-201という名前を入力します。どちらのインタフェースも同じマシンに置かれることになります。

3. 各インタフェースのホスト名と IP アドレスを、/etc/inet/hosts に入力します。

   例:

   192.9.200.20 timbuktu #interface for network 192.9.200 192.9.201.20 timbuktu-201 #interface for network 192.9.201 192.9.200.9 gobi 192.9.200.10 mojave 192.9.200.110 saltlake 192.9.200.12 chilean

   インタフェース timbuktu と timbuktu-201 は、同じマシンにあります。timbuktu-201 のネットワークアドレスが、 timbuktu とは異なる点に注意してください。これは、ネットワーク 192.9.201 のメディアが timbuktu-201 ネットワークインタフェースに接続されるのに対し、ネットワーク 192.9.200 のメディアは timbuktu インタフェースに接続されるからです。

4. サブネット化したネットワークにルータを接続する場合は、/etc/inet/netmasks を編集して、ローカルネットワーク番号 (たとえば 129.9.0.0) と、関連のネットマスク番号 (たとえば 255.255.255.0) を入力します。

マシンがルータかどうかを決定する方法

あるマシンがホストかルータかを決定するのは、マシンのブート時に実行される /etc/rc2.d/S69inet 起動スクリプトです。この決定に伴って、ルーティングプロトコル (RIP と RDISC) を、ルータモードで実行するかホストモードで実行するかも決まります。

/etc/rc2.d/S69inet スクリプトは、次の 2 つの条件が満たされているとき、マシンがルータであると判断します。

• /etc/hostname.interface ファイルが 2 つ以上ある

• ifconfig コマンドにより、複数のインタフェースが "up" として構成されている (ifconfig(1M) のマニュアルページを参照してください)。

インタフェースが 1 つしか見つからない場合は、このスクリプトはそのマシンがホストであると判断します。「ルータの両方のネットワークインタフェースの構成」を参照してください。/etc/hostname.interface ファイル以外の方法で構成されているインタフェースは、考慮の対象にされません。

ルーティングプロトコルの自動選択

起動スクリプトは、次に、マシン上でルーティングプロトコル (RIP または RDISC) を起動するか、それとも静的ルーティングを使用するかを決める必要があります。

ホストで静的ルーティングを選択するには

ホストがディスクレスクライアントかネットワーククライアントである場合は、単に、ネットワーク上のルータを /etc/defaultrouter に追加するだけですみます (「/etc/defaultrouter ファイル」を参照してください)。すると、唯一の静的なデフォルトルートがルーティングテーブルに組み込まれます。この条件下では、ホストは動的ルーティングプロトコル (RIP や RDISC など) を実行しません。

ホストで動的ルーティングを選択するには

ディスクレスクライアントまたはネットワーククライアントに、強制的に動的ルーティングプロトコルを選択させるには、/etc/defaultrouter ファイルが空であることが必要です。使用する動的ルーティングの種類は、次の基準に従って選択されます。

• /usr/sbin/in.rdisc プログラムが存在する場合は、起動スクリプトは in.rdisc を起動する。すると、ネットワーク上で RDISC を実行しているすべてのルータが、ホストからのすべての RDISC 照会に応答するようになる。少なくとも 1 つのルータが応答すれば、ホストはルーティングプロトコルとして RDISC を選択する。

• ネットワークルータが RDISC を実行していないか、または RDISC 照会に対する応答が失敗した場合は、ホストでの in.rdisc は終了する。そして、ホストは in.routed を起動し、その結果 RIP が実行される。

マシンを強制的にルータにする方法

/etc/hostname.interface ファイルが 1 つだけのマシン (デフォルトではホスト) を、強制的にルータにすることができます。そのためには、/etc/gateways という名前のファイルを作成し、それを空のままにしておきます。これは、PPP リンクを構成することに決めた場合は、特に重要です。これについては、「ルーティングに関する考慮事項」を参照してください。

マルチホームホストの作成

デフォルトでは、TCP/IP は、複数のネットワークインタフェースを持つマシンをすべてルータとみなします。しかし、ルータをマルチホームホストに変更することもできます。マルチホームホストとは、複数のネットワークインタフェースを持っているが、ルーティングプロトコルの実行も IP パケットの転送もしないマシンのことです。一般に、次のような種類のマシンはマルチホームホストとして構成します。

• NFS サーバ、特に大規模なデータセンタは、複数のネットワークに接続することによって、多数のユーザ間でファイルを共有できるようになります。この種のサーバはルーティングテーブルを備えている必要はありません。

• データベースサーバは、NFS サーバの場合と同じ目的で複数のネットワークインタフェースを持つことにより、多数のユーザに資源を提供できます。

• ファイアウォールゲートウェイは、企業のネットワークとインターネットなどの公共ネットワークとの間の接続を提供するマシンです。管理者は、セキュリティの手段としてファイアウォールを設定します。ファイアウォールとして構成されたホストは、自己に接続されているネットワーク相互間でのパケットの受け渡しを行いません。その一方で、許可されたユーザに対しては、通常どおり、ftp や rlogin などの標準 TCP/IP サービスを提供します。

TCP/IP は、複数のネットワークインタフェースを持つマシンのすべてをルータとみなすので、それをマルチホームホストに変えるには、いくつかの操作が必要になります。

マルチホームホストの作成方法

マルチホームホストにしたいマシンでスーパーユーザになり、次のことを行います。

1. マシンにインストールされている追加の各ネットワークについて、/etc/hostname.interface ファイルを 1 つずつ作成します。

2. 次のようにタイプします。

   % touch /etc/notrouter

   これで、/etc/notrouter と呼ばれる空のファイルが作成されます。

3. マシンをリブートします。

マシンをリブートすると、起動スクリプトは /etc/notrouter ファイルの有無を確認します。このファイルが存在する場合は、起動スクリプトは、in.routed -s も in.rdisc -r も実行せず、また、ifconfig により "up" として構成されているインタフェースでは、いっさい IP の転送を行いません。これは、/etc/gateway ファイルが存在しているかどうかに関係なく行われます。これで、マシンはマルチホームホストになります。

スペース節約モードをオンにする方法

スペース節約モードでは、デフォルトの送信経路だけを含むテーブルがホストに提供されます。デフォルトでは、スペース節約モードをオフにした状態で、ホストで in.routed が実行されます。

フルルーティングテーブル (これは、構成に誤りのあるルータを排除するための保護を強化します) をホストに提供する必要がない場合は、スペース節約モードをオンにします。そのためには、/etc/rc2.d/S69inet 起動スクリプトの中の次の行を編集します。

/usr/sbin/in.routed -q

これを次のように変更します。

/usr/sbin/in.routed -q -S

ホストでの ICMP Router Discovery を止める方法

ルータの信頼性に関連した理由により、ホストに RDISC を使用させたくない場合があります。RDISC を止めるには、ホストの /usr/sbin/in.rdisc の名前を、何か別の名前、たとえば /usr/sbin/in.rdisc.saved に変更し、そしてホストをリブートします。

ルータでの ICMP Router Discovery を止める方法

ホストにおいて、RDISC ではなく RIP の自動選択が確実に働く場合は、ネットワーク内のルータ (特に RDISC を実行するもの) でも確実に働かなければなりません。

RDISC を実行するルータがほかにないときに、Solaris ルータを 1 つインストールすると、デフォルトにより、そのルータに接続されるすべてのホストがそのルータだけに依存することになります。そのネットワーク上のホストが他のルータも使用できるようにするには、新しいルータで RDISC をオフにします。そのためには、そのルータの /usr/bin/in.rdisc ファイルの名前を別の名前に変更し、ルータをリブートします。

第 6 章 TCP/IP の障害追跡

この章では、TCP/IP ネットワークの一般的な障害追跡の方法と、そのために使用できるいくつかのツールについて説明します。この種のツールには、ping、ifconfig、netstat、route などがあります。

• 「一般的な障害追跡方法」

• 「ソフトウェア検査の実行」

• 「ping コマンド」

• 「ifconfig コマンド」

• 「netstat コマンド」

• 「ネットワークの問題の記録」

• 「パケットの内容表示」

一般的な障害追跡方法

ネットワーク上での問題を示す最初の徴候は、1 つまたはいくつかのホストでの通信の消滅です。あるホストを初めてネットワークに追加したときに、そのホストがまったく作動状態にならない場合は、構成ファイルのどれかか、またはネットワークインタフェースに問題があることが考えられます。1 つのホストに突然問題が生じた場合は、ネットワークインタフェースに原因があると考えられます。ネットワーク上のホスト相互間の通信はできるが、他のネットワークとの通信ができないという場合は、ルータに問題があるか、または他のネットワークに問題があることが考えられます。

ifconfig プログラムを使用すればネットワークインタフェースに関する情報を入手でき、netstat を使用すればルーティングテーブルとプロトコル統計が表示できます。サードパーティのネットワーク診断プログラムから、さまざまの障害追跡ユーティリティが提供されています。詳細は、サードパーティのマニュアルを参照してください。

比較的はっきりしにくいのは、ネットワーク上でのパフォーマンス低下の原因です。たとえば、ping のようなツールを使用することで、ホストでのパケットの消失など、問題の原因を突き止めることができます。

ソフトウェア検査の実行

ネットワークに障害が生じた場合は、以下のような処置によって、ソフトウェア関連の問題を診断し修正することができます。

1. netstat コマンドを使ってネットワーク情報を表示します。

2. hosts データベースを検査して、個々のエントリが適正で現行のものであるかどうかを確認します。

3. RARP を実行している場合は、 ethers データベース内のイーサネットアドレスを検査して、個々のエントリが適正で現行のものであるかどうかを確認します。

4. telnet によりローカルホストに接続してみます。

5. ネットワークデーモン inetd が実行中であることを確かめます。そのためには、スーパーユーザとしてログインし、次のように入力します。

   # ps -ef | grep inetd

inetd デーモンが実行中であれば、次の例に示すような出力が表示されます。

root 57   1    0 Apr 04   ?     3:19 /usr/sbin/inetd -s
root 4218 4198 0 17:57:23 pts/3 0:00 grep inetd 

ping コマンド

ping コマンドは、特定のホストとの IP 接続が存在しているかどうかを確認するために使用します。基本構文は次のとおりです。

/usr/sbin/ping host [timeout]

上記において、host は問題のマシンのホスト名です。オプションの timeout 引数は、ping がそのマシンに到達しようと試みる秒数を示し、デフォルトは 20 秒です。詳しい構文とオプションについては、ping(1M) のマニュアルページに説明があります。

ping を実行すると、ICMP プロトコルは、指定されたホストにデータグラムを送って、応答を求めます (ICMP は、TCP/IP ネットワーク上のエラー処理を担当するプロトコルです。詳細は、「ICMP プロトコル」を参照してください)。

次のように入力したとします。

$ ping elvis

ホスト elvis が作動状態にあれば、次のメッセージが表示されます。

elvis is alive

これは、elvis が ICMP の要求に応答したことを示します。しかし、elvis がダウン状態にあるかまたは ICMP パケットを受け取れなかった場合は、ping から次の応答が戻されます。

no answer from elvis

マシンが作動状態にあるのにパケットが失われている疑いがある場合は、ping の s オプションを使用して、問題を追求することができます。たとえば次のように入力します。

$ ping -s elvis 

ping は、ユーザが割り込み文字を送るかまたはタイムアウトが生じるまで、elvis にパケットを送り続けます。画面上に現れる応答は次のようなものとなります。

PING elvis: 56 data bytes
64 bytes from 129.144.50.21: icmp_seq=0. time=80. ms
64 bytes from 129.144.50.21: icmp_seq=1. time=0. ms
64 bytes from 129.144.50.21: icmp_seq=2. time=0. ms
64 bytes from 129.144.50.21: icmp_seq=3. time=0. ms
.
.
.
----elvis PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/20/80   

パケットロスの統計値は、ホストがパケットを失ったかどうかを示します。

ping が失敗した場合は、ifconfig と netstat が報告するネットワーク状態を調べます。これについては、次の 「ifconfig コマンド」と、「netstat コマンド」を参照してくだい。

ifconfig コマンド

ifconfig コマンドは、指定したインタフェースの構成に関する情報を表示します (詳細は、ifconfig(1M) のマニュアルページを参照してください)。ifconfig の構文は次のとおりです。

ifconfig interface-name [protocol_family]

特定のインタフェース、たとえば le0 に関する情報を表示したい場合は、次のように入力します。

$ ifconfig le0

le0 インタフェースの場合は、出力は次のようなものになります。

le0: flags=863<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
 	inet 129.144.44.140 netmask ffffff00 broadcast 129.144.44.255
ether 8:0:20:8:el:fd

上記の flags セクションは、インタフェースが "up" として構成されていて、ブロードキャストの能力があり、"trailer" リンクレベルのカプセル化を使用していないことを示しています。mtu フィールドは、このインタフェースの最大転送速度が 1500 であることを示しています。2 行目には、使用しているホストの IP アドレス、現在使用されているネットマスク、そして、インタフェースの IP ブロードキャストアドレスの情報が含まれています。3 行目は、ホストのマシンアドレス (この場合はイーサネット) です。

ifconfig の便利なオプションの 1 つに -a があります。これを使用すると、ネットワーク上のすべてのインタフェースに関する情報が提供されます。たとえば、ifconfig -a と入力したとします。

le0:  flags=49<UP,LOOPBACK,RUNNING> mtu 8232
     inet 127.144.44.140 netmask ff000000 
le0:flags=863<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
     inet 129.144.44.140 netmask ffffff00 broadcast 129.144.44.255
ether 8:0:20:8:el:fd

出力が、実行されていないインタフェースがあることを示している場合は、そのインタフェースに問題があることが考えられます。その場合は、ifconfig(1M) のマニュアルページを参照してください。

netstat コマンド

netstat コマンドは、ネットワーク状態とプロトコル統計を表示します。TCP と UDP のエンドポイントの状態 (テーブル形式)、ルーティングテーブルの情報、そしてインタフェースの情報を表示できます。

netstat は、選択したコマンド行オプションに応じて、さまざまな種類のデータを表示します。この表示は、特にシステム管理に役立ちます。このコマンドの構文は次のとおりです。

netstat [-m] [-n] [-s] [-i | -r] [-f address_family]

ネットワーク状態の判別のために最もよく使われるオプションは、 s、r、i です。オプションの説明については、netstat(1M) のマニュアルページを参照してください。

プロトコル別統計の表示

netstat -s オプションは、UDP、TCP、ICMP、IP プロトコルについて、プロトコル別の統計を表示します。結果は、下に示す出力例のように表示されます (出力の一部は省略してあります)。この情報には、プロトコルに問題のある箇所が示されることがあります。たとえば、ICMP からの統計情報には、このプロトコルがどこにエラーを検出したかを示すことがあります。

UDP

      udpInDatagrams      =  39228     udpOutDatagrams     =  2455
      udpInErrors         =     0

TCP

      tcpRtoAlgorithm     =     4      tcpMaxConn          =    -1
      tcpRtoMax           = 60000      tcpPassiveOpens     =     2
      tcpActiveOpens      =     4      tcpEstabResets      =     1
      tcpAttemptFails     =     3      tcpOutSegs          =   315
      tcpCurrEstab        =     1      tcpOutDataBytes     = 10547
      tcpOutDataSegs      =   288      tcpRetransBytes     =  8376
      tcpRetransSegs      =    29      tcpOutAckDelayed    =    23
      tcpOutAck           =    27      tcpOutWinUpdate     =     2
      tcpOutUrg           =     2      tcpOutControl       =     8
      tcpOutWinProbe      =     0      tcpOutFastRetrans   =     1
      tcpOutRsts          =     0
      tcpInSegs           =   563      tcpInAckBytes       = 10549
      tcpInAckSegs        =   289      tcpInAckUnsent      =     0
      tcpInDupAck         =    27      tcpInInorderBytes   =   673
      tcpInInorderSegs    =   254      tcpInInorderBytes   =   673
      tcpInUnorderSegs    =     0      tcpInUnorderBytes   =     0
      tcpInDupSegs        =     0      tcpInDupBytes       =     0
      tcpInPartDupSegs    =     0      tcpInPartDupBytes   =     0
      tcpInPastWinSegs    =     0      tcpInPastWinBytes   =     0
      tcpInWinProbe       =     0      tcpInWinUpdate      =   237
      tcpInClosed         =     0      tcpRttNoUpdate      =    21
      tcpRttUpdate        =   266      tcpTimRetrans       =    26
      tcpTimRetransDrop   =     0      tcpTimKeepalive     =     0
      tcpTimKeepaliveProbe=     0      tcpTimKeepaliveDrop =     0

IP
 
      ipForwarding        =     2      ipDefaultTTL        =   255
      ipInReceives        =  4518      ipInHdrErrors       =     0
      ipInAddrErrors      =     0      ipInCksumErrs       =     0
      ipForwDatagrams     =     0      ipForwProhibits     =     0
      ipInUnknownProtos   =     0      ipInDiscards        =     0
      ipInDelivers        =  4486      ipOutRequests       =  2805
      ipOutDiscards       =     5      ipOutNoRoutes       =     0
      ipReasmTimeout      =    60      ipReasmReqds        =     2
      ipReasmOKs          =     2      ipReasmReqds        =     2
      ipReasmDuplicates   =     0      ipReasmFails        =     0
      ipFragOKs           =    20      ipReasmPartDups     =     0
      ipFragCreates       =   116      ipFragFails         =     0
      tcpInErrs           =     0      ipRoutingDiscards   =     0
      udpInCksumErrs      =     0      udpNoPorts          =    33
      rawipInOverflows    =     0      udpInOverflows      =     6

ICMP

      icmpInMsgs          =     0      icmpInErrors        =     0
      icmpInCksumErrs     =     0      icmpInUnknowns      =     0
      icmpInDestUnreachs  =     0      icmpInTimeExcds     =     0
      icmpInParmProbs     =     0      icmpInSrcQuenchs    =     0
      icmpInRedirects     =     0      icmpInBadRedirects  =     0
      icmpInEchos         =     0      icmpInEchoReps      =     0
      icmpInTimestamps    =     0      icmpInTimestampReps =     0
      icmpInAddrMasks     =     0      icmpInAddrMaskReps  =     0
      icmpInFragNeeded    =     0      icmpOutMsgs         =     7
      icmpOutDestUnreachs =     1      icmpOutErrors       =     0
      icmpOutDrops        =     5      icmpOutTimeExcds    =     0
      icmpOutParmProbs    =     0      icmpOutSrcQuenchs   =     6
      icmpOutRedirects    =     0      icmpOutEchos        =     0
      icmpOutEchoReps     =     0      icmpOutTimestamps   =     0
      icmpOutTimestampReps=     0      icmpOutAddrMasks    =     0
      icmpOutAddrMaskReps =     0      icmpOutFragNeeded   =     0
      icmpInOverflows     =     0


IGMP:
 
0 messages received
0 messages received with too few bytes
0 messages received with bad checksum
0 membership queries received
0 membership queries received with invalid field(s)
0 membership reports received
0 membership reports received with invalid field(s)
0 membership reports received for groups to which we belong
0 membership reports sent

ネットワークインタフェースの状態の表示

netstat の i オプションは、このコマンドを実行したマシンで構成されているネットワークインタフェースの状態を示します。次に示すのは、netstat i により生成される表示の例です。

Name Mtu  Net/Dest     Address   Ipkts    Ierrs Opkts    Oerrs  Collis  Queue
le0  1500 b5-spd-2f-cm tatra     14093893 8492  10174659 1119   2314178   0
lo0  8232 loopback     localhost 92997622 5442  12451748 0      775125    0

この表示から、各ネットワークについてマシンが送信し受信したとみなしているパケットの数が分かります。たとえば、サーバについて表示される入力パケットカウント (Ipkts) はクライアントがブートを試みるたびに増加しているのに、出力パケットカウント (Opkts) が変化しないことがあります。これは、サーバがクライアントからのブート要求パケットを見ているが、それを応答すべきものとして認識していないことを示しています。この原因としては、hosts データベースまたは ethers データベース内に誤ったアドレスがあることが考えられます。

逆に、入力パケットカウントが長時間にわたり変化しないとすれば、それは、マシンがまったくパケットを見ていないことを意味します。この原因としては、上記の場合と違って、ハードウェアの問題の可能性が高くなります。

ルーティングテーブルの状態の表示

netstat の -r オプションは、IP ルーティングテーブルを表示します。次に示すのは、マシン tenere で実行した netstat -r の結果の表示サンプルです。

Routing tables
Destination   Gateway Flags Refcnt Use   Interface
temp8milptp   elvis   UGH   0      0	
irmcpeb1-ptp0 elvis   UGH   0      0	
route93-ptp0  speed   UGH   0      0	
mtvb9-ptp0    speed   UGH   0      0	
	              .
mtnside       speed   UG    1      567	
ray-net       speed   UG    0      0	
mtnside-eng   speed   UG    0      36	
mtnside-eng   speed   UG    0      558	
mtnside-eng   tenere	 U     33     190248  le0

最初の列は宛先ネットワークを、そして 2 番目の列はパケットを転送するルータを示しています。U フラグは送信経路が up 状態であること、G フラグは送信経路がゲートウェイへのものであることを示します。H フラグは、宛先がネットワークではなく、完全指定のホストアドレスであることを示します。

Refcnt 列は 1 送信経路当たりの有効ユーザの数、Use 列は 1 送信経路当たりの送信パケット数を示します。最後の Interface 列は、送信経路で使用されているネットワークインタフェースを示します。

ネットワークの問題の記録

ルーティングデーモンについて誤動作の疑いがある場合は、すべてのパケット転送も含めてそのデーモンの動作をログに記録することができます。ルーティングデーモンの動作のログファイルを作成するには、routed デーモンを起動するときにファイル名を指定します。たとえば次のように入力します。

# /usr/sbin/in.routed /var/routerlog

ビジー状態のネットワークでは、ほとんど絶え間なく出力が生じることがあります。

パケットの内容表示

snoop を使用すると、ネットワークパケットを取得して内容を表示できます。取得したパケットについては、そのまま表示することも、ファイルに保存することも可能です。snoop が中間ファイルに書き込む場合、トレースのビジー状態でパケットロスはほとんど発生しません。その後、snoop 自体はファイルの解釈に使用されます。詳細は、snoop(1M) のマニュアルページを参照してください。

snoop コマンドは必ず root(#) になって実行します。プロミスキュアス (promiscuous) モードでデフォルトのインタフェースとやりとりするパケットを取得できます。最高レベルのプロトコルに関連するデータのみが一覧形式で表示されます。たとえば NFS パケットでは、NFS 情報のみが表示されます。RPC、UDP、IP、および Ethernet のフレーム情報は抑止されますが、verbose (詳細表示) オプションのいずれかを選択してあれば表示できます。

snoop が取得するファイル形式は、RFC 1761 で説明しています。アクセスするには、ウェブブラウザで URL に http://ds.internic.net/rfc/rfc1761.txt を指定します。

snoop server client rpc rstatd は、クライアント/サーバ間の RPC トラフィックをすべて収集し、rstatd に対するフィルタをかけます。

システムから全パケットを確認する方法

1. netstat -i と入力し、システムに接続されたインタフェースを検索します。

   通常、snoop では最初の非ループバックデバイス (le0) が使用されます。

2. root になって snoop と入力します。

   Ctrl -C でプロセスを停止します。

   # snoop
   Using device /dev/le (promiscuous mode)
        maupiti -> atlantic-82  NFS C GETATTR FH=0343
    atlantic-82 -> maupiti      NFS R GETATTR OK
        maupiti -> atlantic-82  NFS C GETATTR FH=D360
    atlantic-82 -> maupiti      NFS R GETATTR OK
        maupiti -> atlantic-82  NFS C GETATTR FH=1A18
    atlantic-82 -> maupiti      NFS R GETATTR OK
        maupiti -> (broadcast)  ARP C Who is 129.146.82.36, npmpk17a-82 ?

3. 結果を解釈します。

   上の例の場合、クライアント maupiti からサーバ atlantic-82 への転送には NFS ファイルハンドル 0343 が使用され、atlantic-82 は OK と応答しています。who is 129.146.82.36? と問い合わせる ARP 要求が maupiti から伝送されるまで、会話は継続します。

   この例は、snoop の形式を説明しています。次の手順では、snoop にフィルタをかけてファイルにパケットを取り込みます。

   取り込んだファイルを解釈する際には、RFC 1761 に記述された説明を使用します。アクセスするには、ウェブブラウザで URL に http://ds.internic.net/rfc/rfc1761.txt を指定します。

snoop の結果をファイルに取り込む方法

1. root になって snoop -o filename の形式で入力します。たとえば、次のようになります。

   # snoop -o /tmp/cap Using device /dev/le (promiscuous mode) 30 snoop: 30 packets captured

   これによって、ファイル /tmp/cap に 30 ものパケットが取り込まれました。ディスク容量が足りる場所であれば、ファイルはどこにでも格納できます。取り込んだパケットの数はコマンド行に表示され、Ctrl-C を押せばいつでも終了できます。

   snoop によってホストマシン上のネットワーク負荷が顕著になることで、結果に誤差が生じる場合があります。実際の状況を確認するには、第 3 のシステムから snoop を実行してください (次の節を参照)。

2. snoop -i filename の形式で入力し、ファイルを検査します。

   # snoop -i /tmp/cap
   
   1  0.00000 frmpk17b-082 -> 224.0.0.2   IP  D=224.0.0.2 S=129.146.82.1 LEN=32, ID=0
   2  0.56104        scout -> (broadcast) ARP C Who is 129.146.82.63, grail ?
   3  0.16742  atlantic-82 -> (broadcast) ARP C Who is 129.146.82.76, honeybea ?
   4  0.77247        scout -> (broadcast) ARP C Who is 129.146.82.63, grail ?
   5  0.80532 frmpk17b-082 -> (broadcast) ARP C Who is 129.146.82.92, holmes ?
   6  0.13462        scout -> (broadcast) ARP C Who is 129.146.82.63, grail ?
   7  0.94003        scout -> (broadcast) ARP C Who is 129.146.82.63, grail ?
   8  0.93992        scout -> (broadcast) ARP C Who is 129.146.82.63, grail ?
   9  0.60887        towel -> (broadcast) ARP C Who is 129.146.82.35, udmpk17b-82 ?
   10 0.86691  nimpk17a-82 -> 129.146.82.255 RIP R (1 destinations)

   ARP、IP、RIP その他の詳細な分析と推奨されるパラメタについては、特定のプロトコルのマニュアルを参照してください。RFC の確認には、ウェブを検索することをお奨めします。

サーバ/クライアント間のパケットを確認する方法

1. クライアントかサーバに接続されたハブを外した snoop システムを確立します。

   第 3 のシステム (snoop システム) はすべてのトラフィックを監視するので、snoop のトレースには実際の状況が反映されます。

2. root になって snoop をオプション付きで入力し、ファイルに保存します。

3. 結果の検査と解釈を行います。

   snoop 取り込みファイルの詳細については、RFC 1761 に記述された説明を使用します。アクセスするには、ウェブブラウザで URL に http://ds.internic.net/rfc/rfc1761.txt を指定します。

頻繁かつ定期的に snoop を使用して、システムが正常に動作する感覚をつかんでください。最近の白書や RFC を参照したり、NFS や YP といった特定分野の専門家からアドバイスを受けるのも、パケットの分析に役立ちます。snoop とそのオプションの使用法についての詳細は、snoop(1M) のマニュアルページを参照してください。