IPアドレスなのにエラー868？Windowsが最初に解決するもの
プロファイルは数値に見えるのに、ダイアログは名前解決の失敗を伝えます。実際のプロファイル項目を読み、名前の問題と古い再接続バグを切り分けます。
ダイアログはサーバー名を解決できなかったと告げていますが、見つめているプロファイル項目はアドレスです。この組み合わせは矛盾ではありません。クライアントは、あなたが読んでいると思っている値とは別のものを解決しています。DNSが壊れていると結論づける前に、実際に何へ接続しているのかを突き止めてください。クライアント自身の手順の順序を見れば、どこを見るべきか分かります。
クライアントは接続する前に名前を解決する
WindowsのネイティブVPN接続は、プロファイルを読み、サーバーアドレスを解決し、トンネルを開始し、その後にだけ認証します。エラー868は二つ目の手順に属します。後の手順が実行されないため、名前解決が先に失敗していても、ダイアログは資格情報の問題のように見えます。
この順序は、調べる層を絞り込めるので役立ちます。同じプロファイルが一方のネットワークでは動き、別のネットワークでは失敗する場合、違いは通常トンネルの種類やアカウントではなく名前解決です。プロファイルを作成した場所ではなく、障害が起きる場所で名前解決を試してください。
項目がアドレスを示すとき、どの名前か
表示名ではなく保存値を読みます。接続のラベルはサーバーアドレスではないため、似たラベルの二つのエントリがあると、間違った方を追いかけることになります。
Get-VpnConnection -Name "Work VPN" |
Select-Object Name, ServerAddress, TunnelTypeプロファイルが全ユーザー向けに用意されている場合は、そのスコープも次で照会します。-AllUserConnection。次に、コマンドが出力した値をそのまま、障害が起きるネットワークから解決します。事業者が文書化したゲートウェイを使い、トンネルが上がってからでないと解決しない内部アプリケーション名は使わないでください。この二度目の問い合わせは想定どおりの理由で失敗し、接続について何も教えてくれません。
Resolve-DnsName vpn.example.com保存値が本当に数値の場合は、クライアントが名前を読む二つ目の場所を探します。EAP構成がサーバーを参照していたり、別ツールからインポートしたプロファイルが独自の値を持っていたり、以前のインストーラーが重複エントリを残していたりすることがあります。ダイアログの項目が常に唯一の入力とは限りません。
Windows 7の再接続パターン
このエラーの背景にあるスレッドは、一度接続した後に、プロファイルを何も変えていないのに868で失敗するマシンについて述べています。投稿者らは、Remote Access Connection Managerサービスを再起動するか、サインアウトして再度サインインすると一時的に接続が回復したと報告しています。これは回避策であり、実証された根本原因ではありません。
そのパターンは別の仮説として扱ってください。再起動はクライアントの状態をリセットするため、その後の一時的な成功はDNSレコードが誤っていたことを証明しません。
| Observation | Points toward | What to do next |
|---|---|---|
| Fails from one network, works from another | Name resolution on that path | Resolve the stored name from both networks |
| Fails after a disconnect, works after service restart | Client state, not DNS | Record the sequence for the vendor |
| Fails only on a newly provisioned machine | Profile content or scope | Compare ServerAddress and TunnelType |
表は診断ではなく、区別するための観察の集合として読んでください。最初の行は名前の問題、二番目の行はクライアントの状態、三番目の行はそもそも正しくなかったプロファイルです。それぞれ異なる担当者と異なる修正につながります。
管理者に渡すべき情報
プロファイル名、保存アドレス、トンネルの種類、クライアントがいたネットワーク、切断後に障害が起きたかどうかを書き留めます。この記録があれば、誰かが推測しなくても、実際の名前解決の失敗と過去の再接続挙動を切り分けられます。試行前後のクライアントイベントログも保管してください。
古いビルドの回避策は、その挙動が存在した証拠であり、同じサービス再起動が現在のマシンを直すという約束ではありません。文書化されたホスト名をリテラルアドレスに置き換えることも修理ではありません。
プロファイルによっては、構成された名前と一致するサーバーIDを期待するため、数値による回避策は一つのエラーを別のエラーと交換するだけになります。名前を残す必要があるなら、プロファイルのテキストではなく解決経路を直してください。いずれにせよ、何をなぜ変更したかを記録してください。