Windows の NAT-T レジストリ値：まずトポロジーを確認する

Windows の VPN 接続が失敗し、検索でレジストリ値が見つかり、その値が再起動とともに投入される。この手順はときどき効くが、何も説明しない。問題の設定が答えるのは、サーバーが NAT 機器に対してどこにあるかという一つの問いであり、どのプロトコルがどの段階で失敗したかを知るまでは無意味だ。

その値が実際に選ぶもの

AssumeUDPEncapsulationContextOnSendRule は、Windows の IPsec 実装が NAT 機器の背後にあるピアとの関連付けを試みるかどうかを決める。文書化された既定値 0 はそのケースを許さず、1 はサーバーが NAT の背後の側である場合に許し、2 は両端が変換される場合を扱う。これは誰がどこにいるかというトポロジーの記述である。

並びとして読むと、これらの数値は信頼性が順に上がるのではなく、変換が順に増えることを示す。何も変換されないネットワークで 2 を設定しても、接続が速くも安定にもならず、認証の失敗も直らない。Microsoft の L2TP/IPsec 向け NAT ガイダンス は、ポリシーとその歴史的なプラットフォーム文脈を記述している。その文脈は、実際に動かしている Windows のバージョンと役割に照らして確認すべきだ。複数のリリースを生き延びた文書は、現在のすべてのビルドについての説明ではない。

数値より先にトポロジーを合わせる

経路を描き、変換点に印を付ける。クライアントは家庭用ルーターの背後か、サーバーはロードバランサーやアドレスを書き換えるファイアウォールの背後か、どちらかの端が自分で制御できない事業者側の変換の背後にあるかを見極め、その図を描いて初めて、値が当てはまるか、どちらの端に当てはまるかを決められる。

現在の Windows Server のバージョンが単に NAT トラバーサルを無効にして出荷されているという主張は、行動の根拠にするには広すぎる。重要なのは自分のシステムのポリシー、その前にあるトポロジー、そして失敗した交換であり、この順である。両端が公開アドレスを持つなら、その設定は自分の問題ではない。代わりに提案、証明書、アカウントを見て、レジストリはそのままにしておく。

まず失敗した段階を確認する

L2TP/IPsec は少なくとも三つの異なる失敗を生む。ピアに到達できない、IPsec 保護を確立できない、そして トンネルが存在した後に PPP ユーザー認証が拒否される。拒否されたアカウントは NAT ポリシーの変更では直らず、提案の不一致は再起動では直らない。

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

応答がないタイムアウトはポリシーよりも到達性やフィルタリングを示す。提案メッセージを伴う即時の拒否はアルゴリズムを指す。トンネルが上がった後の失敗は認証段階に属し、別の担当と別の対処になる。

HTTPS 上の SSTP とネイティブの IKEv2 には独自のログと独自の制御がある。Windows でも動くというだけで、どちらかが NAT トラバーサルの事例になるわけではない。

戻る道を用意して変更する

文書化されたポリシーと観測したトポロジーの両方がそれを求めるなら、以前の値を記録し、プロファイルごとのスクリプトではなく管理された構成で変更を適用し、再起動を計画する。他のワークロードを支えるサーバーでは、これは無害な編集ではない。

NAT 機器はカプセル化された通信と戻りトラフィックを依然として運ぶ必要がある。レジストリ値は転送規則を作らず、提案を揃えず、身元を検証しない。だから変更後に動き出した接続が、まったく別の理由で動いている可能性がある。元のトポロジーで元のプロトコルを再試験し、どの段階が失敗したのか、なぜその値が解決するはずだったのかを書き留める。その一文が、インターネットの噂を擁護できる構成に変える。