test

TCP/IP とデータ通信

パート II PPP によるネットワークの拡張

パート II では、ネットワーク上で非同期 PPP 通信リンクを設定し管理する方法について説明します。この章の説明は、読者が、TCP/IP に関する十分な知識を持つ熟練したネットワーク管理者であることを前提としています。

第 7 章 PPP の概要

この章では、TCP/IP プロトコル群に含まれているデータリンクプロトコルの 1 つである Solaris PPP の概要を示します。仕様、最も典型的な PPP 構成の紹介、PPP に関連した用語の定義について説明します。

Solaris PPP の概略

PPP を用いると、モデムと電話回線を使って、物理的に離れた場所にあるコンピュータとネットワークを接続することができます。ユーザーは PPP を使って、自宅や職場から、所属するサイトのネットワークに接続できます。また、PPP ソフトウェア、モデム、電話回線を組み合わせて、別々の場所にあるネットワーク同士を結ぶルーターとして使用することもできます。PPP は、このようなマシンとネットワークを構成するための方法を提供します。この章ではその方法を紹介します。

Solaris PPP の仕様

Solaris PPP は、標準化されたデータリンクレベルのポイントツーポイントプロトコル (PPP) の非同期実装の 1 つです。PPP は TCP/IP プロトコル群に含まれているもので、多くのルーターシステムのベンダーや端末集線装置から提供されています。Solaris PPP には標準化されたカプセル化プロトコルが組み込まれているので、ネットワーク層プロトコルにとってデータグラムの転送が透過的になります。

Solaris PPP の主な特性には次のものがあります。

このプロトコルの主な機能には次のものがあります。

PPP が使用する伝送機能

PPP は、Solaris ソフトウェアを実行するほとんどのマシンに備わっている CPU シリアルポートを使用した、RS-232-C(V.24) インタフェースをサポートします。さらに、PPP は、Solaris ソフトウェアを実行するマシンの製造元の多くが提供またはサポートしている、オプションの非同期シリアルポートでも動作します。PPP は、使用するマシンのシリアルポートで使用可能な最大のデータ速度をサポートします。マシンのシリアルハードウェアがサポートしている速度については、コンピュータシステムの製造元にお問い合わせください。

注 -

x86 アーキテクチャのマシンには、一定の速度以上で実行される UART が必要です。

規格への適合性

PPP と、Solaris ソフトウェアに組み込まれているルーティング機能は、業界標準の規格に従って動作します。この規格は次のような機能をサポートしています。

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

PPP を用いると、モデムなどのような非同期デバイスをネットワークインタフェースとして使用できるようになります。Solaris PPP では、2 つの仮想ネットワークインタフェース ipdptpn と ipdn を構成できます (n は、インタフェースに割り当てるデバイス番号です)。

PPP ネットワークインタフェースは、仮想ネットワークインタフェースとみなされます。なぜなら、イーサネットインタフェースなどのようにネットワークハードウェアを含んでいないからです。さらに、PPP ネットワークインタフェースは特定のシリアルポートに関連付けられるものでもありません。PPP ネットワークインタフェースは、物理ネットワークインタフェースとともに /devices ディレクトリに入っています (物理ネットワークインタフェースについては、「ネットワークインタフェース」を参照してください)。

使用するネットワークインタフェースの種類は、設定したい PPP 通信リンクによって異なります。ipdptp インタフェースは、ポイントツーポイント PPP リンクをサポートしています。ipd インタフェースは、ポイントツーマルチポイントリンク (「マルチポイントリンク」と呼ばれる) をサポートしています。

PPP によるネットワークの拡張

この節では、PPP に関連する通信の概念を紹介します。また、最も一般的な PPP 構成についても説明します。

ポイントツーポイント通信リンク

Solaris PPP の最も一般的な使用目的は、ポイントツーポイント通信リンクを設定することです。一般的なポイントツーポイント通信構成は、2 つのエンドポイントを通信リンクで接続したものです。この一般構成では、エンドポイントシステムはコンピュータでも端末でもよく、切り離された状態でも、ネットワークに物理的に接続していてもかまいません。通信リンクという用語は、2 つのエンドポイントシステムを接続するハードウェアとソフトウェアを指します。図 7-1 にこの概念を示します。

図 7-1 基本的なポイントツーポイントリンク

Graphic

ダイヤルアウト操作とアウトバウンド通信

一方のエンドポイントが通信リンクの反対側のエンドポイントとの通信を望むとき、そのエンドポイントはダイヤルアウト操作を開始します。たとえば、エンドポイント B と通信する場合、その対等ホストであるエンドポイント A のユーザーは、rlogin end-point-B と入力します。すると、エンドポイント A は通信リンクを介してダイヤルアウトします。この場合、エンドポイント A はダイヤルアウトマシンとして機能することになります。rlogin コマンドは、モデムがエンドポイント B の電話番号をダイヤルすることを引き起こします。このコマンドが起動する動作と相手に渡す情報を、アウトバウンド通信と言います。

ダイヤルインとインバウンド通信

データが通信リンクを介してエンドポイント B に到達すると、エンドポイント B のシステムは着信データを受け取り、肯定応答信号をエンドポイント A に送って、通信を確立します。この場合、エンドポイント B は他のシステムからのダイヤルインを受け入れるので、ダイヤルインマシンとして機能することになります。通信の受信側に渡される情報と受信側が行う動作を、インバウンド通信と言います。

Solaris PPP がサポートするポイントツーポイント構成

Solaris PPP は、次の 4 つの種類のポイントツーポイント構成をサポートしています。

PPP リンクは、実質的にはローカルエリアネットワークと同じ種類の接続を提供しますが、ブロードキャスト機能だけはありません。以下の各節では、上記の構成についてそれぞれ簡単に説明します。各構成の設定方法については、第 8 章「PPP 構成の準備」で説明します。

2 つの単独ホストをポイントツーポイントリンクで接続

PPP を使用すると、異なる場所にある 2 つのスタンドアロンマシンを接続するポイントツーポイントリンクを設定できます。これにより、事実上、この 2 つのマシンだけからなるネットワークが作成されることになります。これはエンドポイントが 2 つしかなく、したがって最も単純なポイントツーポイント構成と言えます。図 7-1 に示した一般的な構成でも、このホストツーホスト構成が使われています。

可搬マシンをダイヤルインサーバーに接続

従来は、標準的なダイヤル呼び出し接続または一時接続の場合、ネットワークに接続できるのは ASCII 端末だけでした。Solaris PPP を用いれば、個々のマシンを PPP リンクの 1 つのエンドポイントとして構成することによって、それらのマシンを物理的に離れた場所にあるネットワークの一部とすることができます。この可搬接続は、頻繁に旅行するユーザーや在宅勤務のユーザーを含むネットワークの場合に、特に便利です。

図 7-2 に示す可搬コンピュータは、それぞれネットワーク上のエンドポイントシステムへのポイントツーポイントリンクを持っています。ネットワーク上のエンドポイントシステムを、ダイヤルインサーバーと言います。

図 7-2 可搬コンピュータと動的リンクを持つダイヤルインサーバー

Graphic

動的ポイントツーポイントリンクを持つダイヤルインサーバー

図 7-2 に示したネットワークのエンドポイントマシンは、動的ポイントツーポイントリンクを持つダイヤルインサーバーとして働きます。これをダイヤルインサーバーと呼ぶのは、リモートマシンがこのマシンにダイヤルインすることによってネットワークに入ることができるからです。サーバーは、あるマシンからダイヤルインの要求を受け取ると、必要時に提供するという方式でそのマシンに PPP リンクを割り当てます。

ダイヤルインサーバーは、動的ポイントツーポイントリンクまたはマルチポイントリンクを介してリモートホストと通信します。マルチポイントリンクについては、「マルチポイント通信リンク」で説明します。動的ポイントツーポイントには、ポイントツーポイント通信と同じ利点があります。つまり、リンク上で RIP を実行でき、ブロードキャストが使用可能になります。最も重要なのは、物理ネットワーク上の複数のマシンが、ダイヤルインサーバーとして機能することができるという点です。これはバックアップサーバーを構成できることを意味し、したがってサーバーの重複が可能となり、管理が容易になります。図 7-2 の各マシンはネットワークエンドポイントとは直接通信できますが、互いに直接通信することはできません。ダイヤルインサーバーエンドポイントを仲介として、相互に情報を受け渡しする必要があります。

2 つのネットワークをポイントツーポイントリンクで接続

PPP を使用すると、2 つのネットワークをポイントツーポイントリンクで接続し、各ネットワーク上の 1 つのシステムをエンドポイントとして機能させることができます。これらのエンドポイントは、図 7-1 に示したのと実質的に同じ方法で、モデムと電話回線を使って互いに通信します。ただし、この設定では、エンドポイント、モデム、PPP ソフトウェアは、各物理ネットワークのルーターとして働きます。この種類の構成方式を使用して、地理的に広い範囲にわたるインターネットワークを構築できます。

図 7-3 は、異なる場所にある 2 つのネットワークをポイントツーポイントリンクで接続した構成を示しています。

図 7-3 PPP リンクで接続された 2 つのネットワーク

Graphic

この例では、エンドポイント A と B、それぞれのモデム、公衆電話回線、PPP ソフトウェアが、ネットワーク間のルーターとして働きます。これらのネットワークには、物理ネットワーク間のルーターとして機能する別のホストが存在することもあります。また、PPP ルーターとして機能するホストが追加のネットワークインタフェースボードを備えていて、同時に物理ネットワークのルーターとして機能する場合もあります。

図 7-4 可搬コンピュータとマルチポイントダイヤルインサーバー

Graphic

マルチポイント通信リンク

Solaris PPP を使用して、マルチポイント通信リンクを設定できます。この種類の構成では、それぞれ個々のマシンが通信リンク上の 1 つのエンドポイントとして働きます。リンクの 1 つの端に複数のエンドポイントマシンが存在する場合もあります。これは、通信リンクの両端に 1 つずつしかエンドポイントがないポイントツーポイント構成とは異なります。

PPP がサポートするマルチポイント構成

PPP によって構成できるマルチポイントリンクには、次の 2 つの種類があります。

以下の各節では、これらの構成の概略を説明します。各構成の設定方法については、第 8 章「PPP 構成の準備」で説明します。

マルチポイントダイヤルインサーバー

図 7-4 では、地理的に離れた場所にある 3 台のコンピュータが、ネットワーク上のエンドポイントマシンへのポイントツーポイントリンクを介して、互いに通信します。しかし、ネットワークエンドポイントマシンは、マルチポイントリンクを介して可搬コンピュータと通信できるので、このマシンはマルチポイントダイヤルインサーバーとみなすことができます (「動的ポイントツーポイントリンクを持つダイヤルインサーバー」で説明したように、動的ポイントツーポイント接続を持つダイヤルインサーバーも設定できます)。

ダイヤルインサーバーは、マルチポイント PPP リンクの反対側にあるすべてのマシンと通信できます。図 7-4 の各マシンはマルチポイントダイヤルインサーバーとは直接通信できますが、各マシンどうしが直接通信することはできません。各マシンは、ダイヤルインサーバーを介して、互いに情報を受け渡しする必要があります。

仮想ネットワーク

PPP を使用して仮想ネットワークを設定できます。この設定では、モデム、PPP ソフトウェア、電話回線が、「仮想」ネットワークメディアとなります。イーサネットやトークンリングなどの物理ネットワークでは、コンピュータはケーブルで直接ネットワークメディアに接続されています。仮想ネットワークでは、現実のネットワークメディアは存在しません。

仮想ネットワーク上で各マシンをマルチポイント通信リンクにより接続した場合、マシンはどれも対等ホストとなります。各ホストは、モデムと電話回線を介して、他のエンドポイントマシンと通信できます。各コンピュータはダイヤルインマシンとしても機能するので、仮想ネットワーク上の対等ホストからのダイヤルインを受け入れることができます。

図 7-5 は、モデムと電話回線によって相互に接続されている可搬コンピュータで構成されている、仮想ネットワークを示しています。

図 7-5 可搬コンピュータの仮想ネットワーク

Graphic

各マシンはそれぞれ、仮想ネットワーク上の他のマシンから離れた場所にある別々のオフィスに設置されていますが、マルチポイント通信リンクを介して、他の対等ホストとの通信を確立できます。

PPP ソフトウェアの紹介

PPP のコンポーネントソフトウェアには以下のものがあります。

PPP ソフトウェアのインストールが終わると、PPP 用の実行制御スクリプトである /etc/init.d/asppp ファイルが作成されています。このファイルは、実行制御ディレクトリ内の他のいくつかのファイルにリンクしています。

図 7-6 に、PPP の各ソフトウェアコンポーネントと、それぞれの相互作用を示します。

図 7-6 PPP のコンポーネントソフトウェア

Graphic

リンクマネージャ

/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 ファイルを示します。

例 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) のマニュアルページを参照してください。

FIFO ファイル

PPP FIFO ファイル /tmp/.asppp.fifo は、aspppd と aspppls の間の通信に用いる名前付きパイプです。PPP ログインサービスがリンクマネージャに接続するためには、このファイルが /tmp に入っていなければなりません。 /tmp/.asppp.fifo ファイルは、リンクマネージャが作成、管理、削除を行います。

UUCP データベース

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 コマンドを入力して、リンクの反対側のホストからファイルをコピーしようとしたとすると、以下に示すような動作が生じます。

  1. rcp は、TCP/IP プロトコルスタックの各レベルを通してデータを送り出す。

  2. 仮想ネットワークインタフェース (ipdn または ipdptpn) が、IP パケットの形式でデータを受け取る。

  3. インタフェースは、アウトバウンド接続を開始するための接続要求を、aspppd リンクマネージャに送リ出す。

  4. リンクマネージャは以下のことを行う。

    1. 接続要求が、/etc/asppp.cf 構成ファイル中で構成されているパスに対応していることを確認する。

    2. UUCP データベースファイル (/etc/uucp/Systems、/etc/uucp/Devices、/etc/uucp/Dialers) を調べて、モデムと宛先システムに関する必要な情報を入手する。

    3. 宛先ホストへの電話呼び出しをかけるか、適切な直結シリアル回線に接続する。

  5. 対等ホストへの物理リンクが確立される。

  6. リンクマネージャは PPP を構成して開始する。

  7. データリンク層が確立され、対等ホスト上の PPP モジュールが通信を開始する。

  8. リンクマネージャはリンクを介した IP を使用可能にする。

その後、リンクマネージャは、アイドルタイムアウト、回線の切断、エラー条件などのイベントが発生するまで、接続を監視します。これらのイベントのどれかが発生すると、リンクマネージャは対等ホストとの接続を切り離し、アイドル状態に戻ります。

インバウンド接続の概要

インバウンド通信を開始するホストがログインすると、/usr/sbin/aspppls ログインサービスが呼び出され、以下のイベントが発生します。

  1. ログインサービスは、/tmp/.asppp.fifo ファイルを通してリンクマネージャに接続する。

  2. ログインサービスは、リンクの反対側のエンドポイントで使用するログイン名などの情報を、リンクマネージャに提供する。

  3. リンクマネージャはこのログイン名を使って、対応する構成済みのパスを、構成ファイルの中から見つける。

  4. リンクマネージャは、PPP を構成し起動する。

  5. データリンク層が確立され、対等ホスト上の PPP モジュールが通信を開始する。

  6. リンクマネージャはリンクを介した IP を使用可能にする。

その後、リンクマネージャは、アイドルタイムアウト、回線の切断、エラー条件などのイベントが発生するまで、接続を監視します。これらのイベントのどれかが発生すると、リンクマネージャは対等ホストとの接続を切り離し、アイドル状態に戻ります。

PPP のセキュリティ

構成に含まれているすべてのマシンに PPP をインストール後、PPP リンクに関する 1 レベルまたは 2 レベルのセキュリティを付加できます。

第 1 のレベルのパスワード認証プロトコル (PAP) は、最小限のセキュリティです。認証が確認されるかまたは接続が切断されるまで、パスワードを暗号化しない状態で回線上に送り出します。

第 2 レベルのセキュリティであるチャレンジハンドシェーク認証プロトコル (CHAP) は、ポイントツーポイントリンクの反対側にある対等ホストの識別情報を、定期的に検査します。認証者、つまり接続またはチャレンジ (Challenge) を開始するシステムが、対等ホストにチャレンジメッセージを送ります。これに対する応答が、リンクを介さずに渡されている「シークレット」と照合され、両者の値が一致すれば認証が確認されます。一致しない場合は、接続は切断されます。PPP のセキュリティを付加する方法については、「PAP/CHAP セキュリティのための asppp.cf の編集」で説明します。

第 8 章 PPP 構成の準備

PPP ソフトウェアを構成する前に、必要なハードウェアとソフトウェアの準備を整え、構成に必要な情報を収集する必要があります。この章では、構成の前に行う必要のある作業について説明します。主に次のような作業があります。

この章の末尾には、PPP リンクを構成する前に、上記の点を確認するためのチェックリストがあります。

構成に応じた要件の決定

Solaris PPP は、以下のようなさまざまな構成をサポートしています。

これらの構成については、 第 7 章「PPP の概要」 の 「PPP によるネットワークの拡張」で紹介しました。

この節では、構成を始める前に確認しておかなければならない情報と、行なっておかなければならない作業について、構成別に説明します。 設定したい構成に該当する節をお読みください。

検討を要する事項は次のとおりです。

リモートコンピュータ対ネットワークの構成

リモートコンピュータ対ネットワークは、最も一般的な非同期 PPP 構成です。この構成を使用するのは、リモートオフィスやユーザーの自宅にあるマシンが、ポイントツーポイント PPP リンクを介してダイヤルアウトし、ネットワーク上のダイヤルサーバーに接続する場合です。

リモートホスト対リモートホストの構成

ホスト対ホストの構成を確立するのは、物理的に異なる位置にある 2 つのリモートホスト間のポイントツーポイント通信を確立する場合です。この構成は、リモートオフィスにある 2 つのスタンドアロンマシンの間で情報を交換したい場合に便利です。物理ネットワークは関与しません。

ネットワーク対ネットワークの構成

ネットワーク対ネットワークの PPP 構成を使用するのは、物理的に離れた場所にある 2 つのネットワークを連結してインターネットワークを構築したい場合です。その場合は、モデムと PPP ソフトウェアが、ネットワークを相互に接続するルーターとして働きます。

動的ポイントツーポイントリンクを持つダイヤルインサーバー

動的ポイントツーポイントリンクは、リモートホストからアクセスするネットワークエンドポイントとして機能する、ダイヤルインサーバー用に使用できる 2 つの種類の構成のうちの 1 つです。この構成方式では、サーバーは、動的に割り当てられたポイントツーポイントリンクを介してリモートホストに接続します。ダイヤルインサーバーは、必要時提供の方式で動的リンクを使用して、サービス対象のリモートホストとの通信を確立します。

マルチポイントダイヤルインサーバー

マルチポイントリンクは、リモートマシンからアクセスするネットワークエンドポイントとして機能するダイヤルインサーバー用に使用できる、2 つの種類の構成のうちの 1 つです。この構成では、ダイヤルインサーバーは、同じマルチポイントリンクを介して複数のリモートホストを接続します。「リモートコンピュータ対ネットワークの構成」で説明したように、リモートホストは、常にポイントツーポイントリンクを介してダイヤルインサーバーに接続されます。

この構成を使用するのは、リモートホストとダイヤルインサーバーから成る独立したネットワークを定義したい場合です。

仮想ネットワーク上のホスト

仮想ネットワーク構成を使用するのは、電話回線、モデム、PPP ソフトウェアを使って、物理的に離れた場所にある 3 台以上のコンピュータを 1 つの仮想ネットワークにしたい場合です。

PPP リンク用の IP アドレス指定の決定

PPP リンクを介した通信ができるようにするには、リンクの一端にあるマシンが、リンクの反対側にある対等ホストのホスト名と IP アドレスを認識している必要があります。PPP 構成は、特定のアドレス指定スキーマを必要とすることがよくあります。この節では、各アドレス指定スキーマと、それぞれをどのような場合に使用するかについて説明します。

IP アドレスの指定

各エンドポイントマシンでは、次の場所にアドレス指定情報を指定します。

ローカルマシンの 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 データベースを編集する前に、使用する構成に適切なアドレス指定スキーマを決める必要があります。アドレス指定スキーマには次のものがあります。

一次ネットワークインタフェースと同じ IP アドレスの使用

この方式は、ポイントツーポイントリンクの場合にのみ使用できます。このアドレス指定スキーマでは、各エンドポイントについて一次ネットワークインタフェースのアドレスを指定します (一次ネットワークインタフェースについての詳細は、第 1 章「ネットワーク管理の概要」を参照してください)。このようなエンドポイントには次のようなものがあります。

ローカルエンドポイントの /etc/inet/hosts ファイルを編集するときに、一次ネットワークインタフェースの IP アドレスと、リンクの反対側の対等ホストのホスト名と IP アドレスを入力します。

一意な IP アドレスとホスト名の作成

この方式では、PPP ネットワークインタフェースに、一意なホスト名と IP アドレスを割り当てます (インタフェースを hostname-ppp と名付けるとよいでしょう)。このアドレス指定スキーマは次のものに使用します。

asppp.cf 構成ファイル中に、PPP ネットワークの一意なアドレスとホスト名を指定する必要があります。

新しいホスト名と IP アドレスを作成するには、「hosts データベース」の説明に従って、単にその名前とアドレスを /etc/inet/hosts ファイルに追加するだけです。

PPP リンクへのネットワーク番号の割り当て

PPP 構成用に新しいネットワーク番号を作成するのは、次のものが構成に含まれる場合です。

(ネットワーク番号については、第 3 章「ネットワークの計画」を参照してください)。

PPP リンクは、物理ネットワークメディアを含まないため、仮想ネットワークとなります。すべてのエンドポイントマシンの networks データベースに、その仮想ネットワークのネットワーク番号と、リンクするネットワークのネットワーク番号を入力する必要があります。

例 8-1 は、PPP を用いたインターネットワーク用の /etc/inet/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 は起動されません。したがって、マルチポイントリンクの場合は静的ルーティングを設定する必要があります。その方法については、「ホストで静的ルーティングを選択するには」を参照してください。

RIP を不使用にする

/etc/gateways ファイルによって、ポイントツーポイントリンク上で RIP を使用しないようにすることができます。このファイルはオペレーティングシステムに付属しているものではないので、テキストエディタを使って作成する必要があります。

RIP を使用しないようにするには、/etc/gateways に次のエントリを入力する必要があります。


norip ipdptpn

ipdptpn は、使用するポイントツーポイント PPP インタフェースのデバイス名です。

詳細は、in.routed(1M) のマニュアルページを参照してください。

PPP のハードウェア要件

基本的な PPP 構成には、コンピュータ、モデム、RS-232 電話回線が含まれます。しかし、構成を行う前に、選択したハードウェアが PPP をサポートするものであるかどうかを確認しておく必要があります。この節では、PPP で必要なハードウェアについて説明します。

ファイルスペースの要件

以下のディレクトリ内に、PPP 用の十分なスペースを確保する必要があります。

64 ビットの PPP 用には、以下のディレクトリ内に十分なスペースを確保する必要があります。

PPP は、/usr に約 243 K バイト、/ (ルート) に約 4 K バイトを必要とします。

64 ビットの PPP は、32 ビットの PPP と同じサイズのディスク容量を必要とします。/usr/kernel/drv/sparcv9 に 64 ビットドライバ、/usr/kernel/strmod/sparcv9 に 64 ビットモジュールがあります。

PPP 構成前のチェックリスト

このチェックリストは、PPP の構成の準備を整えるために使用します。構成プロセスに着手する前に収集する必要のある情報と、行う必要のある作業を列記してあります。

表 8-1 PPP 構成前のチェックリスト
/usr に使用可能な空き領域が 300 K バイトありますか。 はい/いいえ
/ (ルート) に使用可能な空き領域が 4 K バイトありますか。 はい/いいえ
 各エンドポイントのモデムが、V.32 または V.32bis 以上をサポートしていますか。 はい/いいえ
 ダイヤルインサーバーでシリアルポートマネージャを使用して、モデム用のシリアルポートを指定しましたか。 はい/いいえ
各エンドポイントマシンに Solaris PPP をインストールしてあることを確認しましたか (PPP をインストールしてない場合は、pkgadd プログラムまたは admintool ソフトウェアマネージャを使ってインストールできます。インストール方法については、『Solaris のインストール (上級編)』を参照してください)。 はい/いいえ
 各エンドポイントで別のバージョンの PPP が実行されていないことを確認しましたか (そのようなバージョンがある場合は、それぞれのマニュアルの説明に従って不使用にしてください)。 はい/いいえ
 PPP リンクに関与するすべてのコンピュータについて、使用する IP アドレスを決定しましたか。 はい/いいえ
 すべてのマシンのホスト名と IP アドレスをリストしてください。 _____________________ _____________________ _____________________ _____________________
 ダイヤルインサーバーの名前と IP アドレスを記入してください (該当する場合)。 _____________________
使用するネットワークインタフェースの名前を記入してください。  _____________________

第 9 章 PPP の構成

この章では、PPP を構成するための手順と情報を記載しています。説明に使用する例は、リモートホストとそのマルチポイントダイヤルインサーバーの両方の種類の PPP リンクを持つ構成を想定しています。その他の種類の PPP 構成の設定方法については、第 11 章「PPP リンクの調整」に記載されています。

構成プロセスの概要

第 8 章「PPP 構成の準備」で述べたプリインストール作業が終われば、いよいよ PPP の構成にとりかかることができます。

PPP については次のことを行う必要があります

  1. PPP ソフトウェアのインストール (まだインストールしてない場合)

  2. 関与するすべてのマシンの /etc/inet/hosts ファイルの編集

  3. すべてのダイヤルアウトマシンの UUCP データベースファイルの編集

  4. ダイヤルインマシンの /etc/passwd ファイルと /etc/shadow ファイルの編集

  5. リンク上の各マシンの /etc/asppp.cf ファイルの編集

  6. リンク上の各マシンでのリンクマネージャ aspppd の起動

  7. PPP が正常に実行されていることの確認

上記の作業 1 〜 4 は順番どおりに進めなくてもかまいませんが、PPP 構成ファイルの編集の前に、すべて完了しておく必要があります。

この章の各節では、PPP の構成のための手順について説明します。

PPP ソフトウェアのインストール

Solaris インストールプログラムを実行するときに配布ソフトウェア全体を選択すると、PPP ソフトウェアは自動的に組み込まれます。配布ソフトウェア全体を選択しなかった場合は、PPP を個別のパッケージとしてインストールできます。

インストールの確認

先へ進む前に、PPP リンクに含めるすべてのマシンに、Solaris バージョンの PPP をインストールしてあることを確認する必要があります。リンクに含める各エンドポイントについて、次のように入力します。 


# pkginfo | grep ppp

32 ビットPPP がインストールされている場合は、次のパッケージ名が表示されます。 


SUNWpppk       # Contains kernel modules
SUNWapppu      # Contains the link manager and login service
SUNWappp       # Contains configuration files

64 ビットPPP がインストールされている場合は、次のパッケージ名が表示されます。


SUNWpppk       # Contains the 32-bit kernel modules
SUNWpppkx      # Contains the 64-bit kernel modules
SUNWapppu      # Contains the link manager and login service
SUNWappp       # Contains configuration files

PPP がインストールされていないエンドポイントシステムがある場合は、pkgadd プログラムまたは admintool ソフトウェアマネージャを使ってインストールしてください。

注 -

pkgadd を使って PPP をインストールする場合は、上記のスクリーンボックスに並べた順序でパッケージをインストールする必要があります。

pkgadd プログラムと admintool ソフトウェアマネージャについての詳細は、『Solaris のシステム管理 (第 1 巻)』を参照してください。

PPP 構成例

この節と以後の各節では、最も一般的な 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 も持っています。

図 9-1 リモートホストとマルチポイントダイヤルインサーバーのネットワーク例

Graphic

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

構成に含まれるすべてのマシンに PPP がインストールされていることを確認したら、次に、各マシンの /etc/inet/hosts ファイルを編集します。PPP リンクの反対側にあって、ローカルマシンが通信する必要のあるすべてのマシンについて、hosts データベースにホスト情報を追加する必要があります。

注 -

物理ネットワーク上でどのネームサービスを使用しているかに関係なく、/etc/inet/hosts を更新する必要があります。これは、ブートプロセスの中で、PPP の方がネームサービスデーモンより前に起動されるからです。

リモートマシンの hosts データベースの構成方法

  1. スーパーユーザーとなり、 /etc/inet/hosts ファイルを編集するための準備を整えます。

  2. リンクの反対側にあるダイヤルインサーバー用の PPP ネットワークインタフェースの IP アドレスとホスト名が入ったエントリを追加します。

    図 9-1 では、ダイヤルインサーバー nubian の PPP ネットワークインタフェースの IP アドレスが入ったエントリが、nomada の /etc/inet/hosts ファイルに入れられます。nomadb と nomadc の /etc/inet/hosts ファイルについても、同じことが行われます。

  3. ダイヤルインサーバーのネットワーク上にあって、リモートホストからのリモートログインが可能な各マシンの 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

  4. ネットワークで使用中のネームサーバーがある場合に、リモートホストのホスト名と IP アドレスによって、そのネームサーバーのデータベースを更新します。

マルチポイントダイヤルインサーバーの hosts データベース

マルチポイントダイヤルインサーバーは、一次ネットワークインタフェースのローカル IP アドレスのほかに、PPP インタフェース用の一意な IP アドレスも持っていなければなりません。ダイヤルインサーバー用の hosts データベースを構成するために必要な手順は、次のとおりです。

ダイヤルインサーバーの hosts データベースの構成方法

  1. 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

  2. サーバーの物理ネットワークでネームサービスが使用されていない構成の場合は、次のようにします。

    1. サービス対象となる各リモートホストに関するエントリを、サーバーの /etc/inet/hosts ファイルに追加します。

    2. 物理ネットワーク上にあって、リモートマシンとの通信が許可されているすべてのマシンの /etc/inet/hosts ファイルに、リモートホストについてのエントリを追加します。

  3. サーバーとそのリモートホストからなるネットワークの新しいネットワーク番号を、ダイヤルインサーバーの /etc/inet/networks ファイルに追加します。

    「PPP リンクへのネットワーク番号の割り当て」 を参照してください。

UUCP データベースの編集

マシンが PPP リンクを介してダイヤルアウトできるようにするには、そのマシンの UUCP データベース内の以下のファイルを編集する必要があります。

これらのファイルの編集が必要なのは、PPP ダイヤルアウトマシンとして機能するリモートホストの場合です。また、ダイヤルインサーバーがリモートホストへのダイヤルアウトを行う場合も (マルチポイントダイヤルインサーバーの場合の必須条件)、そのダイヤルインサーバーにある上記のファイルを編集する必要があります。これらのファイルについては、第 12 章「UUCP のデータベースとプログラム」で詳しく説明します。

PPP の /etc/uucp/Devices の更新

/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 ファイル」を参照してください。

PPP の /etc/uucp/Dialers の更新

/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 のシステム管理 (第 2 巻)』および、そのモデムの操作マニュアルの説明を参照してください。

PPP の /etc/uucp/Systems の更新

/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/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 のシステム管理 (第 1 巻)』を参照してください。

注 -

/etc/passwd ファイル中の情報に加えて、/etc/shadow ファイルもサーバーへのダイヤルインを許可されている各エンドポイントマシンで使用するログイン名のパスワードに更新します。詳細は、『Solaris のシステム管理 (第 1 巻)』を参照してください。

/etc/asppp.cf 構成ファイルの編集

/etc/asppp.cf 構成ファイルは、エンドポイントマシン上にある PPP リンクマネージャに、リンクの反対側にあるマシンに関する情報、またはマルチポイントリンク (または動的ポイントツーポイントリンク) の反対側にあるマシンに関する情報を提供します。このマシンがブートすると、リンクマネージャはこの情報を使って、リモートエンドポイントとの通信を確立し維持します。

基本構成ファイルの各部分

基本的な asppp.cf 構成ファイルには、少なくとも 2 つのメインセクションが含まれていなければなりません。それは、1 個の ifconfig 行と、少なくとも 1 つの path セクションです。これに加えて defaults セクションも含めることができます。このセクションは、エンドポイントについてデフォルト値を設定したい場合に使用します (default セクションで使用するキーワードの説明については、第 11 章「PPP リンクの調整」を参照してください)。

例 9-1 に示す基本構成ファイルは、ダイヤルインサーバーとの間にポイントツーポイントリンクを確立するリモートホスト用として作成されたものです。

例 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 セクション

asppp.cf ファイルには、次の構文の ifconfig セクションを含める必要があります。

ifconfig interface-number plumb local-machine remote-machine up

各フィールドについて説明します。

リンクマネージャは、まずローカルホストで ifconfig コマンドを実行して、ipdptp0 ポイントツーポイントインタフェースを構成します。ipdptp0 の中の 0 は、インタフェースのデバイス番号を示します。plumb オプションは、IP が ipdptp0 インタフェースを認識するのに必要な各種の操作を行います。nomada はローカルホストの名前です。nubian-pppは、nomada がポイントツーポイントリンクを介して接続するダイヤルインサーバーの名前です。ifconfig オプション up は、ipdptp0 インタフェースに "up" のマークを付けます。

注 -

ifconfig についての詳細は、第 10 章「PPP の障害追跡」と、ifconfig(1M) のマニュアルページを参照してください。

asppp.cf ファイルの path セクション

構成ファイルの path セクションは、リモートエンドポイントの名前と、エンドポイントマシン間を結ぶインタフェースの名前を、リンクマネージャに指示します。path セクションには、少なくとも下記の行が必要です。 


path
   interface interface-number
   peer_system_name endpoint-name

interface キーワード

このキーワードは PPP インタフェースを定義します (ipdptpn か ipdn のどちらか)。例 9-1 では、path セクションに次の情報があります。 


interface ipdptp0	  
peer_system_name nubian-ppp

この interface キーワードは、ローカルエンドポイント nomada が、この path セクションの記述に従ってリモートエンドポイントと通信するのに使用するポイントツーポイントインタフェースが ipdptp0 であることを表します。このキーワードは、peer_system_name をインタフェースに結び付けています。

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 キーワード

inactivity_timeout キーワードは省略可能です。このキーワードは、指定した時間が経過するまでの期間は、リンクが未使用状態であっても構わないことをリンクマネージャに指示します。その期間が経過すると、リンクマネージャは自動的にリンクを切り離します。デフォルトの時間は 2 分です。未使用期間として別の時間を指定したい場合でない限り、inactivity_timeout を使用する必要はありません。

その他のキーワード

asppp.cf ファイルには、上記以外にも、エンドポイントマシンによる通信の方法を定義するためのキーワードがいくつかあります。これらのキーワードについては、第 11 章「PPP リンクの調整」に詳しい説明があります。

マルチポイントダイヤルインサーバーの構成ファイル

マルチポイントダイヤルインサーバーの asppp.cf ファイルの場合も、基本的なセクションはポイントツーポイントリンクの場合と同じで、1 個の ifconfig セクションと、少なくとも 1 つの path セクションのほかに、必要に応じて指定する defaults セクションがあります。

例 9-2 は、図 9-1 に示したダイヤルインサーバー nubian の構成ファイルです。

例 9-2 マルチポイントダイヤルインサーバーの構成ファイル

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 セクションは、ポイントツーポイントリンクの場合とはやや構文が異なります。構文は次のとおりです。

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 + パラメータの指定が必要になります。

マルチポイントダイヤルインサーバーの path セクション

asppp.cf ファイルの path セクションは、リモートエンドポイントの名前と、エンドポイントマシンをリンクするインタフェースの名前を、リンクマネージャに指示します。ただし、マルチポイントダイヤルインサーバーでは、複数の path セクションを設けることができます。また、キーワードへの引数のいくつかは、マルチポイントリンクでは使い方が異なります。 

path
    interface interface-number
    peer_system_name endpoint-username
    peer_ip_address endpoint-hostname

path セクションは、ダイヤルインサーバーが接続を確立する相手となる各可搬エンドポイントについて、1 つずつ定義する必要があります。

interface キーワード

マルチポイントダイヤルインサーバーの場合は、interface キーワードは PPP インタフェース ipdn を定義します。このインタフェースを介してサーバーと通信するすべてのエンドポイントについて、同じ PPP インタフェースを path セクションに指定する必要があります。

peer_system_name キーワード

ダイヤルインマシンの場合の 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 キーワード

peer_ip_address キーワードは、マルチポイントリンクの場合は必須です。このキーワードは、引数としてリモートエンドポイントのホスト名または IP アドレスを受け取ります。上記の例では、peer_ip_address キーワードの引数はホスト名 nomads です。

その他のキーワード

asppp.cf ファイルには、上記以外にもエンドポイントマシンによる通信の方法を定義するためのキーワードがいくつかあります。これらのキーワードについては、第 11 章「PPP リンクの調整」に詳しい説明があります。

構成ファイルの編集

asppp.cf を編集するときは、次の点に注意してください。

ファイル内のキーワード入力については、上記以外には形式上の必要条件はありません。

asppp.cf 構成ファイルの編集方法

  1. 1 つのエンドポイントマシンでスーパーユーザーになり、/etc ディレクトリに移動します。

  2. 汎用 asppp.cf ファイルを編集して、このマシンの PPP リンクを定義する情報を追加します。

  3. アクセス権が必ず 600 に設定されるように、ファイルを保存します。

  4. 残りの各エンドポイントで /etc ディレクトリに移動し、上記の手順 2 と 3 を繰り返します。

PPP のセキュリティの付加

構成に含まれるすべてのマシンへ PPP をインストール後、asppp.cf を修正することによって、PPP リンクについての PAP または CHAP レベルのセキュリティを付加できます。「PAP/CHAP セキュリティのための asppp.cf の編集」を参照してください。

新規の PPP リンクの起動と停止

PPP は、ブート時に自動的に起動されるようにすることも、コマンド行から手動で起動することもできます。

手動で PPP を起動する方法

通常は必要ありませんが、PPP を手動で起動することができます。

  1. スーパーユーザーになり、次のように入力します。 


    # /etc/init.d/asppp start

PPP が実行中であることを確認する方法

  1. ps コマンドを実行します。 


     # ps -e | grep asppp

    grep の結果の出力に aspppd デーモンがリストされれば、PPP が実行中です。

  2. 結果が表示されたら、リモート PPP リンクに到達できるかどうかを確認するために、次のように入力します。 


    # ping remote-host 300

    この例の ping では、タイムアウト値が 5 分 (300 秒) に設定されています。このコマンドに対しては、「remote-host is alive」のような出力が表示されるはずです。これとは異なる出力、たとえば「remote-host unreachable」などと表示された場合は、経路の構成が失敗したことを意味します。

  3. ログファイルを調べて、構成にエラーがないかどうか検査します。 


    # tail /var/adm/log/asppp.log

    構成時にエラーが見つかった場合は、asppp.log にエラーメッセージが記録されています。

障害追跡と問題解決については、第 10 章「PPP の障害追跡」 を参照してください。

PPP の停止方法

  1. ネットワーク上での PPP 操作を停止するには、次のように入力します。 


    # /etc/init.d/asppp stop

第 10 章 PPP の障害追跡

この章では、ネットワーク上に PPP を構成した後に行う必要のある一連の検査事項を示します。その後、PPP リンクを介した通信に問題が生じたときには、PPP 診断機能を問題の解決に用いることができます。

要約すると、これらの検査は次の順序で行う必要があります。

  1. ハードウェア

  2. インタフェースの状態

  3. 接続

  4. ネットワークインタフェースの動作状態

  5. ローカルルーティングテーブル

  6. アクセス権

  7. パケットフロー

PPP がすべてのテストに合格すれば、TCP と UDP のサービス、たとえば rlogin、telnet、ftp などを、リンクを介して使用できるようになっているはずです。それでもリンクに障害がある場合は、PPP 診断機能を利用して障害追跡を試みてください。

以下の各節では、上記の各検査について詳しく説明します。

ハードウェアの検査

すべてのモデムケーブルと電源ケーブルがしっかりと接続されていることを確認します。PPP に問題が生じたときは、常に、モデム、ケーブル、シリアルカード、電話回線を最初に検査してください。

インタフェースの状態の検査

PPP を起動した後は、PPP インタフェース名だけを引数として指定した ifconfig を使用して、回線の現在の状態が監視できます。例 10-1 に示すのは、実行中の PPP リンクについての ifconfig のサンプル出力です。

注 -

特権 (root) ユーザーが ifconfig コマンドを発行した場合は、上記のようにマシンのアドレスが出力に表示されます。

例 10-1 ポイントツーポイントリンクに関する 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 に示すような出力が得られます。

例 10-2 マルチポイントリンクに関する ifconfig の出力

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 を用いて動的ルーティングを使用しているときは、次のようにします。

  1. 次のように入力して、in.routed が実行中であるかどうかを確認します。 


    # ps -e | grep route

    それでもまだルーティングテーブルが正しくない場合は、スーパーユーザーになって次の手順に進みます。

  2. ps -e から入手したプロセス ID を kill の引数として指定して、in.routed を終了します。たとえば、1384 がプロセス ID であるとすれば、次のように入力します。 


    # kill 1384

  3. 次のようにしてルーティングテーブルをフラッシュします。 


    # /usr/sbin/route -f

  4. in.routed を再起動します。 


    # /usr/sbin/in.routed

アクセス権の検査

rsh を使用しようとして、Permission denied というメッセージが出力された場合は、リモートシステムの /etc/hosts.equiv ファイルまたは /.rhosts ファイルに、送信側システムのホスト名が含まれていないか、行 + が含まれていません。

パケットフローの検査

次にパケットフローを検査します。snoop コマンドを使って、ネットワークからパケットを観察し、各パケットの内容を観察します。 例 10-3 に、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 レベルの診断機能を用いた障害追跡を行うことができます。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 構成ファイルの編集」を参照してください。

マシンに対する診断の設定方法

監視したいホストについて診断を設定するには、次のようにします。

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

  2. 現在の asppp.cf ファイルを編集して、path セクションに下記を追加します。 debug_level 8.

  3. アクセス権が必ず 600 に設定されるように、ファイルを保存します。

  4. 現在の 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 は、サンプルの構成要求を示します。

例 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 に示した構成要求について説明します。

残りの項目は、ホスト間でのネゴシエーションを必要とするオプションのリストです。

その後のいくつかの行は、無効な 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

第 11 章 PPP リンクの調整

この章には、第 9 章「PPP の構成」で述べた基本リンクに比べて少々特殊な PPP リンクを構成するために必要な情報を記載しています。主に 2 つの種類の PPP リンクの構成方法について説明します。2 つの種類とは、動的ポイントツーポイントリンクを持つダイヤルインサーバーと、仮想ネットワーク (これはマルチポイントリンクを使用します) です。章末には、asppp.cf 構成ファイルで使用できるすべてのキーワードのリストを記載しています。

動的割り当て PPP リンクの構成

動的ポイントツーポイントリンクを持つダイヤルインサーバーを使用するサイトでは、ポイントツーポイント通信の利点を最大限に活用することができます。この構成タイプについては、第 7 章「PPP の概要」で概説しました。この構成では、必要時に動的にポイントツーポイントリンクを割り当てる少なくとも 1 つのダイヤルインサーバーと、リモートホストとの間で通信が行われます。この節では、図 11-1 に示す構成例に基づいて説明を進めます。

図 11-1 リモートホストと動的リンクダイヤルインサーバーのネットワーク

Graphic

各リモートホストは、標準のポイントツーポイントリンクを使ってダイヤルインサーバーと通信します。しかし、図 9-1 に示したマルチポイントダイヤルインサーバーとは違って、ダイヤルインサーバー mojave は、動的ポイントツーポイントリンクを介して呼び出し側ホストに接続されます。リモートホストのどれかが接続を確立しようとすると、サーバーが使用可能なリンクを割り当てます。

動的リンクの基本概念は、接続確立のたびにサーバーがクライアントに IP アドレスを供給するというものです。接続を確立すると、使用可能な IP インタフェースをサーバーがクライアントに割り当てます。その後、接続が継続している間、インタフェースのリモート IP アドレスがクライアントの IP アドレスになります。接続を終了すると、使用可能なインタフェースのプールに IP インタフェースが戻され、別の接続に使用できる状態になります。

動的リンクの構成には、リモートホスト対マルチポイントダイヤルインサーバーの場合と同じ一般的な手順を用います。この手順については、「構成プロセスの概要」に説明があります。ただし、動的ポイントツーポイントリンクには独自の必要条件がいくつかあり、そのため構成に関係するファイルに対する修正のしかたも少々異なります。

動的割り当てリンクの場合のアドレス指定に関する必要事項

動的割り当て PPP リンクを使用する各マシンについて、/etc/inet/hosts ファイルにホスト情報を追加する必要があります。PPP エンドポイントの IP アドレスについては次の規則があります。

注 -

IP インタフェースに割り当てられるリモート IP アドレスに制限はありません。ただし、明確にするには、同じサブネットに属する IP アドレスだけを入れるのが最適です。

動的リンクの場合の hosts データベースの更新

動的リンク構成に含まれるすべてのマシンで、hosts データベースを更新する必要があります。

リモートホストの更新方法

リモートマシンの hosts データベースを構成するための手順は、次のとおりです。

  1. リンクの反対側にある各ダイヤルインサーバーについて、一次ネットワークインタフェースの IP アドレスとホスト名を、/etc/inet/hosts ファイルに追加します。

    たとえば、図 11-1 では、nomada、nomadb、nomadc の /etc/inet/hosts ファイルには、ダイヤルインサーバー mojave の一次ネットワークインタフェースの IP アドレスが入ります。

  2. ダミー 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

  3. ダイヤルインサーバーの物理ネットワーク上にあって、リモートホストからリモートログインできるすべてのマシンの IP アドレスを、/etc/inet/hosts ファイルに追加します。

  4. 物理ネットワーク上にあるネームサーバーのデータベースを、リモートホストのホスト名と IP アドレスに更新します。

ダイヤルインサーバーの更新方法

ダイヤルインサーバーの hosts データベースには、PPP 固有のアドレスを追加する必要はありません。動的割り当てリンクは、サーバーのネットワークインタフェースを使用する必要があります。したがって、ダイヤルインサーバーの hosts データベースを構成するには、次のようにします。

  1. サービス対象の各リモートホストについて、サーバーの /etc/inet/hosts ファイルにエントリを追加します。

  2. 物理ネットワーク上のすべてのマシンの /etc/inet/hosts ファイルに、それぞれが通信することのできるリモートホストについてのエントリを追加します。

その他のファイルに関する考慮事項

次に行う手順として、/etc/passwd ファイルと /etc/shadow ファイルを編集します。動的リンク構成の場合も、リモートホスト対マルチポイントダイヤルインサーバー構成の場合と同じ手順で、これらのファイルを編集します。/etc/passwd ファイルと /etc/shadow ファイルについての詳細は、「/etc/passwd ファイルの修正」を参照してください。

動的リンクの場合の asppp.cf の編集

動的リンク構成用の 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 のようになります。

例 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 セクションの構文は、次のとおりです。

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

動的リンクを持つサーバー用の defaults セクション

動的割り当てリンクを構成するときに、asppp.cf ファイルに defaults セクションを含めることができます。このセクションでは、その後に asppp.cf ファイル内に keyword が現れたときに、keyword に代入するデフォルトの値を設定します。defaults セクションの構文は次のとおりです。 


default 
     keyword

例 11-1 では、キーワード interface を使って ipdptp* をインタフェースとして定義することにより、動的リンクを指定しています。ワイルドカードを示すアスタリスクは、ifconfig セクションで定義されている任意の使用可能な ipdptp インタフェースを使用するよう、リンクマネージャに指示しています。したがって、サーバー mojave のリンクマネージャは、ipdptp0、ipdptp1、ipdptp2 のうち、"down" として構成されている最初のインタフェースを使用します。

動的リンクを持つサーバー用の path セクション

動的リンクを持つサーバー用の構成ファイルには、そのサーバーとの接続の確立が許されているすべてのリモートホストについての path セクションが含まれていなければなりません。path セクションの構文は次のとおりです。 


path
    peer_system_name endpoint-username

interface キーワードは、path セクションの中で定義されていません。これは、この値が defaults セクションで定義されているからです。 この場合の peer_system_name キーワードと peer_ip_address キーワードの意味は、マルチポイントサーバー用の構成ファイルの場合と同じです。詳細は、「マルチポイントダイヤルインサーバーの path セクション」を参照してください。

その他のキーワード

asppp.cf ファイルでは、上記のほかに、エンドポイントがどのように通信するかを定義するためのキーワードをいくつか指定できます。これには、「構成キーワード」で説明するセキュリティキーワードも含まれます。

仮想ネットワークの構成

仮想ネットワークは、それぞれ離れた場所にあるいくつかのスタンドアロンコンピュータを、互いに PPP マルチポイントリンクで接続したものです。仮想ネットワークの概念については、「仮想ネットワーク」で紹介しました。この節では、仮想ネットワークを構成する方法について説明します。

図 11-2 仮想ネットワーク例

Graphic

図 11-2 に示すネットワークは、3 つの単独コンピュータで構成されています。ネットワークの各メンバーは、マルチポイント PPP リンクを介して他のメンバーに接続しています。したがって、このようなネットワークを作成するには、ネットワーク管理者 (そしておそらくリモートロケーションの他のネットワーク管理者) は、関与する各ホストでマルチポイント PPP リンクを構成する必要があります。

マルチポイントリンクの構成には、マルチポイントダイヤルインサーバーの場合と同じ一般的な手順を用います。この手順については、「構成プロセスの概要」に説明があります。ただし、仮想ネットワークには独自の必要条件がいくつかあり、それに従ってネットワーク内の各ホストを構成する必要があります。

仮想ネットワークの場合のアドレス指定に関する必要事項

仮想ネットワーク内の各マシンについて、/etc/hosts ファイルにホスト情報を追加する必要があります。PPP エンドポイント用に使用する IP アドレスを入力するときは、次の規則に従ってください。

hosts データベースと networks データベースの更新

最初に行う手順としては、仮想ネットワークに関する情報によって、hosts データベースと networks データベースを更新します。

仮想ネットワークの場合の /etc/inet/hosts ファイル

各マシンの /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

仮想ネットワークの場合の /etc/inet/networks ファイル

仮想ネットワークは一意な 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 構成ファイル

仮想ネットワーク上のローカルマシン用の構成ファイルには、そのネットワーク内にあってローカルホストからアクセスできるすべてのリモートホストに関する情報が含まれている必要があります。さらに、仮想ネットワーク上のマシンは、どれもダイヤルインとダイヤルアウトの両方の機能を備えたものとして構成されていなければなりません。ローカルホストマシンがブートされると、リンクマネージャは asppp.cf ファイルを読んで通信を確立します。

例 11-2 は、仮想ネットワーク 192.41.47 の nomada 用として設定した構成ファイルです。

例 11-2 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 用として設定した構成ファイルです。

例 11-3 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

PAP/CHAP セキュリティのための asppp.cf の編集

asppp.cf ファイルを編集することによってセキュリティを設定し、リンクの各部分が、パスワード認証プロトコル (PAP) またはチャレンジハンドシェーク認証プロトコル (CHAP) に応答するかどうかを指定できます。PAP と CHAP については、「PPP のセキュリティ」で説明してます。asppp.cf ファイルを編集するには、一連のキーワードを追加します。この節では、認証システムはリンクまたはチャレンジを開始するシステムであり、これは多くの場合サーバーです。対等システムはリンクの反対側にあるシステムであり、これは多くの場合クライアントです。

追加するキーワードは、require_authentication と will_do_authentication です。認証システムつまりサーバーは一般に認証を要求し、対等システムつまりクライアントは一般に認証を行います。

表 11-1 認証システムのキーワードと関連の文字列

require_authentication pap

require_authentication chap

pap_peer_id

chap_peer_secret

pap_peer_password

chap_peer_name

表 11-2 対等システムのキーワードと関連の文字列

will_do__authentication pap

will_do_authentication chap

pap_id

chap_secret

pap_password

chap_name

PAP/CHAP のインストール方法

  1. サーバーでスーパーユーザーになり、/etc/asppp.cf ファイルを編集する準備を整えます。

  2. リンク上の各マシンについて require_authentication キーワードを追加して、PAP セキュリティと CHAP セキュリティのどちらを使用するかを指定します。

    1. 各 pap キーワードについて、関連の pap_peer_id と pap_peer_password 文字列を追加します。

    2. 各 chap キーワードについて、関連の chap_peer_secret と chap_peer_name 文字列を追加します。

      これらのキーワードは明示的に指定することも、パスのデフォルト値を使用することもできます。各キーワードによって指定される内容については、表 11-3 を参照してください。また、例 11-4 は、/etc/asppp.cf ファイルの例を示します。

  3. will_do_authentication キーワードを使って、リンク上で PAP または CHAP セキュリティを使用する各リモートホストについて、リモートホストの /etc/asppp.cf ファイルにエントリを追加します。

    1. 各 pap キーワードについて、関連の pap_id と pap_password 文字列を追加します。

    2. 各 chap キーワードについて、関連の chap_secret と chap_name 文字列を追加します。

これらのキーワードは明示的に指定することも、パスのデフォルト値を使用することもできます。各キーワードによって指定される内容については、表 11-3 を参照してください。また、例 11-4 は、/etc/asppp.cf ファイルの例を示します。

PAP/CHAP キーワードに関する規則

表 11-3 PAP/CHAP のキーワードの定義

キーワード 

値の定義 

require_authentication keywords1

対等システムがそれ自身を認証することを指定する。pap か chap のどちらかがある場合は、対等システムは認証に参加するか、または接続を終了する必要がある。デフォルト値は off

pap_peer_id peername2

現在のパスについて認証される必要のある対等システムの名前を指定する。peername 文字列の長さは 1 オクテット3 以上。長さがゼロの文字列を指示するには、このキーワードを省略する

pap_peer_password string4

対等システムのパスワードを 1 オクテット以上の長さで指定する。長さがゼロの文字列を指示するには、このキーワードを省略する 

chap_peer_secret string

対等システムが送る応答を生成するためにチャレンジ値とともに使用されるシークレットを指定する。形式は 1 オクテット以上の長さで、少なくとも 16 オクテット以上が望ましい 

chap_peer_name peername

パケットを伝送する対等システムの識別情報を指定する。名前には、NULL と、CR/LF で終わる文字列は使用できない。名前は、対等システムからの応答パケットの一部として受信されるもので、1 オクテット以上の長さからなる 

will_do_authentication keywords

システムが、指定した認証プロセスに認証された対等システムとして参加する意志があるかどうかを指定する。pap と chap の両方が存在する場合は、システムはどちらの認証プロトコルにも参加する意志を持つことになる。デフォルト値は off

pap_id peername

応答パケットに入れて認証システムに送るシステムの名前を指定する。長さがゼロの文字列を指示するには、このキーワードを省略する 

pap_password string

応答パケットに入れて認証システムに送るシステムのパスワードを指定する。長さがゼロの文字列を指示するには、このキーワードを省略する 

chap_secret string

認証システムに送る応答を生成するために、受信したチャレンジ値とともに使用するシークレットを入れる。形式は 1 オクテット以上の長さで、少なくとも 16 オクテット以上が望ましい 

chap_name peername

システムの識別情報を指定する。名前は、NULL または CR/LF で終わるものであってはならない。この名前は、応答パケットに入れて認証システムに送られる 

1. キーワード として使用できるのは off|pap[chap] | chap[pap]

2. peername は、認証システムから見てポイントツーポイントリンクの反対側にあるシステムの名前です。これは、 4. に示す構文の文字列です。

3. オクテットはバイトの厳密な定義です。

4. string はホワイトスペースを含まない単一トークンです。特殊文字を含めるには、標準 ANSI の ¥ エスケープ文字を使用できます。空白文字を入れるには、¥s を使用します。文字列の先頭にポンド記号がある場合は、コメントとして解釈されないようにするために、エスケープ (¥#) する必要があります。NULL (¥0) は文字列を切り捨てます。

PAP/CHAP の例

例 11-4 は、PAP と CHAP の認証を必要とするサーバー mojave 用の asppp.cf ファイルを示しています。対等システムは、nomada (PAP) と nomadb (CHAP) です。

例 11-4 サーバー mojave 用のコード例

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 の両方を認証しようしています。

例 11-5 リモートホスト nomada 用のコード例


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 を認証しようしています。

例 11-6 リモートホスト nomadbe 用のコード例


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 の必須キーワード

キーワード 

値の定義 

ifconfig parameters

parameters に指定する値で ifconfig コマンドを実行するよう、リンクマネージャに指示する。詳細は、「asppp.cf ファイルの ifconfig セクション」、「マルチポイントダイヤルインサーバーの ifconfig セクション」、ifconfig(1M) のマニュアルページを参照。

path

この (現行の) パスの属性としてグループ化するトークンシーケンスの始まりを指定する。現行パスを形成する属性の集合は、後続の path キーワード、defaults キーワード、ファイルの終わり文字のどれかが生じた時点で終了する。

interface (ipdptpn, ipdptp* または ipdn)

ネットワーク内の各インタフェースについて、ipdptp (静的ポイントツーポイント)、ipdptp* (動的ポイントツーポイント)、ipd (マルチポイント) のどれかのデバイスを指定する。ipdptpn と ipdn, の場合は、このキーワードは、n で定義される特定のインタフェースを現行パスに関連付ける。n は 0 もしくは正の整数でなければならない。この数は、path セクションに定義されているインタフェースと、ifconfig セクションに指定されているインタフェースが一致するようにする。

 

ipdptp** インタフェースの場合は、* は、インタフェースが、"down" として構成されているどのポイントツーポイントインタフェースにも一致することを示す。

peer_system_name hostname peer_system_name username

ダイヤルアウトマシンでは、ローカルマシンから呼び出したいリモートエンドポイントのホスト名 (hostname) を指定する。この名前は、/etc/uucp/Systems ファイルの中のシステム名と同じである。リモートシステム名を現行パスに関連付ける。この名前は、/etc/uucp/Systems ファイルから、アウトバウンド接続に関する、モデムと対等システムに固有の情報を見つけるために使用される。

ダイヤルインマシンでは、そのダイヤルインマシンにログインするときにリモートマシンが使用するユーザー名 (username) を指定する。username と、接続の獲得に使用されたログイン名との突き合わせによって、適正なパスが決定される。

peer_ip_address hostname peer_ip_address ip-address

宛先ホストアドレスを指定する。これは、マルチポイントリンクの場合に限り必要とされる。このアドレスは現行パスに関連付けされる。パスがポイントツーポイントインタフェースを示している場合は、この値は無視される。アドレスの形式は、ドット付き 10 進数、16 進数、シンボルのどれでもよい。 

表 11-5 に、PPP 構成をさらに進んで定義するために使用できる、asppp.cf の省略可能キーワードを示します。

表 11-5 asppp.cf の省略可能キーワード

キーワード 

値の定義 

debug_level 0-9

ログファイルに書き込むデバッグ情報の量を定義する 0 〜 9 の整数。数値が大きいほど出力の量が多くなる。 

defaults

次の path キーワードか、EOF 文字が現れるまでの後続のすべてのトークンシーケンスをデフォルトの属性に設定して、その間に定義されるパスに適用することを指示する。

default_route

現行パスに対応する IP 層が完全に稼動状態にあるときに、このパスの対等 IP アドレスをデフォルトの宛先としてルーティングテーブルに追加するよう、リンクマネージャに指示する。IP 層がダウン状態になったときは、この送信経路は削除される。 

inactivity_timeout seconds

現行パスの接続が、終了しないでアイドル状態のままでいられる最大秒数を指定する。タイムアウトなしの場合は 0 を指定する。デフォルトは 120 秒。 

ipcp_async_map hex-number

現行パスの非同期制御文字マップを指定する。hex-number は、マップを形成する 4 オクテットの自然 (ビッグエンディアン) 形式を示す。デフォルト値は 0x FFFFFFFF。

ipcp_compression (vj または off)

IP 圧縮を使用可能にするかどうかを指定する。デフォルトは、Van Jacobson 圧縮アルゴリズム (vj)。

lcp_compression (on または off)

PPP アドレスフィールド、制御フィールド、プロトコルフィールドの圧縮を使用可能にするかどうかを指定する。デフォルトは on。

lcp_mru number

必要な最大受信ユニットパケットサイズの値を指定する。number はサイズを指定するオクテット数。デフォルトは 1500。

negotiate_address (on または off)

ローカル IP アドレス割り当てをネゴシエーションにより入手し動的に割り当てるかどうかを指示する。これを使用可能にした場合は、ローカルアドレスは PPP リンクのリモート側から渡される。このようにして渡された場合、0.0.0.0 を除くどのようなローカルアドレスでも、インタフェースの初期構成に使用できる。デフォルトはネゴシエーションなし (off)。

peer_ip_address hostname peer_ip_address ip-address

宛先ホストアドレスを指定する。このキーワードはポイントツーポイントリンクの場合に限りオプション。address は現行パスに関連付けされる。アドレスの形式は、ドット付き 10 進数、16 進数、シンボルのどれでもよい。

version n

構成ファイルの内容が形式バージョン n に対応することを指定する。このキーワードを使用する場合は、ファイルの最初のキーワードとする必要がある。このキーワードがないときは、バージョンは 1 とみなされる。本書では、バージョン 1 形式の定義を構成ファイルに使用している 。