L2TP の致命的シグナル 15：NO_PROPOSAL_CHOSEN と modp1024 の欠落
NO_PROPOSAL_CHOSEN を伴う致命的シグナル 15 はフェーズ 2 の不一致です。デーモンが modp1024 を提供しなくなったか、フェーズ 1 の値がフェーズ 2 の欄に入っているかのどちらかです。
接続が止まり、クライアントが終了し、画面の最後の行は death_handler: Fatal signal 15 received です。その行が伝えるのは中断であって、原因ではありません。IPsec ログの一行上にはほぼ必ず NO_PROPOSAL_CHOSEN があり、この二行は交換のフェーズ 2 を指します。そこでは両側が暗号化とハッシュの選択肢を突き合わせ、共通点がなければ停止します。この段階では認証情報はまだ送られていないため、パスワードを打ち直しても結果は変わりません。
Linux クライアントでこの共通部分を空にするのは、通常二つの要因です。ローカルのデーモンがプロファイルの要求する Diffie-Hellman グループを実装しなくなったか、プロファイルがフェーズ 1 の提案をフェーズ 2 の欄に持っているかです。どちらもログに痕跡を残し、どちらもアカウントの問題ではありません。
二つのメッセージが実際に何を言っているか
IKE は複数の段階で交渉します。フェーズ 1 は保護されたチャネルを構築し、独自のアルゴリズムを選びます。フェーズ 2、つまり子 SA は別のセットでトラフィックを運びます。NO_PROPOSAL_CHOSEN は、提示された組み合わせがどれも受け入れられないときに応答側が返す通知で、INFORMATIONAL 交換の内部に [ HASH N(NO_PROP) ] として現れます。
シグナル 15 は別の出来事です。何かがローカルプロセスに停止を命じ、ハンドラーがそれを記録しました。二行が同時に現れるとき、順序は因果的で、拒否が先、停止が後です。
認証情報に触れる前に交渉を読む
デーモンが書き込む場所でログレベルを上げ、出力を眺めながら再接続します。NetworkManager のホストでは L2TP プラグインがそのレベルをバックエンドに渡し、メッセージはディストリビューションに応じて journal か従来の syslog ファイルに届きます。どちらでも交換は見えます：journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' または tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'。
pluto を含む行は libreswan から、charon は strongSwan から出ており、どちらも同じ状態を別の言葉で説明しています。探す価値があるのは、欠けているグループを名指す形です。たとえば algorithm 'modp1024' is not supported で、曖昧な失敗を具体的な失敗に変えます。
modp1024 はどこへ消えたか
Diffie-Hellman グループ 2 は弱すぎるため、いくつかのディストリビューションは 3.30 以降 libreswan へのコンパイルをやめました。すると何年も前に書かれたプロファイルや、aes128-sha1-modp1024 しか載っていないゲートウェイ解説から流用したプロファイルは、ローカルのデーモンに到底実行できないものを要求します。新しい NetworkManager-l2tp のビルドはこの結果を起こりやすくします。1.2.16 以降はセットを Windows 10 や iOS 風の提案に置き換え、libreswan を検出すると modp1024 を落とします。相手側は無実であることが多く、今も 設定したとおりのグループを提示しています。
この非対称性が、障害を偶然のように感じさせます。古いクライアントは接続し、更新されたノート PC の同じプロファイルは接続せず、サーバー設定は動いていません。被害を出しているのはバージョンのずれです。
影響範囲の異なる二つの修復
安価な修復は、アルゴリズムを決め打ちするのをやめることです。エディターで提案の二つの欄を空にし、プラグインに相手側が受け入れるセットを選ばせます。ゲートウェイが現代的なグループに対応していれば、追加作業なしで交渉が完了します。
二つ目の修復は、strongSwan を導入して古いゲートウェイを到達可能に保ちます。そのパッケージはほとんどのディストリビューションで今もグループ 2 を実装しています。これはデーモンの入れ替えなので、コストがかかります。削除する前に、ホスト上の他のトンネルが libreswan の設定に依存していないか確認し、Fedora では NetworkManager と strongSwan プラグインの間で SELinux の拒否が起きることを想定してください。その拒否は IKE のトレースではなく監査ログに現れるため、導入が成功した直後にトンネルが壊れて見えることがあります。うまくいく順序は、先に dnf install strongswan、次に rpm -e libreswan です。
一致する提案文字列と、その周りの罠
欄を手で埋めなければならないとき、フェーズ 1 とフェーズ 2 は別の値を取ります。Meraki 風の相手に対して機能することが知られている組み合わせは、フェーズ 1 に aes128-sha1-modp1024 を、その背後に 3des-sha1-modp1024 を持ち、どちらも感嘆符で閉じてセットを厳格にするため、その提案だけが送られます。
次にフェーズ 2 は、同じ厳格な印を付け、Diffie-Hellman の接尾辞をまったく付けずに aes128-sha1 と 3des-sha1 へ絞られます。-modp1024 を伴うフェーズ 2 の行は誤った欄に入ったフェーズ 1 の値であり、応答側は再試行のたびに拒否します。その行を二つ目のプロファイルにコピーすると、二つ目も同じように失敗します。こうして一つの打ち間違いが艦隊全体のインシデントになります。
他の不具合も提案の不一致ではないのに同じポップアップをまといます。KDE ではプラグインが導入済みでも L2TP 種別が一覧に現れ、その間すべての接続が即座に落ちます。接続エディターと実行時ヘルパーが別パッケージで提供されるためです。画面のないホストは動作するデスクトップのプロファイルを再利用できます。/etc/NetworkManager/system-connections/ からコピーし、モードを 600 に設定してから nmcli con reload を実行します。nmcli con up id work-l2tp で起動します。素の形は UUID を要求するためです。古い ifname の項目は削除してください。そうしないと、他がすべて正しくてもマネージャーは Could not find source connection と返します。
事前共有鍵は平文でも、0s に続く base64 でも保存できます。どちらの形式も機能しますが、値は末尾にコピーした空白も含めてゲートウェイとバイト単位で一致しなければなりません。