L2TP/IPsec が失敗する: IPsec、トンネル認証、PPP ログインを切り分ける

一つの L2TP/IPsec 接続の内部では三つのものが認証を行い、そのうちダイヤルする本人が関わるのは一つだけです。IPsec はトンネルの端点を証明し、L2TP 制御接続は自前の秘密でピアを再度証明することがあり、その後 PPP がセッション内のユーザーアカウントを証明します。どの段階での失敗もクライアントのダイアログでは一般的なログインエラーに見えますが、サーバーログではまったく違って見えます。段階を順にたどり、未検証の段階より下にある段階はすべて未検証なので、最初に失敗した段階で止めてください。

三つの認証段階、三つの異なる識別子

IPsec は事前共有鍵または証明書を使って、端点が誰のものかを証明します。その識別子はマシンやゲートウェイに属し、キーボードの前の人間に属することはありません。この段階でピア同士が合意できない場合、L2TP パケットは一切交換されません。

L2TP 制御接続は、両端が保持しなければならない共有秘密によって駆動される、二つ目の独立したチャレンジ応答交換を追加できます。

RFC 2661 はその制御接続の認証を任意にしているため、同じ誤りが二台のサーバーで異なる症状を生む理由が説明できます。トンネル秘密を一度も設定していない配備はこの段階を完全に飛ばし、片側だけに設定した配備は PPP が提示される前に失敗します。その後 PPP が PAP、CHAP、MSCHAPv2 でユーザーを認証し、その名前をローカル、chap-secrets、または RADIUS 上のアカウントストアに渡します。その時点での誤ったパスワードでも、動作するトンネルと失敗したセッションが残ります。

設定を編集する前に止まる場所を読む

まず ipsec --version を実行して状態出力が strongSwan のものか Libreswan のものかを把握し、次にクライアントのダイアログではなくサーバーログを読みます。どの段階が拒否したかをサーバーが記録しているからです。

多くの場合、IKE や提案に関する不満は第一段階、制御接続のメッセージは第二段階、PPP 方式またはアカウントの拒否は第三段階という一行でチケットは決まります。その行をタイムスタンプとともにチケットへコピーしてください。クライアント側からの推測は、すでに手元にある唯一の証拠を無駄にします。

鍵素材とパスワードはその貼り付けから外し、段階の名前が作業を振り分け、漏れた事前共有鍵はより悪い結果でチケットを再び開くことになるからです。

第一段階: IPsec にアソシエーションはあるか？

strongSwan では ipsec statusall、Libreswan では ipsec whack --status を実行し、ゼロでないカウンターを持つ子アソシエーションが確立しているかを探します。ip xfrm state は両方でカーネルの見え方を示します。カウンターが増える SA の組がインストールされていれば、第一段階は完了して先へ進めます。

アソシエーションがまったく無い場合は、ピアアドレス、提案セット、または事前共有鍵を指し、ときには UDP 500 を書き換えながら UDP 4500 を落とす機器を指します。確立してから数秒で消えるアソシエーションは、資格情報の問題ではなく両端の寿命の不一致であることが普通です。何かを打ち直す前に、両側が同じ暗号化とハッシュの提案を並べているか確認してください。そうでなければ、どんな鍵でも永遠に機能しません。

アソシエーションが欠けている間は止まってください。その時点で PPP オプションを編集しても何も変わらず、本当の不具合を次の人から隠すだけです。

第二段階: L2TP 制御接続は認証されたか？

IPsec が上がったら、それ以前には PPP を始められないので、L2TP デーモンが確立状態に達する制御接続を監視してください。制御接続での拒否は、両端でトンネル秘密が異なるか、一方の端が他方が決して送らない秘密を要求していることを意味します。クライアントは shared secret というラベルの一つの欄を出すことが多く、それは通常 L2TP ではなく IPsec に属します。そこを埋めてもトンネル秘密は設定されず、空にしても無効化されません。

どちらの側もトンネル秘密を設定していない場合は、この段階を飛ばし、制御接続の失敗を到達性の問題として扱ってください。UDP 1701 がデーモンに届くこと、両端が同じカプセル化で合意していることを確認します。その二つの条件の片方だけを書いたファイアウォール規則は、接続が半分だけ開くよくある原因です。

PPP のネゴシエーションを始めたセッションだけが、実際にトンネル段階を通過しています。

第三段階: PPP がアカウントを拒否しているか？

PPP の失敗は外から見ると異なり、トンネルは確立し、セッションは始まり、デーモンは認証方式の失敗またはアカウント拒否を記録します。そのメッセージで名指しされた方式を読んでください。PAP と CHAP は別の理由で失敗し、片方を拒否するサーバーはそれだけを提示するクライアントを拒否します。

Linux サーバーでは、デーモンが PPP に渡すオプションファイル（通常は /etc/ppp/options.xl2tpd）を調べ、どの方式が受け入れられ、アカウントがどこで解決されるかを確認します。RADIUS にあってローカルの秘密ファイルに無い名前は、きれいに失敗して不正なパスワードのように見えます。次に、クライアントがサーバーの受け入れる方式を提示しているか、サーバーが交渉を拒むより強い方式を提示していないかを確認します。この段階を直すために事前共有鍵を変えても、午後が無駄になり何も変わりません。

セッションがようやく上がったとき、アドレス割り当て、DNS、ルートはまだ未確認です、そしてそれぞれが独自のやり方で静かに失敗します。メモでは三つの層を分けておき、正しい鍵と誤ったアカウントは必ず失敗し、一つの層を直しても別の層は直りません。