Ubuntu のアップグレードで L2TP/IPsec が壊れた？ IKEv1 の提案を比較する

接続は木曜日には動いていました、アップグレードは金曜日に実行され、月曜日にはクライアントが「connecting」で回り続けて諦めます。 同じノート PC、同じサーバー、同じアカウント、同じ事前共有鍵です。 プロファイルは何も編集されていません、だからこそ、明白な容疑者であるパスワードとファイアウォールに時間を浪費することになります。

変わったのは、あなたのマシンが提示してよいと考える変換の一覧です。 Ubuntu で使われる二つの IPsec スタック、strongSwan と Libreswan は、安全ではないと判断したアルゴリズムを削除し、その手前にある NetworkManager プラグインは独自の一覧を持っていて、別のスケジュールで動きます。 3DES、SHA1、1024 ビットの Diffie-Hellman グループに固定されたサーバーは、自分が受け入れるものを何も聞けなくなることがあります。

アップグレードが実際に変えたもの

IKEv1 の提案は二つの層から供給されます。 デーモンはコンパイル済みの既定の提案セットを同梱し、L2TP プラグインはそれに従うか、独自の一覧を渡します。 NetworkManager-l2tp 1.2.16 より前はプラグインがそれに従っていたため、提案はインストールされたデーモンが妥当と考えるものでした。 1.2.16 以降、プラグインは Windows と Apple のクライアントをモデルにした文書化された一覧を送ります、その一覧は古い既定より広いものの、キューの先頭にあったすべての旧来の組み合わせを含むわけではありません。

この分離が、人々が戸惑う失敗の形を説明します、同じ Ubuntu リリースの二台が違う動作をすることがあります、一方にはディストリビューションのパッケージがあり、もう一方にはバックポートがあるからです、しかもバグ報告では両者のデーモンのバージョンが同じに見えます。 アップグレードで何も関係するものが変わっていないと結論づける前に、デーモンのバージョンだけでなくプラグインのバージョンを確認してください。

同じ領域にもう少し小さな罠があります。 二つのデーモンは楕円曲線 Diffie-Hellman グループの綴りが異なり、一方は ecp384、もう一方は ecp_384 と書きます。 間違った綴りを Advanced ダイアログに貼り付けると、デーモンは解析不能として設定を拒否し、ログには設定の誤字ではなくネゴシエーションの問題として現れます。

何かを変える前に失敗を読む

どのバックエンドを動かしているかから始めてください、答えが構文とログの場所の両方を決めるからです。

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

次にやり取りそのものを読みます。 strongSwan では、デーモンは現行リリースでは journal に、古いリリースでは /var/log/syslog に書き出します、興味深いのは最後の行ではなく、送った提案です。 探すのは、一致する提案がないという記述（アルゴリズムの問題）、認証の失敗（鍵かアカウントを示す）、あるいは単なるタイムアウト（到達性を示す）です。

この三つの結果は、あまりにも頻繁に一つの症状として扱われます。 デーモンのログが空のままのタイムアウトは、パケットが届いていないことを意味します。 提案の拒否は、届いたうえで拒否されたことを意味します。 ログが沈黙しているなら、一回の試行だけプラグインのデバッグ水準を上げ、その後で下げてください、詳細な出力は journal をすぐに埋めます。

フェーズ 1 とフェーズ 2 は別々の賭けです

IKEv1 は二回ネゴシエーションします。 メインモードは、暗号化アルゴリズム、整合性アルゴリズム、Diffie-Hellman グループ、認証方式から IKE セキュリティアソシエーションを構築します。 次にクイックモードが、L2TP を運ぶ ESP アソシエーションを構築します。 サーバーは前者を受け入れて後者を拒否する自由があるため、半端に正しいプロファイルは予想より遅く失敗し、別のバグのように見えます。

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

感嘆符は strongSwan の構文で、厳格な項目を意味します、この一つの組み合わせだけを提示し、他は提示しないという意味です。 それがなければ項目はフォールバック一覧に加わります、相手が現代的な機器なら問題ありませんが、単一のハードコードされたポリシーを持つ機器では逆効果です。 上の組は形式の例として扱い、今日作っている何かへの推奨とは考えないでください。

一つのフィールドを変えて、テストを繰り返す

現行のプラグインでは、最も速い最初のテストは両方の提案フィールドを完全に空にして再接続することです、同梱の既定一覧には一般的な Windows と Apple の組み合わせがすでに含まれているからです。 古いプラグインでは、空にするとサーバーが要求するアルゴリズムを落としているかもしれないデーモンに制御が戻り、失敗はさらに悪化します。

空にしても改善しないなら、サーバーが文書化している厳格な組を一フェーズずつ設定してください。 フェーズ 1 を変えて再接続し、フェーズ 2 に触る前にログを読んでください。 組み合わせがようやく動いたら、サーバーの型番とプラグインのバージョンの横に書き留めてください、既定値はまた動きますし、そのメモが次のアップグレードを五分の確認に変えます。