Part 2 では、ネットワーク上で非同期 PPP 通信リンクを設定し管理する方法について説明します。この章の説明は、読者が、TCP/IP に関する十分な知識を持つ熟練したネットワーク管理者であることを前提としています。
この章では、TCP/IP プロトコル群に含まれているデータリンクプロトコルの 1 つである Solaris PPP の概要を示します。プロダクトの仕様、最も典型的な PPP 構成の紹介、PPP に関連した用語を収めてあります。
PPP を用いれば、モデムと電話回線を使って、物理的に離れた場所にあるコンピュータとネットワークを接続できます。ユーザは、PPP を使って、自宅からも職場からも、所属するサイトのネットワークに接続できます。また、PPP ソフトウェア、モデム、電話回線を組み合わせて、別々の場所にあるネットワーク同士を結ぶルータとして使用することもできます。PPP は、このようなマシンとネットワークを構成するための方法を提供します。この章ではその方法を紹介します。
Solaris PPP は、標準化されたデータリンクレベルのポイントツーポイントプロトコル (PPP) の非同期実装の 1 つです。PPP は TCP/IP プロトコル群に含まれているもので、多くのルータシステムのベンダや端末集線装置から提供されています。Solaris PPP には標準化されたカプセル化プロトコルが組み込まれているので、ネットワーク層プロトコルにとってデータグラムの転送が透過的なものとなります。
Solaris PPP の主な特性には次のものがあります。
RFC 1331 で定義されているインターネットポイントツーポイントプロトコルを実装
CRC を用いたエラー検出機能を提供
全二重伝送をサポート
このプロトコルの主な機能には次のものがあります。
IP が非同期シリアル回線を介してパケットを転送するためのインタフェース
要求時の接続確立
構成可能オプションのネゴシエーション
接続の切断 (自動ハングアップ)
PPP は、Solaris ソフトウェアを実行するほとんどのマシンに備わっている CPU シリアルポートを使用した、RS-232-C(V.24) インタフェースをサポートします。さらに、PPP は、Solaris ソフトウェアを実行するマシンの製造元の多くが提供またはサポートしている、オプションの非同期シリアルポートでも動作します。PPP は、使用するマシンのシリアルポートで使用可能な最大のデータ速度をサポートします。マシンのシリアルハードウェアがサポートしている速度については、コンピュータシステムの製造元にお尋ねください。
x86 アーキテクチャのマシンには、一定の速度以上で実行される UART が必要です。詳細は、『Solaris 2.6 情報ライブラリ (Intel 版)』の「デバイスの構成」を参照してください。
PPP と、Solaris ソフトウェアに組み込まれているルーティング機能は、業界標準の規格に従って動作します。この規格は次のような機能をサポートしています。
IP データグラムを転送する
転送するパケットを IP 互換にネットワーク化されたシステムから受け取る
ローカルエリアネットワークメディア、たとえばイーサネット、トークンリング、FDDI などにを使って IP 互換にネットワーク化されたシステムにパケットを配送する
標準化されたルーティングプロトコルを使用しているため、ユーザは、多数の製造元が提供する PPP プロトコルをサポートする装置との間でパケットを交換できる
PPP を用いると、モデムなどのような非同期デバイスをネットワークインタフェースとして使用できるようになります。Solaris PPP では、2 つの仮想ネットワークインタフェース ipdptpn と ipdn を構成できます (n は、インタフェースに割り当てるデバイス番号です)。
PPP ネットワークインタフェースは、仮想ネットワークインタフェースとみなされます。なぜなら、イーサネットインタフェースなどのようにネットワークハードウェアを含んでいないからです。さらに、PPP ネットワークインタフェースは特定のシリアルポートに関連付けられるものでもありません。PPP ネットワークインタフェースは、物理ネットワークインタフェースとともに /devices ディレクトリに入っています (物理ネットワークインタフェースについては、「ネットワークインタフェース」を参照してください)。
使用するネットワークインタフェースの種類は、設定したい PPP 通信リンクによって異なります。ipdptp インタフェースは、ポイントツーポイント PPP リンクをサポートしています。ipd インタフェースは、ポイントツーマルチポイントリンク (「マルチポイントリンク」と呼ばれる) をサポートしています。
この節では、PPP に関する通信概念を紹介します。また、最も一般的な PPP 構成についても説明します。
Solaris PPP の最も一般的な使用目的は、ポイントツーポイント通信リンクを設定することです。一般的なポイントツーポイント通信構成は、2 つのエンドポイントを通信リンクで接続したものです。この一般構成では、エンドポイントシステムはコンピュータでも端末でもよく、切り離された状態でも、ネットワークに物理的に接続していてもかまいません。通信リンクという用語は、2 つのエンドポイントシステムを接続するハードウェアとソフトウェアを指します。図 7-1 にこの概念を示します。
一方のエンドポイントが通信リンクの反対側のエンドポイントとの通信を望むとき、そのエンドポイントはダイヤルアウト操作を開始します。たとえば、エンドポイント B と通信する場合、その対等ホストであるエンドポイント A のユーザは、rlogin end-point-B と入力します。すると、エンドポイント A は通信リンクを介してダイヤルアウトします。この場合、エンドポイント A はダイヤルアウトマシンとして働くことになります。rlogin コマンドは、モデムがエンドポイント B の電話番号をダイヤルすることを引き起こします。このコマンドが起動する動作と相手に渡す情報を、アウトバウンド通信と言います。
データが通信リンクを介してエンドポイント B に到達すると、エンドポイント B のシステムは着信データを受け取り、肯定応答信号をエンドポイント A に送って、通信を確立します。この場合、エンドポイント B は他のシステムからのダイヤルインを受け入れるので、ダイヤルインマシンとして働くことになります。通信の受信側に渡される情報と受信側が行う動作を、インバウンド通信と言います。
Solaris PPP は、次の 4 つの種類のポイントツーポイント構成をサポートしています。
ある場所のホストを、物理的に異なる場所にある別のホストに接続した構成 (図 7-1)
ダイヤルインサーバとリモートホストを動的ポイントツーポイントリンクで接続した構成 (図 7-2)
ネットワークを、物理的に離れた場所にある別のネットワークに接続した構成 (図 7-3)
コンピュータを、離れた場所にあるネットワークに物理的に接続されているマルチポイントダイヤルインサーバに接続したもの (図 7-4)
PPP リンクは、実質的にはローカルエリアネットワークと同じ種類の接続を提供しますが、ブロードキャスト機能だけはありません。以下の各節では、上記の構成タイプをそれぞれ簡単に説明します。各構成タイプの設定方法については、第 8 章「PPP 構成の準備」で説明します。
PPP を使用すると、異なる場所にある 2 つのスタンドアロンマシンを接続するポイントツーポイントリンクを設定できます。これにより、事実上、この 2 つのマシンだけからなるネットワークが作成されることになります。これはエンドポイントが 2 つしかなく、したがって最も単純なポイントツーポイント構成と言えます。図 7-1 に示した一般構成でも、このホストツーホスト構成が使われています。
従来は、標準的なダイヤル呼び出し接続または一時接続の場合、ネットワークに接続できるのは ASCII 端末だけでした。Solaris PPP を用いれば、個々のマシンを PPP リンクの 1 つのエンドポイントとして構成することによって、それらのマシンを物理的に離れた場所にあるネットワークの一部とすることができます。この可搬接続は、頻繁に旅行するユーザや在宅勤務のユーザを含むネットワークの場合に、特に便利です。
図 7-2 に示す可搬コンピュータは、それぞれネットワーク上のエンドポイントシステムへのポイントツーポイントリンクを持っています。ネットワーク上のエンドポイントシステムを、ダイヤルインサーバと言います。
図 7-2 に示したネットワークのエンドポイントマシンは、動的ポイントツーポイントリンクを持つダイヤルインサーバとして働きます。これをダイヤルインサーバと呼ぶのは、リモートマシンがこのマシンにダイヤルインすることによってネットワークに入ることができるからです。サーバは、あるマシンからダイヤルインの要求を受け取ると、必要時提供の方式でそのマシンに PPP リンクを割り当てます。
ダイヤルインサーバは、動的ポイントツーポイントリンクまたはマルチポイントリンクを介してリモートホストと通信します。マルチポイントリンクについては、「マルチポイント通信リンク」で説明します。動的ポイントツーポイントには、ポイントツーポイント通信と同じ利点があります。つまり、リンク上で RIP を実行でき、ブロードキャストが使用可能になります。最も重要なのは、物理ネットワーク上の複数のマシンが、ダイヤルインサーバとして働くことができるという点です。これはバックアップサーバを構成できることを意味し、したがってサーバの重複が可能となり、管理が容易になります。図 7-2 の各マシンはネットワークエンドポイントとは直接通信できますが、互いに直接通信することはできません。ダイヤルインサーバエンドポイントを仲介として、相互に情報を受け渡しする必要があります。
PPP を使用すると、2 つのネットワークをポイントツーポイントリンクで接続し、各ネットワーク上の 1 つのシステムをエンドポイントとして働かせることができます。これらのエンドポイントは、図 7-1 に示したのと実質的に同じ方法で、モデムと電話回線を使って互いに通信します。ただし、この設定では、エンドポイント、モデム、PPP ソフトウェアは、各物理ネットワークのルータとして働きます。この種類の構成方式を使用して、地理的に広い範囲にわたるインターネットワークを構築できます。
図 7-3 は、異なる場所にある 2 つのネットワークをポイントツーポイントリンクで接続した構成を示しています。
この例では、エンドポイント A と B、それぞれのモデム、公衆電話回線、そして PPP ソフトウェアが、ネットワーク間のルータとして働きます。これらのネットワークには、物理ネットワーク間のルータとして働く別のホストが存在することもあります。また、PPP ルータとして働くホストが追加のネットワークインタフェースボードを備えていて、同時に物理ネットワークのルータとして働く場合もあります。
Solaris PPP を使用して、マルチポイント通信リンクを設定できます。この種類の構成では、それぞれ個々のマシンが通信リンク上の 1 つのエンドポイントとして働きます。リンクの 1 つの端に複数のエンドポイントマシンが存在する場合もあります。これは、通信リンクの両端に 1 つずつしかエンドポイントがないポイントツーポイント構成とは異なります。
PPP によって構成できるマルチポイントリンクには、次の 2 つの種類があります。
以下の各節では、これらの構成の概略を説明します。各構成の設定方法については、第 8 章「PPP 構成の準備」で説明します。
図 7-4 では、地理的に離れた場所にある 3 台のコンピュータが、ネットワーク上のエンドポイントマシンへのポイントツーポイントリンクを介して、互いに通信します。しかし、ネットワークエンドポイントマシンは、マルチポイントリンクを介して可搬コンピュータと通信できるので、このマシンはマルチポイントダイヤルインサーバとみなすことができます (「動的ポイントツーポイントリンクを持つダイヤルインサーバ」で説明したように、動的ポイントツーポイント接続を持つダイヤルインサーバも設定できます)。
ダイヤルインサーバは、マルチポイント PPP リンクの反対側にあるすべてのマシンと通信できます。図 7-4 の各マシンはマルチポイントダイヤルインサーバとは直接通信できますが、互いに直接通信することはできません。各マシンは、ダイヤルインサーバを介して、互いに情報を受け渡しする必要があります。
PPP を使用して仮想ネットワークを設定できます。この設定では、モデム、PPP ソフトウェア、電話回線が、「仮想」ネットワークメディアとなります。イーサネットやトークンリングなどの物理ネットワークでは、コンピュータはケーブルで直接ネットワークメディアに接続されています。仮想ネットワークでは、現実のネットワークメディアは存在しません。
仮想ネットワーク上で各マシンをマルチポイント通信リンクにより接続した場合、マシンはどれも対等ホストとなります。各ホストは、モデムと電話回線を介して、他のエンドポイントマシンと通信できます。各コンピュータはダイヤルインマシンとしても働くので、仮想ネットワーク上の対等ホストからのダイヤルインを受け入れることができます。
図 7-5 は、モデムと電話回線によって相互に接続されている可搬コンピュータからなる仮想ネットワークを示しています。
各マシンは、それぞれ、仮想ネットワーク上の他のメンバから離れた場所にある別々のオフィスに存在しています。しかし、各マシンは、マルチポイント通信リンクを介して、他の対等ホストとの通信を確立できます。
PPP のコンポーネントソフトウェアには以下のものがあります。
リンクマネージャ (/usr/sbin/aspppd)
ログインサービス (/usr/sbin/aspppls)
構成ファイル (/etc/asppp.cf)
ログファイル (/var/adm/log/asppp.log)
FIFO ファイル (/tmp/.asppp.fifo)
PPP ソフトウェアのインストールが終わると、PPP 用の実行制御スクリプトである /etc/init.d/asppp ファイルが作成されています。このファイルは、実行制御ディレクトリ内の他のいくつかのファイルにリンクしています。
図 7-6 に、PPP の各ソフトウェアコンポーネントと、それぞれの相互作用を示します。
/usr/sbin/aspppd リンクマネージャは、ユーザレベルのデーモンで、PPP サービスが必要となったときのリモートホストへの接続プロセスを自動化します。この自動化されたプロセスは、IP トラフィックを生じさせるようななんらかの動作が生じるたびに起動されます (たとえば、ユーザがリモートマシンにログインしたり、NFS によりマウントされたファイルにアクセスしたりした場合)。リモートホストが接続を確立しようとすると、ローカルホストのリンクマネージャが接続を完了します。
リンクマネージャに関する個別の情報については、aspppd(1M) のマニュアルページを参照してください。
/usr/sbin/aspppls ログインサービスは、ユーザがダイヤル呼び出しし、ログインした後で、PPP を起動するログインシェルとして呼び出されます。このログインサービスの機能は、「UUCP を構成するソフトウェア」で説明する /usr/lib/uucp/uucico コマンドに似ています。マシンをダイヤルインサーバとして構成するときは、ローカルホストへのダイヤルインが許されているすべての可搬コンピュータについて、/etc/passwd ファイルの中の対応するエントリのログインシェルに aspppls を指定する必要があります。
asppp.cf ファイルは、ローカルホストの通信相手の各リモートエンドポイントに関する情報を、リンクマネージャに与えます。この情報は、構成ファイル内の path というセクションに定義します。また、path セクションは、使用する PPP インタフェースを定義し、さらにオプションとして、通信をどのように行うかについてのその他の属性 (セキュリティに関する事項など) も定義します。asppp.cf ファイルの各セクションについては、「基本構成ファイルの各部分」で詳しく説明します。例 7-1 は、変更されていない asppp.cf ファイルを示します。
#ident "@(#)asppp.cf 10 93/07/07 SMI" # # Copyright (c) 1993 by Sun Microsystems, Inc. # # Sample asynchronous PPP /etc/asppp.cf file # # ifconfig ipdptp0 plumb mojave gobi private up path inactivity_timeout 120 # Approx. 2 minutes interface ipdptp0 peer_system_name Pgobi # The name this system logs in with when # it dials this server # *OR* the entry we look up in # /etc/uucp/Systems when we dial out. |
リンクマネージャは、メッセージを生成し、ログファイル /var/adm/log/asppp.log に記録します。このファイルに記録される詳細さのレベルは、aspppd の -d オプションか、構成ファイル内の debug_level キーワードにより制御されます。詳細については、「構成キーワード」と、aspppd(1M) のマニュアルページを参照してください。
PPP FIFO ファイル /tmp/.asppp.fifo は、aspppd と aspppls の間の通信に用いる名前付きパイプです。PPP ログインサービスがリンクマネージャに接続するためには、このファイルが /tmp に入っていなければなりません。/tmp/.asppp.fifo ファイルは、リンクマネージャが作成し、管理し、削除します。
Solaris PPP は、コンポーネントソフトウェアのほかに、/etc/uucp/Systems、/etc/uucp/Dialers、/etc/uucp/Devices の 3 つの UUCP ファイルを利用して、通信リンクを確立します。ホストが PPP リンクを介してダイヤルアウトできるようにするには、これらのファイルを修正する必要があります。あるいは、/etc/uucp/Sysfiles を使用して、Systems、Devices、Dialers ファイルに別の名前を指定することもできます。
これらの UUCP ファイルの詳しい説明については、第 12 章「UUCP のデータベースとプログラム」を参照してください。
この節では、PPP の各種コンポーネントが、アウトバウンド接続とインバウンド接続についてどのような働きをするかを説明します。
PPP リンクの 1 つのエンドポイントのユーザが、反対側のエンドポイントにある対等ホストの参加を必要とする活動を開始すると、アウトバウンド通信が始まります。ユーザが rcp コマンドを入力して、リンクの反対側のホストからファイルをコピーしようとしたとすると、以下に示すような動作が生じます。
rcp は、TCP/IP プロトコルスタックの各レベルを通してデータを送り出す。
仮想ネットワークインタフェース (ipdn または ipdptpn) が、IP パケットの形式でデータを受け取る。
インタフェースは、アウトバウンド接続を開始するための接続要求を、aspppd リンクマネージャに送リ出す。
リンクマネージャは以下のことを行う。
接続要求が、/etc/asppp.cf 構成ファイル中で構成されているパスに対応していることを確認する。
UUCP データベースファイル (/etc/uucp/Systems、/etc/uucp/Devices、/etc/uucp/Dialers) を調べて、モデムと宛先システムに関する必要な情報を入手する。
宛先ホストへの電話呼び出しをかけるか、適切な直結シリアル回線に接続する。
対等ホストへの物理リンクが確立される。
リンクマネージャは PPP を構成して開始する。
データリンク層が確立され、対等ホスト上の PPP モジュールが通信を開始する。
リンクマネージャはリンクを介した IP を使用可能にする。
その後、リンクマネージャは、アイドルタイムアウト、回線の切断、エラー条件などのイベントが発生するまで、接続を監視します。これらのイベントのどれかが発生すると、リンクマネージャは対等ホストとの接続を切り離し、アイドル状態に戻ります。
インバウンド通信を開始するホストがログインすると、/usr/sbin/aspppls ログインサービスが呼び出されます。そして以下のイベントが生じます。
ログインサービスは、/tmp/.asppp.fifo ファイルを通してリンクマネージャに接続する。
ログインサービスは、リンクの反対側のエンドポイントで使用するログイン名などの情報を、リンクマネージャに提供する。
リンクマネージャはこのログイン名を使って、対応する構成済みのパスを、構成ファイルの中から見つける。
リンクマネージャは、PPP を構成し起動する。
データリンク層が確立され、対等ホスト上の PPP モジュールが通信を開始する。
リンクマネージャはリンクを介した IP を使用可能にする。
その後、リンクマネージャは、アイドルタイムアウト、回線の切断、エラー条件などのイベントが発生するまで、接続を監視します。これらのイベントのどれかが発生すると、リンクマネージャは対等ホストとの接続を切り離し、アイドル状態に戻ります。
構成に含まれているすべてのマシンに PPP をインストールしてしまったら、PPP リンクに関する 1 レベルまたは 2 レベルのセキュリティを付加できます。
第 1 のレベルのパスワード認証プロトコル (PAP) は、最小限のセキュリティです。認証が確認されるか接続が切断されるまで、パスワードを「平文」で回線上に送り出します。
第 2 レベルのセキュリティである誰何ハンドシェーク認証プロトコル (CHAP) は、ポイントツーポイントリンクの反対側にある対等ホストの識別情報を、定期的に検査します。認証者、つまり接続または誰何 (Challenge) を開始するシステムが、対等ホストに誰何メッセージを送ります。これに対する応答が、リンクを介さずに渡されている「シークレット」と照合され、両者の値が一致すれば認証が確認されます。一致しない場合は、接続は切断されます。PPP のセキュリティを付加する方法については、「PAP/CHAP セキュリティのための asppp.cf の編集」で説明します。
PPP ソフトウェアを構成する前に、必要なハードウェアとソフトウェアの準備を整え、構成工程に必要な情報を収集する必要があります。この章では、構成の前に行う必要のある作業について説明します。主な作業には次のものがあります。
ネットワークアドレス指定方針の決定
ハードウェアが PPP の要件を満たしているかどうかの確認
PPP の要件を満たすソフトウェアの準備
この章の末尾には、PPP リンクを構成する前に、上記の情報を整理するためのチェックリストを収めてあります。
Solaris PPP はさまざまの構成オプションをサポートしています。主なものは次のとおりです。
ポイントツーポイントリンクを介した、リモートコンピュータ対ネットワーク
ポイントツーポイントリンクを介した、リモートコンピュータ対リモートコンピュータ
ポイントツーポイントリンクを介した、ネットワーク対ネットワーク
1 つまたは複数の動的ポイントツーポイントリンクを介した、ダイヤルインサーバ対複数のリモートコンピュータ
マルチポイントリンクを介した、ダイヤルインサーバ対複数のリモートコンピュータ
仮想ネットワークを形成する複数のリモートコンピュータ。すべてがマルチポイントリンクを介して通信を行う
これらの構成については、 第 7 章「PPP の概要」の中の 「PPP によるネットワークの拡張」で紹介しました。
この節では、構成プロセスを始める前に収集しておかなければならない情報と、行なっておかなければならない作業について、構成タイプ別に説明します。 設定したい構成について説明されている節を選んでお読みください。
検討を要する事項には次のものがあります。
ネットワークインタフェース
アドレス指定方式
ネームサービスを使うかどうか
ダイヤルインとダイヤルアウトのサポート
ルーティングの要件
リモートコンピュータ対ネットワークは、最も一般的な非同期 PPP 構成です。この構成を使用するのは、リモートオフィスやユーザの自宅にあるマシンが、ポイントツーポイント PPP リンクを介してダイヤルアウトし、ネットワーク上のダイヤルサーバに接続する場合です。
ネットワークインタフェース - このポイントツーポイントリンクは、ipdptpn 仮想ネットワークインタフェースを使用します。ネットワークへのダイヤルアウトを行うすべてのリモートマシンの構成ファイルの中で、このネットワークインタフェースを指定しておく必要があります。
アドレス指定方式 - 構成ファイルには、リンクを介して通信するマシンのホスト名または IP アドレスが含まれていなければなりません。リモートホストについては、既存のホスト名と IP アドレスを使用するのが普通です。詳細は、「PPP リンク用の IP アドレス指定の決定」を参照してください。
ネームサービス - リモートホスト用のネームサービスとしては、NIS と NIS+ はお勧めできません。これらのサービスは、多くは予想外のときに大量のネットワークトラフィックを生じさせます。この種類の構成の場合は、DNS ネームサービスの方が効率的です。DNS は、『Solaris ネーミングの管理』の説明に従って、各リモートホストごとに設定します。DNS を使用しない場合は、PPP は、リモートマシン上の /etc/inet/hosts ファイルを使用します。
ダイヤルインとダイヤルアウトのサポート - 通常、リモートホストはダイヤルアウト通信だけを実装しています。リモートホストは、他のマシンからの直接的なダイヤルインは受け入れません。したがって、ダイヤルアウト通信をサポートできるようにするには、各マシンの UUCP ファイルを更新する必要があります。その方法については、「UUCP データベースの編集」で説明します。
ルーティングの要件 - Solaris TCP/IP プロトコルスタックの一部として RIP が組み込まれているので、リモートホストではデフォルトにより RIP が実行されます。パフォーマンスの改善のために必要なら、RIP を止めて、代わりに静的ルーティングを使用します。詳細は、「ホストで静的ルーティングを選択するには」と、「RIP を止める」を参照してください。
ホスト対ホストの構成を確立するのは、物理的に異なる位置にある 2 つのリモートホスト間のポイントツーポイント通信を確立する場合です。この構成は、リモートオフィスにある 2 つのスタンドアロンマシンの間で情報を交換したい場合に便利です。物理ネットワークは関与しません。
ネットワークインタフェース - この基本的なポイントツーポイントリンクは、ipdptpn 仮想ネットワークインタフェースを使用します。両方のエンドポイントの構成ファイルの中で、このインタフェースを指定しておく必要があります。
アドレス指定方式 - 構成ファイルには、リンクを介して通信するマシンのホスト名または IP アドレスが含まれていなければなりません。一次ネットワークインタフェースに割り当てられている既存のホスト名と IP アドレスがある場合は、それらを使用します。既存のものがない場合は、エンドポイント用の IP アドレスを作成します。詳細は、「PPP リンク用の IP アドレス指定の決定」を参照してください。
ネームサービス - 2 つの対等ホストが通信し合うだけなので、本当のネームサービスは必要ありません。両方の対等ホスト上にある /etc/inet/hosts ファイルを使って、アドレスが解決されます。
ダイヤルインとダイヤルアウトのサポート - 両方のマシンが、ダイヤルイン操作とダイヤルアウト操作を行う必要があります。したがって、両方のエンドポイントの UUCP データベースと /etc/passwd を修正する必要があります。
ルーティングの要件 - Solaris TCP/IP プロトコルスタックの一部として RIP が組み込まれているので、リモートホストではデフォルトにより RIP が実行されます。パフォーマンスの改善のために必要なら、RIP を止めて、代わりに静的ルーティングを使用します。詳細は、「ホストで静的ルーティングを選択するには」と、「RIP を止める」を参照してください。
ネットワーク対ネットワークの PPP 構成を使用するのは、物理的に離れた場所にある 2 つのネットワークを連結してインターネットワークを構築したい場合です。その場合は、モデムと PPP ソフトウェアが、ネットワークを相互に接続するルータとして働きます。
ネットワークインタフェース - ポイントツーポイントリンクは、ipdptpn 仮想ネットワークインタフェースを使用します。2 つのネットワークを連結する両方のエンドポイントマシンの構成ファイルの中で、ipdptpn を指定しておく必要があります。
アドレス指定方式 - 構成ファイルには、リンクを介して通信するマシンのホスト名または IP アドレスが含まれていなければなりません。この種類の構成については 2 種類のアドレス指定が考えられます。これについては、「PPP リンク用の IP アドレス指定の決定」に説明があります。
ネームサービス - この種類の PPP リンクでは、NIS ネームサービスと NIS+ ネームサービスを使用できます。しかし、各ネットワークがそれぞれ別個のドメインであることが必要です。DNS を使用する場合は、2 つのネットワークが同じドメインに属していてもかまいません。詳細は、『Solaris ネーミングの管理』を参照してください。ローカルファイルをネームサービスとして使用する場合は、両方のエンドポイントマシン上にある /etc/inet/hosts ファイルを使って、アドレスが解決されます。このファイルには、リンクを介した通信ができる、各ネットワーク上のすべてのホストのホスト名と IP アドレスが含まれていることが必要です。
ダイヤルインとダイヤルアウトのサポート - 両方のネットワークエンドポイントマシンが、ダイヤルイン操作とダイヤルアウト操作を行う必要があります。したがって、両方のエンドポイントの UUCP と /etc/passwd ファイルを修正する必要があります。
ルーティングの要件 - 通常、ネットワーク対ネットワークのリンクのエンドポイントは、RIP を実行することによりルーティング情報を交換します。この構成の場合は、RIP を使用禁止にしないでください。
動的ポイントツーポイントリンクは、リモートホストからアクセスするネットワークエンドポイントとして働く、ダイヤルインサーバ用に使用できる 2 つの種類の構成の内の 1 つです。この構成方式では、サーバは、動的に割り当てられたポイントツーポイントリンクを介してリモートホストに接続します。ダイヤルインサーバは、必要時提供の方式で動的リンクを使用して、サービス対象のリモートホストとの通信を確立します。
ネットワークインタフェース - 動的ポイントツーポイントリンクは、ipdptp* 仮想ネットワークインタフェースを使用します。アスタリスクはワイルドカード文字です。このアスタリスクの働きにより、リンクが動的に割り当てられます。構成ファイルの中に、このインタフェースを指定しておくことが必要です。
アドレス指定方式 - 構成ファイルには、リンクを介して通信するマシンのホスト名または IP アドレスが含まれていなければなりません。詳細は、「PPP リンク用の IP アドレス指定の決定」を参照してください。
ネームサービス - NIS と NIS+ はリモートホスト用としては勧められませんが、リモートホスト対ネットワークの構成でのダイヤルインサーバは、それが物理的に接続されているネットワーク上の NIS クライアントとなることができます。NIS がサーバの物理ネットワーク上にある場合は、リモートホストのホスト名と IP アドレスによって NIS マップを更新してください。DNS は、ダイヤルインサーバとそのリモートホストのどちらにも使用できます。DNS とネームサービスの一般的な事項については、『Solaris ネーミングの管理』を参照してください。ローカルファイルをネームサービスとして使用する場合は、PPP はダイヤルインサーバの /etc/inet/hosts ファイルを使用して、アドレスを解決します。
ダイヤルインサポート - 動的ポイントツーポイントダイヤルインサーバの /etc/passwd ファイルを更新する必要があります。動的リンクサーバは、直接にはリモートホストへのダイヤルアウトをしません。
ルーティングの要件 - Solaris TCP/IP プロトコルスタックの一部として RIP が組み込まれているので、リモートホストではデフォルトにより RIP が実行されます。パフォーマンスの改善のために必要なら、RIP をオフにして、代わりに静的ルーティングを使用します。詳細は、「ホストで静的ルーティングを選択するには」と、「RIP を止める」を参照してください。
マルチポイントリンクは、リモートマシンからアクセスするネットワークエンドポイントとして働くダイヤルインサーバ用に使用できる、2 つの種類の構成の 1 つです。この構成方式では、ダイヤルインサーバは、同じマルチポイントリンクを介して複数のリモートホストを接続します。「リモートコンピュータ対ネットワークの構成」で説明したように、リモートホストは、常にポイントツーポイントリンクを介してダイヤルインサーバに接続されます。
この構成を使用するのは、リモートホストとダイヤルインサーバから成る独立したネットワークを定義したい場合です。
ネットワークインタフェース - マルチポイントリンクは、ipdn 仮想ネットワークインタフェースを使用します。ダイヤルインサーバの構成ファイルの中に、このインタフェースを指定しておくことが必要です。
アドレス指定方式 - 構成ファイルには、リンクを介して通信するマシンのホスト名または IP アドレスが含まれていなければなりません。詳細は、「PPP リンク用の IP アドレス指定の決定」を参照してください。マルチポイントリンク上のホストのための独立したネットワークを作成する必要があります。詳細は、「PPP リンクへのネットワーク番号の割り当て」を参照してください。
ネームサービス - NIS と NIS+ はリモートホスト用としては勧められませんが、リモートホスト対ネットワークの構成でのダイヤルインサーバは、それが物理的に接続されているネットワーク上の NIS クライアントとなることができます。NIS がサーバの物理ネットワーク上にある場合は、リモートホストのホスト名と IP アドレスによって NIS マップを更新してください。DNS は、ダイヤルインサーバとそのリモートホストのどちらにも使用できます。DNS とネームサービスの一般的な事項については、『Solaris ネーミングの管理』を参照してください。ローカルファイルをネームサービスとして使用する場合は、PPP はダイヤルインサーバの /etc/inet/hosts ファイルを使用して、アドレスを解決します。
ダイヤルインとダイヤルアウトのサポート - マルチポイントダイヤルインサーバは、PPP 仮想ネットワークと、サーバが接続している物理ネットワークとの間のネットワークルータとして働きます。サーバは、PPP ネットワークを宛先とする IP トラフィックを物理ネットワークから受け取るたびに、リモートホストに対してダイヤルアウトします。したがって、マルチポイントダイヤルインサーバは、ダイヤルインサポートとダイヤルアウトサポートの両用として構成し、UUCP と /etc/passwd ファイルを更新する必要があります。
ルーティングの要件 - ipdn インタフェースは RIP をサポートしません。RIP を使用禁止にする必要はありません。
仮想ネットワーク構成を使用するのは、電話回線、モデム、PPP ソフトウェアを使って、物理的に離れた場所にある 3 台以上のコンピュータを 1 つの仮想ネットワークにしたい場合です。
ネットワークインタフェース - この種類の構成はマルチポイントリンクを必要とし、マルチポイントリンクは ipdn 仮想ネットワークインタフェースを使用します。このインタフェースは、各エンドポイントシステムを、仮想ネットワークの反対側のエンドポイントに接続します。
アドレス指定方式 - 構成ファイルには、リンクを介して通信するマシンのホスト名または IP アドレスが含まれていなければなりません。詳細は、「PPP リンク用の IP アドレス指定の決定」を参照してください。仮想ネットワークにはネットワーク番号を割り当てる必要があります。詳細は、「一意な IP アドレスとホスト名の作成」を参照してください。
ネームサービス - 仮想ネットワークでは、NIS と NIS+ を実行できます。しかし、これはリンクのパフォーマンスを低下させることがあります。DNS の方が効率的です。これらのネームサービスの設定方法については、『Solaris ネーミングの管理』を参照してください。ローカルファイルをネームサービスとして使用する場合は、仮想ネットワークを形成するすべてのマシンのホスト名と IP アドレスにより、各マシンの /etc/inet/hosts を更新する必要があります。
ダイヤルインサポートとダイヤルアウトサポート - 仮想ネットワーク内のすべてのマシンを、ダイヤルイン操作とダイヤルアウト操作の両用として構成し、UUCP と /etc/passwd ファイルを更新する必要があります。
ルーティングの要件 - ipdn インタフェースは RIP をサポートしません。RIP を使用禁止にする必要はありません。
PPP リンクを介した通信ができるようにするには、リンクの一端にあるマシンが、リンクの反対側にある対等ホストのホスト名と IP アドレスを認識していることが必要です。PPP 構成は、特定のアドレス指定方針を必要とすることがよくあります。この節では、各アドレス指定方針と、それぞれをどのような場合に使用するかについて説明します。
各エンドポイントマシンでは、次の場所にアドレス指定情報を指定します。
/etc/asppp.cf 構成ファイル
/etc/inet/hosts ファイル
NIS+、NIS、DNS データベースのどれか (該当する場合)
ローカルマシンの asppp.cf ファイルを編集するときに、リンク上に配置する各エンドポイントマシンについて、ホスト名と、場合によっては IP アドレスを指定する必要があります。たとえば、各エンドポイントの IP アドレスまたはホスト名を、構成ファイル内の ifconfig セクション内の引数として入力する必要があります。
ifconfig ipdptp0 plumb 192.99.44.01 192.99.44.02 up |
/etc/asppp.cf の形式については、第 9 章「PPP の構成」を参照してください。
さらに、通信を可能にするには、/etc/inet/hosts を編集することにより、リモートエンドポイントの IP アドレスとホスト名を、ローカルエンドポイントの hosts データベースに追加する必要があります。このプロセスについては、「ネットワーククライアントの構成」に説明があります。
PPP 用のアドレス指定方針はいくつかあり、構成のタイプに応じてどれかを選択できます。asppp.cf ファイルと hosts データベースを編集する前に、使用する構成に適合するアドレス指定方針を決める必要があります。方針には次のものがあります。
ローカル /etc/inet/hosts ファイル内で一次ネットワークインタフェースに割り当てられているのと同じ IP アドレスを PPP 用に使用する
各 PPP エンドポイントに一意な IP アドレスを割り当てる
PPP リンクが作成したネットワークに新しいネットワーク番号を割り当てる
このアドレス指定方針は、ポイントツーポイントリンクの場合に限り使用できます。この方針では、各エンドポイントについて一次ネットワークインタフェースのアドレスを指定します (一次ネットワークインタフェースについての詳細は、第 1 章「ネットワーク管理の概要」を参照してください)。この種のエンドポイントには次のようなものがあります。
PPP リンクを介して通信する 2 つのスタンドアロンマシン (既存の IP アドレスを持っている場合)
PPP リンクを介して通信する 2 つのネットワークエンドポイント
ポイントツーポイントリンクによりネットワークダイヤルインサーバに接続されているリモートホスト
動的割り当てポイントツーポイントリンクによりリモートホストに接続されているダイヤルインサーバ
ローカルエンドポイントの /etc/inet/hosts ファイルを編集するときに、一次ネットワークインタフェースの IP アドレスと、リンクの反対側の対等ホストのホスト名と IP アドレスを入力します。
この方式では、PPP ネットワークインタフェースに、一意なホスト名と IP アドレスを割り当てます (インタフェースを hostname-ppp と名付けるとよいでしょう)。このアドレス指定方針は次のものに使用します。
マルチポイントダイヤルインサーバとして使用されるネットワーク上のエンドポイントマシン
仮想ネットワーク上のマシン
専用 IP アドレスを使用して、動的に割り当てられた PPP リンクを介してダイヤルインサーバと通信するリモートホスト (これは、動的リンク構成の場合の必須条件ではない)
イーサネットやトークンリングなどの物理ネットワークのルータとしても構成されているマシン
スタンドアロン対スタンドアロンの構成において、既存の IP アドレスを持っていないマシン (PPP インタフェースが一次ネットワークインタフェースになる)
asppp.cf 構成ファイルの中で、PPP ネットワークの一意なアドレスとホスト名を指定する必要があります。
新しいホスト名と IP アドレスを作成するには、「hosts データベース」の説明に従って、単にその名前とアドレスを /etc/inet/hosts ファイルに追加するだけです。
PPP 構成用に新しいネットワーク番号を作成するのは、次のものが構成に含まれる場合です。
マルチポイントダイヤルインサーバとそのリモートホスト (必須)
2 つのネットワーク間の PPP リンク、特に、ネットワークエンドポイントマシンの一方または両方が物理ネットワークのルータでもある場合 (オプション)
(ネットワーク番号については、第 3 章「ネットワークの計画」を参照してください)。
PPP リンクは、物理ネットワークメディアを含まないため、仮想ネットワークとなります。すべてのエンドポイントマシンの networks データベースに、その仮想ネットワークのネットワーク番号と、リンクするネットワークのネットワーク番号を入力する必要があります。
例 8-1 は、PPP を用いたインターネットワーク用の /etc/inet/networks ファイルのサンプルを示します。
kalahari 192.9.253 negev 192.9.201 nubian-ppp 192.29.15 |
このサンプルファイルの中で、kalahari と negev は 2 つのローカルエリアネットワークで、nubian-ppp は PPP リンクの名前です。
Solaris TCP/IP ネットワークでは、デフォルトにより RIP ルーティングプロトコルが実行されます。ほとんどの場合、ポイントツーポイントリンクでは、RIP をそのまま実行させておくのが妥当です。しかし、リンクのパフォーマンスに問題がある場合は、ポイントツーポイントリンク上で RIP を使用禁止にした方がよい場合もあります。
マルチポイントリンクでは RIP は起動されません。したがって、マルチポイントリンクの場合は静的ルーティングを設定する必要があります。その方法については、「ホストで静的ルーティングを選択するには」を参照してください。
ポイントツーポイントリンク上では、/etc/gateways ファイルを使って RIP を使用禁止にできます。このファイルはオペレーティングシステムに付属しているものではないので、テキストエディタを使って作成する必要があります。
RIP をオフに切り替えるには、/etc/gateways に次のエントリを入力する必要があります。
norip ipdptpn |
ipdptpn は、使用するポイントツーポイント PPP インタフェースのデバイス名です。
詳細は、in.routed(1M) のマニュアルページを参照してください。
基本的な PPP 構成には、コンピュータ、モデム、RS-232 電話回線が含まれます。しかし、構成を行う前に、選択したハードウェアが PPP をサポートするものであるかどうかを検査する必要があります。この節では、PPP に関するハードウェア要件について説明します。
モデムの要件 - PPP を実行するには、各エンドポイントマシンが、少なくとも 9600 bps 以上の双方向接続をサポートするモデムを備えていることが必要です。このようなモデムは、V.32 または V.32bis の仕様を満たしています。
シリアルポート選択 (ダイヤルインサーバの場合だけ) - ほとんどの CPU では、シリアルポート A とシリアルポート B のどちらでも、PPP 用として構成できます。ダイヤルインサーバでポートを初期化するには、Solaris シリアルポートマネージャを使用します。適正なポートを選択する方法については、『Solaris のシステム管理』に説明があります。追加のシリアルカードをインストールしてある場合は、そのシリアルポートも PPP 接続用に使用できます。
以下のディレクトリ内に、PPP 用の十分なスペースを確保する必要があります。
/usr
/usr/kernel/drv
/usr/kernel/strmod
/usr/sbin
PPP は、/usr に約 243 K バイト、/ (ルート) に 4 K バイトを必要とします。
このチェックリストは、PPP の構成の準備を整えるために使用します。構成プロセスに着手する前に収集する必要のある情報と、行う必要のある作業を列記してあります。
/usr に使用可能な空き領域が 300 K バイトありますか。 ___________
/ (ルート) に使用可能な空き領域が 4 K バイトありますか。 ___________
各エンドポイントのモデムが、V.32 または V.32bis 以上をサポートしていますか。 ___________
ダイヤルインサーバでシリアルポートマネージャを使用して、モデム用のシリアルポートを指定しましたか。 ___________
各エンドポイントマシンに Solaris PPP をインストールして あることを確認しましたか (PPP をインストールしてない場合は、pkgadd プログラムか admintool ソフトウェアマネージャを使ってインストールできます。その方法については、『Solaris のインストール (上級編)』を参照してください)。 ___________
各エンドポイントで別のバージョンの PPP が実行されていないことを確認しましたか (そのようなバージョンがある場合は、それぞれのマニュアルの説明に従って使用禁止にしてください)。 ___________
PPP リンクに関与するすべてのコンピュータについて、使用する IP アドレスを決定しましたか。 __________
すべてのマシンのホスト名と IP アドレスをここにリストしてください。 ___________ ___________ ___________ ___________
ダイヤルインサーバの名前と IP アドレスを記入してください (該当する場合)。 ___________
この章には、PPP を構成するための手順と情報を収めてあります。説明に使用する例は、リモートホストとそのマルチポイントダイヤルインサーバの両方のタイプの PPP リンクを持つ構成を想定しています。その他の PPP 構成タイプの設定方法に関する情報は、第 11 章「PPP リンクの調整」に収めてあります。
第 8 章「PPP 構成の準備」で述べたプリインストール作業が終われば、いよいよ PPP の構成にとりかかることができます。
PPP については次のことを行う必要があります
PPP ソフトウェアのインストール (まだインストールしてない場合)
関与するすべてのマシンの /etc/inet/hosts ファイルの編集
すべてのダイヤルアウトマシンの UUCP データベースファイルの編集
ダイヤルインマシンの /etc/passwd ファイルと /etc/shadow ファイルの編集
リンク上の各マシンの /etc/asppp.cf ファイルの編集
リンク上の各マシンでのリンクマネージャ aspppd の起動
PPP が正常に実行されていることの確認
上記の作業 1 〜 4 は順番どおりに進めなくてもかまいませんが、PPP 構成ファイルの編集の前に、すべて完了しておくことが必要です。
この章の各節では、PPP の構成のための手順について説明します。
Solaris インストールプログラムを実行するときに配布ソフトウェア全体を選択すると、PPP ソフトウェアは自動的に組み込まれます。配布ソフトウェア全体を選択しなかった場合は、PPP を個別のパッケージとしてインストールできます。
先へ進む前に、PPP リンクに含めるすべてのマシンに、Solaris バージョンの PPP をインストールしてあることを確認する必要があります。リンクに含める各エンドポイントについて、次のように入力します。
# pkginfo | grep ppp |
PPP がインストールされていれば、次のパッケージ名が表示されます。
SUNWpppk # Contains kernel modules SUNWapppu # Contains the link manager and login service SUNWappp # Contains configuration files |
PPP がインストールされていないエンドポイントシステムがある場合は、pkgadd プログラムか admintool ソフトウェアマネージャを使ってインストールしてください。
pkgadd を使って PPP をインストールする場合は、上記のスクリーンボックスに並べた順序でパッケージをインストールする必要があります。
pkgadd プログラムと admintool ソフトウェアマネージャについての詳細は、『Solaris のシステム管理』を参照してください。
この節と以後の各節では、最も一般的な PPP 構成、つまりリモートホストとそのダイヤルインサーバをサポートするファイルを編集する方法を紹介します。図 9-1 は、この章で例として使用する構成を示しています。この例は、3 台のリモートマシン (nomada、nomadb、nomadc) と、ダイヤルインサーバ nubian で構成されるネットワーク 192.41.43 を表しています。このネットワークは、ダイヤルインサーバ nubian が直接接続しているローカルエリアネットワーク 192.41.40 とは別個のネットワークです。ネットワーク 192.41.40 は、ネームサービスとして NIS を実行しています。
各リモートホストについて示されている IP 番号は、それぞれの PPP ネットワークインタフェースのアドレスです。しかし、ダイヤルインサーバは、自己の一次ネットワークインタフェースの IP アドレスである 192.41.40.45 のほかに、PPP インタフェース用として特別に作成された IP アドレスである 192.41.43.10 も持っています。
構成に含まれるすべてのマシンに PPP がインストールされていることを確認したら、次に、各マシンの /etc/inet/hosts ファイルを編集します。PPP リンクの反対側にあって、ローカルマシンが通信する必要のあるすべてのマシンについて、hosts データベースにホスト情報を追加する必要があります。
物理ネットワーク上でどのネームサービスを使用しているかに関係なく、/etc/inet/hosts を更新する必要があります。これは、ブートプロセスの中で、PPP の方がネームサービスデーモンより前に起動されるからです。
リンクの反対側にあるダイヤルインサーバ用の PPP ネットワークインタフェースの IP アドレスとホスト名が入ったエントリを追加します。
図 9-1 では、ダイヤルインサーバ nubian の PPP ネットワークインタフェースの IP アドレスが入ったエントリが、nomada の /etc/inet/hosts ファイルに入れられます。nomadb と nomadc の /etc/inet/hosts ファイルについても、同じことが行われます。
ダイヤルインサーバのネットワーク上にあって、リモートホストからのリモートログインが可能な各マシンの IP アドレスが入ったエントリを追加します。
たとえば、 nomadc の /etc/inet/hosts ファイルは次のようになります。
# Internet host table # 127.0.0.1 localhost loghost 192.41.43.3 nomadc 192.41.43.10 nubian-ppp 192.41.40.20 nismaster |
ネットワークで使用中のネームサーバがある場合に、リモートホストのホスト名と IP アドレスによって、そのネームサーバのデータベースを更新します。
マルチポイントダイヤルインサーバは、一次ネットワークインタフェースのローカル IP アドレスのほかに、PPP インタフェース用の一意な IP アドレスも持っていなければなりません。ダイヤルインサーバ用の hosts データベースを構成するために必要な手順は、次のとおりです。
PPP インタフェースの IP アドレスが入ったエントリを、ダイヤルインサーバの /etc/inet/hosts ファイルに追加します。
たとえば、図 9-1 に示すダイヤルインサーバ nubian の /etc/hosts ファイルは、次のようになります。
# Internet host table # 127.0.0.1 localhost loghost 192.41.43.10 nubian-ppp 192.41.40.45 nubian |
サーバの物理ネットワークでネームサービスが使用されていない構成の場合は、次のようにします。
サーバとそのリモートホストからなるネットワークの新しいネットワーク番号を、ダイヤルインサーバの /etc/inet/networks ファイルに追加します。
「PPP リンクへのネットワーク番号の割り当て」 を参照してください。
マシンが PPP リンクを介してダイヤルアウトできるようにするには、そのマシンの UUCP データベース内の以下のファイルを編集する必要があります。
/etc/uucp/Devices
/etc/uucp/Dialers
/etc/uucp/Systems
これらのファイルの編集が必要なのは、PPP ダイヤルアウトマシンとして働くリモートホストの場合です。また、ダイヤルインサーバがリモートホストへのダイヤルアウトを行う場合も (マルチポイントダイヤルインサーバの場合の必須条件)、そのダイヤルインサーバにある上記のファイルを編集する必要があります。これらのファイルについては、第 12 章「UUCP のデータベースとプログラム」で詳しく説明します。
/etc/uucp/Devices ファイルは、そのホストが使用するか、または認識していなければならない、すべての通信デバイスについてのエントリを含んでいる必要があります。たとえば、あるマシンが US Robotics V.32bis モデムを PPP リンクの一部として使用しているのであれば、/etc/uucp/Devices ファイルに次のようなエントリが入っていなければなりません。
# Use these if you have a USrobotics V.32bis modem on Port B. ACUEC cua/b - 9600 usrv32bis-ec ACUEC cua/b - 19200 usrv32bis-ec ACUEC cua/b - 38400 usrv32bis-ec |
各 PPP エンドポイントマシンの Devices ファイルに、それぞれのモデムを記述するエントリがあることを確かめてください。/etc/uucp/Devices についての詳細は、「/etc/uucp/Devices ファイル」を参照してください。
/etc/uucp/Dialers ファイルには、PPP エンドポイントマシンに接続しているモデムとの会話を記述するエントリを含めてあることが必要です。たとえば、US Robotics V.32bis モデムを PPP リンクとして使用する場合、このエントリは次のようになります。
usrv32bis-ec =,-, "" ¥dA¥pT&FE1V1X1Q0S2=255S12=255&A1&H1&M5&B2¥r¥c OK¥r ¥EATDT¥T¥r¥c CONNECT¥s14400/ARQ STTY=crtscts
このエントリの最初のパラメータである usrv32bis は、/etc/uucp/Devices ファイルの最後のパラメータに対応しており、これによって両者が結合されます。このエントリの残りの部分には、モデムが送る文字、モデムが受け取ると予期している文字などが記述されています。表 12-6 に、Dialers ファイルの中で使用する制御コードの定義を示してあります。
リンク上の各ダイヤルアウトエンドポイントに接続しているモデムについて、Dialers ファイル内にエントリが 1 つずつあることを確認してください。特定のモデムの会話が正しいかどうか確信がない場合は、『Solaris のシステム管理』と、そのモデムの操作マニュアルを参照してください。
/etc/uucp/Systems ファイルには、ローカルホストがダイヤルアウトできる各マシンについてのエントリが入っています。各エントリには、リモートホストの電話番号や、回線速度などの情報が入っています。たとえば、図 9-1 に示したホスト nomadb では、ダイヤルインサーバについてのエントリは次のような内容のものとなります。
nubian-ppp Any ACUEC 38400 5551212 "" P_ZERO "" ¥r¥n¥c login:-¥r¥n¥c-login:-¥r¥n¥c-login:- EOT-login: bnomad password: Secret-Password |
最初のフィールドに示されているのはサーバのホスト名である nubian-pppで、これは、asppp.cf ファイルのキーワード peer_system_name に使用されます。ACUEC と 38400 はデバイスと速度を示し、これは、/etc/uucp/Devices ファイルからエントリを選択するために使用されます。その後の部分には、nomadb がダイヤルインするマシンの電話番号、nomadb がログインするために使用するログイン名などの情報があります。Systems ファイルに指定する必要のあるパラメータについては、「/etc/uucp/Systems ファイル」で詳しく説明します。
構成内の各リモートホストには、ダイヤルインサーバについてのエントリを追加する必要があります。/etc/uucp/Systems ファイルには、そのホストが UUCP 通信でダイヤルアウトする他のマシンについてのエントリや、他の PPP ダイヤルインサーバについてのエントリを一緒に入れることができます。
ダイヤルインサーバがリモートホストに直接ダイヤルアウトを行う場合は、それらのリモートホストのそれぞれを記述するエントリを Systems ファイルに追加する必要があります。
ダイヤルインサーバを構成するには、/etc/passwd ファイルと /etc/shadow ファイルも編集する必要があります。
ダイヤルインサーバへのログインを許可されている各リモートホストの各ユーザについて、そのサーバの /etc/passwd ファイルにエントリを追加する必要があります。リモートホストがダイヤルインサーバを呼び出す場合、自分自身の UUCP データベースを読み、ユーザ名かユーザ ID をサーバに渡すことで呼び出しを開始します。すると、サーバは、/etc/passwd ファイルのユーザ情報に照らして確認します。
そのユーザのパスワードが認証されると、サーバは、PPP ホスト用の特別なシェルである /usr/sbin/aspppls にそのユーザをログインさせます。サーバは、この情報を /etc/passwd ファイルのログインシェルエントリから入手します。たとえば、図 9-1 の例の場合、ダイヤルインサーバ nubian の /etc/passwd ファイルには、次のようなエントリが入っています。
bin:x:2:2::/bin: sys:x:3:3::/bin: uucp:x:5:5::/usr/lib/uucp: nuucp:x:9:9::/var/spool/uucppublic:/usr/lib/uucp/uucico news:x:6:6::/var/spool/news:/bin/csh sundiag:x:0:1:System Diagnostic:/usr/diag/sundiag:/usr/diag/sundiag/sundiag lily:x:20:99:Dial-in Operator:/home/nubian/lily:/bin/csh nomada:x:21:99:R. Burton:/:/usr/sbin/aspppls nomadb:x:22:99:T. Sherpa:/:/usr/sbin/aspppls nomadc:x:23:99:S. Scarlett:/:/usr/sbin/aspppls
/etc/passwd パスワードについての詳細は、『Solaris のシステム管理』を参照してください。
/etc/passwd ファイル中の情報に加えて、/etc/shadow ファイルもサーバへのダイヤルインを許可されている各エンドポイントマシンで使用するログイン名のパスワードに更新します。詳細は、『Solaris のシステム管理』を参照してください。
/etc/asppp.cf 構成ファイルは、エンドポイントマシン上にある PPP リンクマネージャに、リンクの反対側にあるマシンに関する情報、またはマルチポイントリンク (または動的ポイントツーポイントリンク) の反対側にあるマシンに関する情報を提供します。このマシンがブートすると、リンクマネージャはこの情報を使って、リモートエンドポイントとの通信を確立し維持します。
基本的な asppp.cf 構成ファイルには、少なくとも 2 つのメインセクションが含まれていなければなりません。それは、1 個の ifconfig 行と、少なくとも 1 つの path セクションです。これに加えて defaults セクションも含めることができます。このセクションは、エンドポイントについてデフォルト値を設定したい場合に使用します (default セクションで使用するキーワードの説明については、第 11 章「PPP リンクの調整」を参照してください)。
例 9-1 が示す基本構成ファイルは、ダイヤルインサーバとの間にポイントツーポイントリンクを確立するリモートホスト用として作成されたものです。
ifconfig ipdptp0 plumb nomada nubian-ppp up path interface ipdptp0 peer_system_name nubian-ppp # The name in the /etc/uucp/Systems file inactivity_timeout 300 # Allow five minutes before timing out
asppp.cf ファイルには、次の構文の ifconfig セクションを含める必要があります。
ifconfig interface-number plumb local-machine remote-machine up
各フィールドについて説明します。
ifconfig - リンクマネージャに、ifconfig コマンドを実行し、PPP インタフェースの構成を始めるよう指示します。
interface-number - PPP インタフェースを識別します。ポイントツーポイントリンクの場合は ipdptpn、マルチポイントリンクの場合は ipdn (n はインタフェースの番号で置き換えます)。
local-machine - ローカルエンドポイントの名前を指定します。これには、ローカルホスト名か IP アドレスを使用できます。
remote-machine - リモートエンドポイントの名前を指定します。これには、リモートホスト名か IP アドレスを使用できます。
リンクマネージャは、まずローカルホストで ifconfig コマンドを実行して、ipdptp0 ポイントツーポイントインタフェースを構成します。ipdptp0 の中の 0 は、インタフェースのデバイス番号を示します。plumb オプションは、IP が ipdptp0 インタフェースを認識するのに必要な各種の操作を行います。nomada はローカルホストの名前です。nubian-pppは、nomada がポイントツーポイントリンクを介して接続するダイヤルインサーバの名前です。ifconfig オプション up は、ipdptp0 インタフェースに "up" のマークを付けます。
ifconfig についての詳細は、第 10 章「PPP の障害追跡」と、ifconfig(1M) のマニュアルページを参照してください。
構成ファイルの path セクションは、リモートエンドポイントの名前と、エンドポイントマシン間を結ぶインタフェースの名前を、リンクマネージャに指示します。path セクションには、少なくとも下記の行が必要です。
path interface interface-number peer_system_name endpoint-name |
このキーワードは PPP インタフェースを定義します (ipdptpn か ipdn のどちらか)。例 9-1 では、path セクションに次の情報があります。
interface ipdptp0 peer_system_name nubian-ppp |
この interface キーワードは、ローカルエンドポイント nomada が、この path セクションの記述に従ってリモートエンドポイントと通信するのに使用するポイントツーポイントインタフェースが ipdptp0 であることを表します。このキーワードは、peer_system_name をインタフェースに結び付けています。
リモートホストなどのようなダイヤルアウトマシンでは、peer_system_name キーワードは、リモートエンドポイントのホスト名を引数としてとります。これは、/etc/uucp/Systems の中で指定されたリモートエンドポイントの名前です。この名前は、対応する ifconfig 行のホスト名と同じでなくてもかまいません。
ダイヤルインサーバの場合は、peer_system_name キーワードへの引数の値は違うものになります。詳細は、「マルチポイントダイヤルインサーバの構成ファイル」を参照してください。
例 9-1 では、peer_system_name は、このリンクの反対側にあるリモートエンドポイントが、ダイヤルインサーバ nubian-ppp であることを示しています。リンクマネージャは、asppp.cf ファイルを読んだ後で、/etc/uucp/Systems ファイルの中で nubian-ppp についてのエントリを見つけます (Systems ファイルには、リモートエンドポイントとの通信を設定する方法や、そのマシンの電話番号などが含まれているということを思い出してください。「PPP の /etc/uucp/Systems の更新」を参照してください)。
inactivity_timeout キーワードは省略可能です。このキーワードは、指定した時間が経過するまでの期間は、リンクが未使用状態であっても構わないことをリンクマネージャに指示します。その期間が経過すると、リンクマネージャは自動的にリンクを切り離します。デフォルトの時間は 2 分です。未使用期間として別の時間を指定したい場合でない限り、inactivity_timeout を使用する必要はありません。
asppp.cf ファイルには、上記以外にも、エンドポイントマシンによる通信の方法を定義するためのキーワードがいくつかあります。これらのキーワードについては、第 11 章「PPP リンクの調整」に詳しい説明があります。
マルチポイントダイヤルインサーバの asppp.cf ファイルの場合も、基本的なセクションはポイントツーポイントリンクの場合と同じで、1 個の ifconfig セクションと、少なくとも 1 つの path セクションのほかに、必要に応じて指定する defaults セクションがあります。
例 9-2 は、図 9-1 に示したダイヤルインサーバ nubian の構成ファイルです。
ifconfig ipd0 plumb nubian-ppp up path interface ipd0 peer_system_name tamerlane # The user name this remote # machine logs in with when it # dials this server peer_ip_address nomada # nomada is a remote machine that # dials in to this server # nomadb is another remote machine that dials in to nubian path interface ipd0 peer_system_name lawrence peer_ip_address nomadb # nomadc is another remote machine that dials in to nubian path interface ipd0 peer_system_name azziz peer_ip_address nomadc
マルチポイントダイヤルインサーバの場合の ifconfig セクションは、ポイントツーポイントリンクの場合とはやや構文が異なります。構文は次のとおりです。
ifconfig ipdn plumb server-name up
最も大きな相違点は、ifconfig への引数として宛先エンドポイントを指定しないという点です。代わりに、リンクマネージャは、asppp.cf ファイルの path セクションからこの情報を拾いだします。
例 9-2 では、リンクマネージャは、まずダイヤルインサーバで ifconfig コマンドを実行して、マルチポイントインタフェース ipd0 を構成します。ipd0 の中の 0 は、インタフェースのデバイス番号を示します。plumb オプションは、IP が ipd0 インタフェースを認識するために必要な各種の操作を行います。ifconfig オプション up は、ipd0 インタフェースに "up" のマークを付けます。
サブネット化を用いる場合は、ifconfig 行に netmask + パラメータの指定が必要になります。
asppp.cf ファイルの path セクションは、リモートエンドポイントの名前と、エンドポイントマシンをリンクするインタフェースの名前を、リンクマネージャに指示します。ただし、マルチポイントダイヤルインサーバでは、複数の path セクションを設けることができます。また、キーワードへの引数のいくつかは、マルチポイントリンクでは使い方が異なります。
path interface interface-number peer_system_name endpoint-username peer_ip_address endpoint-hostname |
path セクションは、ダイヤルインサーバが接続を確立する相手となる各可搬エンドポイントについて、1 つずつ定義する必要があります。
マルチポイントダイヤルインサーバの場合は、interface キーワードは PPP インタフェース ipdn を定義します。このインタフェースを介してサーバと通信するすべてのエンドポイントについて、同じ PPP インタフェースを path セクションに指定する必要があります。
ダイヤルインマシンの場合の peer_system_name キーワードは、ダイヤルアウトマシンの場合と引数が少々異なります。ダイヤルインサーバの場合は、この引数は、リモートホストがサーバとの通信を確立しようとするときに使用するログイン名です。このユーザ名は、すでにサーバの /etc/passwd ファイル内に存在しているものでなければなりません。ログインサービスは、この名前を読みとると、/etc/passwd ファイルと /etc/shadow ファイルの中のユーザ名と検証して、通信を可能にします。
次に示す、例 9-2 の抜粋を見てください。
path interface ipd0 peer_system_name scarlett peer_ip_address nomadc |
ここでは、peer_system_name への引数は scarlett です。これは、nomadc が nubian-ppp にログインするときに、scarlett というログイン名を使用することを示しています。
peer_ip_address キーワードは、マルチポイントリンクの場合は必須です。このキーワードは、リモートエンドポイントのホスト名または IP アドレスを引数としてとります。上記の例では、peer_ip_address キーワードの引数はホスト名 nomads です。
asppp.cf ファイルには、上記以外にも、エンドポイントマシンによる通信の方法を定義するためのキーワードがいくつかあります。これらのキーワードについては、第 11 章「PPP リンクの調整」に詳しい説明があります。
asppp.cf を編集するときは、次の点に注意してください。
構成ファイル内では、キーワードとキーワードとの間を空白 (ブランク、タブ、改行) で区切る
コメントとして使用する文字列の前には # 記号を付ける。# からその次の改行までの文字はすべてコメントとみなされ、無視される
ファイル内のキーワード入力については、上記以外には形式上の必要条件はありません。
1 つのエンドポイントマシンでスーパーユーザになり、/etc ディレクトリに移動します。
汎用 asppp.cf ファイルを編集して、このマシンの PPP リンクを定義する情報を追加します。
アクセス権が必ず 600 に設定されるように、ファイルを保存します。
構成に含まれるすべてのマシンへの PPP のインストールを完了したら、asppp.cf を修正することにより、PPP リンクについての PAP または CHAP レベルのセキュリティを付加できます。「PAP/CHAP セキュリティのための asppp.cf の編集」を参照してください。
PPP は、ブート時に自動的に起動されるようにすることも、コマンド行から手動で起動することもできます。
通常は必要ありませんが、PPP を手動で起動することができます。
# ps -e | grep asppp |
grep の結果の出力に aspppd デーモンがリストされれば、PPP が実行中です。
結果が表示されたら、リモート PPP リンクに到達できるかどうかを確認するために、次のように入力します。
# ping remote-host 300 |
この例の ping では、タイムアウト値が 5 分 (300 秒) に設定されています。このコマンドに対しては、remote-host is alive のような出力が表示されるはずです。これとは異なる表現、たとえば remote-host unreachable などが表示された場合は、経路構成が失敗したことを意味します。
ログファイルを調べて、構成行程にエラーがないかどうか検査します。
# tail /var/adm/log/asppp.log |
構成時にエラーが見つかった場合は、asppp.log にエラーメッセージが入っています。
障害追跡と問題解決については、第 10 章「PPP の障害追跡」 を参照してください。
この章では、ネットワーク上に PPP を構成した後で行う必要のある一連の検査事項を示します。検査が終わった後は、PPP リンクを介した通信に問題が生じたときに、PPP 診断機能を問題の解決に用いることができます。
要約して言えば、これらの検査は次の順序で行う必要があります。
ハードウェア
インタフェースの状態
接続
ネットワークインタフェースの動作状態
ローカルルーティングテーブル
アクセス権
パケットフロー
PPP がすべてのテストに合格すれば、TCP と UDP のサービス、たとえば rlogin、telnet、ftp などを、リンクを介して使用できるようになっているはずです。それでもリンクに障害がある場合は、PPP 診断機能を用いた障害追跡を試みてください。
以下の各節では、上記の各検査について詳しく説明します。
すべてのモデムケーブルと電源ケーブルがしっかりと接続されていることを確認します。PPP に問題が生じたときは、常に、モデム、ケーブル、シリアルカード、電話回線を最初に検査してください。
PPP を起動した後は、PPP インタフェース名だけを引数として指定した ifconfig を使用して、回線の現在の状態が監視できます。例 10-1 に示すのは、実行中の PPP リンクについての ifconfig のサンプル出力です。
nomadb# ifconfig ipdptp0 ipdptp0: flags=28d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,UNNUMBERED> mtu 1500 inet 129.144.111.26 --> 129.144.116.157 netmask ffff0000 ether 0:0:0:0:0:0
標準と動的のどちらのポイントツーポイントリンクの場合も、コード例 10-2 に示すような出力が得られます。
nubian# ifconfig ipd0 ipd0: flags=c1<UP,RUNNING,NOARP> mtu 1500 inet 129.144.201.191 netmask ffffff00 ether 0:0:0:0:0:0
ifconfig に UP と RUNNING が表示されない場合は、PPP を正しく構成していないことになります。ifconfig の詳細は、「ifconfig コマンド」と、ifconfig(1M) のマニュアルページを参照してください。
ping コマンドを使用して、接続が up 状態であるか、または確立可能であるかを検査します。たとえば、次のような単純な往復テストを考えてみてください。
# ping elvis |
ここで、elvis はリモートホスト上の PPP インタフェースの名前です。結果の表示が次のとおりであったとします。
elvis is alive |
この場合は、elvis との間でパケットを送受信できます。この結果が得られなかったとすれば、ローカルホストとリモートホストの間のどこかに、ルーティングに関する問題があります。ping についての詳細は、「ping コマンド」と、ping(1M) のマニュアルページを参照してください。
パケットが正しく送受信されているかどうかを検査するには、netstat コマンドを使用します。
# netstat -i |
「netstat コマンド」 と netstat(1M) マニュアルページを参照してください。
ローカルルーティングテーブルを表示するには、netstat コマンドを使用します。
# netstat -r |
次に示すのはサンプル出力です。
Routing tables Destination Gateway Flags Refcnt Use Interface sahara deserted UGH 0 0 ie1 karakum labia UGH 0 0 ie1 frodo bilbo UGH 1 12897 ipdptp0 route7 route7 UGH 0 0 ie0 eastgate route71 UGH 0 158 ie0 backbone pitstopbb U 1 16087 ie1 dresdenpc route1 UG 0 0 ie1 loopback localhost U 2 113436 lo0 swan-bb pitstop U 406 146044 ie0 dallas2 route7 UG 0 0 ie0 trainingpc route62 UG 0 0 ie1 |
ありうる宛先ネットワークのそれぞれについて、ルーティングテーブルエントリが 1 つずつあることを確認してください。特に、Interface の欄に示される PPP デバイスが、Gateway の欄に示される適切なホスト名と適合していることが必要です。同様に、Gateway エントリは、Destination の欄の正しいエントリと適合していることが必要です。
この条件が満たされていない場合は、静的ルーティングを使用しているのであれば、適正な静的送信経路を追加します。in.routed を用いて動的ルーティングを使用しているときは、次のようにします。
次のように入力して、in.routed が実行中であるかどうかを確認します。
# ps -e | grep route |
それでもまだルーティングテーブルが正しくない場合は、スーパーユーザになって次にステップに進みます。
ps -e から入手したプロセス ID を kill の引数として指定して、in.routed を終了します。たとえば、1384 がプロセス ID であるとすれば、次のように入力します。
# kill 1384 |
# /usr/sbin/route -f |
# /usr/sbin/in.routed |
rsh を使用しようとして、Permission denied というメッセージを受け取った場合は、リモートシステムの /etc/hosts.equiv ファイルまたは /.rhosts ファイルに、送信側システムのホスト名が含まれていないか、行 + が含まれていません。
次にパケットフローを検査します。snoop コマンドを使って、ネットワークからパケットを観察し、各パケットの内容を観察します。 例 10-3 は、snoop からのサンプル出力を示します。
# snoop -d ipdptp0 Using device ipdptp0 (promiscuous mode) corey -> pacifica7 RLOGIN C port=1019 hugo -> ponc3 RPC R XID=22456455 Success ponc3 -> hugo NFS C WRITE FH=1B29 at 32768 commlab3 -> commlab4 TELNET R port=34148 commlab4 -> commlab3 IP D=129.144.88.3 S=129.144.88.4 LEN=46, ID=41925 commlab3 -> commlab4 TELNET R port=34148 commlab4 -> commlab3 ICMP Echo request commlab3 -> commlab4 ICMP Echo reply commlab4 -> commlab3 FTP C port=34149 commlab4 -> commlab3 FTP C port=34149 commlab3 -> commlab4 FTP R port=34149 commlab4 -> commlab3 FTP C port=34149
出力の最初の行の Using device ipdptp0 に含まれている ipdptp0 というデバイス名は、ポイントツーポイント接続を示しています。
snoop を使って回線の状態を検査するには、リンクが "up" 状態にあり、トラフィックがある程度生成されていることが必要です。
snoop は、ネットワークからパケットを取り込んで、その内容を表示します。snoop は、パケットフィルタモジュールとストリームバッファモジュールの両方を使用して、ネットワークから効率的にパケットを取り込みます。取り込んだパケットは、受け取ると同時に表示することも、後で見るためにファイルに保存しておくこともできます。
snoop は、単一行要約形式と複数行詳細形式のどちらでも、パケットを表示できます。要約形式の場合は、最高レベルのプロトコルに関するデータだけが表示されます。たとえば、NFS パケットについては NFS に関する情報だけが表示されます。その下位にある RPC、UDP、IP、イーサネットフレームの情報は抑止されますが、詳細形式オプションのどれかを選択した場合は表示されます。
snoop コマンドの詳細は、snoop(1M) のマニュアルページを参照してください。
モデム接続を正常に確立した後でリンクに問題がある場合は、PPP レベルの診断機能を用いた障害追跡を行うことができます。PPP レベルの診断機能は、リンクの動作状況に関する詳細情報を報告するので、どこに障害があるのかを突き止めるのに役立ちます。
診断情報を入手するには、debug_level 8 の行を asppp.cf ファイルの path セクションに追加します (データ通信に関する詳しい知識がある場合は、デバッグレベル 9 を用いれば、きわめて詳細な情報が得られます)。次に、PPP 診断機能を呼び出すサンプル構成ファイルを示します。
ifconfig ipdptp0 plumb nomada nubian-ppp up path interface ipdptp0 peer_system_name nubian-ppp #The name in the /etc/uucp/Systems file inactivity_timeout 300 #Allow five minutes before timing out debug_level 8 #Start up PPP diagnostics for this link
aspppd.conf ファイルについての詳細は、「/etc/asppp.cf 構成ファイルの編集」を参照してください。
監視したいホストについて診断を設定するには、次のようにします。
スーパーユーザになり、/etc ディレクトリに移動します。
アクセス権が必ず 600 に設定されるように、ファイルを保存します。
現行の aspppd デーモンを終了し、そして再起動します。
#kill PID #aspppd |
ここで、PID は aspppd のプロセス ID です。
PPP は、/var/adm/log/asppp.log に診断情報を報告します。
PPP が正常に実行されているときに、asppp.log ファイルには、通常の出力のほかに診断情報が含まれています。この節では、診断メッセージの意味について説明します。出力が違っている場合は、RFC 1331 を参照してください。
この節には、ローカルホストがモデムに構成情報を送り、モデムがリモートホストにダイヤルしようとしたときに発生するメッセージを収めてあります。これらの初期の挙動は、実際には UUCP デーモンが取り扱います。これらの挙動は、非同期 PPP 通信の UUCP 部分と考えることができます (UUCP の詳細は、第 12 章「UUCP のデータベースとプログラム」を参照してください)。
下記の 2 つのメッセージは、セッションの始めに常に表示されるものです。これは、aspppd デーモンが正常に起動されたことを示します。
11:53:33 Link manager (1057) started 04/14/94 11:53:33 parse_config_file: Successful configuration
次の行は、パケットがローカルホストの ipdptp0 インタフェースに送られたことを示しています。これは、ダイヤルアウトが正常に行われたかどうかを判断するのに役立ちます。たとえば、リモートマシンの ping を試みたときに、asppp.log 内にこのメッセージがないとすれば、おそらくルーティングの問題が原因でパケットが失われています。
次に、UUCP は、/etc/uucp/Systems ファイル内のチャットスクリプトの中にある Ppac7 に一致するエントリを見つけます。そして、デバイスタイプが ACUTEC であるエントリが見つかったことを報告します (Systems ファイルの詳細は、「/etc/uucp/Systems ファイル」を参照してください)。
11:53:46 process_ipd_msg: ipdptp0 needs connection conn(Ppac7) Trying entry from '/etc/uucp/Systems' - device type ACUTEC.
UUCP は、次に、/etc/uucp/Devices ファイルから、ACUTEC ダイヤラに関するダイヤル情報を見つけます。この情報が見つかると、UUCP は、ローカルホストの該当するシリアルポートをオープンし、その速度を 9600 に設定します (/etc/uucp/Devices の詳細は、「/etc/uucp/Devices ファイル」を参照してください)。
Device Type ACUTEC wanted Trying device entry 'cua/a' from '/etc/uucp/Devices'. processdev: calling setdevcfg(ppp, ACUTEC) fd_mklock: ok fixline(8, 9600) gdial(tb9600-ec) calle |
UUCP は、/etc/uucp/Dialers ファイルの中から tb9600 というエントリを見つけ、次のメッセージを送り出します。
Trying caller script 'tb9600-ec' from '/etc/uucp/Dialers' expect: ("") |
ホストは 2 秒間待ってから、モデムのレジスタを設定します。下記のログに示される情報は、個々のモデムに固有のものです。この情報は /etc/uucp/Dialers ファイルからとられます。
got it sendthem (DELAY) APAUSE APAUSE APAUSE T&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M<NO CR>) |
次の行は、モデムとホストマシンとの間のダイアログです。expect (OK^M) は、モデムが「了解」を送ることを予期していることを意味します。2 行目の終わりの got it という語句は、ホストがモデムから「了解」メッセージを受け取ったことを意味します。
expect: (OK^M) AAAT&D2E1V1X1Q0S2=255S12=255S50=6S58=2^M^M^JOK^Mgot it |
次にホストは下記の文字列をモデムに送り、実際にはモデムがダイヤリングを行います。2 行目の電話番号は、/etc/uucp/Systems ファイル内のリモートホストに関するエントリから検索されます。
sendthem (ECHO CHECK ON A^JATTDDTT99003300887744^M^M<NO CR>) |
expect で始まる行は、ローカルホストが、モデムから 9600 bps の速度であるという応答を受け取ることを予期していることを意味します。その次の行は、モデムが応答したことを示しています。
expect: (CONNECT 9600) ^M^JCONNECT 9600got it |
次の行は、リンク上でハードウェアフロー制御が開始されたことを示しています。ホストは、フロー制御情報を /etc/uucp/Dialers ファイルから入手します。
STTY crtscts |
その後の一連のメッセージは、ローカルホストが、リモートホストから標準的な UNIX ログインプロンプトが送られてくるのを待っていることを示しています。
getty ret 8 expect: ("") got it sandiest (^J^M) expect: (login:)
次に出るメッセージは、ローカルホストがリモートからのログインプロンプトを受け取ったことを示します。ローカルホストは、リモートホストについての /etc/uucp/Systems エントリ内のチャットスクリプトから、該当するログインシーケンスを検索します。このシーケンスは Ppong^M で、リモートホストがログインするにはこれが必要です。
^M^J^M^Jlogin:got it sendthem (Ppong^M) |
下記のメッセージでは、ローカルホストは、リモートホストからの ssword プロンプトを待ちます。このプロンプトを受け取ると、ローカルホストは、リモートホストに関する /etc/uucp/Systems エントリ内のチャットスクリプトから検索したパスワードを送ります。
expect: (ssword:) login: Ppong^M^JPassword:got it |
下記のメッセージは、ダイヤリングとモデム接続が正常に完了したことを示しています。
sendthem (ppptest1^M) call cleanup(0)^M |
この時点で、ローカルホストとリモートホストの間のリンクが確立され、そして PPP 通信が開始されます。
セッションのこの部分の最初のいくつかの行は、構成要求 (Config-Req) です。これは、リモートホストに送られる最初の PPP パケットです。構成要求は、リンク制御プロトコル (LCP) パケットの一例です。このパケットは、構成を設定することを要求し、そして、エンドポイントマシン間の PPP リンクを設定します。 例 10-4 は、サンプルの構成要求を示します。
11:54:20 004298 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=4c LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
以下、例 10-4 に示した構成要求について説明します。
11:54:20 - タイムスタンプフィールド。パケットが送られた時刻を示す
004298 - パケットの番号
ipdptp0 - 使用するネットワークインタフェース
SEND PPP ASYNC - モデムが非同期 PPP を送信していることを示す
29 Octets - ホストが送ったデータの量
LCP - 送信するパケットタイプ
ID=4c - パケットに関連付けられている識別子。これは実際にはパケットの一部
LEN=24 - パケットの LCP 部の長さ
残りの項目は、ホスト間でのネゴシエーションを必要とするオプションのリストです。
MRU=1500 - 最大受信単位 (MRU)。呼び出し側ホストがリモートホストから受信できる最大パケットサイズ
ACCM=00000000 - 非同期文字マップ (ACCM)。送信でエスケープする制御文字をリモートホストに知らせるために送られるマスク
MAG#=69f4f5b2 - マジックナンバフィールド。ループバック検出メカニズムに使用される
ProtFCOMP AddrCCOMP - フレームヘッダの特定の部分 (プロトコルフィールド、アドレスフィールド) の圧縮をリモートホストに要求する
その後のいくつかの行は、無効な PPP パケットを報告しています。これらのパケットは、実際には UNIX テキストを送信しようとしているリモートホストから送られてきたものです。これは PPP に問題があることを示すものではありません。
11:54:20 004299 ipdptp0 RECEIVE {Invalid ppp packet}PPP ASYNC 7 Octets [BAD FCS] {Unrecognized protocol: 1} 11:54:20 004299 ipdptp0 RECEIVE PPP ASYNC 73 Octets [BAD FCS] {Unrecognized protocol: 880a}
次のパケットでは、ローカルホストはリモートホストからの構成要求を受け取り、さらに別の構成要求を送ります。これら 2 つのパケットは、ID フィールド以外の部分はどちらも同じです。2 つのパケットは ID フィールドにより区別されます。
11:54:21 004301 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- Req ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP 11:54:21 004302 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-Req ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
次のパケットでは、ローカルホストは、リモート要求に対する確認として、構成肯定応答 (Config-ACK) を送ります。
11:54:21 004303 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK ID=35 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP |
ローカルホストは、リモートホストからの構成要求 (Config-Req) を受け取ります。
11:54:21 004304 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- Req ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP |
次のパケットでは、ローカルホストはリモートホストから送られてきた第 2 のパケットを確認し、リモートホストの肯定応答を受け取ります。
11:54:21 004305 ipdptp0 SEND PPP ASYNC 29 Octets LCP Config-ACK ID=36 LEN=24 MRU=1500 ACCM=00000000 MAG#=a8562e5f ProtFCOMP AddrCCOMP 11:54:21 004306 ipdptp0 RECEIVE PPP ASYNC 29 Octets LCP Config- ACK ID=4d LEN=24 MRU=1500 ACCM=00000000 MAG#=69f4f5b2 ProtFCOMP AddrCCOMP |
次のパケットでは、ローカルホストは IP 伝送に関するパラメータについてのネゴシエーションを行います。LEN=16 はパケットサイズを表します。VJCOMP は、Van Jacobson のヘッダ圧縮を示しています。IPADDR の後にあるのは呼び出し側ホストの IP アドレスです。
11:54:21 004307 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config- Req ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.70 |
次のパケットは、ローカルホストがリモートホストから、IP アドレスを含む IP 構成を受け取ったことを示しています。
11:54:22 004308 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP Config-Req ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.71 |
ローカルホストは次の ACK をリモートホストに送り、リモートホストからの ACK を受け取ります。
11:54:22 004309 ipdptp0 SEND PPP ASYNC 21 Octets IP_NCP Config- ACK ID=37 LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.71 11:54:22 004310 ipdptp0 RECEIVE PPP ASYNC 21 Octets IP_NCP Config-ACK ID=4e LEN=16 VJCOMP MAXSID=15 Sid-comp-OK IPADDR=192.9.68.70 |
下記の最初のメッセージは、リンク上で IP が起動されたことを示しています。第 2 のメッセージは、ローカルホストがリンクを介して IP トラフィックを送信していることを示しています。
11:54:22 start_ip: IP up on interface ipdptp0, timeout set for 120 seconds 11:54:24 004311 ipdptp0 SEND PPP ASYNC 89 Octets IP_PROTO |
下記の最初のメッセージでは、ローカルホストはリモートホストからの IP トラフィックを受け取ります。その後のメッセージは、アイドルタイムアウトが原因でインタフェースが切り離されたことを示しています。
11:54:25 004312 ipdptp0 RECEIVE PPP ASYNC 89 Octets IP_PROTO 11:56:25 process_ipd_msg: interface ipdptp0 has disconnected 11:56:25 disconnect: disconnected connection from ipdptp0 |
下記のメッセージからは、終了シーケンスを開始します。最初のメッセージは、リモートホストが IP 層を終了するためのパケットを送ったことを示しています。第 2 のメッセージは、終了要求に対するローカルホストの肯定応答です。
11:56:25 004313 ipdptp0 RECEIVE PPP ASYNC 9 Octets IP_NCP Term- REQ ID=38 LEN=4 11:56:25 004314 ipdptp0 SEND PPP ASYNC 9 Octets IP_NCP Term-ACK ID=38 LEN=4 |
ローカルホストは、LCP 層の終了要求を受け取ります。第 2 のメッセージはその要求に対する肯定応答であり、その結果正常なシャットダウンが行われます。
11:56:25 004315 ipdptp0 RECEIVE PPP ASYNC 9 Octets LCP Term-REQ ID=39 LEN=4 11:56:25 004316 ipdptp0 SEND PPP ASYNC 9 Octets LCP Term-ACK ID=39 LEN=4
次のメッセージはリンクが閉じられたことを示しています。
11:56:29 004317 ipdptp0 PPP DIAG CLOSE |
この章には、第 9 章「PPP の構成」で述べた基本リンクに比べて少々特殊な PPP リンクを構成するために必要な情報を収めてあります。この章では、主として 2 つの種類の PPP リンクの構成方法について説明します。2 つの種類とは、動的ポイントツーポイントリンクを持つダイヤルインサーバと、仮想ネットワーク (これはマルチポイントリンクを使用します) です。章の終わりには、asppp.cf 構成ファイルで使用できるすべてのキーワードのリストを示してあります。
動的ポイントツーポイントリンクを持つダイヤルインサーバを使用するサイトでは、ポイントツーポイント通信の利点を最大限に活用することができます。この構成タイプについては、第 7 章「PPP の概要」で概説しました。この構成では、必要時提供方式で動的にポイントツーポイントリンクを割り当てる少なくとも 1 つのダイヤルインサーバと、リモートホストとの間で通信が行われます。この節では、図 11-1 に示すサンプル構成に基づいて説明を進めます。
各リモートホストは、標準のポイントツーポイントリンクを使ってダイヤルインサーバと通信します。しかし、図 9-1 に示したマルチポイントダイヤルインサーバとは違って、ダイヤルインサーバ mojave は、動的ポイントツーポイントリンクを介して呼び出し側ホストに接続されます。リモートホストのどれかが接続を確立しようとすると、サーバが使用可能なリンクを割り当てます。
動的リンクの基礎概念は、接続確立のたびにサーバがクライアントに IP アドレスを供給するというものです。接続を確立すると、使用可能な IP インタフェースをサーバがクライアントに割り当てます。その後、接続が継続している間、インタフェースのリモート IP アドレスがクライアントの IP アドレスになります。接続を終了すると、使用可能なインタフェースのプールに IP インタフェースが戻され、別の接続に使用できる状態になります。
動的リンクの構成には、リモートホスト対マルチポイントダイヤルインサーバの場合と同じ一般的な手順を用います。この手順については、「構成プロセスの概要」に説明があります。ただし、動的ポイントツーポイントリンクには独自の必要条件がいくつかあり、そのため構成に関係するファイルに対する修正のしかたも少々異なります。
動的割り当て PPP リンクを使用する各マシンについて、/etc/inet/hosts ファイルにホスト情報を追加する必要があります。PPP エンドポイントの IP アドレスについては次の規則があります。
ダイヤルインサーバの場合は、そのサーバの一次ネットワークインタフェースの IP アドレス (たとえば le0、smc0 など) を、動的リンクのアドレスとして使用する必要があります。
動的リンクでは、各リモートホストに IP アドレスを割り当てる (静的リンクの場合) 必要はありません。ただし、サーバ上のポイントツーポイント IP インタフェースのそれぞれにリモート IP アドレスを割り当てる必要があります。使用可能な IP インタフェースの数は、サーバに接続されたモデムの数と一致します。たとえば、モデムが 3 つある場合、ポイントツーポイント IP インタフェースと IP アドレスが 3 つずつ必要です。
クライアント上で ifconfig コマンドを正しく実行するには、ダミーの IP アドレスを入れなければなりません。PPP が起動すると、このアドレスはクライアントの IP インタフェースに割り当てられたローカル IP アドレス用のプレースホルダとして機能します。
IP インタフェースに割り当てられるリモート IP アドレスに制限はありません。ただし、明確にするには、同じサブネットに属する IP アドレスだけを入れるのが最適です。
動的リンク構成に含まれるすべてのマシンで、hosts データベースを更新する必要があります。
リモートマシンの hosts データベースを構成するための手順は、次のとおりです。
リンクの反対側にある各ダイヤルインサーバについて、一次ネットワークインタフェースの IP アドレスとホスト名を、/etc/inet/hosts ファイルに追加します。
たとえば、図 11-1 では、nomada、nomadb、nomadc の /etc/inet/hosts ファイルには、ダイヤルインサーバ mojave の一次ネットワークインタフェースの IP アドレスが入ります。
ダミー IP アドレスを追加します。
この IP アドレスが使用されるのは、PPP の起動時だけです。
nomadc の /etc/inet/hosts ファイルは、次のように表示されます。
# Internet host table # 127.0.0.1 localhost loghost 192.41.40.55 mojave 1.2.3.4 dummy |
ダイヤルインサーバの物理ネットワーク上にあって、リモートホストからリモートログインできるすべてのマシンの IP アドレスを、/etc/inet/hosts ファイルに追加します。
物理ネットワーク上にあるネームサーバのデータベースを、リモートホストのホスト名と IP アドレスに更新します。
ダイヤルインサーバの hosts データベースには、PPP 固有のアドレスを追加する必要はありません。動的割り当てリンクは、サーバのネットワークインタフェースを使用する必要があります。したがって、ダイヤルインサーバの hosts データベースを構成するには、次のようにします。
サービス対象の各リモートホストについて、サーバの /etc/inet/hosts ファイルにエントリを追加します。
物理ネットワーク上のすべてのマシンの /etc/inet/hosts ファイルに、それぞれが通信することのできるリモートホストについてのエントリを追加します。
構成プロセスの次のステップでは、/etc/passwd ファイルと /etc/shadow ファイルを編集します。動的リンク構成の場合も、リモートホスト対マルチポイントダイヤルインサーバ構成の場合と同じ手順で、これらのファイルを編集します。/etc/passwd ファイルと /etc/shadow ファイルの詳細は、「/etc/passwd ファイルの修正」を参照してください。
動的リンク構成用の asppp.cf 構成ファイルには、リモートホストに関する情報と、PPP リンクに使用するインタフェースに関する情報が含まれていなければなりません。ダイヤルインサーバがブートした後、リモートエンドポイントからサーバが呼び出されるたびに、リンクマネージャはこの情報を使って通信を確立します。
リモートホスト用の asppp.cf 構成ファイルは、「基本構成ファイルの各部分」で説明したファイルと同じですが、パラメタ negotiate_address が追加されている点が異なります。
ifconfig ipdptp0 plumb dummy mojave up path interface ipdptp0 peer_system_name mojave-ppp connectivity_timeout 300 negotiate_address on |
negotiate_address パラメタは、ローカル IP アドレスの割り当てがネゴシエーションによって取得されて動的に割り当てられているかどうかを示します。設定が on の場合、サーバから供給された IP アドレスが、接続中にクライアントのローカルアドレスとして使用されます。
ダイヤルインサーバが着信パケットを受信すると、リンクマネージャは構成ファイルの path セクションを読んで、リモートエンドポイントを識別し、使用するインタフェースを決定します。例 11-1 に示す構成ファイルには、インタフェースキーワードは含まれていません。代わりに、リンクマネージャは、defaults セクションに設定されているインタフェース情報を使用します。
動的割り当てリンクを持つダイヤルインサーバ用の asppp.cf 構成ファイルは、例 11-1 のようになります。
ifconfig ipdptp0 plumb mojave clienta down ifconfig ipdptp1 plumb mojave clientb down ifconfig ipdptp2 plumb mojave clientc down # This means grab whatever interface is available (not in use) defaults interface ipdptp* # Each path specifies a machine that might dial up / log # in to this server path peer_system_name tamerlane # nomada uses the login name # tamerlane path peer_system_name lawrence # nomadb uses the name lawrence # for login path peer_system_name nomadc |
動的割り当てリンクを持つダイヤルインサーバ用の ifconfig セクションの構文は、次のとおりです。
ifconfig ipdptpn plumb server-name client-address down
例 11-1 には、3 つの ifconfig 行があり、それぞれポイントツーポイントインタフェースを初期化しています。
ifconfig ipdptp0 plumb mojave clienta down ifconfig ipdptp1 plumb mojave clientb down ifconfig ipdptp2 plumb mojave clientc down |
動的割り当てリンクを構成するときに、asppp.cf ファイルに defaults セクションを含めることができます。このセクションでは、その後に asppp.cf ファイル内に keyword が現れたときに、keyword に代入するデフォルトの値を設定します。defaults セクションの構文は次のとおりです。
default keyword |
例 11-1 では、キーワード interface を使って ipdptp* をインタフェースとして定義することにより、動的リンクを指定しています。ワイルドカードを示すアスタリスクは、ifconfig セクションで定義されている任意の使用可能な ipdptp インタフェースを使用するよう、リンクマネージャに指示しています。したがって、サーバ mojave のリンクマネージャは、ipdptp0、ipdptp1、ipdptp2 のうち、「ダウン」として構成されている最初のインタフェースを使用します。
動的リンクを持つサーバ用の構成ファイルには、そのサーバとの接続の確立が許されているすべてのリモートホストについての path セクションが含まれていなければなりません。path セクションの構文は次のとおりです。
path peer_system_name endpoint-username |
interface キーワードは、path セクションの中で定義されていません。これは、この値が defaults セクションで定義されているからです。 この場合の peer_system_name キーワードと peer_ip_address キーワードの意味は、マルチポイントサーバ用の構成ファイルの場合と同じです。詳細は、「マルチポイントダイヤルインサーバの path セクション」を参照してください。
asppp.cf ファイルでは、上記のほかに、エンドポイントがどのように通信するかを定義するためのキーワードをいくつか指定できます。これには、「構成キーワード」で説明するセキュリティキーワードも含まれます。
仮想ネットワークは、それぞれ離れた場所にあるいくつかのスタンドアロンコンピュータを、互いに PPP マルチポイントリンクで接続したものです。仮想ネットワークの概念については、「仮想ネットワーク」で紹介しました。この節では、仮想ネットワークを構成する方法について説明します。
図 11-2 に示すネットワークは、3 つの単独コンピュータから成っています。ネットワークの各メンバは、マルチポイント PPP リンクを介して他のメンバに接続しています。したがって、このようなネットワークを作成するには、ネットワーク管理者 (そしておそらくリモートロケーションの他のネットワーク管理者) は、関与する各ホストでマルチポイント PPP リンクを構成する必要があります。
マルチポイントリンクの構成には、マルチポイントダイヤルインサーバの場合と同じ一般的な手順を用います。この手順については、「構成プロセスの概要」に説明があります。ただし、仮想ネットワークには独自の必要条件がいくつかあり、それに従ってネットワーク内の各ホストを構成する必要があります。
仮想ネットワーク内の各マシンについて、/etc/hosts ファイルにホスト情報を追加する必要があります。PPP エンドポイント用に使用する IP アドレスを入力するときは、次の規則に従ってください。
ポイントツーポイントリンクには PPP 固有の IP アドレスを指定する。物理ネットワーク内でまだ構成されていないマシンの場合は、PPP リンク用の IP アドレスを作成する必要がある。このアドレスが、ホストの一次ネットワークインタフェースになる
仮想ネットワークのネットワーク番号を作成する。詳細は、「PPP リンクへのネットワーク番号の割り当て」を参照
構成プロセスの最初のステップでは、仮想ネットワークに関する情報によって、hosts データベースと networks データベースを更新します。
各マシンの /etc/inet/hosts ファイルには、このホストからアクセスできるすべてのネットワークメンバに関するアドレス指定情報が含まれていることが必要です。たとえば、図 11-2 に示したネットワーク内の各ホストは、次のような情報を持っていることが必要です。
# Internet host table # 127.0.0.1 localhost loghost 192.41.47.15 nomada 192.41.47.20 nomadb 192.41.47.12 nomadc
仮想ネットワークは一意な IP アドレスを必要とするので、このアドレスを networks データベースに入力する必要があります。たとえば、図 11-2 に示したネットワークの番号は 192.41.47 です。さらに、このネットワーク上のホストが他のネットワークと通信する必要がある場合は、このネットワークを InterNIC のアドレス指定機関に登録する必要があります。networks データベースの編集方法については、第 4 章「ネットワーク上での TCP/IP の構成」を参照してください。
仮想ネットワーク上の各ホストは、ネットワークのアドレスが入ったエントリを、/etc/inet/networks ファイル中に持っている必要があります。たとえば、ネットワーク 192.41.47 の各ホストは、/etc/inet/networks の中に次のようなエントリを持っていることが必要とされます。
# Internet networks # # arpanet 10 arpa # ucb-ether 46 ucbether # # local networks loopback 127 ppp 192.41.47 #remote sales offices |
構成プロセスの次のステップでは、UUCP データベース、/etc/passwd ファイル、/etc/shadow ファイルを編集します。仮想ネットワーク内のマシンについてこれらのファイルを編集する方法は、マルチポイントダイヤルインサーバ構成の場合と同じです。UUCP 関係の情報については、「UUCP データベースの編集」を、そして passwd ファイルについては、「/etc/passwd ファイルの修正」を参照してください。
仮想ネットワーク上のローカルマシン用の構成ファイルには、そのネットワーク内にあってローカルホストからアクセスできるすべてのリモートホストに関する情報が含まれていることが必要です。さらに、仮想ネットワーク上のマシンは、どれもダイヤルインとダイヤルアウトの両方の機能を備えたものとして構成されていなければなりません。ローカルホストマシンがブートすると、リンクマネージャは asppp.cf ファイルを読んで通信を確立します。
例 11-2 は、仮想ネットワーク 192.41.47 の nomada 用として設定した構成ファイルです。
# /etc/asppp.cf for hosta ifconfig ipd0 plumb nomada netmask + up defaults interface ipd0 path peer_ip_address nomadb peer_system_name lawrence # name machine logs in with path peer_ip_address nomadc peer_system_name azziz |
例 11-3 は、仮想ネットワーク 192.41.47 の nomadb 用として設定した構成ファイルです。
# /etc/asppp.cf for nomadb ifconfig ipd0 plumb nomadb netmask + up defaults interface ipd0 path peer_ip_address nomada peer_system_name tamerlane # name the machine logs in with path peer_ip_address nomadc peer_system_name azziz |
asppp.cf ファイルを編集することによってセキュリティを設定し、リンクの各部分が、パスワード認証プロトコル (PAP) または誰何ハンドシェーク認証プロトコル (CHAP) に応答するかどうかを指定できます。PAP と CHAP については、「PPP のセキュリティ」に説明があります。asppp.cf ファイルを編集するには、一連のキーワードを追加します。この節では、認証システムはリンクまたは誰何を開始するシステムであり、これは多くの場合サーバです。対等システムはリンクの反対側にあるシステムであり、これは多くの場合クライアントです。
追加するキーワードは、require_authentication と will_do_authentication です。認証システムつまりサーバは一般に認証を要求し、対等システムつまりクライアントは一般に認証行為を行います。
表 11-1 認証システムのキーワードと関連の文字列
require_authentication chap |
|
---|---|
chap_peer_secret |
|
chap_peer_name |
表 11-2 対等システムのキーワードと関連の文字列
will_do_authentication chap |
|
---|---|
chap_secret |
|
chap_name |
リンク上の各マシンについて require_authentication キーワードを追加して、PAP セキュリティと CHAP セキュリティのどちらを使用するかを指定します。
will_do_authentication キーワードを使って、リンク上で PAP または CHAP セキュリティを使用する各リモートホストについて、リモートホストの /etc/asppp.cf ファイルにエントリを追加します。
これらのキーワードは明示的に指定することも、パスのデフォルト値を使用することもできます。各キーワードが何を指定するかについては、表 11-3 を参照してください。例は 例 11-4に示してあります。
PAP と CHAP の両方が存在する場合は、認証システムはまず CHAP を試みる。失敗するとリンクは終了する。認証システムは PAP を試みない。
PAP と CHAP の認証キーワードのデフォルトはオフである。キーワードの構文は次のとおり
require_authentication off | pap[chap] | chap[pap] will_do_authentication off | pap[chap] | chap[pap] |
pap_id と pap_password キーワードまたは pap_peer_id と pap_peer_password キーワードに対する値を、関連のパスに指定しなかった場合は、それぞれの値は NULL 文字列に設定されます。
該当するパスについて、chap_name、chap_secret、chap_peer_secret、chap_peer_name キーワードと値を指定する必要があります。
例 11-4 は、PAP と CHAP の認証を必要とするサーバ mojave 用の asppp.cf ファイルを示しています。対等システムは、nomada (PAP) と nomadb (CHAP) です。
ifconfig ipdptp0 plumb mojave nomada up ifconfig ipdptp1 plumb mojave nomanb up path peer_system_name tamerlane require_authentication pap #tells nomada that mojave #requires pap authentication pap_peer_id desert pap_peer_password oasis path peer_system_name lawrence require_authentication chap #tells nomadb that mojave #requires chap authentication chap_peer_name another¥sdesert chap_peer_secret secret¥soasis¥swith¥007bell
例 11-5 に示された mojave のリモートホスト nomada は、PAP と CHAP の両方を認証しようしています。
ifconfig ipdptp0 plumb tamerlane mojave up path interface ipdptp0 peer_system_name mojave will_do_authentication chap pap #nomada tells mojave #that it will do chap and #pap authentication pap_id desert pap_password oasis chap_name desert¥srain chap_secret %$#@7&*(+|`P'12 |
例 11-6 に示された mojave のリモートホスト nomadb は、CHAP を認証しようしています。
ifconfig ipdptp0 plumb nomadb mojave private up path interface ipdptp0 peer_system_name mojave will_do_authentication chap #nomadb tells mojave that it #will do chap authentication chap_name another¥sdesert chap_secret secret¥soasis¥swith¥007bell |
一般に、CHAP と PAP の両方が構成ファイルに組み込まれていて、サーバが認証を要求し、リモートホストが認証を行おうとするのが、理想的な形です。しかし、逆にリモートホストの方が認証を要求するようにすることも可能です。CHAP シークレットは安全な手段で送付する必要があります。そのためには、一般に CHAP シークレットは先方に手で渡すことが必要です。
この節では、asppp.cf 構成ファイルで使用できる構成キーワードと、それぞれについて定義する必要のある値について説明します。これらのキーワードのほとんどはオプションです。必須のものについてはその旨示してあります。キーワードの詳しい説明については、RFC 1331、1332、1333、1334 を参照してください。
表 11-4 は、すべての asppp.cf ファイルに含まれていなければならない必須キーワードの一覧です。
表 11-4 asppp.cf の必須キーワード
キーワード |
値の定義 |
---|---|
parameters に指定する値で ifconfig コマンドを実行するよう、リンクマネージャに指示する。詳細は、「asppp.cf ファイルの ifconfig セクション」、「マルチポイントダイヤルインサーバの ifconfig セクション」、そして ifconfig(1M) のマニュアルページを参照 |
|
この (現行の) パスの属性としてグループ化するトークンシーケンスの始まりを指定する。現行パスを形成する属性の集合は、後続の path キーワード、defaults キーワード、ファイルの終わり文字のどれかが生じた時点で終了する |
|
ネットワーク内の各インタフェースについて、ipdptp (静的ポイントツーポイント)、ipdptp* (動的ポイントツーポイント)、ipd (マルチポイント) のどれかのデバイスを指定する。ipdptpn と ipdn, の場合は、このキーワードは、n で定義される特定のインタフェースを現行パスに関連付ける。n は 0 もしくは正の整数でなければならない。この数は、path セクションに定義されているインタフェースと、ifconfig セクションに指定されているインタフェースが一致するようにする
ipdptp** インタフェースの場合は、* は、インタフェースが、「ダウン」として構成されているどのポイントツーポイントインタフェースにも一致することを示す |
|
ダイヤルアウトマシンでは、ローカルマシンから呼び出したいリモートエンドポイントのホスト名 (hostname) を指定する。この名前は、/etc/uucp/Systems ファイルの中のシステム名と同じである。リモートシステム名を現行パスに関連付ける。この名前は、/etc/uucp/Systems ファイルから、アウトバウンド接続に関する、モデムと対等システムに固有の情報を見つけるために使用される ダイヤルインマシンでは、そのダイヤルインマシンにログインするときにリモートマシンが使用するユーザ名 (username) を指定する。username と、接続の獲得に使用されたログイン名との突き合わせによって、適正なパスが決定される |
|
宛先ホストアドレスを指定する。これは、マルチポイントリンクの場合に限り必要とされる。このアドレスは現行パスに関連付けされる。パスがポイントツーポイントインタフェースを示している場合は、この値は無視される。アドレスの形式は、ドット付き 10 進数、16 進数、シンボルのどれでもよい |
表 11-5 には、PPP 構成をさらに進んで定義するために使用可能な、asppp.cf のオプションキーワードを示します。
表 11-5 asppp.cf のオプションキーワード