L2TP NO_PROPOSAL_CHOSEN：実際に失敗したのはどのフェーズか
通知は「提案が拒否された」としか告げず、どれとは言いません。バックエンドのログでフェーズを特定し、その後ゲートウェイの運用者とスイートを突き合わせてください。
NO_PROPOSAL_CHOSEN は PPP のユーザー名が調べられるより前に届きますが、これは有用な事実であり、同時にこのメッセージが誤解を招く理由でもあります。一方の側が提案を拒否したことだけを伝え、どのパラメータが食い違ったかは伝えず、拒否が IKE アソシエーションの構築中に起きたのか、それとも後段のトラフィック保護の交渉中に起きたのかも語りません。この二つの可能性の背後には別々の修正があり、人が最初に手を伸ばす PFS チェックボックスが関わるのは片方だけです。
一つのメッセージ、二つの提案セット
IKEv1 L2TP/IPsec の構成には二段階の交渉があります。フェーズ 1 は暗号化アルゴリズム、整合性アルゴリズム、Diffie-Hellman グループから IKE セキュリティアソシエーションを構築します。続いてフェーズ 2 がトラフィックの保護方法を交渉し、PFS の要件はその二つ目の会話に属します。
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
フェーズが順序立っているため、失敗した位置がどのリストを比較すべきかを教えてくれます。メッセージの診断的価値はそこに尽きるので、設定に触れる前に取り出しておく価値があります。
PFS チェックボックスがフェーズ 1 を直せない理由
PFS を無効にすると変わるのはフェーズ 2 の性質です。両者がフェーズ 1 で合意していなければ ESP の会話は一度も起きないため、チェックボックスは拒否にまったく影響せず、だからこそ切り替えても同じエラーが別のタイムスタンプで現れます。
逆の誤りも同じくらいよくあります。IKE アソシエーションの成功は ESP 提案が受け入れ可能だという証明にはならず、フェーズ 2 のグループが一致する証明には決してなりません。確立した管理トンネルはフェーズ 1 についての証拠としてだけ扱ってください。人は緑の行を「トンネルが上がっている」と読み、二度目の交渉が始まっていないことを誰も教えてくれなかったために、間違ったフェーズで一時間を費やします。
アルゴリズムを選ぶ前にログを読む
拒否の直前に出たメッセージを、実際に接続を処理しているバックエンドから集め、同じ試行と対応づけてください。その対応づけがなければ、あなたは別の接続の履歴を読んで結論を出していることになります。
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # Libreswanその行から、フェーズ 1 のアソシエーションが確立したか、どの交換が失敗したかという二つの問いに答えてください。この二つの答えが検索対象を一つの属性リストに絞ります。周囲の文脈がない裸の通知では、フォーラムのスレッドから提案を試すのがいかに魅力的でもそれはできません。別のバックエンドのマシンから動く文字列を写すと、たいていは一つの拒否が別の拒否に置き換わるだけで、しかも少し遅れて現れます。
バックエンドの構文は持ち運べない
何かを比較する前に NetworkManager-l2tp のバージョンと IPsec バックエンドのバージョンを記録してください。Libreswan と strongSwan は提案の構文もアルゴリズム集合も共有しないため、一方で動く文字列は他方では構文エラーです。インストールされたバックエンドがポリシーによって IKEv1 を拒否することもあり、その場合どの提案も受け入れられません。
プロジェクトの README はそうしたバックエンドの違いを記述し、フェーズ 1 とフェーズ 2 のフィールドを分けたままにしています。そうして初めて成功する接続は求められた接続ではないので、それを構造の文書として、過去の暗号や弱いグループをすべて有効にする招待としてではなく読んでください。
スイートで合意し、それから段階を検証する
ゲートウェイの運用者に、どの IKE と ESP のスイートがサポートされ承認されているかを尋ね、その答えをクライアントの設定ファイルではなく実際の提案と比較してください。不一致が特にフェーズ 2 の PFS に関するものであれば、サポートされたグループか、明示的に承認された PFS なしのポリシーで決着させます。ポリシーをエラーの名前から推測しないでください。
唯一の重なりが組織としてもう受け入れない暗号を要求する場合、判断はゲートウェイかプロトコル移行に属します。何かが交渉するまでクライアントの文字列を広げるのは、既知の弱さに緑のチェックを添えて出荷する方法です。
本当の不一致を直した後、L2TP と PPP を調べる前に IPsec の確立を確認し、その後の認証拒否は次の段階に属するものとして扱ってください。そのうえで、最初のアソシエーションの確立はその残りの寿命について何も語らないため、承認されたテスト手順で更新を試してください。