PPTPがパスワードを誤りと告げるとき：どの修正を先に選ぶか

パスワードが違うと主張する PPTP プロファイルは、聞こえるより狭いことを伝えている。シークレットはケイパビリティ交渉から始まる連鎖のごく最後に試されるので、その連鎖のどこかで食い違えば認証エラーとして現れる。だからパスワードを再設定しても、打ち直しても、プロファイルを作り直しても何も変わらない。まず交渉を読み、経路のどこまでを制御できるかに応じて修正を選ぶ。

シークレットが試されない理由

PPP 認証は、サーバーが方式を提示し、クライアントができることで応答し、資格情報が交わされる前に双方が一つの方式で合意する交渉で決まる。サーバーが EAP-PEAP だけを提示し、クライアントの pppd がそれを実装していなければ、会話は提示の段階で終わる。サーバーが認証失敗を記録するのは、失敗したのがその段階だからであり、パスワードを照合して不足と判定したからではない。

だから誤ったパスワードでも方式の食い違いでも同じエラーになる。両者を区別できるのはログだけであり、しかもクライアントが詳細出力を許されている場合に限る。

最後のエラーではなく交渉を読む

デバッグを有効にして接続を前面で実行し、認証の行を上から読む。ログには提示された方式、受け入れられた方式、交換が止まった場所が記される。サーバーが PEAP を期待しているのにプロファイルが CHAP や MSCHAPv2 から出ないなら、それは方式の問題であって資格情報の問題ではない。ログの最後の行はクライアントが諦めた場所であり、原因の在り処ではない。

sudo pppd call provider debug nodetach

その出力を保存しておく。サーバー側の方針を変える前にネットワーク管理者が必要とする証拠でもあり、パスワードがそもそも関与したのかという問いにも決着をつける。

二つ目の原因はシークレットファイルに隠れている

ログで方式が一致しているなら、シークレットを保存するファイルを見る。パスワード欄に書かれた改行や末尾の空白はパスワードの一部として送られるので、サーバーは入力した文字列とは別の文字列を比較する。エディターでは正しく見えるが、まさにそれゆえに何度やり直しても直らない。

sudo cat -A /etc/ppp/chap-secrets

その出力では各行の終わりがドル記号で示される。その記号の前に何かがあるパスワード欄や、欄の間に紛れた空白は、ツールが記す引用符の作法で書き直す必要がある。

サーバーの所有者に応じて修正を選ぶ

サーバーが自分のものなら、そのアカウントに MSCHAPv2 を許可するのが最小の変更であり、弱い方式を意図的に受け入れたと記録しておくべきだ。他人のものなら、EAP-PEAP を実装したクライアントが誠実な修正であり、pppd にパッチを当てると非互換が自分の保守作業になる。プロトコルの選択がまだ開いているなら、PPTP は設計上もっとも弱い部分であり、パッチを当てたクライアントを生かし続けるより移行のほうがたいてい安い。その判断をプロファイルのそばに書き、次の人が蒸し返さないようにする。

どの道を選んでも、後で別のネットワークの二台目のマシンから試す。保存されたプロファイルが古い方式を提示し続け、直したサーバーが壊れているように見えることもある。デバッグ設定は、詳細な PPP ログが共有のワークステーションでは望まないものまで記録しうるので、その後で外す。