L2TP/IPsec エラー 789・720・691：まず正しい段階を直す

Windows 11 は L2TP/IPsec の段階ごとに異なる番号を報告し、その番号は故障を採点するのではなく段階を示します。789 は PPP リンクが存在する前に失敗し、720 はリンクを立ち上げている最中に失敗し、691 はリンクが上がって資格情報が拒否された後に失敗します。役立つ判断は、どの修正が最も人気かではなく、コードがどの段階に到達したことを証明しているかです。まずそれを読み、次に試行ごとに一層だけ変えて、次のコードがまだ何かを教えてくれるようにします。

コードを障害一覧ではなく段階として読む

L2TP 接続は決まった順序で三つの境界を越えます。IKE は UDP 500 でセキュリティ アソシエーションをネゴシエートし、NAT トラバーサルがそのトラフィックを UDP 4500 に移し、その後に初めて L2TP トンネルが、ユーザーを認証してアドレスを割り当てる PPP セッションを運びます。

この順序のおかげで、変わるエラー コードが有用な証拠になります。789 から 720 に進むことは、IPsec がネゴシエートするようになり、障害がリンク確立に移ったことを意味します。720 から 691 に進むことは、リンクが上がり、ゲートウェイが ID を拒否したことを意味します。五つの修正を一度に適用すると、その信号を失い、どの変更が効いたのか分からなくなります。

789：経路とローカル ポリシーのどちらを選ぶか

コード 789 は、初期のセキュリティ ネゴシエーション中の処理エラーです。IPsec は使用可能なアソシエーションを一度も生成しなかったので、アカウントはまだ試されていません。アカウントではなく、経路と共有キーから始めましょう。

UDP 500 と UDP 4500 がサーバーに到達すること、および事前共有キーが大文字小文字や末尾の空白も含めてバイト単位で一致することを確認します。サーバーが NAT の背後にある場合は、Windows に文書化されたレジストリ値も必要になることがあります。サーバーが NAT の背後にあるときは 1、両端がそうであるときは 2 を使用し、ポリシー エージェントが起動時に値を読むため再起動します：

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

より重いアダプター修復は別の分岐に属します。Wi-Fi デバイスと WAN ミニポートを削除してからハードウェアを再スキャンするのは、ローカルの IPsec スタック自体が破損していて他の VPN の種類も同じように失敗する場合に正当化されます。一つの L2TP サーバーだけが失敗し、他のすべてのネットワーク経路が機能している場合は無駄な努力です。

720：このアダプターとサーバー プールのどちらを選ぶか

エラー 720 は、リモート コンピューターへの接続を確立できなかったことを報告し、IPsec が成功した後に現れます。トンネルはインターフェイスを立ち上げるかアドレスを取得する地点まで到達し、そこで停止しました。そのためこれはローカル アダプターの問題か、サーバー容量の問題になります。

判断には影響範囲を使います。Windows マシン一台の失敗は、不良な WAN ミニポート、停止した Remote Access サービス、壊れた接続プロファイルを示します。複数のクライアントが同時に失敗する場合は、アドレス プールの枯渇、停止した RRAS サービス、クライアントのサブネットと合わなくなったプールというサーバー側を示します。パターンが示す側を、もう一方を変える前に直しましょう。

単一クライアントの分岐では、WAN ミニポートを一度削除してハードウェア変更をスキャンし、再起動して再試行します。サーバーの分岐では、動作しているアダプターを再インストールしてもサーバーが持っていないアドレスは作れないため、クライアントではなくプールとサービスの状態を確認します。

691：資格情報と停止したヘルパーのどちらを選ぶか

コード 691 は認証拒否であり、間違ったパスワードとして最も誤読されるコードです。トンネルは上がっており、ゲートウェイは ID を見てそれを拒否しました。原因は依然としてパスワード欄の外にある可能性があります。

まずドメイン欄を確認し、次にパスワードの正確な文字を確認します。空白、引用符、シェル特殊文字を含むパスワードは、サーバーに届く前に壊れることがあり、Linux では、pppd が E=691 と同じ拒否を報告します（引用符なしの値やドメイン欠落の場合）。貼り付けずにシークレットを入力し直し、古い値を保持している可能性のある保存済み資格情報を消去してください。

人が見落とす分岐は、停止したヘルパー サービスです。ベンダーのクライアントが資格情報をゲートウェイに渡すために独自のサービスに依存している場合、無効化またはクラッシュしたサービスは、パスワードが正しくても 691 を生成します。アカウントをリセットする前に、特に再起動や更新の後に、ベンダー サービスの状態を確認してください。

分岐を切り分けるには、同じユーザー名を別の動作する VPN プロファイルまたは RADIUS テスト アカウントで試します。それが成功すれば資格情報は正常で、ローカル クライアント経路が疑わしいです。同じように失敗すれば、アカウントまたはゲートウェイ ポリシーが問題です。

試行ごとに一層だけ変える

外側から内側へ進めます：到達性と NAT トラバーサル、次に事前共有キー、次にローカル アダプター スタック、次に資格情報、次にサーバー プールとサービスです。この順序はコードが示す段階に従い、各結果を一つの変更に帰属させ続けます。

各試行の前後のコード、クライアントのビルド、サーバーとクライアントのどちらを変えたかの短い記録をつけます。789、次に 720、次に 691 という並びは進捗の地図で、同じコードが二度続くなら、最後の変更がその段階に対処していません。Windows の再インストールはこの地図を消し、ゲートウェイに住む失敗をめったに直しません。

コードが変わらなくなったら、物を変えるのをやめます。現在のコード、サーバー アドレス、認証方法、試行の時刻を記録し、その記録を動作するクライアントと比較します。二つの記録の差は、通常、人が既定で試す修正リストより小さいものです。