Windows の VPN エラーコード：どの段階で失敗したか、何を記録するか
829、703、720、691、649：どの番号も段階を指し、段階ごとに証拠が違う。一度の試行を記録し、ゲートウェイのログと突き合わせ、一つの層だけを変える。
障害のあとに Windows の VPN ダイアログを開くと、番号と一文が表示されるが、その一文はたいてい役に立たない半分である。番号は接続のどの段階で失敗したかを示し、段階が分かれば次に見るべきログ、設定、担当チームも決まる。段階を順にたどるのに十分ほどかかるが、それでアダプターの再インストール、プロトコルの切り替え、スタックのリセットといった、もともとダイヤルを許可されていなかったアカウントを直そうとするいつもの手順を避けられる。
番号を段階として読む
ネイティブ接続は四つの節目を通る。サーバーに到達してリンクを確立し、セキュリティを交渉し、ユーザーを認証し、アドレス指定とルーティングを適用する。それぞれの失敗は残す証拠が異なり、ある段階に属するコードは他の段階について何も教えてくれない。
避けるべき誤りは、コードを深刻度として扱うことだ。リンクの失敗も認可の失敗も「接続できませんでした」と表示されるが、それ以外に共通点はない。深刻度はどれだけ急ぐかを示し、段階は何を開くかを示す。
| Code family | Stage | Where the evidence lives |
|---|---|---|
| 829, 703 | Link or dial completion | Client event log, remote listener reachability |
| 720 | PPP negotiation and miniport binding | Adapter state, bindings, client log detail |
| 691, 649, 812 | Identity and authorization | Gateway or authentication server decision |
| Connected, no traffic | Addressing, routing and resolution | Route table and resolver configuration |
第一段階：リンクとダイヤルの試行
829 は基盤のリンクが切れたことを意味する。相手側が応答をやめたのか、中間装置がセッションを殺したのか、クライアントのポリシーが閉じたのかは分からない。703 のようなダイヤル完了コードはさらに手前で、試行がリンクを持つところまで届いておらず、これは通常プロファイル、サービスの状態、ローカルポリシーを指す。
Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Messageイベント クエリは人が飛ばす部分だ。タイムスタンプとインターフェイス名を伴うクライアント側の記録がダイアログより価値があるのは、試行がそもそも端末から出たのかが分かるからだ。記録もなくリスナーの応答もなければ到達性の問題であり、クライアントをどれだけ編集しても変わらない。
同じプロファイルが別のネットワークで動くなら、ここで止める。このコードは設定ミスではなく経路の状態を述べているのであり、次に比べるべきは再インストールではなく二つのキャプチャだ。
第二段階：PPP とミニポートのバインド
720 はリンクとユーザーの間に位置する。トンネルは上がったが、そのあと PPP 層がアドレスや制御プロトコルを交渉できなかった。これは多くの場合クライアント側のバインドの問題であり資格情報の拒否ではなく、その区別がこのコードの価値のすべてで、資格情報まで到達していないと分かるので、アカウントは容疑者ではない。
Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabledこの二つの出力を読むほうが、何かをリセットするより情報が多い。存在するが起動していないミニポート、あるいは他のソフトが無効にしたプロトコルのバインドは、まさにこの段階の失敗を生む。どちらもスタックの残りに触れずに直せる。逆に完全なリセットは、障害と無関係なアドレス指定やフィルターの状態まで消してしまう。
第三段階：身元と認可
691 は資格情報が拒否されたことを意味する。649 はアカウントにダイヤルの許可がないこと、812 はリモート アクセスのポリシーが接続を拒否したことを意味する。これらは判断であって転送の障害ではなく、クライアントは報告することしかできない。
証拠は反対側にある。そのタイムスタンプの試行と一致したポリシーをゲートウェイの運用担当者に尋ね、アカウントにダイヤルの許可があるか、ポリシーが要求するグループに入っているかをディレクトリの所有者に尋ねる。トンネルの種類を変えてもクライアントを再インストールしても、身元について下された判断は変わらない。
この段階で役に立つ習慣は、ドメインの接頭辞も含めてアカウント文字列を正確にチケットへ書くことだ。691 の驚くほど多くの事例は誤ったドメイン用に保存された資格情報であり、それはプロトコルの設定ではなくアカウント文字列に現れる。
第四段階：接続済みで、何も動かない
接続は完了しても役に立たないことがある。アドレスは持っていて、クライアントは成功を報告し、アプリケーションのすべての要求がタイムアウトする。ダイアログにはそれが何も現れず、調べるコードもない。その時点でダイアログは終わっており、役に立つ証拠は別の場所にある。
Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445経路がなければ、サーバーが押し出していないかクライアントが落とした。経路があり名前が解決できないなら、問題は名前解決にある。両方が動いてアプリケーションがまだ失敗するなら、トンネルの先、アプリケーション自身の設定に入っている。
変更は一回の試験につき一層に抑える。次の試行の前にした編集はすべて次のコードの文脈の一部になり、直前の編集を説明するコードはコードがないより悪い。
一度の試行、一つの変更、一つの記録
どの段階であれ、記録にはコード、メッセージ、プロファイル名、タイムスタンプ、そして自分がいたネットワークを含める。五つの項目で、どれもすでにダイアログかクライアントのログの目の前にある。この組み合わせはチケットに貼れるほど小さく、他人が再現できるほど具体的だ。
次にそのタイムスタンプを反対側の記録の隣に置く。このページの上部近くの表が、どの不一致がどの段階のものかを示す。二つ目の記録がなければコードは探索を狭めるだけだが、あれば段階が決まる。推測ではなく診断にするのは、この突き合わせである。
この習慣は Windows のネイティブ VPN の障害のほぼすべてを覆い、どの枝も何かの再インストールを必要としない。ダイアログはいつもどれを持っているかを教えてくれていたので、仕事は、それらすべてを同じ問題として扱わないことにある。