パート I では、Solaris オペレーティング環境で TCP/IP を実行するネットワークの設定方法について説明します。ここでは、読者が UNIX に関する十分な知識を持ち、ローカル UNIX システムの管理についてある程度の経験を積んでいることを前提として、説明を進めます。ネットワーク管理の経験はなくてもかまいません。
この章では、ネットワーク管理者の役割を紹介します。新しくネットワーク管理者になった方にとっては、必要な作業の概略を理解するためにこの章の内容が役立ちます。またこの章には、本書を読むときに必要になるネットワークの基礎概念も示しています。すでに経験を積んだネットワーク管理者は、この章をとばして次の章に進んでもかまいません。
一般に、ネットワーク管理者の作業には次の 4 つの分野があります。
ネットワークの設計と計画
ネットワークの設定
ネットワークの保守
ネットワークの拡張
各作業分野は、ネットワークのライフサイクルの中の各段階に対応しています。ネットワーク管理者は、これらのすべての段階に責任を持つ場合もあり、また、ネットワークの保守など特定の分野だけを専門的に受け持つ場合もあります。
ネットワーク管理の最初の作業として、まずネットワークの設計という作業がありますが、一般にこれはネットワーク管理の初心者が行う作業ではありません。ネットワークの設計では、組織のニーズを最大限に満たすようなネットワークの種類を選定する必要があります。大規模の組織では、熟練したネットワーク設計者、つまりネットワークのソフトウェアとハードウェアの両方を熟知している経験豊富なネットワーク管理者が、この作業を担当します。
ネットワーク設計に関連する各種の要素については、第 3 章「ネットワークの計画」で説明します。
新しいネットワークの設計が終わったら、次にネットワークの設定と構成という作業を行います。この段階では、ネットワークの物理的な部分を形成するハードウェアをインストールし、ファイルまたはデータベース、ホスト、ルーター、ネットワーク構成サーバーを構成します。
この作業は、ネットワーク管理者の主な責任のうちの 1 つです。組織が非常に大規模ですでに十分なネットワーク構造が整っている場合を除いて、必須な作業の 1 つです。
ネットワークの設定に関連する作業については、第 4 章「ネットワーク上での TCP/IP の構成」で説明しています。
ネットワーク管理作業の第 3 の段階には、管理者の責任のもっとも大きい部分を占める、次のような日常的な作業が含まれます。
ネットワークへの新規マシンの追加
ネットワークのセキュリティ
NFS、ネームサービス、電子メールなどのネットワークサービスの管理
ネットワーク上の問題に関する障害追跡
既存のネットワーク上に新しいホストを設定する方法については、第 4 章「ネットワーク上での TCP/IP の構成」を参照してください。第 6 章「TCP/IP の障害追跡」には、ネットワーク上の問題を解決するためのヒントが記載されています。ネットワークサービスについての詳細は、『NFS の管理』、『Solaris ネーミングの管理』、『NIS+ への移行』、『メールシステムの管理』を参照してください。セキュリティ関係の作業については、『Solaris のシステム管理 (第 2 巻)』を参照してください。
ネットワークが安定し問題なく動作する期間が長くなるにつれて、ネットワークの機能とサービスの拡張を望む組織の要求が大きくなってきます。始めのうちは、新しいホストを追加することによってネットワーク人口を増やし、共有ソフトウェアを追加することによってネットワークサービスを拡張することができます。しかし最終的には、単一のネットワークではこれ以上効率的に運営できないような限界点に達することになります。そのようになったとき、ネットワーク管理作業の第 4 の段階である拡張作業にとりかかります。
ネットワークの拡張については、以下のように選択肢がいくつかあります。
新規のネットワークを設定し、ルーターとして機能するマシンを使ってそのネットワークを既存のネットワークに接続して、インターネットワークを作る。
家庭やリモートオフィスにあるマシンを構成し、それらのマシンが電話回線を介してネットワークに接続できるようにする。
ネットワークをインターネットに接続して、ネットワークのユーザーが、世界中の他のシステムから情報を検索できるようにする。
UUCP 通信の構成を行い、リモートマシンとの間でファイルや電子メールをやりとりできるようにする。
第 5 章「ルーターの構成」は、インターネットを設定するための手順を説明しています。パート II には、可搬コンピュータ用のネットワーク接続の設定方法を説明しています。パート III は、UUCP を使って、ユーザーのマシンと他の UUCP システムとの間で情報を交換する方法について説明しています。
ネットワーク通信プロトコルは、ネットワークの中でソフトウェアとハードウェアがどのように対話するかを規定した正規の規則です。ネットワークが正しく機能するためには、情報が目的の宛先に明瞭な形式で伝送される必要があります。ネットワークが機能するためには異なる種類のネットワーク用のソフトウェアとハードウェアが相互に対話できる必要があることから、通信プロトコルという概念が開発されました。
Solaris オペレーティングシステムには、組織でのネットワーク管理に必要なソフトウェアが含まれています。このネットワークソフトウェアは、総称的に TCP/IP (Transmission Control Protocol/Internet Protocol) と呼ばれる通信プロトコル群を実装しています。TCP/IP は、多くの主要な国際標準化機構によって標準として認定されており、世界中で使用されています。TCP/IP は複数の規格を集まりなので、多くの異種コンピュータで実行することができます。またこれを用いることによって、Solaris オペレーティングシステムを実行する異機種のシステムが混在したネットワークを容易に設定することができます。
TCP/IP は、多くの異なる種類のコンピュータ、オペレーティングシステム、ネットワークに対して、サービスを提供します。TCP/IP は、イーサネット、FDDI、トークンリングなどのローカルエリアネットワークや、T1 (デジタル専用線)、X.25、ATM などの広域ネットワークに、適用することができます。
TCP/IP を使用することで、複数のローカルエリアネットワークから成る 1 つのネットワークを構築できます。また、TCP/IP を使用すれば、事実上どのようなポイントツーポイントデジタル回線を用いても、広域ネットワークを構築することができます。
TCP/IP とそのプロトコル群については、第 2 章「TCP/IP プロトコル群」で詳しく説明します。
ローカルエリアネットワーク (LAN) という用語は、たとえば 1 つのビル内または 2 つの隣接するビル間のように、比較的狭い空間に限定されている単一のコンピュータネットワークを指します。ローカルエリアネットワークには、ハードウェアとソフトウェアの両方の構成要素があります。ハードウェアの観点から見ると、基本的な Solaris LAN は、ローカルエリアのなんらかのネットワークメディアに接続された複数のコンピュータで構成されます。
コンピュータネットワーク用に使用するケーブル配線や電気配線をネットワークメディアと言います。図 1-1 は、イーサネットメディアを介して相互に接続されている 4 つのコンピュータを示しています。Solaris LAN 環境で最もよく使用されているローカルエリアネットワークメディアは、イーサーネットメディアです。Solaris LAN で使用できるその他のローカルエリアネットワークメディアには、FDDI とトークンリングがあります。
TCP/IP ネットワーク上のコンピュータは、ネットワークメディアに接続するために 2 種類のコネクタを使用します。それは、シリアルポートと、ネットワークインタフェース上のポートです。
どのコンピュータにも、少なくとも 2 つのシリアルポートがあり、コンピュータにプリンタやモデムを接続するためのコネクタとして使用されます。シリアルポートは CPU ボードに装備されている場合もありますが、新たに購入しなければならない場合もあります。システムにモデムを接続して PPP 接続や UUCP 接続を確立するときは、これらのポートを使用します。PPP と UUCP はネットワークメディアとして電話回線を使用することができるので、事実上の広域ネットワークサービスを提供します。
ネットワークへの接続ができるようにするためにコンピュータに内蔵されているハードウェアを、ネットワークインタフェースと言います。多くのコンピュータにはネットワークインタフェースが始めからインストールされていますが、そうでない場合は、別にネットワークインタフェースを購入する必要があります。
LAN メディアの種類別に、それぞれ異なるネットワークインタフェースが定められています。たとえば、イーサネットをネットワークメディアとして使用したいのであれば、ネットワーク内の各ホストにイーサネットインタフェースをインストールしておく必要があります。イーサネットケーブルを接続するために使用するボード上のコネクタを、イーサネットコネクタと言います。たとえば FDDI を使用しようと計画しているのであれば、予定している各ホストに FDDI ネットワークインタフェースが装備されている必要があります (その他のネットワークメディアの場合も同様です)。
本書では、ホストのデフォルトのネットワークインタフェースを一次ネットワークインタフェースと呼びます。
ネットワークハードウェアのインストールについては、本書では取り扱いません。シリアルポートの構成方法については、 『Solaris のシステム管理 (第 2 巻)』を、ネットワークメディアのインストールの手順については、ネットワークメディアに付属しているマニュアルを参照してください。
ネットワークソフトウェアの設定は複雑な作業です。そこで、まず設定しようとしているネットワークソフトウェアがどのようにして情報を転送するかを理解しておくことが重要です。
図 1-2 に、ネットワーク通信に関係のある基本的な要素を示します。
この図では、あるコンピュータがネットワークメディアを介して、同じメディアに接続している別のコンピュータにパケットを送信しています。
ネットワークを介して転送する情報の基本単位をパケットと言います。パケットの構成は通常の手紙によく似ています。
どのパケットにもヘッダーがあり、これは手紙の封筒に当たります。ヘッダーには、受取先と送信元のアドレスに加えて、パケットがプロトコル群の各層を移送されるときにそのパケットをどのように扱うかを指示する情報が含まれています。
パケットのメッセージ部は手紙の本文に相当します。パケットに含めることのできるデータのバイト数には制限があり、これは使用しているネットワークメディアによって異なります。したがって、電子メールメッセージなどのような代表的な通信は、いくつかのパケットフラグメントに分割されることがあります。
経験を積んだ Solaris ユーザーなら、もちろん「ホスト」という言葉はよくご存じのことでしょう。この言葉は、しばしば「コンピュータ」または「マシン」の同義語として使われます。TCP/IP の視点から見れば、ネットワーク上に存在する実体は、ルーターとホストの 2 つだけです。
ルーターは、ネットワークから別のネットワークへとパケットを転送するマシンです。これを行うには、ルーターは少なくとも 2 つのネットワークインタフェースを持っている必要があります。ネットワークインタフェースが 1 つしかないマシンは、パケットを転送できません。このようなマシンはホストとみなされます。ネットワーク管理者がネットワーク上に設定するマシンのほとんどはホストです。
複数のネットワークインタフェースを持っているけれどもルーターとしては機能しないマシンもあります。このようなマシンをマルチホームホストと呼びます。マルチホームホストは、持っているネットワークインタフェースを用いて複数のネットワークに直接的に接続されます。ただし、1 つのネットワークから別のネットワークへとパケットを転送することはしません。
あるホストが通信を開始したとき、それを送信側ホスト、送信、送信元、などと呼びます。たとえば、あるホストのユーザーが rlogin を入力するか、または他のユーザーに電子メールメッセージを送ると、そのホストは通信を開始します。通信の宛先となるホストを、受信側ホスト、受信側、受信先などと呼びます。たとえば、rlogin への引数として指定されたリモートホストは、そのログイン要求の受信先です。
各ホストは、ネットワーク上の他の対等ホストに自身を識別させるための次の 3 つの特性を備えています。
ホスト名 は、ローカルマシンの名前と所属組織の名前を組み合わせたものです。多くの組織では、ユーザーが各自のマシンのホスト名を選定します。sendmail や rlogin などのプログラムは、ネットワーク上のリモートマシンを指定するときにホスト名を使用します。ホスト名については、 『Solaris のシステム管理 (第 1 巻)』でより詳しく説明しています。
マシンのホスト名は、一次ネットワークインタフェースの名前にもなります。この概念は、ネットワークデータベースを設定したりルーターを構成したりするときに重要な意味を持ちます。
ネットワークを設定するときは、そのネットワークに関与するすべてのマシンのホスト名を入手する必要があります。ネットワークデータベースを設定するときに、必要となります。詳細は、第 4 章「ネットワーク上での TCP/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 のシステム管理 (第 2 巻)』に説明されています。詳細な説明は、William R. Cheswick および Steven M. Bellovin 共著の『Firewalls and Internet Security』(Addison Wesly, 1994) に記載されています。
米国の majordomo@greatcircle.com に、subscribe firewalls という文字列を入れたメールを送ることで、セキュリティについての情報を入手することもできます。ダイジェスト版の方をご希望の場合は、テキスト中に firewalls_digest という文字列を入れてください。
TCP セッションのラージウィンドウは、RFC1323 に記述されたサポートを提供します。このサポートは、一般的な上限値の 65,535 バイトより大きなウィンドウを使用することで、ATM や衛星ネットワークなどの広帯域または遅延ネットワークのパフォーマンスを改善するように設計されています。
サポートするデータ量の増大が顕著なのは、65,535 バイトから約 1 ギガバイトに上限値が拡張された TCP セッションです。
TCP セッションのラージウィンドウでは、多数の TCP 構成パラメータがサポートされます。これらのパラメータにより、システム管理者は拡張された送受信ウィンドウサイズと RFC1323 タイムスタンプオプションを使用できます。その際に、アプリケーションを修正する必要はありません。システム全体か特定のホストやネットワークに対して、パラメータを変更できます。このことが特に有効なのは、使用するバッファーサイズの拡張機能を持たない ftp や rcp などの標準的なネットワークユーティリティを使用する場合です。
構成パラメータは、TCP デバイスを示す /dev/tcp に関連付けられ、ndd(5) による検査と変更が可能です。通常、これらのパラメータは、システムのブート時に init(1M) が実行するシェルスクリプトの 1 つに設定されます (新規スクリプトの追加方法については、init.d(4) を参照してください)。
接続の受信バッファースペース (受信データ用に割り当てられたバッファースペースの量。公示されている受信ウィンドウの最大サイズ) にデフォルト値 (8K) を指定します。
パラメータがゼロ以外であれば、リモートシステムへの接続時にウィンドウスケールオプションが必ず送信されます。パラメータがゼロであれば、64K より大きな受信ウィンドウをユーザーが要求した場合に (限って) 送信されます。デフォルトはゼロです。
このパラメータの値にかかわらず、ウィンドウスケールオプションが必ず接続肯定応答に含まれるのは、接続システムがそのオプションを使用した場合です。
パラメータがゼロ以外であれば、リモートシステムへの接続時にタイムスタンプオプションが必ず送信されます。デフォルトはゼロです。
このパラメータの値にかかわらず、タイムスタンプオプションが必ず接続肯定応答 (および以降の全パケット) に含まれるのは、接続システムがそのオプションを使用した場合です。
パラメータがゼロ以外であれば、リモートシステムへの接続時にタイムスタンプオプションが送信されるのは、64K より大きな受信ウィンドウをユーザーが要求した場合 (つまり、ゼロ以外のスケールを指定したウィンドウスケールオプションを使用している場合) です。デフォルトはゼロです。
SO_SNDBUF または SO_RCVBUF オプション付きでユーザーが指定できるバッファーサイズの最大値を指定します。この値より大きなバッファーの使用を試みると、EINVAL を返して失敗します。デフォルトは 256K です。アプリケーションに必要な最大バッファーサイズよりもずっと大きな値をパラメータに指定するのはお勧めできません。障害や悪影響の原因となっているアプリケーションが、カーネルメモリを不当に大きく消費しかねないからです。
このパラメータは、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>' |
<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 オプションの設定により、タイムスタンプオプションが送信されることがあります。
TCP 選択式応答 (TCP SACK) は、RFC 2018 に記述されているサポートを提供し、特に衛星リンクや大陸間リンク上で TCP ラージウィンドウ (RFC 1323) を使用するアプリケーションにおいて、混雑や複数パケットの脱落に関連した問題を解決します。
構成パラメータは、TCP デバイス /dev/tcp に関連付けられており、ndd(1M) を使用してその検査や変更を行うことができます。通常、このパラメータは、システムの起動時に init(1M) によって実行されるシェルスクリプトのいずれかで設定されます (新しいスクリプトの追加方法については、init.d(4) を参照してください)。
SACK を許可するかどうかを示します。デフォルトは 1 です。使用可能なオプションを以下に示します。
TCP は SACK 情報の受信や送信を行いません。
TCP は SACK_PERMITTED オプションによる接続は開始しません。受信した要求に SACK_PERMITTED が含まれている場合は、TCP は SACK_PERMITTED オプションを使用して応答します。
TCP は SACK_PERMITTED オプションを使用して接続の開始と許可を行います。
詳細は、tcp(7P) のマニュアルページを参照してください。
この章では、Solaris 実装の TCP/IP ネットワークプロトコル群を紹介します。この章の情報は、まだあまり TCP/IP に慣れていないネットワーク管理者を対象としています (ネットワークの基本概念の紹介については、第 1 章「ネットワーク管理の概要」を参照してください)。TCP/IP の経験のあるネットワーク管理者の場合は、この章をとばして行いたい作業に該当する章に進んでもかまいません。
この節では、TCP/IP を構成するプロトコルについて詳しく紹介します。ここに示す情報は概念的なものですが、各プロトコルの名前とそれぞれの働きを理解することができます。TCP/IP 関係の書籍は、どれもここに示す概念を理解していることを前提として書かれているので、この情報は重要です。
TCP/IP は、インターネットプロトコル群を形成するネットワークプロトコルの集合を示すニックネームとして使われています。多くの書籍では、「インターネット」という用語は、プロトコル群と広域ネットワークの両方を表すものとして使われています。本書では、「TCP/IP」は特にインターネットプロトコル群を表し、「インターネット」は広域ネットワークとそれを運営する組織を表すものとします。
TCP/IP ネットワークと他のネットワークとを相互接続するには、一意な IP ネットワーク番号を入手する必要があります。本書を作成した時点では、IP ネットワーク番号は、InterNIC と呼ばれる組織によって割り当てられていました。
ネットワーク上のホストがインターネットドメイン名システム (DNS) に参加する場合は、一意なドメイン名を入手し登録する必要があります。InterNIC は、いくつかのトップレベルのドメイン、たとえば .com (商業)、.edu (教育)、.gov (政府) などのドメインの傘下にあるドメイン名の登録も行なっています。InterNIC については、第 3 章「ネットワークの計画」で詳しく説明します (DNS についての詳細は、『Solaris ネーミングの管理』を参照してください)。
ほとんどのネットワークプロトコル群は、一連の層として構築されており、これはしばしば総称的にプロトコルスタックと呼ばれます。各層はそれぞれ特定の目的のために設計されていて、送信側ホストと受信側ホストの両方に存在しています。一方のマシンの特定の層が、相手のマシンの対等プロセスが送受信するオブジェクトと同じものを送受信するように設計されています。このような動作は、問題の層の上下の層で進行していることとは独立して行われます。つまり、ホストの各層は、同じマシンの他の層から独立して、他のホストの同じ層と協調して働きます。
ほとんどのネットワークプロトコル群が層の形に構造化されているとみなされるのは、国際標準化機構 (ISO) が設計した開放型相互接続 (OSI) 参照モデルの結果です。OSI モデルは、ネットワーク活動が 7 つの層から成る構造を持ち、それぞれの層に 1 つまたは複数のプロトコルが関連付けされるものと規定しています。層は、連携するネットワーク相互間でのすべての種類のデータ転送に共通するデータ転送操作を表します。
OSI 参照モデルのプロトコル層は、通常は表 2-1 に示すように、上 (層 7) から下 (層 1) へ並べて表します。
表 2-1 開放型相互接続参照モデル
層番号 |
層の名前 |
説明 |
---|---|---|
7 |
誰でも使用できる標準の通信サービスとアプリケーション |
|
6 |
情報が解読可能な形で受信側マシンに渡されるようにする |
|
5 |
連携コンピュータ間の接続と終了を管理する |
|
4 |
データの転送を管理し、受信されたデータと送信されたデータが同じになるようにする |
|
3 |
ネットワーク間でのデータのアドレス指定と配送を管理する |
|
2 |
ネットワークメディアを通過するデータの転送を取り扱う |
|
1 |
ネットワークハードウェアの特性を定義する |
OSI モデルにより定義されている動作は概念的なものであり、特定のネットワークプロトコル群に特有のものではありません。たとえば、OSI ネットワークプロトコル群は、OSI 参照モデルの 7 つの層をすべて実装しています。TCP/IP は、OSI モデルの層のいくつかを使用し、その他を合併しています。その他のネットワークプロトコル、たとえば SNA では、8 番目の層が追加されています。
TCP/IP は、いくつかの OSI 層を合併して 1 つの層にしていたり、またまったく使わない層があったりするため、このモデルに直接対応しているとは言えません。表 2-2 は、Solaris 実装の TCP/IP の層を示しています。最上位の層 (アプリケーション) から最下位の層 (物理ネットワーク) まで並べてあります。
表 2-2 TCP/IP プロトコルスタック
OSI 参照の層番号 |
対応する OSI 層 |
TCP/IP 層 |
TCP/IP プロトコルの例 |
---|---|---|---|
5,6,7 |
アプリケーション、セッション、プレゼンテーション |
NFS、NIS+、DNS、telnet、ftp、"r"(リモート) コマンド1、RIP、RDISC、SNMP、その他 |
|
4 |
トランスポート |
TCP, UDP |
|
3 |
ネットワーク |
IP, ARP, ICMP |
|
2 |
データリンク |
PPP, IEEE 802.2 |
|
1 |
物理 |
イーサネット (IEEE 802.3) トークンリング、RS-232、その他 |
1."r" コマンドには、rlogin、rsh、rcp があります。
この表は、TCP/IP プロトコルの層、対応する OSI モデルの層、および TCP/IP プロトコルスタックの各レベルで使用できるプロトコルの例を示しています。通信トランザクションに関与する各ホストは、それぞれ独自の実装によるプロトコルスタックを実行します。
物理ネットワーク層は、ネットワークに使用するハードウェアの特性を規定します。たとえば、通信メディアの物理特性を規定します。TCP/IP の物理層はハードウェア規格を意味しています。たとえば、イーサネットネットワークメディアの仕様である IEEE 802.3 や、標準ピンコネクタの仕様である RS-232 などです。
データリンク層は、パケットのネットワークプロトコルの種類を識別します。この場合は TCP/IP です。また、この層には、エラー制御と「フレーミング」の働きもあります。データリンク層の例としては、イーサネット IEEE 802.2 フレーミングと、ポイントツーポイントプロトコル (PPP) フレーミングがあります。
この層はネットワーク層とも呼ばれるもので、ネットワークに対してパケットを受け入れたり、配送したりします。この層には、強力なインターネットプロトコル (IP)、ARP プロトコル、ICMP プロトコルが組み込まれています。
IP プロトコルとそれに関連したルーティングプロトコルは、TCP/IP 群全体の中でたいへん重要なものです。IP は次の機能を受け持ちます。
IP アドレス指定 - IP アドレス指定の規則は IP プロトコルの一部です (IP アドレス指定については、第 3 章「ネットワークの計画」で詳しく説明します)。
パケット形式設定 - IP は、パケットを IP データグラムと呼ばれる単位に組み立てます。データグラムについては、「インターネット層」で詳しく説明します。
フラグメント化 - パケットが大きすぎてネットワークメディアを介して転送できないときは、送信側ホストの IP は、パケットを小さいフラグメントに分割します。受信側ホストの IP は、これらのフラグメントを組み立てて元のパケットに戻します。
アドレス解決プロトコル (ARP) は、データリンク層とインターネット層の間に概念的に存在するものです。ARP は、イーサネットアドレス (48 ビット長) を既知の IP アドレス (32 ビット長) にマッピングし、IP はこの情報に基づいてデータグラムを正しい受信側ホストに向けることができます。
インターネット制御メッセージプロトコル (ICMP) は、ネットワークエラー条件の検出とその報告を担当するプロトコルです。ICMP は以下の事項について報告します。
第 6 章「TCP/IP の障害追跡」に、エラー検出のために ICMP を使用するオペレーティングシステムコマンドに関する詳細が記載されています。
TCP/IP トランスポート層プロトコルは、パケットが正しい順序でエラーなしに到着するようにするために、データ受領の肯定応答を交換し、失われたパケットがあれば転送しなおします。この種類の通信を「終端間」通信と呼びます。このレベルのトランスポート層プロトコルは、トランスミッションコントロールプロトコル (TCP) とユーザーデータグラムプロトコル (UDP) です。
TCP は、物理的な回線で接続されているのと同じようにしてアプリケーション相互間の通信ができるようにします。TCP は、独立したパケットの形ではなく、文字単位で転送されているような形でデータを送信します。この転送では、まず開始ポイントで接続がオープンされ、次にバイト順序ですべてのデータが転送され、終了ポイントで接続がクローズされます。
TCP は、転送するデータにヘッダーを添付します。このヘッダーには、送信側マシン上のプロセスが受信側マシン上の対等プロセスに接続できるようにするための、多数のパラメータが含まれています。
TCP は、送信側ホストと受信側ホストとの間に終端間接続を確立することにより、パケットが宛先に到達したことを確認します。したがって、TCP は、「信頼性の高い接続指向型」プロトコルとみなすことができます。
もう 1 つのトランスポート層プロトコルである UDP は、データグラム配送サービスを提供します。受信側ホストと送信側ホストとの間で接続が達成されているかどうかを検査する手段は提供しません。UDP は接続の確立と検査を省略するので、少量のデータを送信するアプリケーションにとっては、TCP よりも効率的です。
アプリケーション層は、誰でも使用できる標準的なインターネットサービスとネットワークアプリケーションを定義します。これらのサービスとトランスポート層の両方の働きにより、データの送受信が行われます。アプリケーション層のプロトコルにはさまざまのものがあり、そのうちのいくつかは、すでに使用しているでしょう。以下に、この種のプロトコルの例をいくつか挙げます。
標準 TCP/IP サービス。たとえば、ftp、tftp、telnet コマンドなど
UNIX の "r"(リモート) コマンド。たとえば、 rlogin や rsh など
ネームサービス。たとえば、NIS+ やドメインネームシステム (DNS) など
ファイルサービス。たとえば NFS など
SNMP (ネットワーク管理用プロトコルの一種。Simple Network Mamagement Protocol の略)
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 のシステム管理 (第 1 巻)』に説明があります。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"(リモート) コマンドを使用すると、ユーザーは、指定したリモートホストで実行したいコマンドを、各自のローカルマシンで発行することができます。この種のコマンドには次のものがあります。
rcp
rlogin
rsh
これらのコマンドの使い方については、 『OpenWindows ユーザーズガイド (上級編)』および、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 ManagerTM はその一例です。
TCP/IP ネットワーク用の 2 つのルーティングプロトコルとして、RIP (Routing Information Protocol) と RDISC (Router Discovery Protocol) があります。これらのプロトコルについては、第 5 章「ルーターの構成」で説明します。
ユーザーが TCP/IP アプリケーション層プロトコルを使用するコマンドを発行すると、一連のイベントが発生します。ユーザーのコマンドまたはメッセージは、ローカルマシン上の TCP/IP プロトコルスタックを通過し、ネットワークメディアを通り、受信側のプロトコルに到達します。送信側ホストの各層のプロトコルにより、オリジナルのデータに情報が付加されていきます。
ユーザーのコマンドがプロトコルスタックを通過していくとき、送信側ホストの各層のプロトコルは、受信側ホストのそれぞれの対等プロトコルとの間で対話します。図 2-1 に、この対話がどのように行われるかを示します。
パケットは、ネットワーク上を転送される情報の基本単位で、少なくとも、送信側ホストと受信側ホストのアドレスが入ったヘッダーと、転送するデータが入ったボディーが含まれています。パケットが TCP/IP プロトコルスタックを通過するとき、各層のプロトコルは、基本ヘッダーにフィールドを追加したり、そこからフィールドを削除したりします。送信側ホストのプロトコルがパケットヘッダーにデータを追加する場合、その動作をデータのカプセル化と呼びます。また、変更後のパケットを表す言葉は、図 2-1 に示すように層によって異なります。
この節では、ユーザーがコマンドを発行するかまたはメッセージを送信してから、それを受信側ホストの該当のアプリケーションが受け取るまでの、パケットのライフサイクルを要約して示します。
パケットの履歴は、あるホストのユーザーが、リモートホストへのアクセスを必要とするようなメッセージを送信するかコマンドを発行した時点から始まります。そのコマンドまたはメッセージに関連付けられているアプリケーションプロトコルは、対応する TCP か UDP のどちらかのトランスポート層プロトコルで取り扱えるように、パケットの形式を設定します。
図 2-1 に示したように、ユーザーが、リモートホストにログインするために rlogin コマンドを発行したとします。rlogin コマンドは TCP トランスポート層プロトコルを使用します。TCP は、コマンド内の情報を含むデータをバイトストリーム形式で受け取るものと仮定しています。したがって、rlogin はこのデータを TCP ストリームとして送信します。
しかし、すべてのアプリケーション層プロトコルが TCP を使用するわけではありません。あるユーザーが、リモートホストのファイルシステムをマウントしようとして、NIS+ アプリケーション層プロトコルを開始したとします。NIS+ は UDP トランスポート層プロトコルを使用します。したがって、このコマンドを含むパケットは、UDP が仮定しているような方法に形式化する必要があります。この種類のパケットをメッセージと言います。
データがトランスポート層に到着すると、この層のプロトコルはデータのカプセル化を開始します。最終的な結果は、TCP と UDP のどちらが情報を処理したかによって異なります。
TCP はしばしば「接続指向型」プロトコルと呼ばれますが、これは、このプロトコルが、受信側ホストにデータが正常に到達したかどうかを確認するからです。 図 2-1 に、TCP プロトコルが rlogin コマンドからのストリームをどのように受け取るかを示してあります。TCP は、アプリケーション層から受け取ったデータをセグメントに分割し、各セグメントにヘッダーを添付します。
セグメントヘッダーには、送信側と受信側のポート、セグメント順序に関する情報、検査合計と呼ばれるデータフィールドが含まれています。両方のホストの TCP プロトコルがこの検査合計データを使用して、データがエラーなしに転送されたかどうかを判別します。
TCP は、受信側ホストでデータ受信の準備が整っているかどうかを判別するためにも、セグメントを使用します。送信側 TCP は、接続を確立するために、受信側ホストで実行されている対等 TCP プロトコルに SYN と呼ばれるセグメントを送ります。受信側 TCP は ACK と呼ばれるセグメントを戻して、セグメントを正しく受信したことを知らせます。送信側 TCP は新たな ACK セグメントを送信して、それからデータの送信を開始します。このような制御情報の交換を「3 相ハンドシェーク」と呼びます。
UDP は「コネクションレス」プロトコルです。TCP の場合と異なり、UDP は、受信側ホストにデータが到達したかどうかを確認しません。そのかわりに、UDP は、アプリケーション層から受け取ったメッセージを「UDP パケット」に形式化します。UDP は、各パケットにヘッダーを付加します。ヘッダーには、送信側ホストと受信側ホストのポート、パケットの長さを示すフィールド、検査合計が含まれています。
送信側 UDP プロセスは、受信側ホストの対等 UDP プロセスにパケットを送ろうとします。アプリケーション層は、受信側 UDP プロセスが、パケットを受信したことを示す肯定応答を戻すかどうかを判別します。UDP は受領の通知を必要としません。UDP は 3 相ハンドシェークを使用しません。
図 2-1 に示したように、TCP と UDP はどちらもセグメントとパケットを下位のインターネット層に送り、セグメントとパケットはそこで IP プロトコルにより処理されます。IP は、セグメントとパケットを IP データグラムと呼ばれる単位に形式化して、配送の準備を整えます。次に、IP はデータグラムの IP アドレスを判別して、受信側ホストへの効率的な配送ができるようにします。
IP は、TCP または UDP が付加した情報に付け加える形で、セグメントまたはパケットのヘッダーに「IP ヘッダー」を付加します。IP ヘッダーには、送信側ホストと受信側ホストの IP アドレス、データグラムの長さ、データグラムのシーケンス番号が含まれます。これらの情報が付加されるのは、データグラムがネットワークパケットとしての許容バイトサイズを超過してフラグメント化が必要になった場合に備えるためです。
PPP などのデータリンク層プロトコルは、IP データグラムをフレームの形に形式化します。これらのプロトコルは、第 3 のヘッダーとフッターを付加することにより、データグラムを「フレーミング」します。フレームヘッダーには、フレームがネットワークメディアを通過するときのエラーを検査するための、巡回冗長検査 (CRC) フィールドが含まれています。次に、データリンク層は物理層にフレームを渡します。
送信側ホストの物理ネットワーク層は、フレームを受け取ると、IP アドレスをネットワークメディアに合わせたハードウェアアドレスに変換します。次に、物理ネットワーク層は、フレームをネットワークメディアに送り出します。
受信側ホストに到着したパケットは、送信側ホストのときと逆の順序で TCP/IP プロトコルスタックを通過します。 図 2-1 にこの経路を示してあります。受信側ホストの各プロトコルは、送信側ホストの対等プロトコルがパケットに付加したヘッダー情報を取り除きます。この処理の順序を以下に示します。
物理ネットワーク層はフレーム形式のパケットを受け取ります。パケットの CRC を計算し、データリンク層にフレームを送ります。
データリンク層はフレームの CRC が正しいかどうかを検査し、フレームヘッダーと CRC と取り除きます。最後に、データリンクプロトコルは、インターネット層にフレームを送ります。
インターネット層はヘッダーの情報を読み、転送の種別を識別して、それがフラグメントであるかどうかを判別します。その転送がフラグメントである場合は、IP は、フラグメントを組み立て直して、オリジナルのデータグラムに戻します。そして、IP ヘッダーを取り除いてから、データグラムをトランスポート層プロトコルに渡します。
トランスポート層 (TCP と UDP) はヘッダーを読んで、どのアプリケーション層プロトコルにデータを渡すかを判断します。次に、TCP または UDP は、自分に関連するヘッダーを取り除き、メッセージまたはストリームを受信アプリケーションに送ります。
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』 - この書籍は、インターネットを介して情報を検索するためのさまざまなツールの使用に関心がある方にとって最適です。
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 7 システム管理者セットに含まれる他のマニュアルでも、随所で関連の 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 形式で検索したい場合、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 に電子メールで送ってください。
インターネットは急速に成長しているので、上記に示したアドレスは、本書をお読みになる時点には変更されている場合があります。
この章では、コスト効率のよい整然とした方法でネットワークを構築するために解決しておく必要のある事項について説明します。これらの事項を解決後、ネットワークを設定し引き続き管理するための計画を立てることができます。
まだ TCP/IP の基本事項に慣れていない方は、第 2 章「TCP/IP プロトコル群」を参照してください。
ネットワークのライフサイクルの最初の段階は、ネットワークの設計です。この段階では、まず、組織のニーズを満たす最適のネットワークの種類を決定することから始めます。計画段階で行う決定には、たとえば次のように、ネットワークハードウェアに関連したものがいくつかあります。
ネットワークがサポートするホストマシンの数
使用するネットワークメディアの種類。たとえば、イーサネット、トークンリング、FDDI など
ネットワークトポロジ、すなわちネットワークハードウェアの物理的なレイアウトと接続
ネットワークがサポートするホストの種類。スタンドアロン、ディスクレス、データレス
これらの要因に基づいて、ローカルエリアネットワークのサイズを決定できます。
ネットワークハードウェアの計画については、本書では説明しません。詳細は、ハードウェアに付属しているマニュアルを参照してください。
ハードウェアの計画後は、次に、ソフトウェアに重点を置いたネットワーク計画に着手することができます。
この計画工程では次のような手順が必要になります。
ネットワーク番号を入手し、必要に応じてネットワークドメインを InterNIC に登録します。
IP ネットワーク番号を受け取ったら、ホストに適用する IP アドレス指定スキーマを考えます。
ネットワークを形成するすべてのマシンの IP アドレスとホスト名を含むリストを作成します。これは、ネットワークデータベースの構築の際に利用できます。
ネットワークでどのネームサービスを使用するかを決定します。使用できるのは、NIS、NIS+、DNS、または、ローカルな /etc ディレクトリにあるネットワークデータベースのどれかです。
必要に応じて、管理作業を分担するための区分を設定します。
ネットワークがルーターを必要とするような規模のものかどうかを判断し、必要なら、ルーターをサポートするようなネットワークトポロジを作成します。
必要に応じて、サブネットを設定します。
以下第 3 章「ネットワークの計画」では、上記の要素を念頭に置きながらネットワークの計画を立てる方法について説明します。
サポートを予定しているマシンの数によって、このサイトでのネットワーク設定について、現段階で行ういくつかの決定事項が影響を受けます。組織によっては、1 つの階または 1 つのビルの中にある数十台のスタンドアロンマシンから成る小さいネットワークが必要な場合もあります。また、複数のビルに散在する 1000 以上のホストを持つネットワークの設定が必要な場合もあります。このような大きい配置の場合は、ネットワークをサブネットと呼ばれる小区分に分割することが必要になる場合もあります。予定されているネットワークのサイズは、次の事項に影響を与えます。
適用するネットワーククラス
受け取るネットワーク番号
ネットワークで使用する IP アドレス指定スキーマ
ネットワーク番号を入手し、IP アドレス指定スキーマを確立することは、ネットワーク管理の計画段階において、最も重要な作業の 1 つです。
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 アドレスの 2 バイトを占めています。
IP アドレスのこの部分は、管理者が各ホストに割り当てる番号です。この番号は、ネットワーク内でこのマシンを一意なものとして識別します。ネットワーク上の各ホストについて、アドレスのネットワーク部は同じで、ホスト部はそれぞれ異なる必要があるという点に注意してください。
多数のホストを持つローカルネットワークは、いくつかのサブネットに分割されることがあります。ネットワークをサブネット化することにした場合は、サブネットにサブネット番号を割り当てる必要があります。IP アドレスのホスト番号部の一部のビットをネットワーク識別子として使用することで、IP アドレス空間の有効率を最大限にすることができます。ネットワーク識別子として使用した場合、アドレスの指定した部分がサブネット番号になります。サブネット番号は、ネットマスクを使って作成します。ネットマスクは、IP アドレスのネットワーク部とサブネット部を選択するビットマスクです (詳細は、「ネットワークマスクの作成」を参照してください)。
ネットワーク上での IP アドレス指定に関する計画の第 1 ステップは、最も妥当なネットワーククラスを決定することです。それが済んだら、きわめて重要な第 2 のステップ、つまり InterNIC アドレス指定機関からのネットワーク番号の入手に移ることができます。
現在、TCP/IP ネットワークには 3 つのクラスがあります。32 ビットのアドレス空間は、ネットワーク部のビット数が多かったり少なかったりするなど、クラスによって使い方が異なります。3 つのクラスとは、クラス A、クラス B、クラス C です。
クラス A ネットワーク番号では、IP アドレスの最初の 8 ビットが「ネットワーク部」として使用されます。残りの 24 ビットは、下の 図 3-2 に示すように、IP アドレスのホスト部です。
クラス A ネットワーク番号の最初のバイトに割り当てられる値の範囲は、1 〜 127 です。たとえば、75.4.10.4 という IP アドレスがあるとします。最初のバイトの 75 という値は、このホストがクラス A ネットワーク内にあることを示しています。残りのバイトの 4.10.4 はホストアドレスを形成します。クラス A の番号の場合、InterNIC が割り当てるのは、最初の 1 バイトだけです。残りの 3 バイトをどのように使用するかは、そのネットワーク番号の所有者の自由です。クラス A のネットワークとして存在可能なのは 127 個だけです。この範囲内の各番号が、それぞれ最大 16,777,214 個のホストを収容できます。
クラス B ネットワーク番号では、16 ビットがネットワーク番号に使用され、16 ビットがホスト番号に使用されます。クラス B ネットワーク番号の最初のバイトの値の範囲は、128 〜 191 です。129.144.50.56 の番号の場合、最初の 2 バイトの 129.144 は InterNIC により割り当てられるネットワークアドレスです。残りの 2 バイトの 50.56 はホストアドレスで、これはネットワーク番号の所有者が任意に割り当てることができます。図 3-3 に、クラス B のアドレスを示します。
一般に、クラス B は、多数のホストを備えたネットワークを持つ組織に割り当てられます。
クラス C ネットワーク番号では、24 ビットがネットワーク番号に使用され、8 ビットがホスト番号に使用されます。クラス C ネットワーク番号は、ホスト数が少ない、つまり最大ホスト数が 254 台程度のネットワークに適しています。クラス C ネットワーク番号は、IP アドレスの最初の 3 バイトを占めます。ネットワーク番号の所有者が自由に割り当てることができるのは、4 番目のバイトだけです。図 3-4 に、クラス C アドレスのバイトを示します。
クラス C ネットワーク番号の最初のバイトの値の範囲は、192 〜 223 です。第 2 と第 3 のバイトの値の範囲は、どちらも 1 〜 255 です。典型的なクラス C アドレスは、たとえば 192.5.2.5 のようになります。最初の 3 バイトの 192.5.2 がネットワーク番号です。最後のバイト、つまり 5 がホスト番号です。
所属している組織に複数のネットワーク番号が割り当てられているか、またはサブネットを使用している場合は、組織内でネットワーク番号を割り当てる総括責任者 (人または部門) を指名してください。この責任者が、割り当てられたネットワーク番号のプールを管理する権限を保持し、ネットワーク、サブネット、ホスト番号を必要に応じて割り当てます。問題の発生を避けるために、組織内に重複したネットワーク番号や無秩序なネットワーク番号が生じることのないように注意してください。
ネットワーク番号を受け取ったら、IP アドレスのホスト部をどのように割り当てるかについて、計画を立てることができます。
表 3-1 は、IP アドレス空間がどのようにネットワークアドレス空間とホストアドレス空間に分かれるかを示しています。どのクラスについても、「範囲」の欄は、ネットワーク番号の最初のバイトの 10 進数値の範囲を示しています。「ネットワークアドレス」は、IP アドレスの中でネットワーク部の働きをするバイト数を示し、xxx が 1 バイトを表しています。「ホストアドレス」は、アドレスのホスト部を表すバイト数を示します。たとえばクラス A ネットワークアドレスの場合は、最初の 1 バイトがネットワーク番号で、残りの 3 バイトがホスト番号です。クラス C ネットワークの場合は、この関係が逆になります。
表 3-1 IP アドレス空間の区分
クラス |
範囲 |
ネットワークアドレス |
ホストアドレス |
---|---|---|---|
1 〜 127 |
xxx |
xxx.xxx.xxx |
|
128 〜 191 |
xxx.xxx |
xxx.xxx |
|
192 〜 223 |
xxx.xxx.xxx |
xxx |
IP アドレスの最初のバイトの数値は、ネットワークがクラス A、B、C のどれであるかを示す値で、常に InterNIC が割り当てます。残りの 3 つのバイトの値の範囲は、どれも 0 〜 255 です。番号 0 と 255 は予約されています。ネットワーク管理者は、割り当てられているネットワーク番号に応じて、各バイトに 1 〜 254 の範囲内の番号を指定することができます。
表 3-2 は、IP アドレスのどのバイトがインターネットから割り当てられ、ホストへの割り当てが可能な各バイトにどの範囲の値を指定できるかを示しています。
表 3-2 使用できる番号の範囲
ネットワーククラス |
バイト 1 の範囲 |
バイト 2 の範囲 |
バイト 3 の範囲 |
バイト 4 の範囲 |
---|---|---|---|---|
0 〜 127 |
1 〜 254 |
1 〜 254 |
1 〜 254 |
|
128 〜 191 |
インターネットにより事前割り当て |
1 〜 254 |
1 〜 254 |
|
192 〜 223 |
インターネットにより事前割り当て |
インターネットにより事前割り当て |
1 〜 254 |
「ネットワークインタフェース」 で説明したように、ネットワークに接続するには、コンピュータは少なくとも 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 ネームサービスは、ネットワーク内のいくつかのサーバー上にネットワークデータベースを維持します。これらのネームサービスとそれぞれの設定方法については、『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 は、インターネットのユーザーに以下の情報を提供するための本部組織として、1993 年に創立されました。
インターネットの運営方針
インターネットへのアクセス方法。これには研修サービスも含まれる
インターネットのユーザーが利用できる資源。たとえば、匿名 FTP サーバー、Usenet ユーザーグループなど
InterNIC には、ユーザーが TCP/IP ネットワークを登録する InterNIC Registration Services という組織も含まれています。InterNIC Registration Services は、ネットワークを入手しドメインを登録するためのテンプレートを提供しています。登録については、次の 2 つの点に注意してください。
ネットワークを他の既存の TCP/IP ネットワークに接続する予定がなくても、勝手なネットワーク番号を割り当てることはしないでください。
サブネット番号は InterNIC が割り当てるものではありません。この番号は、割り当てられたネットワーク番号と、ネットワーク管理者が指定する番号を組み合わせたものとなります。これについては、「サブネット化とは」で説明します。
InterNIC Registration Services には次の方法で連絡できます。
郵便
Network Solutions Attn: InterNIC Registration Services 505 Huntmar Park Drive Herndon, Virginia 22070
電話
電話番号は、米国の 703-742-4777 です。電話サービスの利用可能時間は、米国東部標準時で午前 7 時から午後 7 時までです。
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-6 のような場合が考えられます。この例では、ネットワーク 1 とネットワーク 3 が、ルーター R3 により直接接続されています。このような冗長な方法を使用する目的は、信頼性にあります。ネットワーク 2 がダウンしても、ルーター R3 はネットワーク 1 と 3 の間の送信経路を提供することができます。すべてが同じネットワークプロトコルに従っていれば、ネットワークをいくつでも相互接続して、互いに通信させることができます。
ネットワーク上でのルーティングに関する決定は、パケットヘッダーに含まれている受信側 IP アドレスのネットワーク部に基づいて行われます。このアドレスにローカルネットワークのネットワーク番号が含まれている場合は、その IP アドレスを持つホストに直接パケットが送られます。ネットワーク番号がローカルネットワークではない場合は、パケットはローカルネットワーク上のルーターに送られます。
ルーターは、ルーティングテーブル内にルーティング情報を維持します。このテーブルには、ルーターが接続されているネットワーク上のホストとルーターの IP アドレスが含まれています。また、それらのネットワークを指すポインタも含まれています。ルーターは、パケットを受け取ると、ルーティングテーブルを調べて、ヘッダー内の宛先アドレスがテーブルにリストされているかどうかを確認します。テーブルにその宛先アドレスが含まれていない場合は、ルーターは、ルーティングテーブルにリストされている他のルーターにパケットを転送します。ルーターについての詳細は、 第 5 章「ルーターの構成」を参照してください。
図 3-7 は、2 つのルーターにより接続された 3 つのネットワークのネットワークトポロジを示しています。
ルーター R1 は、ネットワーク 192.9.200 とネットワーク 192.9.201 と接続しています。ルーター R2 は、ネットワーク 192.9.201 とネットワーク 192.9.202 を接続しています。ネットワーク 192.9.200 のホスト A がネットワーク 192.9.202 のホスト B にメッセージを送るとすると、その操作は次の手順で行われます。
ホスト A は、ネットワーク 192.9.200 にパケットを送り出します。パケットヘッダーには、受信側ホスト B の IP アドレスである 192.9.202.10 が含まれています。
ネットワーク 192.9.200 には、192.9.202.10 の IP アドレスを持つマシンはありません。したがって、ルーター R1 がパケットを受け取ります。
ルーター R1 は自己のルーティングテーブルを調べます。ネットワーク 192.9.201 には、アドレスが 192.9.202.10 であるマシンはありません。ただし、ルーティングテーブルにはルーター R2 がリストされています。
R1 は「次の中継」ルーターとして R2 を選択し、パケットを R2 に送ります。
R2 はネットワーク 192.9.201 を 192.9.202 に接続しているので、ホスト B に関するルーティング情報を保持しています。そこで、ルーター R2 はパケットをネットワーク 192.9.202 に転送し、ホスト B がそのパケットを受け取ります。
ネットワーク管理の第 2 の段階では、ネットワークを設定します。ここで行う作業は、ネットワークの物理部分を形成するハードウェアの組み立てと、TCP/IP の構成です。この章では、TCP/IP の構成方法を次の事項に分けて説明します。
ネットワーク上の各マシンについてのホスト構成モードの決定
ネットワークのサブネットマスクの設定 (オプション)
ローカルファイルモードで実行されるマシン上での TCP/IP の構成
ネットワーク構成サーバーの構成
ネットワーククライアントモードで実行されるマシン上での TCP/IP の構成
ネットワーク用に選択したネームサービスに基づくネットワークデータベースの編集
ネームサービススイッチファイルの構成
TCP/IP ソフトウェアを構成する前に、以下のことをしておく必要があります。
ネットワーク設計者の場合は、ネットワークトポロジを設計します。(詳細は、「ネットワークトポロジ」を参照してください)。
インターネットのアドレス指定機関からネットワーク番号を入手します。( 「ネットワーククラス」を参照してください)。
設計したトポロジに従ってネットワークハードウェアを組み立て、ハードウェアが動作することを確認します。(ハードウェアのマニュアルと、 「ネットワークトポロジ」を参照してください)。
ネットワークインタフェースとルーターが必要とする構成ソフトウェアがあれば、それを実行します。(ルーターについては、 第 3 章「ネットワークの計画」と第 5 章「ルーターの構成」を参照。購入したネットワークインタフェースをマシンにインストールしてある場合は、ソフトウェア構成要件についてそのインタフェースのマニュアルを参照してください)。
ネットワークに対する IP アドレス指定スキーマの計画を立てます。これには、必要に応じてサブネットアドレス指定も含まれます。(「IP アドレス指定スキーマの設計」を参照してください)。
ネットワークに含まれるすべてのマシンに、IP 番号とホスト名を割り当てます。(「IP アドレス指定スキーマの設計」を参照してください)。
ネットワークでどのネームサービス、つまり NIS、NIS+、DNS、またはローカルファイルのどれを使用するかを決定します。(『Solaris ネーミングの管理』を参照してください)。
必要なら、ネットワークで使用するドメイン名を選択します。(『Solaris ネーミングの管理』を参照してください)。
予定しているネットワーク上の少なくとも 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 のシステム管理 (第 1 巻)』で説明しています。
システムは高い柔軟性を備えているため、すべてをローカルホストモードに構成したり、すべてをネットワーククライアントモードに構成するような、どちらか一方に限定する必要はありません。そのよい例がルーターとサーバーで、これらは常にローカルモードで構成するのが最適です。ホストについては、必要に応じてローカルモードとネットワーククライアントモードを任意に組み合わせて使用できます。
図 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 に示すネットワークにもとづいて説明しています。
ネットワーク上の各マシンは、以下に示す 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 ファイルが少なくとも 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 です。
このファイルにはエントリが 1 つ入っています。それは、ローカルマシンのホスト名です。たとえば、マシン timbuktu では、/etc/nodename ファイルには timbuktu というエントリが入ります。
このファイルにはエントリが 1 つ入っています。それは、ローカルホストのネットワークが属している管理ドメインの完全指定のドメイン名です。ネットワーク管理者は、この名前を Solaris インストールプログラムに指示したり、また後日にこのファイルを編集することができます。
図 4-1 では、ネットワークはドメイン deserts.worldwide に属しており、このドメインは .com ドメインとして分類されています。したがって、/etc/defaultdomain には deserts.worldwide.com というエントリが入ります。ネットワークドメインについての詳細は、『Solaris ネーミングの管理』を参照してください。
このファイルには、直接ネットワークに接続されている各ルーターについてのエントリが入っています。このエントリは、ネットワーク間のルーターとして機能するネットワークインタフェースの名前です。
図 4-1 で、ネットワークインタフェース le1 は、マシン timbuktu をネットワーク 192.9.201 に接続しています。このインタフェースには、timbuktu-201 という一意な名前が付いています。したがって、ネットワーク 192.9.201 にあってローカルファイルモードで構成されているマシンについては、/etc/defaultrouter に timbuktu-201 という名前が エントリとして入ります。
hosts データベースには、ネットワーク上のマシンの IP アドレスとホスト名が入っています。NIS、NIS+、DNS のどれかのネームサービスを使用している場合は、hosts データベースは、ホスト情報用として指定されているデータベースに格納されます。たとえば、NIS+ を実行するネットワークでは、hosts データベースはホストテーブルに格納されます。
ネームサービスとしてローカルファイルを使用している場合は、hosts データベースは /etc/inet/hosts ファイルに格納されます。このファイルには、一次ネットワークインタフェースのホスト名と IP アドレス、マシンに備わっている他のネットワークインタフェース、このマシンが認識している必要がある他のネットワークアドレスが入っています。
BSD ベースのオペレーティングシステムとの互換性を確保するために、/etc/hosts ファイルは /etc/inet/hosts へのシンボリックリンクになっています。
/etc/inet/hosts ファイルには、次のような基本構文を使用します (構文についての詳細は、hosts(4) のマニュアルページを参照してください)。
IP-address hostname [nicknames] [#comment]
IP-address には、ローカルホストが認識する必要のある各インタフェースの IP アドレスが入ります。
hostname には、設定時にマシンに割り当てたホスト名と、ローカルホストが認識しなければならない増設ネットワークインタフェースに割り当てたホスト名が入ります。
[nickname] は、ホストのニックネームが入ります (省略可能)。
[# comment] は、コメントを入れることができます (省略可能)。
Solaris インストールプログラムを実行すると、プログラムは初期 /etc/inet/hosts ファイルを作成します。このファイルには、ローカルホストにとって必要最小限のエントリ (ループバックアドレス、IP アドレス、ホスト名) が入っています。
たとえば、図 4-1 に示したマシン ahaggar については、Solaris インストールプログラムは次のような /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 ファイルです。
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 を、ルーターとして接続します。
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 アドレスを入手します。
ネットワーク構成の一環として 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 ビットをホスト番号用として確保する必要があります。
ネットワークで NIS または NIS+ を実行する場合は、これらのネームサービスを提供するサーバーは netmasks データベースを保持しています。ローカルファイルをネームサービスとして使用するネットワークの場合は、この情報は /etc/inet/netmasks ファイル内に格納されます。
BSD ベースのオペレーティングシステムとの互換性を確保するために、/etc/netmasks ファイルが /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 ファイルに、ネットワーク番号の記号名を入力することもできます。そうすれば、ネットワーク番号の代わりにこれらのネットワーク名を、コマンドへのパラメータとして使用できます。
サブネットを使用していないネットワークをサブネット化するには、次の手順を使用します。
新しいサブネットトポロジについて決定します。これには、ルーターに関する考慮事項や、サブネット上でのホストの位置などが含まれます。
すべてのサブネットアドレスとホストアドレスを割り当てます。
手作業で TCP/IP を構成している場合は、/etc/inet/netmasks ファイルを修正します。そうでない場合は、Solaris インストールプログラムにネットマスクを与えます。
すべてのホストで、新しいホストアドレスを反映するように /etc/inet/hosts ファイルを修正します。
ネットワークデータベースは、ネットワークを構成するために必要な情報を提供するファイルです。ネットワークデータベースには次のものがあります。
hosts
netmasks
ethers
bootparams
protocols
services
networks
構成工程の一環として、ネットワークをサブネット化する場合は、hosts データベースと netmasks データベースを編集します。マシンをネットワーククライアントとして構成するには、bootparams と ethers の 2 つのネットワークデータベースを使用します。残りのデータベースはオペレーティングシステムが使用するもので、編集が必要になることはほとんどありません。
ネットワークデータベースではありませんが、nsswitch.conf ファイルも、関連のネットワークデータベースとともに構成する必要があります。nsswitch.conf は、特定のマシンに、NIS、NIS+、DNS、ローカルファイルのどのネームサービスを使用するかを指定します。
ネットワークデータベースがとる形式は、ネットワーク用として選択するネームサービスの種類によって異なります。たとえば、hosts データベースには、少なくとも、ローカルマシンとそのマシンに直接接続されているネットワークインタフェースのホスト名と IP アドレスだけは入っています。しかし、ネットワークで使用するネームサービスの種類によっては、その他の IP アドレスとホスト名も hosts データベースに入ることがあります。
DNS のブートファイルとデータファイルは、直接的にはネットワークデータベースに対応していません。
図 4-2 に、これらのネームサービスにより使用される hosts データベースの形式を示します。
表 4-1 に、ネットワークデータベースと、各ネットワークデータベースに対応する、ローカルファイル、NIS+ および NIS のネームサービスファイルを示します。
表 4-1 ネットワークデータベースと対応するネームサービスファイル
ネットワークデータベース |
ローカルファイル |
NIS+ のテーブル |
NIS のマップ |
---|---|---|---|
/etc/inet/hosts |
hosts.ord_dir |
hosts.byaddr hosts.byname |
|
/etc/inet/netmasks |
netmasks.ord_dir |
netmasks.byaddr |
|
/etc/ethers |
ethers.ord_dir |
ethers.byname ethers.byaddr |
|
/etc/bootparams |
bootparams.ord_dir |
bootparams |
|
/etc/inet/protocols |
protocols.ord_dir |
protocols.byname protocols.bynumber |
|
/etc/inet/services |
services.ord_dir |
services.byname |
|
/etc/inet/networks |
networks.ord_dir |
networks.byaddr networks.byname |
本書では、ローカルファイルをネームサービスとして使用するネットワークで使用されるものとして、ネットワークデータベースの説明を進めます。hosts データベースに関する情報は、「hosts データベース」を、netmasks データベースに関する情報は、「netmasks データベース」を。NIS、DNS、NIS+ でのネットワークデータベースの対応付けについては、『Solaris ネーミングの管理』を参照してください。
/etc/nsswitch.conf ファイルは、ネットワークデータベースの検索順序を定義します。Solaris インストールプログラムは、インストール中にネットワーク管理者が指定するネームサービスに基づいて、ローカルマシン用のデフォルトの /etc/nsswitch.conf ファイルを作成します。"None" オプションを指定して、ローカルファイルをネームサービスとして使用することを指示した場合は、nsswitch.conf ファイルは例 4-5 のようになります。
# /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 ディレクトリに入っているファイルから、ネットワークデータベース情報のほか、セキュリティと自動マウントに関する情報を入手します。
/etc ディレクトリには、Solaris インストールプログラムが作成した nsswitch.conf ファイルが入っています。そのほかに、次のネームサービス用のテンプレートファイルも入っています。
nsswitch.files
nsswitch.nis
nsswitch.nis+
あるネームサービスから別のネームサービスに変更したい場合は、対応するテンプレートを nsswitch.conf にコピーすることができます。また、nsswitch.conf ファイルを選択的に編集して、個々のデータベースを見つけるために検索するデフォルトのネームサービスを変更することができます。
たとえば、NIS を実行するネットワークでは、ディスクレスクライアントについての nsswitch.conf ファイルの変更が必要な場合があります。bootparams データベースと ethers データベースの検索順序では、最初のオプションとして files、次に nis が指定されている必要があります。例 4-6 に、正しい検索順序を示します。
## /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 データベースには、ネットワーククライアントモードでブートするように構成されているディスクレスのクライアントとマシンが使用する情報が入っています。ネットワーククライアントを持つネットワークの場合は、このデータベースの編集が必要になります。(手順については、「ネットワーククライアントの構成」を参照してください)。このデータベースは、/etc/bootparams ファイルに入力した情報をもとにして構築されます。
このデータベースの構文についての詳細は、bootparams(4) のマニュアルページで説明されています。基本構文は次のとおりです。
machine-name file-key-server-name:pathname
個々のディスクレスまたはネットワーククライアントマシンについて、エントリが 1 つずつあります。各エントリに入っている情報は、クライアント名、キーのリスト、サーバー名、パス名です。
各エントリの最初の項目は、クライアントマシンの名前です。その次は、キー、サーバー名、パス名をタブ文字で区切ったリストです。最初の項目以外は、すべてオプションです。このデータベースには、すべてのクライアントに一致するワイルドカードエントリを含めることができます。次に例を示します。
myclient root=myserver : /nfsroot/myclient ¥ swap=myserver : /nfsswap//myclient ¥ dump=myserver : /nfsdump/myclient |
この例の dump=: は、ダンプファイルを捜さないようにディスクレスホストに指示します。
ディスクレスクライアントをサポートするように bootparams データベースを編集するときには、ほとんどの場合、ワイルドカードエントリを使用する方が便利です。次のようにしてワイルドカードエントリを使用します。
* root=server:/path dump=:
アスタリスク (*) ワイルドカードは、このエントリが、bootparams データベース内で明示的に指定されていないすべてのクライアントに適用されることを示します。
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)。
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 データベースは、/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 ファイルのサンプルを示します。
#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 データベースには、システムにインストールされている TCP/IP プロトコルとそれぞれの番号のリストが入っています。このデータベースは、Solaris インストールプログラムが自動的に作成します。このファイルについて管理作業が必要になることはほとんどありません。
protocols データベースには、システムにインストールされている TCP/IP プロトコルの名前が含まれています。詳しい構文は、protocols(4) マニュアルページに記載されています。例 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 データベースには、TCP サービスと UDP サービスの名前と、それぞれのよく知られているポート番号のリストが入っています。このデータベースは、ネットワークサービスを呼び出すプログラムにより使用されます。Solaris インストールプログラムは、services データベースを自動的に作成します。このデータベースについては、通常は管理作業が必要になることはありません。
詳しい構文は、services(4) のマニュアルページに記載されています。 例 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 Discovery Protocol) や RIP (Routing Information Protocol) などのルーティングプロトコルを実行しない場合だけである。(これらのプロトコルについての詳細は、第 5 章「ルーターの構成」を参照してください)
サブネットマスク (サブネットを持つネットワークの場合に限り必要)
ここでは、ローカル構成ファイルを作成および編集する手順を説明しています。ネームサービスデータベースの処理については、『Solaris ネーミングの管理』を参照してください。
ローカルファイルモードで動作するマシン上の TCP/IP を構成するための手順は、次のとおりです
スーパーユーザーになり、/etc ディレクトリに移動します。
マシンのホスト名を /etc/nodename ファイルに入力します。
たとえば、ホストの名前が tenere であるとすれば、このファイルに tenere と入力します。
各ネットワークインタフェースについて、/etc/hostname.interface という名前のファイルを作成します
(一次ネットワークインタフェースについては、Solaris インストールプログラムが自動的にこのファイルを作成します)。
詳細は、「/etc/hostname.interface ファイル」を参照してください。
/etc/hostname.interface ファイルに、インタフェース IP アドレスかインタフェース名を入力します。
たとえば、hostname.ie1 という名前のファイルを作成し、ホストのインタフェースの IP アドレスかまたはホスト名を入力します。
/etc/inet/hosts ファイルを編集して、以下の内容を追加します。
ローカルマシンに増設したネットワークインタフェースに割り当てた IP アドレスと、各インタフェースのホスト名
一次ネットワークインタフェースとループバックアドレスについてのエントリは、すでに Solaris インストールプログラムにより作成されています。
/usr ファイルシステムを NFS マウントする場合は、ファイルサーバーの IP アドレス
Solaris インストールプログラムは、ローカルマシン用のデフォルトの /etc/inet/host を作成します。このファイルが存在していない場合は、「hosts データベース」の説明に従って作成してください。
完全指定のドメイン名を、/etc/defaultdomain ファイルに入力します。
たとえば、ホスト tenere がドメイン deserts.worldwide.com に所属しているとします。その場合は、/etc/defaultdomain に deserts.worldwide.com を入力します。詳細は、 「/etc/defaultdomain ファイル」を参照してください。
ルーターの名前を、/etc/defaultrouter に入力します。
詳細は、「/etc/defaultrouter ファイル」を参照してください。
デフォルトのルーターの名前とその IP アドレスを、 /etc/inet/hosts に入力します。
上記以外にも、使用できるルーティングオプションがいくつかあります。 「ネットワーククライアントモードの場合のホストの構成方法」中の、ルーティングオプションについての説明を参照してください。これらのオプションは、ローカルファイルモード構成にも適用できます。
ネットワークをサブネット化する場合は、ネットワーク番号とネットマスクを、/etc/inet/netmasks ファイルに入力します。
NIS または NIS+ サーバーを設定してある場合は、サーバーとクライアントが同じネットワーク上にあれば、サーバー上の該当のデータベースにネットマスク情報を入力できます。
いくつかのホストをネットワーククライアントとして構成することを予定している場合は、ネットワーク上のマシンの少なくとも 1 つは、ネットワーク構成サーバーとして構成する必要があります (方法については、 「ネットワーク構成サーバー」を参照してください)。
ネットワーク構成サーバーの設定には、次のような操作が必要です。
ネットワーク構成デーモンが動作するようにします。
in.tftpd
in.rarpd
rpc.bootparamd
構成サーバー上のネットワーク構成ファイルを編集し保守します。
「ネットワーク構成サーバーの設定方法」では、ネットワーク構成サーバーをすでにローカルファイルモード用として設定してあるものとします。
スーパーユーザーになり、予定しているネットワーク構成サーバーのルートディレクトリに移動します。
ディレクトリ /tftpboot を作成することにより、in.tftpd デーモンが動作するようにします。
# mkdir /tftpboot
これで、マシンは、TFTP、bootparams、RARP のサーバーに構成されます。
手順 2. で作成したディレクトリに対するシンボリックリンクを作成します。
# ln -s /tftpboot/. /tftpboot/tftpboot
inetd.conf ファイルにある tftp の行を有効にします。
/etc/inetd.conf のエントリが次のようになっていることを確認してください。
tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
これによって、/tftpboot に格納されたファイル以外のファイルを inettftpd() で検索できなくなります。
hosts データベースを編集して、ネットワーク上のすべてのクライアントのホスト名と IP アドレスを追加します。
ethers データベースを編集して、ネットワーククライアントモードで実行するネットワーク上のすべてのホストについてエントリを作成します。
bootparams データベースを編集します。
「bootparams データベース」を参照してください。ワイルドカードエントリを作成するか、または、ネットワーククライアントモードで実行するすべてのホストについてエントリを作成します。
サーバーをリブートします。
ディスクレスクライアント、インストールサーバー、ブートサーバーを設定する方法については、『Solaris のインストール (上級編)』を参照してください。
ネットワーククライアントは、各自の構成情報をネットワーク構成サーバーから入手します。したがって、あるホストをネットワーククライアントとして構成するときは、このネットワーク用として、ネットワーク構成サーバーが少なくとも 1 つは設定されていることを確認してください。
ネットワーククライアントモードで構成する必要のある各ホストについて、次のことを行います。
スーパーユーザーになります。
ディレクトリを調べて、/etc/nodename ファイルがあるかどうかを確認します。ある場合は、このファイルを削除してください。
/etc/nodename を削除すると、システムは hostconfig プログラムを使用して、ネットワーク構成サーバーから、ホスト名、ドメイン名、ルーターアドレスを入手するようになります。「ネットワーク構成手順」を参照してください。
/etc/hostname.interface ファイルが存在していない場合は、それを作成します。
そのファイルが空であることを確認してください。/etc/hostname.interface ファイルが空であれば、システムはネットワーク構成サーバーから IP アドレスを入手します。
/etc/inet/hosts ファイルに、ループバックネットワークインタフェースのホスト名と IP アドレス以外の内容が入っていないことを確認します。
(「ループバックアドレス」を参照してください)。このファイルには、ローカルマシン (一次ネットワークインタフェース) の IP アドレスとホスト名が入っていてはいけません。
ただし、ディスクレスクライアント (NFS マウントされたルートファイルシステムを持つマシン) の場合は、クライアントのルートファイルシステム (ほとんどの場合ネットワーク構成サーバ) を提供するサーバーの名前と IP アドレスを入力します。
/etc/defaultdomain ファイルがあるかどうかを調べます。ある場合は、このファイルを削除します。
hostconfig プログラムは、自動的にドメイン名を設定します。hostconfig プログラムが設定したドメイン名を上書きしたいときは、/etc/defaultdomain に代わりのドメイン名を入力します。
クライアントの /etc/nsswitch.conf の中の検索パスが、ネットワークのネームサービスの要件を満たしていることを確認します。
ネットワーク上にルーターが 1 つしかなく、ネットワーク構成サーバーが自動的にそのルーターの名前を指定するようにしたい場合は、ネットワーククライアントが /etc/defaultrouter ファイルを持っていないことを確認します。
次の手順に従って、ネットワーク構成サーバーが設定したデフォルトのルーターの名前を上書きします。
ネットワークに複数のルーターがある場合は、ネットワーククライアント上に /etc/defaultrouter を作成し、それを空のままにしておきます。
/etc/defaultrouter を作成し、それを空のままにしておくと、2 つの動的ルーティングプロトコル、つまり、ICMP RDISC (Router Discovery Protocol) か RIP (Routing Information Protocol) のどちらか一方が実行されます。システムは、まず in.rdisc プログラムを実行します。このプログラムは、ルーター検出プロトコルを実行しているルーターを捜します。該当するルーターが見つかった場合は、in.rdisc はそのまま実行を続け、RDISC プロトコルを実行するルーターを追跡し続けます。
RDISC プロトコルに応答しているルーターがないと判断した場合は、システムは RIP を使用し、in.routed デーモンを実行してルーターを追跡します。
各ネットワーククライアントマシン上のファイルを編集し終わったら、ネットワーク構成サーバーで次の作業を行います。
bootparams データベースにそのホストのエントリを追加します。
操作を簡単にするために、bootparams データベースには、各ホストのエントリを個別に入力する代わりに、ワイルドカードを入力することができます。その例については、「bootparams データベース」を参照してください。
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 ネーミングの設定と構成』を参照してください。
以下の情報は参考用です。ネットワークのブート処理の概要を示しています。構成時にどのようなことが起こるかを全体的にとらえるのに役立ちます。
起動スクリプトの名前は、Solaris リリースごとに変更されることがあります。
ホストでオペレーティングシステムを起動します。
カーネルが、ブート処理の一部として /sbin/init を実行します。
/sbin/init が、/etc/rcS.d/S30rootusr.sh 起動スクリプトを実行します。
/etc/rcS.d/S30rootusr.sh 起動スクリプトが、ディスクレスとデータレスの操作のための最小限のホスト構成とネットワーク構成の確立など、いくつかのシステム起動処理を行います。また、このスクリプトは、/usr ファイルシステムをマウントします。
ローカルデータベースファイルに、必要な構成情報 (ホスト名と IP アドレス) が含まれている場合は、スクリプトはそれを使用します。
ローカルホスト構成ファイル内に必要な情報がない場合は、/etc/rcS.d/S30rootusr.sh は、RARP を使用してホストの IP アドレスを入手します。
ドメイン名、ホスト名、デフォルトのルーターアドレスがローカルファイルに含まれている場合は、マシンはそれらを使用します。ローカルファイルに構成情報が含まれていない場合は、システムは bootparams プロトコルを使用して、ホスト名、ドメイン名、デフォルトのルーターアドレスを入手します。必要な情報が、ホストと同じネットワーク上にあるネットワーク構成サーバーから入手可能でなければなりません。これは、この時点ではまだインターネットワーク通信が存在していないからです。
/etc/rcS.d/S30rootusr.sh が作業を完了し、その他のいくつかのブート手続きが実行されると、次に /etc/rc2.d/S69inet が実行されます。このスクリプトは、ネームサービス (NIS、NIS+、または DNS) の開始の前に完了しておく必要のある起動作業を実行します。これらの作業には、IP の構成、ドメイン名のルーティングと設定などがあります。
S69inet の作業が完了すると、/etc/rc2.d/S71rpc が実行されます。このスクリプトは、NIS、NIS+、DNS のどれかのネームサービスを起動します。
/etc/rc2.d/S71rpc の実行の後で、/etc/rc2.d/S72inetsvc が実行されます。このスクリプトは、ネームサービスの存在の有無に応じて異なるサービスを起動します。S72inetsvc は inetd デーモンも起動します。このデーモンは、telnet などのユーザーサービスを管理します。
ブート処理についての詳細は、『Solaris のシステム管理 (第 1 巻)』を参照してください。
この章では、ルーティングプロトコルについて説明し、特に TCP/IP ネットワーク上にルーターを構成するための手順を示します。ルーターとは、複数のネットワークインタフェースを持ち、1 つのネットワークから別のネットワークへとパケットを送信するマシンです。最も一般的なルーターの種類としては、カードスロットに増設ネットワークインタフェースを持つコンピュータと、各種のメーカーから販売されている専用ルーターの 2 種類があります。
この章では、ルーティングの原理については説明していません。ルーティングの原理については、「ネットワークトポロジ」で説明されています。また、「ルーターがどのようにパケットを転送するか」には、ルーティングに関する基本事項の説明があります。サブネットの作成方法については、「netmasks データベース」を参照してください。
Solaris オペレーティングシステムは 2 つのルーティングプロトコルをサポートしています。それは、RIP (Routing Information Protocol) と ICMP RDISC (Router Discovery Protocol) です。RIP と RDISC は、どちらも標準 TCP/IP プロトコルです。
RIP はルーティングデーモン in.routed により実現されるもので、このデーモンはマシンのブート時に自動的に起動されます。s オプションを指定した in.routed をルーターで実行すると、in.routed は、到達可能なすべてのネットワークへの送信経路をカーネルルーティングテーブルに組み入れ、すべてのネットワークインタフェースを経由する「到達可能性」を通知します。
q オプションを指定した in.routed をホストで実行した場合は、in.routed はルーティング情報を抽出しますが、到達可能性は通知しません。ホストでは、ルーティング情報は次の 2 つの方法で抽出できます。
S フラグ (大文字の S は「スペース節約モード」) を指定しない場合、in.routed は、ルーターで実行したときと同様にフルルーティングテーブルを作成します。
S フラグを指定すると、in.routed は、使用可能な各ルーターについてデフォルトの送信経路を 1 つずつ示す最小核テーブルを作成します。
ホストは、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 アドレスを持つことになります。
ルーターとして構成したいマシンでスーパーユーザーになり、次のようにします。
インストールされている各ネットワークインタフェースについて、/etc/hostname.interface ファイルを作成します。
たとえば、hostname.ie0 と hostname.ie1 を作成します (詳細は、「/etc/hostname.interface ファイル」を参照してください)。
対応するインタフェース用として選択したホスト名を各ファイルに入力します。
たとえば、hostname.ie0 ファイルに timbuktu という名前を入力し、hostname.ie1 ファイルに timbuktu-201という名前を入力します。どちらのインタフェースも同じマシンに置かれることになります。
各インタフェースのホスト名と 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 インタフェースに接続されるからです。
サブネット化したネットワークにルーターを接続する場合は、/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 は、複数のネットワークインタフェースを持つマシンのすべてをルーターとみなすので、それをマルチホームホストに変えるには、いくつかの操作が必要になります。
マルチホームホストにしたいマシンでスーパーユーザーになり、次のことを行います。
マシンにインストールされている追加の各ネットワークについて、/etc/hostname.interface ファイルを 1 つずつ作成します。
次のようにタイプします。
% touch /etc/notrouter
これで、/etc/notrouter と呼ばれる空のファイルが作成されます。
マシンをリブートします。
マシンをリブートすると、起動スクリプトは /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
ルーターの信頼性に関連した理由により、ホストに RDISC を使用させたくない場合があります。RDISC を止めるには、ホストの /usr/sbin/in.rdisc の名前を、何か別の名前、たとえば /usr/sbin/in.rdisc.saved に変更し、ホストをリブートします。
ホストにおいて、RDISC ではなく RIP の自動選択が確実に動作する場合は、ネットワーク内のルーター (特に RDISC を実行するもの) でも確実に動作しなければなりません。
RDISC を実行するルーターがほかにないときに、Solaris ルーターを 1 つインストールすると、デフォルトにより、そのルーターに接続されるすべてのホストがそのルーターだけに依存することになります。そのネットワーク上のホストが他のルーターも使用できるようにするには、新しいルーターで RDISC をオフにします。そのためには、そのルーターの /usr/bin/in.rdisc ファイルの名前を別の名前に変更し、ルーターをリブートします。
この章では、TCP/IP ネットワークの一般的な障害追跡の方法と、そのために使用できるツール (ping、ifconfig、netstat、route など) について説明します。
ネットワーク上での問題を示す最初の徴候は、1 つまたはいくつかのホストでの通信の消滅です。あるホストを初めてネットワークに追加したときに、そのホストがまったく動作しない場合は、構成ファイルのどれか、またはネットワークインタフェースに問題があることが考えられます。1 つのホストに突然問題が生じた場合は、ネットワークインタフェースに原因があると考えられます。ネットワーク上のホスト相互間の通信はできるが、他のネットワークとの通信ができないという場合は、ルーターに問題があるか、または他のネットワークに問題があることが考えられます。
ifconfig プログラムを使用すればネットワークインタフェースに関する情報を入手でき、netstat を使用すればルーティングテーブルとプロトコル統計を表示できます。サードパーティのネットワーク診断プログラムから、さまざまな障害追跡ユーティリティが提供されています。詳細は、サードパーティのマニュアルを参照してください。
比較的明らかになりにくいのは、ネットワーク上でのパフォーマンス低下の原因です。たとえば、ping のようなツールを使用することで、ホストでのパケットの消失など、問題の原因を突き止めることができます。
ネットワークに障害が生じた場合は、以下のような処置によって、ソフトウェア関連の問題を診断し修正することができます。
RARP を実行している場合は、 ethers データベース内のイーサネットアドレスを検査して、個々のエントリが適正で最新であるかどうかを確認します。
telnet によりローカルホストに接続してみます。
ネットワークデーモン 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 コマンドは、特定のホストとの 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(1M) のマニュアルページを参照してください。ifconfig の構文は次のとおりです。
ifconfig interface-name [protocol_family]
特定のインタフェース、たとえば le0 に関する情報を表示したい場合は、次のように入力します。
$ ifconfig 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 |
特権 (root) ユーザーが ifconfig コマンドを発行した場合は、上記のようにマシンのアドレスが出力に表示されます。
実行されていないインタフェースがあることが出力に示されている場合は、そのインタフェースに問題があると考えられます。その場合は、ifconfig(1M) のマニュアルページを参照してください。
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 で説明しています。これを参照するには、Web ブラウザで http://ds.internic.net/rfc/rfc1761.txt にアクセスしてください。
snoop server client rpc rstatd は、クライアント/サーバー間のすべての RPC トラフィックを収集し、rstatd に対するフィルタをかけます。
netstat -i と入力し、システムに接続されたインタフェースを検索します。
通常、snoop では最初の非ループバックデバイス (le0) が使用されます。
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 ?
結果を解釈します。
上記の例では、クライアント maupiti からサーバー atlantic-82 への転送には NFS ファイルハンドル 0343 が使用され、atlantic-82 は OK と応答しています。who is 129.146.82.36? と問い合わせる ARP 要求が maupiti から伝送されるまで、会話は継続します。
この例は、snoop の形式を説明しています。次の手順では、snoop にフィルタをかけてファイルにパケットを取り込みます。
取り込んだファイルを解釈するには、RFC 1761 に記述された説明を使用します。これを参照するには、Web ブラウザで http://ds.internic.net/rfc/rfc1761.txt にアクセスします。
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 を実行してください (次の節を参照)。
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 の確認には、Webを検索することをお奨めします。
snoop を実行するシステムから、クライアントまたはサーバーに接続されたハブのいずれかを外します。
この第 3 のシステム (snoop システム) はすべてのトラフィックを監視するので、snoop のトレースには実際のネットワーク上の状態が反映されます。
root になって snoop をオプション付きで実行し、結果をファイルに保存します。
結果の検査と解釈を行います。
snoop 取り込みファイルの詳細については、RFC 1761 を参照してください。これを参照するには、Web ブラウザで http://ds.internic.net/rfc/rfc1761.txt にアクセスします。
頻繁かつ定期的に snoop を使用して、システムが正常に動作している場合の状態を把握してください。最近の白書や RFC を参照したり、NFS や YP といった特定分野の専門家からアドバイスを受けるのも、パケットの分析に役立ちます。snoop とそのオプションの使用法についての詳細は、snoop(1M) のマニュアルページを参照してください。
traceroute ユーティリティは、IP パケットが特定のインターネットホストに至るまでのルートを追跡する際に使用します。traceroute ユーティリティは、IP プロトコルの ttl (time to live) フィールドを利用して、経路に沿った各ゲートウェイからの ICMP TIME_EXCEEDED 応答と、宛先ホストからの応答 PORT_UNREACHABLE (または、ECHO_REPLY) の受信を試みます。traceroute ユーティリティは、ttl を 1 にしてプローブの送信を開始し、プローブが目的のホストに到達するか、最大数の中間ホストを通過するまで ttl を 1 ずつ増加します。
traceroute ユーティリティは、ルーティングの誤設定やルーティング経路の障害を判定する場合に特に役立ちます。特定のホストが到達不可能な場合には、traceroute ユーティリティ を使用して、パケットがどの経路をたどって目的のホストに到達し、どこで障害が起きる可能性があるかを調べることができます。
また、traceroute ユーティリティは、経路に沿った各ゲートウェイの宛先ホストとの間の往復時間も表示します。この情報は、2 つのホスト間のどこでトラフィックが遅くなっているかを分析する際に利用することができます。
以下のコマンドを入力するのが、traceroute ユーティリティを実行する最も簡単な方法です。
traceroute hostname |
以下の traceroute コマンドの例では、パケットがホスト istanbul から ホスト sanfrancisco までにたどる 7 つの経路と、パケットが各経路を通過する時間が表示されています。
istanbul% traceroute sanfrancisco traceroute: Warning: Multiple interfaces found; using 172.31.86.247 @ le0 traceroute to sanfrancisco (172.29.64.39), 30 hops max, 40 byte packets 1 frbldg7c-86 (172.31.86.1) 1.516 ms 1.283 ms 1.362 ms 2 bldg1a-001 (172.31.1.211) 2.277 ms 1.773 ms 2.186 ms 3 bldg4-bldg1 (172.30.4.42) 1.978 ms 1.986 ms 13.996 ms 4 bldg6-bldg4 (172.30.4.49) 2.655 ms 3.042 ms 2.344 ms 5 ferbldg11a-001 (172.29.1.236) 2.636 ms 3.432 ms 3.830 ms 6 frbldg12b-153 (172.29.153.72) 3.452 ms 3.146 ms 2.962 ms 7 sanfrancisco (172.29.64.39) 3.430 ms 3.312 ms 3.451 ms |
traceroute ユーティリティについての詳細は、traceroute(1M) のマニュアルページを参照してください。