L2TP/IPsec の PSK が拒否された：まずダイアログ、次にファイル

管理者のメッセージから事前共有鍵を NetworkManager のダイアログに貼り付け、表示のチェックを入れれば、文字単位で一致しているように見えます。それでも接続はトンネルが上がる前に認証エラーで終わります。最初にこれを見たとき、私は鍵が間違っていると思いましたが、そうではありませんでした。デーモンが実際に読むものは、プラグインがその接続のために書き出すシークレットファイルと、値がダイアログを通るあいだに変化しなかったかどうかという二つの要素で決まります。

以下の手順は、鍵をフィールドからファイルまでたどるもので、どこで失われたかを教えるのはこの順序です。動くマシンではなく失敗するマシンで行ってください、両者の違いはたいてい鍵ではなくファイルの配置だからです。

まずダイアログから、ただしフィールドを信用しない

接続の IPsec タブを開き、貼り付けずにもう一度鍵を入力します。チャットのメッセージや PDF、パスワードマネージャーからコピーした鍵には、フィールドが表示しない末尾の改行が付いていることがあり、見えている文字は正しく見えたままです。

パスワード表示の操作を押して、文字列の中央ではなく末尾を見ます。カーソルがテキストの下に空行を残しているなら、それを消して最後の一文字を打ち直します。この一手だけでこうした報告の驚くほど多くが解決し、どのログを読むよりも手間がかかりません。

長い行を折り返すチケットシステムから鍵を得た場合は、折り返さない経路で取り寄せてください。二つの文字列を目で並べるのではなく管理者と長さを突き合わせてください、折り返し位置で失われた文字はプロポーショナルフォントでは見えないからです。

鍵を /etc/ipsec.d の中まで追う

プラグインは PSK をコマンドラインの引数として IPsec デーモンに渡すことはなく、代わりに値をシークレットファイルに保存して、デーモンがそのファイルを読み込むよう手配します。include 行がなければ /etc/ipsec.secrets に追加します。ダイアログが保持しているのは生成されるファイルへの入力であり、使用中の値ではありません。

変更する前に、何が存在するかを一覧にします：

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

古いプラグインは接続ごとに一つのファイルを、接続の UUID にちなんだ名前で、たとえば /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets のように書いていました。アプレットでプロファイルを削除しても、そのファイルは確実には消えません。以前のサーバーの古いファイルがディスクに残り、しかも読み込まれていると、デーモンはもう使っていないプロファイルの秘密を選ぶことがあり、表示上のフィールドが正しいのに接続は失敗します。

1.2.12 の変更がアップグレードに何をもたらしたかを知る

プラグイン 1.2.12 は接続ごとのシークレットファイルを一つの共有ファイル、/etc/ipsec.d/ipsec.nm-l2tp.secrets に置き換えました。アップグレードは古い UUID ごとのファイルを片付けず、既存の include /etc/ipsec.d/*.secrets 行がそれらを読み込み続けます。バージョン 1.2.16 は既定の提案の扱いを変えたのであって、秘密の配置を変えたのではありません。

この経緯が、同じに見えるプロファイルを持つ二台のマシンで挙動が違う理由です。鍵は同一でも、デーモンが読み込むファイルの集合は同一ではありません。孤立したファイルを外すときは削除ではなく脇へ移し、接続を確認し、動作状態を記録してから削除します。名前を変えておけば、障害が別の場所だった場合に古い値を取り戻せます。

保存形式が保持できない文字を切り分ける

共有秘密の文字列について、strongSwan の文書は値に改行や二重引用符を含められないと述べています。文書から貼り付けた鍵は、通常のダイアログでは見た目に何の違いもなく、どちらも持ち込むことがあります。

1.2.12 以降、保存される値は平文ではありません。プラグインはファイルに届く前に PSK を base64 で符号化し、リリースノートはその符号化を、鍵に二重引用符が使えるようになった理由として挙げています。したがってフィールドに入力した引用符は表現可能ですが、すべての制御文字について同じことが言えるわけではありません。

長さは別の制約です。L2TP/IPsec のソフトウェア全体に共通する最小値はありません、二十文字より短い鍵を受け付けるクライアントもあれば、最小値を課すゲートウェイもあります。短い鍵が拒否された場合、その規則はサーバーの方針かそのクライアントの検証に属し、手元で何かを引き上げても変わりません。

どの認証層で失敗したかを読む

まず ipsec --version を実行するのは、strongSwan と Libreswan でファイル名も構文も異なり、片方への助言がもう片方を壊すことがあるからです。次に、クライアントのメッセージかデーモンのログから失敗の段階を読みます、事前共有鍵への不満はユーザー名とパスワードの拒否とは別の出来事です。

PSK はトンネルの両端を認証します。ユーザー名とパスワードは L2TP の内側の人物を認証し、IPsec の関連付けが上がった後に PPP がそれらを扱います。正しい PSK でもアカウントが違えば失敗し、アカウントを変えても、デーモンが正しく読めなかった鍵は直りません。

チケットを閉じるときは、四つとも書き留めます、プラグインのバージョン、使用中のシークレットファイル、鍵を打ち直したのか貼り付けたのか、そしてエラーに示された層です。そうすれば後でこの手順をたどる人は、動くマシンと動かないマシンの違いへ直接進めます。