PPP CHAP だけでは MPPE の要件を満たせない理由

暗号化を必須とする PPTP プロファイルは、たいてい同じ場所で失敗します。PPP が、MPPE に必要な鍵素材を決して生成しない認証交換に合意してしまうのです。トンネルは半分だけ生きているように見え、パスワードは受け入れられ、トラフィックが通過する前にリンクが切れます。何かがつながるまで CHAP のドロップダウンに手を伸ばすことは、本当の欠陥を隠します。その欠陥とは、認証方式と保護ポリシーの間の契約です。以下の確認は、それぞれが次より安上がりな原因を除外する順に並んでいます。

一つの PPTP 接続の内部で二つの交渉が走る

PPTP は GRE トンネルの内部で通常の PPP セッションを運び、両者は別々に交渉します。外側の層はパケットのカプセル化方法と制御チャネルの有無を決め、内側の PPP セッションは相手が誰か、どの保護を上に載せるかを決めます。したがってパスワードの問い合わせが証明するのは内側の層についてだけで、完了した外側のハンドシェイクはどちらについても何も証明しません。ここでプロファイルが失敗するのは、意見の相違が PPP の内側にあるのに、人がトンネルをデバッグするからです。

素の CHAP は RFC 1994 のチャレンジ応答交換で、共有秘密だけに基づいて構築されています。MS-CHAPv2 はメッセージも出力も異なる別の交換で、RFC 2759 で標準化されています。二つの名前の共通語は、電線上で両者に共通する唯一のものです。どちらの名前も交換が何を生成するかを語らず、そこだけが重要な点です。

だからこそ、単に CHAP とだけ書かれた選択肢は古いプロファイルでは曖昧です。サーバーが MS-CHAPv2 を求め、クライアントが素の CHAP を提示しても、リンク制御は完了でき、パスワードも受け入れられ得ます。失敗はもっと後、サーバーが何も生成しなかった交換から保護鍵を導こうとしたときに訪れます。

要求される方式を、それが生成できる鍵に合わせる

MPPE の鍵は PPP 一般の性質ではありません。Microsoft CHAP ファミリーでは導出が RFC 3079 に規定されており、共有秘密ではなく MS-CHAP 交換の出力を入力に取ります。EAP 方式は別の経路で同じ地点に達し、認証サーバーが鍵を MS-MPPE-Recv-Key と MS-MPPE-Send-Key の属性として返します。素の CHAP はどちらの経路にも現れず、それがこの不一致が存在する理由のすべてです。

鍵を供給できるあらゆる方式を拒否しながら MPPE を要求する構成は、内部で矛盾しています。pppd はその矛盾を、鍵をでっち上げるのではなくリンクを拒否することで解決するため、目に見える結果は、認証は通るがネットワーク段階で終了するセッションです。サーバーが何かを導出する唯一の方式を拒否し続ける限り、クライアントを再試行しても変わりません。

そこから導かれる規則は短いものです。プロファイルが MPPE を要求するなら、方式は MS-CHAP の変種か、サーバーが鍵を返す EAP 方式でなければなりません。MS-CHAPv2 だけを拒否しても、MS-CHAPv1 も鍵を導出し、別途拒否しない限り利用可能なまま残るため、それは強制されません。両方を拒否すると素の CHAP と PAP が残り、これらは何も導出せず、要件を満た不能にします。嫌いな方式を列挙するのではなく、受け入れる方式を明示してください。クライアントをつなぐために暗号化要件を落とすのは修理ではなく降格です。

クライアントを編集する前にサーバーのオプションを読む

こうした不一致の多くはサーバー上の二つのファイルで見え、それを読むほうがクライアントを作り直すより安く済みます。Linux の PPTP エンドポイントでは、関連する設定は pptpd が渡す pppd のオプションファイルにあります。クライアントの状態画面ではなく、サーバー上で実行してください。保護モードを要求・拒否・指定する行から始めます。

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

出力はフラグの一覧ではなく契約として読んでください。MPPE を要求しながら MS-CHAP の両変種を拒否する行はどのクライアントも満たせず、MS-CHAP 方式の要求が欠けていると鍵を生まない交換に扉が開いたままになります。次に、そもそも誰が認証できるかは秘密ファイルが決めます。

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

何かを変える前に三つの値を書き留めてください。外側のプロトコル、サーバーが要求する認証方式、保護が必須か任意かです。この三つが以後のすべての判断を決め、クライアントのダイアログから推測することがプロファイルを中途半端な設定で終わらせる道です。作業中は、次の節が同じ三つの値を必要とするため、ファイルを開いたままにしてください。

PPP の段階で障害を特定する

PPP は障害を段階ごとに報告し、その段階が契約のどの条項が破れたかを示します。リンク制御から一度も抜けないリンクはカプセル化か交渉の問題を抱え、認証は通るがその後死ぬリンクはたいていポリシーか鍵の問題を抱えています。上がったまま何も運ばないリンクはルーティングに進んでおり、それは別の調査です。

ジャーナルは段階の行を保持しており、より高いデバッグ水準より役に立ちます。PPP のプロセスと保護のメッセージを求め、何よりも先に認証結果を読んでください。最後の行は通常、拒否した条項を名指しします。

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

その出力では、まず認証結果を探し、次に保護が要求されたが交渉されなかったという苦情を探します。二番目のメッセージが上の矛盾の署名であり、サーバーが鍵を生成できる唯一の方式を拒否し続ける限り、何度再試行しても消えません。二つの罠を名指ししておきます。段階の行を読まずにデバッグ水準を上げるとノイズが生じ、チャレンジ素材やパスワードを取得すると設定作業が資格情報の漏えいに変わります。どのオプションを変える前にも、その段階を記録してください。

古いエンドポイントを止める前に出口を計画する

MPPE は歴史的なリンク保護機構であり、その存在が PPTP を新しい配備の妥当な選択にするわけではありません。現在の Microsoft の指針は、新しいリモートアクセスの展開に対して PPTP と事前共有鍵を用いる L2TP/IPsec をすでに勧めていません。古いエンドポイントを生かし続けることは既存サービスについての判断であり、次のための雛形ではありません。

エンドポイントを残さざるを得ない場合は、契約を書き出します。外側のプロトコル、要求される認証方式、必須の保護、そしてそれを交渉するクライアントの版です。手放せる場合は、古いプロファイルに触れる前に、代替のゲートウェイ ID、そのクライアント認証、資格情報を置く場所を選びます。そのうえで経路、DNS、各利用者が到達を許可される資源を計画します。想定するクライアントは、動いている接続ではなく所有者の要件に対して検証してください。

意図的な拒否は拒否のままであるべきです。テストを通すために無保護のモードへ後退することは、ポリシーの失敗を露出に変えてしまいます。完成した状態は、支えられ文書化された契約であり、一つの古い接続を成功させる最小の変更ではありません。代替が同じ確認を通るまで、古いプロファイルはそのまま、使わず文書化した状態で残してください。