L2TP で NO_PROPOSAL_CHOSEN？まずゲートウェイをスキャンする

ユーザー名の入力画面は現れず、クライアントは NO_PROPOSAL_CHOSEN を報告します。認証情報と事前共有鍵はその時点では無関係です。両端がフェーズ 1 の保護方法で合意していないからです。多くの人はオンラインで見つけた暗号文字列を貼り付けて対応します。ゲートウェイをスキャンすれば、同じ問いに証拠付きで答えられ、所要時間もほぼ同じです。

このメッセージが排除するもの

拒否はメインモードで、L2TP や PPP の交換より前に起きるため、トンネルもユーザーデータベースも参照されていません。フェーズ 1 は暗号化、完全性、Diffie-Hellman グループを交渉します。フェーズ 2 はデータ用の ESP 提案を交渉します。 フェーズ 1 の失敗はフェーズ 2 の PFS 設定を変えても直りませんし、完了した IKE アソシエーションも ESP 提案が適合することの証明にはなりません。

構文を編集する前にバックエンドを記録します: ipsec --version。libreswan と strongSwan は同じアルゴリズムでも提案の表記が異なります。

次に、拒否を文脈ごと確認します: journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd。

ゲートウェイの変換セットをスキャンする

スキャナーは、どの変換を交渉するかをゲートウェイに直接尋ねます。まずローカルの IPsec サービスを停止し、探査が自分のクライアントと競合しないようにしてから、SA 行を読みます。一覧は相手側に関する証拠として扱い、すべて有効にするメニューとは考えないでください。

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

古い機器は 3DES、SHA1、MODP1024 を提供することがよくあります。製品の出荷時の既定値であり、誰も見直していないからです。スキャンの生出力は保存してください。その日に相手が何を提示したかを示す唯一の記録です。それが利用可能な最強の重なりなら、正しいエスカレーション先はゲートウェイの所有者であり、全員に弱い暗号を再有効化するクライアント設定ではありません。

安全性を無効にせず重なりを合わせる

スキャンとポリシーの両方に現れる変換だけを入力します。以下の例は、フェーズ 1 で 3DES、SHA1、MODP1024 を提供するゲートウェイを反映しています。バックエンドの注意点に留意してください。libreswan 4.x は modp1024 グループをコンパイルしないため、これは strongSwan か DH2 対応の libreswan ビルドに当てはまります。クライアントが壊れていると結論する前にバージョンを確認してください。

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

末尾の感嘆符は単一の提案を固定します。テストを切り分けるために使い、後で外してゲートウェイがより強い提案を交渉できるようにします。

再試行する前にデーモンとポートを確認する

NetworkManager-l2tp は独自の xl2tpd インスタンスを起動します。システムサービスがすでに UDP 1701 を占有している場合、クライアントは一時的な送信元ポートに退避します。RFC 3193 はこれを許容しますが、一部のサーバーは黙って破棄します。次の試行の前にソケットの所有者を確認してください。

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

古い生成シークレットも静かな原因です。次の場所にあるファイル /etc/ipsec.d/ 古い接続名のファイルは、それを作成したプロファイルより長く残ることがあります。何も参照していないものを削除して再試行してください。

最後に、その助言がどこから来たかを確認します。ipsec.conf IKEv1 XAuth 向けに書かれたファイルは別種の VPN を説明しており、その提案だけが L2TP プロファイルで誤りになる行ではありません。入力した変換セットをプロファイルの横に記録し、次の人が同じ探査を繰り返さないようにしてください。