L2TPプロファイルのどの層が実際に壊れたのか

設定画面を横にたどるのではなく、スタックを下へたどる: IPsec交渉、次にL2TP制御、次にPPP認証、最後にアドレスとDNSの割り当てです。各層には独自のエラー署名と、独自の想定原因があります。ユーザー認証で失敗するプロファイルは、以前にタイムアウトしたプロファイルが決して到達しなかった三つの検査をすでに通過しています。まず確定すべきはこの順序です。

同じプロトコル名が四つの異なる会話を隠しています。

設定を変える前に層に名前を付ける

IPsecの設定に失敗するなら、共有シークレット、アルゴリズム、または相手の同一性が疑われます。その後にL2TP制御が失敗するなら、トンネル層そのものが疑われ、より狭い問題です。PPP認証の失敗はアカウントまたは認証方式を指し示します。認証後のアドレスやDNSの失敗は、転送は機能し、設定の交換は機能しなかったことを意味します。

クライアントのバージョン、OSのバージョン、事業者が文書化した設定を記録してください。この三つがなければ、どの変更も別の何かを偶然直してしまうかもしれない推測です。

プロファイルを現在のクライアントと比較する

保存されたプロファイルには、現在のクライアントがもう受け付けない共有シークレット、認証オプション、エンドポイントが含まれていることがあります。一部のプラットフォームはL2TP/IPsecのサポートを完全に廃止または削除しており、更新されたクライアントはサーバー側に何の変更もなく従来のIKE動作を捨てることがあります。保存した値は、一年前に動いていたものではなく、事業者の現在の文書化された要件と比較してください。その二つの文書の差が、通常は答えのある場所です。

キャッシュされたシークレットや名前を変えたアカウントは、通常は普通のプロファイル更新以上のものを必要としません。どちらも何かを再設計する前に確認する価値があります。これらは安価な修正であり、アーキテクチャに関わる作業の前に除外すべきものです。

古いオプションは有効にしても戻らない

検証を無効にしても信頼チェーンの問題は直りませんし、フォーラムのスレッドが言及しているからという理由でアルゴリズムを有効にしても、サーバーが何を受け付けるかについて何も証明しません。弱いIKE提案はたいてい正当な理由でクライアントから削除されており、その一つを再有効化すると壊れた接続より悪い接続ができます。弱いトンネルは修理ではなく、同じ症状を持つ新しい問題です。正しい問いは、事業者が今何をサポートしているかです。

すべてを有効にする修理は、実際の障害よりはるかに多くを変えてしまい、何が直したのか言えなくなります。

移行をプロジェクトとして提示する

配備が必要なクライアントをもうサポートしていないなら、文書化されていない例外を保存するのではなく、事業者と一緒に置き換えを計画してください。アクセス要件、ID、DNSエントリ、ルートを引き継いでください。新しいハンドシェイクだけでは、そうした許可のどれも再現しないからです。それらは、機能している接続が静かに依存していた部分です。復旧が確認されるまで古いプロファイルを安全に保管し、その後、古い資格情報が実際に管理されている場所で廃止してください。それを残しておくことが、全員が閉じたと信じたずっと後まで古い経路が使える理由です。

移行は、そのプロファイルが何のためのものだったかを書き留める機会でもあります。そうでなければ、次の人が説明のないまま機能する接続を引き継ぎます。

層、クライアントのバージョン、事業者の現在の要件を確認してください。そのうえで、それが修理なのか置き換えなのかを決めてください。