pppd バイナリが見つからない：実行環境を直し、認証を疑わない

クライアントが最初に必要とするバイナリを見つけられなかったため、ゲートウェイには何も届いていない。メッセージは実行環境のヘルパーを示しており、遠隔側が何かを拒否したと考えるのが自然な反応になる。拒否してはいない。PPP ベースの統合はそのヘルパーをローカルマシンに必要とし、それが欠けているか、読めないか、呼び出し元が見る場所にない。

メニューとデーモンは別物

デスクトップエディタは、それを確立するはずのヘルパーが欠けていてもプロファイルを保存できるのは、保存が検証するのは項目であって機能ではないからだ。二つの部品は別々のパッケージで配布され、別々の時点で失敗する。きれいに保存できるプロファイルと、即座に失敗する接続は完全に整合している。

逆の誤りも同じくらい多く、ディスクのどこかにある実行ファイルは、選択した統合が対応するコピーを見つける証明にはならない。ホームディレクトリのコピーはシェルを満たしても、サービスからは見えないままになりうる。

ファイルではなくパッケージを読む

何かに触れる前に、インストール済みパッケージの状態、宣言された依存関係、想定されるファイル一覧を確認する。ディストリビューションのパッケージ管理はこれを明示しており、Debian のNetworkManager PPTP パッケージは有用な例で、PPP デーモンのパッケージと PPTP クライアントに別々に依存しているからだ。これは旧来の統合であり、今日 PPTP を配備する勧めではない。ヘルパーがクライアントの中ではなく、独自の依存関係として届くことを示している。

インストールに失敗したパッケージ、候補を提供しないリポジトリ、パッケージの所有外で手作業で入れたバイナリという三つの失敗の型を切り分ける。必要な修理はそれぞれ違い、同じパッケージを再インストールして直るのは最初の一つだけだ。

シェルでの実行ファイル確認が示すのは、そのシェルの検索パスだけであり、それ以上ではない。マネージャーのヘルパーは別のパス、別の環境、あるいは明示的に設定された実行ファイルの場所で動くことがある。

dpkg -s network-manager-pptp | grep -E "Status|Depends"
dpkg -L ppp | grep -E "bin/pppd$"
command -v pppd; ls -l /usr/sbin/pppd

他を壊さずに実行環境を直す

実行環境が明らかに不完全な場合は、ディストリビューションのレビュー済みパッケージ操作を使い、何が変わるのかを先に読む。PPP は複数のアクセスネットワーク統合で共有されているため、削除や再インストールは動作中の利用者を巻き込むことがある。壊れた一つを直すために関連パッケージをすべて消すのは、ノートパソコンが動作中の接続を二つ失うやり方だ。

別の VPN クライアントを入れるのも修理ではない。新しい互換性の要件を作り、元のプロファイルは説明されないまま残る。

組織がプロトコル自体をやめる決定をしたなら、それは所有者のいる移行判断だ。トラブルシューティングの手順ではなく、接続が失敗した瞬間に行うべきものではない。

次のエラーを新しい段階として扱う

ヘルパーが起動したら、次の失敗は別物になると想定する。PPP リンクの折衝、ユーザー認証、アドレス割り当て、ルート、名前解決はそれぞれ独立に失敗しうるし、それぞれに固有の証拠がある。

後から拒否されたときに、依存関係の修理を取り消したり、プロファイルの古い認証・圧縮オプションを全部有効にしたりして応答しない。それは診断できる問題を一つから相互作用する複数へ変える。設定は一度に一つだけ変え、何が変わったかを記録する。

パッケージのバージョンと、実際に見たメッセージを記録する。欠けているバイナリと、それを提供すべきパッケージを名指しする報告は、VPN への一般的な不満にはない実行可能性を持つ。