Hyper-V 後で Cisco VPN が固まる——結合解除か再構築か

クライアントは securing communications で回り続け、ログイン画面がまったく出ません。変わったのはエミュレーターの導入だけです。このパターンはプロファイルやパスワードではなく、仮想アダプターを指します。判断すべきは、アダプターが本来いるべきでない Hyper-V スイッチに結合されているのか、それとも一度も起動していないのかです。

この二つの状態はクライアント上では同じに見え、必要な修理は異なります。一つは取り消せる結合であり、もう一つは結合解除では触れないドライバーの問題です。

securing communications 段階が待っているもの

トンネルが構築される前に、クライアントはゲートウェイまでの正常なローカルネットワーク経路を必要とします。独自の仮想アダプターを導入し、その経路の一部として使います。Hyper-V がそのアダプターをエミュレーター用に作られたスイッチに接続すると、アダプターは使える経路を提示しなくなることがあります。

クライアントはどのアダプターを待っているかを報告しません。ログは通常、到達した最後の段階で終わり、同じ失敗がどのゲートウェイアドレスでも現れます。だからこそエラー文よりも導入履歴が重要です。ログは残しておく価値があります。段階は分かっても原因は分かりません。

資格情報の再入力やプロファイルの再導入では、スイッチの結合は変わりません。それが最初の二手なら、間違った層を直しています。

判断その一——VPN アダプターは誤ったスイッチに結合されているか

Hyper-V マネージャーを開き、次に仮想スイッチマネージャーを開いて、各スイッチのアダプター一覧を読みます。Cisco アダプターがエミュレーター用スイッチの接続先として現れてはいけません。現れているならそれはこちらの誤りで、そのスイッチから外すのが修理です。

まず再起動し、中途半端に接続された状態ではなくきれいに起動させます。結合を外して適用し、試験するまで他のアダプターはそのままにします。変更は元に戻せ、何もアンインストールしませんが、どのアダプターを外したか書き留めます。

クライアントを起動して接続を試します。まだ固まるなら、残りの仮想アダプターを一つずつ結合解除し、その都度試験します。どれが効いたのか分かるようにするためです。

判断その二——アダプターは起動しているがアドレスがない

管理者として開いたコマンドプロンプトから ipconfig /all を実行し、非表示のアダプターも含めて一覧を、導入前の記憶と比べます。アドレスがなく、メディアが切断状態のアダプターは、通常ドライバーが起動していないことを意味します。それは結合解除では直りません。何かを変える前に正確な状態を記録します。

起動しているのに誤ったスイッチに接続されているアダプターは、前の節の事例です。アドレスの状態が両者を見分ける手がかりです。

不具合を戻さずにエミュレーターを戻す

トンネルが動いたら、エミュレーター自身のアダプターをそのスイッチに戻し、VM がアドレスを取得することを確認します。VPN アダプターは戻さないでください。終わりと判断する前に、エミュレーターとクライアントの両方をもう一度試験します。

管理されたワークステーションでは、どの結合を変えたかを管理者に伝えます。後日のポリシー更新で古い接続が戻り、はっきりした原因もなく固まりが再発します。

アダプター名、結合されていたスイッチ、そして変更前と変更後の ipconfig の状態を記録します。更新後に固まりが戻ったとき、その記録が五分の確認と一からのやり直しを分けます。