この章では PPP を構成するための手順および情報、あまり一般的には使用されない PPP リンクを設定する手順、およびの障害追跡の方法をいくつか示します。次のトピックについて説明します。
この節では PPP を構成したり、一度インストールした PPP を保守したり、PPP に関する障害追跡を行なったりするための各種のマップを示します。
表 23-1 PPP 構成作業マップ
作業 |
説明 |
参照ページ |
---|---|---|
PPP がすべてのマシンにインストールされていることを確認する |
pkginfo を使用して、PPP が PPP リンク内のすべてのマシンにインストールされていることを確認する | |
リモートマシンのホストのデータベースを構成する |
/etc/inet/hosts ファイルに IP アドレスとホスト名を追加することにより、リモートマシンのホストのデータベースを構成する | |
ダイアルインサーバーのホストデータベースを構成する |
/etc/hosts ファイルおよび /etc/inet/networks ファイルにエントリを追加することにより、ダイアルインサーバーのホストデータベースを構成する | |
/etc/asppp.cf ファイルを編集して、起動時にエントリが認識されるようにエントリを追加する |
リモートエンドポイントとの通信を確立し維持するために必要な情報を /etc/asppp.cf ファイルに加える | |
RIP をオフにする |
/etc/gateways ファイルに norip を加えて RIP をオフにする | |
リモートホストを更新する |
IP アドレスとホスト名を /etc/inet/hosts ファイルに加えて、リモートホストを更新する | |
ダイアルインサーバーを更新する |
/etc/inet/hosts ファイルを更新して、サーバーに接続されている各ホストに使用するエントリを加える | |
PAP/CHAP サポートを加える |
require_authentication のキーワードと will_do_authentication のキーワードを /etc/asppp.cf ファイルに追加して、リンク上の各マシンが PAP または CHAP に応答するかどうかに関するセキュリティを確立する |
表 23-2 PPP 保守作業マップ
作業 |
説明 |
参照ページ |
---|---|---|
PPP を手動で起動する |
/etc/init.d/asppp start コマンドを使用して PPP を起動します。通常、PPP は自動的にスタートするため、このコマンドを使用する必要はない | |
PPP が作動中であることを確認する |
ps コマンドと ping コマンドを使用して、PPP が作動中であるかどうかを確認する | |
PPP を停止する |
/etc/init.d/asppp stop コマンドを使用して PPP を停止する | |
インタフェースの状態を確認する |
ifconfig コマンドを使用して、回線の現在の状態を監視する | |
接続状態を確認する |
ping コマンドを使用して接続が完了していることを確認する | |
インタフェースの活動を確認する |
netstat コマンドを使用して、パケットが送受されていることを確認する | |
ローカルルーティングテーブルを確認する |
netstat コマンドを使用してローカルルーティングテーブルを表示する | |
in.routed を使用してルートを加える |
動的ルーティングを行っているときに、in.routed コマンドを使用してルートを加える |
表 23-3 PPP 障害追跡の作業マップ
作業 |
説明 |
参照ページ |
---|---|---|
診断機能を設定する |
障害追跡のために PPP 診断機能を設定する方法 |
第 22 章「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 |
32 ビット PPP がインストールされている場合は、次のパッケージ名が表示されます。
SUNWapppr PPP/IP Asynchronous PPP daemon configuration files SUNWapppu PPP/IP Asynchronous PPP daemon and PPP login service SUNWpppk PPP/IP and IPdialup Device Drivers |
64 ビット PPP がインストールされている場合は、次のパッケージ名が表示されます。
SUNWapppr PPP/IP Asynchronous PPP daemon configuration files SUNWapppu PPP/IP Asynchronous PPP daemon and PPP login service SUNWpppk PPP/IP and IPdialup Device Drivers SUNWpppkx PPP/IP and IPdialup Device Drivers (64-bit) |
PPP がインストールされていないエンドポイントシステムがある場合は、pkgadd プログラムまたは admintool ソフトウェアマネージャを使用してインストールしてください。
pkgadd を使用して PPP をインストールする場合は、上記の順序でパッケージをインストールする必要があります。
pkgadd プログラムと admintool ソフトウェアマネージャについての詳細は、『Solaris のシステム管理 (第 1 巻)』を参照してください。
この節と以後の各節では、最も一般的な PPP 構成、つまりリモートホストとそのダイヤルインサーバーをサポートするファイルを編集する方法を紹介します。図 23-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 の方がネームサービスデーモンより前に起動されるからです。
スーパーユーザーになります。
/etc/inet/hosts ファイルを編集して次の手順を行います。
リンクの反対側にあるダイヤルインサーバー用の PPP ネットワークインタフェースの IP アドレスとホスト名が入ったエントリを追加します。
図 23-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 ファイルに追加します。
たとえば、図 23-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 ダイヤルアウトマシンとして機能するリモートホストの場合です。また、ダイヤルインサーバーがリモートホストへのダイヤルアウトを行う場合も (マルチポイントダイヤルインサーバーの場合の必須条件)、そのダイヤルインサーバーにある上記のファイルを編集する必要があります。これらのファイルについては、第 25 章「UUCP の概要」で詳しく説明します。
ダイヤルインサーバーを構成するには、/etc/passwd ファイルと /etc/shadow ファイルも編集する必要があります。
ダイヤルインサーバーへのログインを許可されている各リモートホストの各ユーザーについて、そのサーバーの /etc/passwd ファイルにエントリを追加する必要があります。リモートホストがダイヤルインサーバーを呼び出す場合、自分自身の UUCP データベースを読み、ユーザー名かユーザー ID をサーバーに渡すことで呼び出しを開始します。すると、サーバーは、/etc/passwd ファイルのユーザー情報に照らして確認します。
そのユーザーのパスワードが認証されると、サーバーは、PPP ホスト用の特別なシェルである /usr/sbin/aspppls にそのユーザーをログインさせます。サーバーは、この情報を /etc/passwd ファイルのログインシェルエントリから入手します。たとえば、図 23-1 の例の場合、ダイヤルインサーバー nubian の /etc/passwd ファイルには、次のようなエントリが入っています。
root:x:0:1:Super-User:/:/sbin/sh daemon:x:1:1::/: bin:x:2:2::/usr/bin: sys:x:3:3::/: adm:x:4:4:Admin:/var/adm: lp:x:71:8:Line Printer Admin:/usr/spool/lp: uucp:x:5:5:uucp Admin:/usr/lib/uucp: nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico listen:x:37:4:Network Admin:/usr/net/nls: nomada:x:121:99:R. Burton:/:/usr/sbin/aspppls nomadb:x:122:99:T. Sherpa:/:/usr/sbin/aspppls nomadc:x:123:99:S. Scarlett:/:/usr/sbin/aspppls |
/etc/passwd パスワードについての詳細は、『Solaris のシステム管理 (第 1 巻)』を参照してください。
/etc/passwd ファイル中の情報に加えて、/etc/shadow ファイルもサーバーへのダイヤルインを許可されている各エンドポイントマシンで使用するログイン名のパスワードに更新します。詳細は、『Solaris のシステム管理 (第 1 巻)』を参照してください。
/etc/asppp.cf 構成ファイルは、エンドポイントマシン上にある PPP リンクマネージャに、リンクの反対側にあるマシンに関する情報、またはマルチポイントリンク (または動的ポイントツーポイントリンク) の反対側にあるマシンに関する情報を提供します。このマシンがブートすると、リンクマネージャはこの情報を使用して、リモートエンドポイントとの通信を確立し維持します。
asppp.cf を編集するときは、次の点に注意してください。
構成ファイル内では、キーワードとキーワードとの間を空白 (ブランク、タブ、改行) で区切る
コメントとして使用する文字列の前には # 記号を付ける。# からその次の改行までの文字はすべてコメントとみなされ無視される
キーワードをファイルに設定するためのフォーマットに対して他の条件は無効となります。
エンドポイントマシンの 1 つでスーパーユーザーになります。
/etc ディレクトリに移動します。
汎用 asppp.cf ファイルを編集して、このマシンの PPP リンクを定義する情報を追加します。
アクセス権が必ず 600 に設定されるように、ファイルを保存します。
/etc/gateways ファイルにより、ポイントツーポイントリンク上の RIP を無効にすることができます。このファイルはご使用のオペレーティングシステムには入っていません。テキストエディタで作成する必要があります。
スーパーユーザーになります。
/etc/gateways を編集して、次のエントリを追加します。
norip ipdptpn |
ipdptpn は、使用されているポイントツーポイントの PPP インタフェースのデバイス名を表します。
構成に含まれるすべてのマシンに PPP をインストール後、asppp.cf を修正することによって、PPP リンクについての PAP または CHAP レベルのセキュリティを付加できます。「PAP または CHAP セキュリティのための asppp.cf の編集」を参照してください。
動的ポイントツーポイントリンクを持つダイヤルインサーバーを使用するサイトでは、ポイントツーポイント通信の利点を最大限に活用することができます。この構成タイプについては、第 21 章「PPP の概要」で概説しました。この構成では、必要時に動的にポイントツーポイントリンクを割り当てる少なくとも 1 つのダイヤルインサーバーと、リモートホストとの間で通信が行われます。この節では、図 23-2 に示す構成例に基づいて説明を進めます。
各リモートホストは、標準のポイントツーポイントリンクを使用してダイヤルインサーバーと通信します。しかし、図 23-1 に示したマルチポイントダイヤルインサーバーとは違って、ダイヤルインサーバー mojave は、動的ポイントツーポイントリンクを介して呼び出し側ホストに接続されます。リモートホストのどれかが接続を確立しようとすると、サーバーが使用可能なリンクを割り当てます。
動的リンクの基本概念は、接続確立のたびにサーバーがクライアントに IP アドレスを供給するというものです。接続を確立すると、使用可能な IP インタフェースをサーバーがクライアントに割り当てます。その後、接続が継続している間、インタフェースのリモート IP アドレスがクライアントの IP アドレスになります。接続を終了すると、使用可能なインタフェースのプールに IP インタフェースが戻され、別の接続に使用できる状態になります。
動的リンクの構成には、リモートホスト対マルチポイントダイヤルインサーバーの場合と同じ一般的な手順を用います。この手順については、「構成プロセスの概要」に説明があります。ただし、動的ポイントツーポイントリンクには独自の必要条件がいくつかあり、そのため構成に関係するファイルに対する修正の方法も少々異なります。
リモートマシンの hosts データベースを構成するための手順は、次のとおりです。
スーパーユーザーになります。
リンクの反対側にある各ダイヤルインサーバーについて、一次ネットワークインタフェースの IP アドレスとホスト名を /etc/inet/hosts ファイルに追加します。
たとえば、図 23-2 では、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 ファイルに、それぞれが通信することのできるリモートホストに関するエントリを追加します。
asppp.cf ファイルを編集することによってセキュリティを設定し、リンクの各部分が、パスワード認証プロトコル (PAP) またはチャレンジハンドシェーク認証プロトコル (CHAP) に応答するかどうかを指定できます。PAP と CHAP については、「PPP のセキュリティ」で説明してます。asppp.cf ファイルを編集するには、一連のキーワードを追加します。この節では、認証システムはリンクまたはチャレンジを開始するシステムであり、これは多くの場合サーバーです。対等システムはリンクの反対側にあるシステムであり、これは多くの場合クライアントです。
追加するキーワードは、require_authentication と will_do_authentication です。認証システムつまりサーバーは通常、認証を要求し、対等システムつまりクライアントは通常、認証を行います。
表 23-4 認証システムのキーワードと関連の文字列
require_authentication chap |
|
---|---|
chap_peer_secret |
|
chap_peer_name |
表 23-5 対等システムのキーワードと関連の文字列
will_do_authentication chap |
|
---|---|
chap_secret |
|
chap_name |
サーバー上のスーパーユーザーになります。
リンク上の各マシンについて require_authentication キーワードを追加して、PAP セキュリティと CHAP セキュリティのどちらを使用するかを指定します。
will_do_authentication キーワードを使用して、リンク上で PAP セキュリティまたは CHAP セキュリティを使用する各リモートホストについて、リモートホストの /etc/asppp.cf ファイルにエントリを追加します。
例 23-1 は、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 |
例 23-2 に示された 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 |
例 23-3 に示された 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 シークレットは安全な手段で送付する必要があります。これは一般的に手動での解放を含みます。
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 にエラーメッセージが記録されています。
障害追跡と問題解決については、「共通の確認事項」 を参照してください。
ネットワーク上での PPP 操作を停止するには、次の手順を実行します。
この節では、ご使用の PPP 設定の動作を確認するために行う必要があると思われるいくつかの共通の確認事項について説明します。
これらの確認を行うためにはスーパーユーザーになる必要があります。
すべてのモデムケーブルと電源ケーブルがしっかりと接続されていることを確認します。PPP に問題が生じたときは、常に、モデム、ケーブル、シリアルカード、および電話回線を最初に検査してください。
PPP を起動したあとは、PPP インタフェース名だけを引数として指定した ifconfig を使用して、回線の現在の状態が監視できます。例 23-4 に示すのは、実行中の PPP リンクについての ifconfig のサンプル出力です。
特権 (root) ユーザーが 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 |
標準と動的のどちらのポイントツーポイントリンクの場合も、例 23-5 に示すような出力が得られます。
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 コマンド」と netstat(1M) のマニュアルページを参照してください。
ローカルルーティングテーブルを表示するには、netstat コマンドを使用します。
次に出力例を示します。
Routing tables Destination Gateway Flags Ref 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 |
到達可能なネットワークごとに、ルーティングテーブルエントリが存在することを確認します。特に、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 コマンドを使用して、ネットワークからパケットや、各パケットの内容を観察します。例 23-6 に、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、Ethernet フレームの情報は抑止されますが、詳細形式オプションのどれかを選択した場合は表示されます。
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 |
asppp.cf ファイルについては、「/etc/asppp.cf 構成ファイルの編集」を参照してください。
監視したいホストについて診断を設定するには、次の手順を行います。