Windows のネットワーク リセットは VPN の不具合より多くを消す
リセットは失敗したトンネルだけでなく、アダプター、ルート、WFP フィルターを消去する。まずプロファイル、証明書一覧、証拠を保存し、それから層ごとに検証する。
Windows の VPN に関する苦情のたびに、十分以内にこの助言が届く。ネットワーク リセットを実行すれば全部直る、と。直らないし、的も絞られていない。そのボタンはアダプターを消去し、プロトコルを再バインドし、静的アドレスと既定ルートを削除し、ファイアウォールとフィルターのエントリを捨て、おまけに Wi-Fi プロファイルまで忘れる。トンネルは動いているが設定が誤っているマシンでは、診断可能な一つの不具合を、記録のない作り直しに変えてしまう。まず五つを保存すれば、取り消す選択肢は残る。
リセットは VPN プロファイルに限定されない
VPN 接続はネットワーク スタックを共有する多数のオブジェクトの一つにすぎない。アダプターを削除して再追加するとインターフェイス インデックスが変わり、そのインデックスを参照していたもの、ルートからファイアウォール規則、サードパーティのフィルター ドライバーまで、すべてが存在しないものを指すようになる。
仮想化はこれを悪化させる。Hyper-V スイッチ、VMware ブリッジ、コンテナ ネットワーク、独自の仮想アダプターを持つ VPN クライアントは、すべて同じ空間に同居している。基本スタックを再インストールするリセットは、そうした構成要素を中途半端に残し、結果として機械はハードウェアは正常なのに経路がない、と報告する。
どれも「決してリセットするな」という主張ではない。「まずリセットするな」という主張だ。記録も取っていないマシンで、実際の不具合が一つのルート エントリや古いフィルター一つかもしれないときに。リセットは成功率の狭い広範な道具であり、最初の一手にすれば、二つのどちらだったのかを永久に知れなくなる。
設定を保存する前に証拠を保存する
障害そのものがデータである。正確なエラー コード、時刻、選択されていたプロファイル、ゲートウェイが試行を記録したかどうかを書き留める。トンネルが応答を一度も受け取らなかったというコードと、認証に失敗したというコードは、まったく別の修理を指す。リセット後にはどちらも再現できないかもしれない。壊れた状態は、これから使い切る資産だと考えよう。
まだ壊れているうちに状態を取得し、マシンの一時ディレクトリの外のフォルダーに保存する：
mkdir C:\vpn-evidence
ipconfig /all > C:\vpn-evidence\ipconfig.txt
route print > C:\vpn-evidence\routes.txt
Get-VpnConnection -AllUserConnection | Export-Csv C:\vpn-evidence\profiles.csv -NoTypeInformation
netsh wfp show state file=C:\vpn-evidence\wfp.xml最後のコマンドこそが人が省くもので、しばしば不具合を説明してくれる。削除したクライアントの残りフィルターは永続ポリシーとして生き残り、エクスポートした XML がその唯一のローカル記録である。特定しようとしているものをリセットが消す前に読むこと。
戻ってこない構成を保存する
一部の設定は自動で作り直される。静的アドレス、カスタム ルート、DNS サフィックス、プロキシの例外、ファイアウォール規則は作り直されない。プロファイル自体も同じで、それらは電話帳ファイルの中にあり、リセットは代わりに復元してくれない。
| What to save | Where it lives | Why the reset loses it |
|---|---|---|
| VPN profiles | rasphone.pbk in ProgramData or the user profile | Profiles are not part of the adapter state |
| Static IP and DNS | Adapter configuration | Adapters are removed and recreated |
| Persistent filters | WFP policy store | Filter state is cleared with the stack |
| Third-party bindings | Adapter binding list | Components must be reinstalled manually |
Get-NetIPConfiguration | Out-File C:\vpn-evidence\netip.txt
Get-NetRoute -AddressFamily IPv4 | Export-Csv C:\vpn-evidence\netroutes.csv -NoTypeInformation
Get-DnsClientServerAddress | Export-Csv C:\vpn-evidence\dns.csv -NoTypeInformation
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject,Thumbprint,NotAfter証明書の一覧は見た目より重要だ。ネットワーク リセットはクライアント証明書を破壊しないが、一覧はプロファイルがどれに依存していたか、近く期限切れになるものがあるかを教える。作り直した後に期限切れの証明書を見つけるのは、その作り直しの無駄である。
始める前に復旧経路を書く
マシンが遠隔にあり、VPN が唯一の入口なら、リセットはセッションを終わらせ、現地に人がいなければ戻る道はないかもしれない。アダプターに触れる何かを実行する前に、帯域外のアクセスがあるか、人が待機していることを確認する。
インストーラーと接続情報は、後でマシンがたどり着ける場所に置く。トンネル経由でしか届かないベンダー ポータルから再インストールが必要なクライアントは循環依存であり、この手順がサービス停止になる最も一般的な道である。
次に、何をなぜ行うのかを正確なコマンドとともに記録する。次の人はリセットが実験だったのか判断だったのかを知る必要があり、「全部試した」は記録ではない。
リセット後は層ごとに検証する
一度に多くを戻すと結果が読めなくなる。下から進める。アダプターとアドレス、次に名前解決、次にトンネルの ID 段階、最後にアプリケーション。各層にはその層自身の問いに答えるコマンドがある：
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceDescription
Resolve-DnsName intranet.example.internal
Get-VpnConnection -Name 'Corp' | Select-Object ConnectionStatus,TunnelType
Test-NetConnection -ComputerName intranet.example.internal -Port 443アダプター層が健全で名前解決がそうでないなら、止まって解決を直す。その時点で VPN クライアントを再インストールすると変数が増え、手がかりが消える。説明できる設定だけを一つずつ戻し、戻すたびに同じ層を確認する。
たとえばマイクロソフト自身のエラー 720 のトラブルシューティング ガイダンスは、包括的なリセットを処方するのではなく、バインドの問題とアドレス割り当ての問題を区別している。これはこの系統のどのコードにも当てはまる正しい直感である。最も広い道具に手を伸ばす前に、コードが何を主張しているかを読むこと。