Solaris のシステム管理 (資源管理とネットワークサービス)

第 35 章一般的な問題の解決 (手順)

この章では、Solaris PPP 4.0 で発生する一般的な問題の障害追跡に関する情報を提供します。次の項目について説明します。

James Carlson による「PPP Design, Implementation, and Debugging」やオーストラリア国立大学の Web サイトなどの情報源も、PPP の障害追跡に詳細なアドバイスを提供しています。詳細は、PPP に関する専門技術者向けのリファレンスブックおよび PPP に関する Web サイトを参照してください。

PPP 問題の解決 (作業マップ)

次の作業マップを使用すれば、一般的な PPP の問題のためのアドバイスや解決方法をすばやく探すことができます。

表 35–1 PPP の障害追跡 (作業マップ)


作業	定義	参照先
PPP リンクに関する診断情報を取得する	PPP 診断ツールを使って障害追跡の出力を取得する	pppd から診断情報を取得する方法
PPP リンクのデバッグ情報を取得する	`pppd debug` コマンドを使って障害追跡の出力を生成する	PPP デバッグをオンに設定する方法
ネットワークレイヤーでの一般的な問題を障害追跡する	一連の確認作業を行いネットワーク関連の PPP 問題を特定し解決する	ネットワークの問題を診断する方法
一般的な通信の問題を障害追跡する	PPP リンクに影響を与える通信の問題を特定し解決する	通信の問題を診断し解決する方法
構成の問題を障害追跡する	PPP 構成ファイルで問題を特定し解決する	PPP 構成の問題を診断する方法
モデム関連の問題を障害追跡する	モデムの問題を特定し解決する	モデムの問題を診断する方法
chat スクリプト関連の問題を障害追跡する	ダイアルアウトマシン上の chat スクリプトの問題を特定し解決する	chat スクリプトのデバッグ情報を取得する方法
シリアル回線の速度の問題を障害追跡する	ダイアルインサーバー上で回線速度の問題を特定し解決する	シリアル回線の速度の問題を診断して解決する方法
専用回線の一般的な問題を障害追跡する	専用回線の問題を特定し解決する	専用回線の問題の解決
認証に関連する問題を障害追跡する	認証データベースに関連する問題を特定し解決する	認証の問題の診断と解決
PPPoE の問題領域を障害追跡する	PPP 診断ツールを使用して、PPPoE の問題を特定し解決するための出力を得る	PPPoE の診断情報を取得する方法

PPP の障害追跡のためのツール

PPP リンクは、一般に次の 3 つの主要な領域で障害が発生します。

接続の確立に失敗する
通常の使用の中で接続パフォーマンスが低下する
接続のどちらかの側でネットワークに原因と考えられる問題が発生する

PPP が動作しているかどうかを確認するためのもっとも簡単な方法は、リンクを介したコマンドを実行することです。ping や traceroute などのコマンドをピアのネットワーク上のホストに対して実行し、結果を調べます。ただし、確立されている接続のパフォーマンスを監視したり、問題のある接続を障害追跡したりするには、PPP およびUNIX のデバッグツールを使用してください。

この節では、pppd および関連するログファイルから診断情報を取得する方法について説明します。この章の残りの節では、PPP 障害追跡ツールを使って発見し解決できる PPP に関する一般的な問題を説明します。

pppd から診断情報を取得する方法

次に、ローカルマシン上の接続の現在の動作を表示する手順を説明します。

ローカルマシン上でスーパーユーザーになります。

PPP に設定されているシリアルデバイスを引数として pppd を実行します。

# pppd /dev/ttyname debug updetach

次に、pppd をフォアグラウンドで実行したときに表示されるダイアルアップリンクおよび専用回線リンクの診断結果の例を示します。バックグラウンドで pppd debug を実行すると、作成される出力は /etc/ppp/connect-errors ファイルに送られます。

例 35–1 正常に動作しているダイアルアップ接続からの出力

# pppd /dev/cua/b debug updetach
have route to 0.0.0.0/0.0.0.0 via 172.21.0.4
serial speed set to 230400 bps
Using interface sppp0
Connect: sppp0 <--> /dev/cua/b
sent [LCP ConfReq id=0x7b <asyncmap 0x0> <magic 0x73e981c8> <pcomp> <accomp>]
rcvd [LCP Ident id=0x79 magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Dec  6 
	2000 09:36:22)"]
Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Dec  6 2000 09:36:22)
	rcvd [LCP ConfRej id=0x7b <asyncmap 0x0>]
sent [LCP Ident id=0x7c magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Nov 15 
	2000 09:38:33)"
sent [LCP ConfReq id=0x7d <magic 0x73e981c8> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x7d <magic 0x73e981c8> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x78 <magic 0xdd4ad820> <pcomp> <accomp>]
sent [LCP ConfAck id=0x78 <magic 0xdd4ad820> <pcomp> <accomp>]
sent [LCP Ident id=0x7e magic=0x73e981c8 "ppp-2.4.0b1 (Sun Microsystems, Inc., 
	Nov 15 2000 09:38:33)"]
sent [IPCP ConfReq id=0x3d <addr 0.0.0.0> <compress VJ 0f 01>]
rcvd [LCP Ident id=0x7a magic=0xdd4ad820 "ppp-2.4.0b1 (Sun Microsystems, Inc., 
	Dec  6 2000 09:36:22)"]
Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Dec  6 2000 09:36:22)
rcvd [IPCP ConfReq id=0x92 <addr 10.0.0.1> <compress VJ 0f 01>
sent [IPCP ConfAck id=0x92 <addr 10.0.0.1> <compress VJ 0f 01>
rcvd [IPCP ConfNak id=0x3d <addr 10.0.0.2>]]
sent [IPCP ConfReq id=0x3e <addr 10.0.0.2> <compress VJ 0f 01>]
rcvd [IPCP ConfAck id=0x3e <addr 10.0.0.2> <compress VJ 0f 01>]
local  IP address 10.0.0.2
remote IP address 10.0.0.1

例 35–2 正常に動作している専用回線接続からの出力

# pppd /dev/se_hdlc1 default-asyncmap debug updetach
pppd 2.4.0b1 (Sun Microsystems, Inc., Oct 24 2001 07:13:18) started by root, uid 0
synchronous speed appears to be 0 bps
init option: '/etc/ppp/peers/syncinit.sh' started (pid 105122)
Serial port initialized.
synchronous speed appears to be 64000 bps
Using interface sppp0
Connect: sppp0 <--> /dev/se_hdlc1
sent [LCP ConfReq id=0xe9 <magic 0x474283c6><pcomp> <accomp>]
rcvd [LCP ConfAck id=0xe9 <magic 0x474283c6><pcomp> <accomp>]
rcvd [LCP ConfReq id=0x22 <magic 0x8e3a53ff><pcomp> <accomp>]
sent [LCP ConfReq id=0x22 <magic 0x8e3a53ff><pcomp> <accomp>]
sent [LCP Ident id=0xea magic=0x474283c6 "ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 
	22 2001 14:31:44)"]
sent [IPCP ConfReq id=0xf7 <addr 0.0.0.0> <compress VJ Of o1>]]
sent [CCP ConfReq id=0x3f <deflate 15> <deflate(old#) 15> <bsd v1 15>]
rcvd [LCP Ident id=0x23 magic=0x8e3a53ff "ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 
	22 2001 14:31:44)"]
Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2001 14:31:44)
rcvd [IPCP ConfReq id=0x25 <addr 10.0.0.1> <compress VJ Of 01>]
sent [IPCP ConfAck id=0x25 <addr 10.0.0.1> <compress VJ Of 01>]
rcvd [CCP ConfReq id=0x3 <deflate 15> <deflate(old#) 15 <bsd v1 15>]
sent [CCP ConfAck id=0x3 <deflate 15> <deflate(old#) 15 <bsd v1 15>]
rcvd [IPCP ConfNak id=0xf8 <addr 10.0.0.2>]
rcvd [IPCP ConfReq id=0xf7 <addr 10.0.0.2> <compress VJ Of 01>]
rcvd [CCP ConfAck id=0x3f <deflate 15> <deflate(old#) 15 <bsd v1 15>]
Deflate (15) compression enabled
rcvd [IPCP ConfAck id=0xf8 <addr 10.0.0.2> <compress VJ Of 01>]
local  IP address 10.0.0.2
remote IP address 10.0.0.1

PPP デバッグをオンに設定する方法

次に、pppd コマンドを使ってデバッグ情報を取得する方法を示します。

注 –

手順 1 から手順 3 までは各ホストごとに 1 度実行するだけでかまいません。その後、手順 4 に進んでホストのデバッグをオンに設定できます。

pppd からの出力を保持するためのログファイルを作成します。
% touch /var/log/pppdebug

次の pppd 用の syslog 機能を /etc/syslog.conf に追加します。
daemon.debug;local2.debug /var/log/pppdebug

syslogd を再起動します。
% pkill -HUP -x syslogd

pppd の次の構文を使用して、特定のピアに対する呼び出しのデバッグをオンに設定します。
% pppd debug call peer-name
peer-name は、/etc/ppp/peers ディレクトリにあるファイル名でなければなりません。

ログファイルの内容を表示します。
% tail -f /var/log/pppdebug
ログファイルの例については、例 35–3 を参照してください。

PPP のパフォーマンスに影響を与えるネットワークの問題の解決

PPP リンクがアクティブになっているのに、リモートネットワーク上のホストにほとんど接続できない場合、ネットワークに問題のある可能性があります。この節では、PPP リンクに影響を与えるネットワークの問題を特定し解決する方法について説明します。

ネットワークの問題を診断する方法

ローカルマシン上でスーパーユーザーになり、問題のある接続を切断します。

次のオプションを PPP 構成に追加して、構成ファイルのオプションのプロトコルを無効にします。
noccp novj nopcomp noaccomp default-asyncmap
このオプションは、もっとも単純で圧縮を行わない PPP を使用可能にします。コマンド行でこれらのオプションを引数として pppd を実行してみます。これまで接続できなかったホストに接続できれば、次のいずれかの位置にオプションを追加します。
- /etc/ppp/peers/peer-name、call オプションの後
- /etc/ppp/options、オプションを広域的に適用する場合

リモートピアを呼び出します。次に、デバッグをオンに設定します。
% pppd debug call peer-name

chat の -v オプションを使用して、chat プログラムから冗長ログを取得します。

たとえば、PPP 構成ファイルで次の形式を使用します。
connect 'chat -v -f /etc/ppp/chatfile'
/etc/ppp/chatfile は、お使いの chat ファイルの名前を表します。

Telnet または他のアプリケーションを使ってリモートホストに接続し、問題を再度発生させてみます。

デバッグログを調べます。これでもリモートホストに接続できない場合は、PPP の問題はネットワークに関連している可能性があります。

リモートホストの IP アドレスが登録されているインターネットアドレスであることを確認します。

組織によっては、ローカルネットワーク内では通用するが、インターネットへは経路指定できない内部 IP アドレスを割り当てる場合があります。リモートホストが社内にある場合、インターネットに接続するためには、管理者は、NAT (名前- アドレス変換) またはプロキシサーバーを設定する必要があります。リモートホストが社内にない場合は、遠隔組織に問題を報告する必要があります。

経路指定テーブルを調べます。
1. ローカルマシンとピアの両方で経路指定テーブルを確認します。
2. 経路指定テーブルで、ピアからリモートシステムへのパスにあるルーターをすべて確認します。また、リモートシステムからピアへの戻りのパスにあるルーターもすべて確認します。
  
  中間ルーターの設定が間違っていないことを確認します。ピアへの戻りのパスに問題が見つかることがしばしばあります。

(省略可能) マシンがルーターである場合、オプションの機能を確認します。
# ndd -set /dev/ip ip_forwarding 1
ndd の詳細は、ndd(1M) のマニュアルページを参照してください。

netstat -s および同様のツールから取得した統計を確認します。

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

ローカルマシン上で統計を実行します。

ピアを呼び出します。

netstat -s によって生成された新しい統計を調べます。

netstat -s によって生成されたメッセージを使用すると、次の表に示したネットワークの問題を解決できます。

表 35–2 PPP に影響を与える一般的なネットワークの問題


メッセージ	問題	解決方法
`IP packets not forwardable`	ローカルホストで送信経路が見つからない	ローカルホストの経路指定テーブルに欠如している送信経路を追加する
`ICMP input destination unreachable`	ローカルホストで送信経路が見つからない	ローカルホストの経路指定テーブルに欠如している送信経路を追加する
`ICMP time exceeded`	2 つのルーターが同じ着信アドレスを互いに送信し、パケットが互いに何度も往復し、TTL (存続時間) の値を超過した	`traceroute` を使ってルーティングループの源を見つけ、エラーになっているルーターの管理者に連絡する。`traceroute` の詳細は、`traceroute(1M)` のマニュアルページを参照
`IP packets not forwardable`	ローカルホストで送信経路が見つからない	ローカルホストの経路指定テーブルに欠如している送信経路を追加する
`ICMP input destination unreachable`	ローカルホストで送信経路が見つからない	ローカルホストの経路指定テーブルに欠如している送信経路を追加する

DNS 構成を確認します。

ネームサービス構成に問題があると、IP アドレスを解釈処理できないため、アプリケーションは障害を発生します。

ネームサービスの問題を解決するための情報については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「DNS の障害追跡 (参照情報)」を参照してください。

一般的な通信の問題の解決

通信の問題は、2 つのピアが接続の確立に失敗したときに発生します。これらの問題は、実際は、chat スクリプトの構成が不適切であるために発生するネゴシエーションの問題であることがしばしばあります。この節では、通信の問題を解決するための情報を提供します。問題のある chat スクリプトによって発生するネゴシエーションの問題の解決方法については、表 35–5 を参照してください。

通信の問題を診断し解決する方法

ローカルマシン上でスーパーユーザーになり、ピアを呼び出します。

リモートピアを呼び出します。次に、デバッグをオンに設定します。
% pppd debug call peer-name
通信の問題によっては、問題解決のためにピアからデバッグ情報を取得する必要がある場合があります。

次の表に示す通信問題のリストに、取得したログの内容に対応する症状があるかどうかを確認します。

表 35–3 PPP に影響を与える一般的な通信の問題


症状	問題	解決方法
`too many Configure-Requests` メッセージ	あるピアが他のピアを認識できない	次の問題を確認するマシンまたはモデムの配線が間違っていないかモデムの構成に不適切なビット設定がないか、あるいは間違ったフロー制御がないか chat スクリプトが誤っていないか。この場合は、表 35–5 を参照
`pppd debug` の出力は LCP が起動していることを示しているが、より上位のプロトコルが失敗したか、あるいは CRC エラーを示している	非同期制御文字マップ (ACCM) が正しく設定されていない	`default-async` オプションを使用して ACCM を標準のデフォルトである FFFFFFFF に設定する。まずコマンド行で `pppd` のオプションとして `default-async` を使用してみる。問題が解決したら、`default-async` を `/etc/ppp/options` または `call` オプションの後の `/etc/ppp/peers/peer-name` に追加する
`pppd debug` の出力は IPCP が起動していることを示しているが、すぐに終了してしまう	IP アドレスの設定が間違っている可能性がある	間違った IP アドレスがないか確認するために、chat スクリプトを調べる chat スクリプトが問題ない場合は、ピアのデバッグログを要求し、ピアのログで IP アドレスを確認する
接続のパフォーマンスが非常に低い	フロー制御構成のエラー、モデム設定のエラー、不適切に設定された DTE レートなどにより、モデムが適切に構成されていない可能性がある	モデム構成を確認し、適宜調整する

PPP 構成の問題の解決

PPP の問題には、PPP 構成ファイルの問題が原因となっているものがあります。この節では、一般的な構成の問題を特定して解決するための情報を提供します。

PPP 構成の問題を診断する方法

ローカルマシン上でスーパーユーザーになります。

リモートピアを呼び出します。次に、デバッグをオンに設定します。
% pppd debug call peer-name

次の表に示す構成問題のリストに、取得したログの内容に対応する症状があるかどうかを確認します。

表 35–4 一般的な PPP 構成の問題


症状	問題	解決方法
`pppd debug` の出力に「`Could not determine remote IP address.`」というエラーメッセージが含まれる	`/etc/ppp/peers/peer-name` ファイルにそのピアの IP アドレスが存在しない。ピアが、接続ネゴシエーション時に IP アドレスを提供しない	次の形式を使用して、pppd コマンド行、あるいは `/etc/ppp/peers/peer-name` でピアの IP アドレスを指定する :10.0.0.10
`pppd debug` の出力がCCP データ圧縮が失敗したことを示す。出力には接続が解除されたことも表示する	ピアの PPP 圧縮設定が衝突している可能性がある	ピアの 1 つで `/etc/ppp/options` に `noccp` オプションを追加して CCP 圧縮を無効にする

モデム関連の問題の解決

モデムは、ダイアルアップリンクで問題の発生しやすい領域です。モデム構成でもっともよく発生する問題は、ピアからの応答がないことです。しかし、接続の問題の原因が本当にモデム構成の問題なのかどうかを判定することは難しい場合があります。

モデムの基本的な障害追跡に関するヒントは、『Solaris のシステム管理 (上級編)』の「端末とモデムの問題を解決する方法」を参照してください。モデムメーカーのマニュアルや Web サイトも、特定の装置に関する問題の解決に役立ちます。この節では、モデムの問題を特定して解決するためのヒントを提供します。

モデムの問題を診断する方法

次の手順は、問題のあるモデム構成が接続の問題の原因となっているかどうかを判定するのに役立ちます。

PPP デバッグをオンに設定する方法で説明した手順で、デバッグをオンに設定してピアを呼び出します。

作成された /var/log/pppdebug ログを表示します。

出力に次の症状が認められる場合は、モデム構成に問題がある可能性があります。
- ピアから「recvd」メッセージが返されない
- 出力にピアからの LCP メッセージが含まれるが、接続は失敗し、ローカルマシンから「too many LCP Configure Requests」のメッセージが送信される
  
  このメッセージは、ローカルマシンはピアを認識できるが、ピアはローカルマシンを認識できないことを示します。
- 接続が SIGHUP 信号で終了する

ping を使用してさまざまなサイズのパケットを接続上に送信します。

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

小さいパケットは受信されるが、大きいパケットはドロップされる場合、モデムに問題があることを示します。

インタフェース sppp0 上のエラーを確認します。

% netstat -ni
Name  Mtu  Net/Dest   Address      Ipkts    Ierrs Opkts    Oerrs Collis Queue 
lo0   8232 127.0.0.0  127.0.0.1    826808   0     826808   0     0      0     
hme0  1500 172.21.0.0 172.21.3.228 13800032 0     1648464  0     0      0     
sppp0 1500 10.0.0.2   10.0.0.1     210      0     128      0     0      0

インタフェースのエラーが時間がたつにつれて増えている場合は、モデム構成に問題がある可能性があります。

chat スクリプト関連の問題の解決

chat スクリプトは、ダイアルアップリンクで問題が発生しやすい領域です。この節では、chat からデバッグ情報を取得する手順と、一般的な問題を解決するためのヒントを示します。

chat スクリプトのデバッグ情報を取得する方法

ダイアルアウトマシン上でスーパーユーザーになります。

/etc/ppp/peers/peer-name ファイルを編集してピアが呼び出されるようにします。

connect オプションで指定されている chat コマンドに引数として -v を追加します。
connect "/usr/bin/chat -v -f /etc/ppp/chat-script-name"

/etc/ppp/connect-errors ファイルの chat スクリプトのエラーを表示します。

以下は、chat で見られる主なエラーです。

Oct 31 08:57:13 deino chat[107294]: [ID 702911 local2.info] expect (CONNECT)
Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] alarm
Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] Failed

この例は、(CONNECT) 文字列を待つ間にタイムアウトしたことを示します。chat が失敗すると、pppd から次のメッセージを受け取ります。

Connect script failed

次の表に、chat スクリプトの一般的なエラーと、エラー解決のためのヒントを示します。

表 35–5 chat スクリプトの一般的な問題

症状

問題

解決方法

pppd debug の出力に Connect script failed が含まれる

chat スクリプトは、以下のようにユーザー名とパスワードを指定している。

ogin: user-name
ssword: password

ただし、接続しようとしたピアはこの情報を要求していない

chat スクリプトからログインとパスワードを削除する
再度ピアを呼び出してみる
まだメッセージが表示される場合は、ISP に連絡して正しいログインシーケンスを問い合わせる

/usr/bin/chat -v ログに次のメッセージが含まれる。 "expect (login:)" alarm read timed out

chat スクリプトは、以下のようにユーザー名とパスワードを指定している。

ogin: pppuser
ssword: \q\U

しかし、接続しようとしているピアはこの情報を要求していない

chat スクリプトからログインとパスワードを削除する
再度ピアを呼び出してみる
まだメッセージが表示される場合は、ISP に連絡して正しいログインシーケンスを問い合わせる

pppd debug の出力に以下が含まれる。possibly looped-back

ローカルマシンまたはそのピアがコマンド行で停止していて PPP を実行していない。chat スクリプト内に間違って設定されたログイン名とパスワードがある

chat スクリプトからログインとパスワードを削除する
再度ピアを呼び出してみる
まだメッセージが表示される場合は、ISP に連絡して正しいログインシーケンスを問い合わせる

pppd debug 出力は LCP が起動していることを示しているが、接続がすぐに終了してしまう

chat スクリプト内のパスワードが間違っている可能性がある

ローカルマシンの正しいパスワードを確認する
chat スクリプト内のパスワードを確認する。間違っている場合は修正する
再度ピアを呼び出してみる
まだメッセージが表示される場合は、ISP に連絡して正しいログインシーケンスを問い合わせる

ピアからのテキストがチルダ (~) で始まる

chat スクリプトは、以下のようにユーザー名とパスワードを指定している。

ogin: pppuser
ssword: \q\U

しかし、接続しようとしているピアはこの情報を要求していない

chat スクリプトからログインとパスワードを削除する
再度ピアを呼び出してみる
まだメッセージが表示される場合は、ISP に連絡して正しいログインシーケンスを問い合わせる

モデムが停止する

chat スクリプトに次の行が含まれており、ローカルマシンがピアからの CONNECT メッセージを待つように強制している。

CONNECT ”