Azure VPN Client: VPN プラットフォームが接続を開始しませんでした
再インポート、修復、リセットでは失うものが三つとも違います。ハンドオフの失敗をコスト順に切り分け、その後ストアの問題とゲートウェイの問題を分けます。
状態行は VPN プラットフォームが接続を開始しなかったと告げ、プロファイルは警告なくインポートされ、ゲートウェイは他の全員にとって正常です。このメッセージが示すのは Windows 内部のハンドオフであり、資格情報が拒否されたわけではないので、有効な順序は最も安い状態変更から最も破壊的なものへ進みます。プロファイルの再インポートは一分、パッケージの修復は再起動一つ、リセットはそのマシンの全プロファイルを失います。誤った順序で作業すると、これらのケースを区別するための証拠が失われます。
再インポート、修復、リセット:三つの異なるコスト
三つの操作は互換ではなく、手間なしで元に戻せるのは一つだけです。再インポートはプロファイルを更新し、アプリのインストールを保ちます。修復はインポート済みのプロファイルを保ち、パッケージのファイルを書き直します。リセットはプロファイルをアプリの状態ごと削除するので、後ですべてをインポートし直すことになります。
| Action | Keeps | Removes |
|---|---|---|
| Re-import profile | App, other profiles | The stale profile entry |
| Repair package | Imported profiles | Damaged app files |
| Reset app | Nothing local | All profiles and app state |
ゲートウェイ、アドレスプール、認証方法が変わったときは、必ず azurevpnconfig.xml を新しくダウンロードしてから始めます。削除されたゲートウェイを指すプロファイルはまさにこの状態行を出し、クライアント側の修復では存在しないものを指すファイルは直りません。
破壊的な手順の前に、アプリがバックグラウンドで動作してよいか確認します。設定、アプリ、インストールされているアプリ、Azure VPN Client、詳細オプションの順です。中断されたクライアントはプラットフォームのハンドオフを完了できません。
RasMan はクライアントがハンドオフする先のサービスです
Remote Access Connection Manager がクライアントの要求を Windows の接続に変えます。管理者として開いたコマンドプロンプトで net stop rasman、続いて net start rasman を実行して再起動し、他を変える前に再接続します。
それで接続が戻るなら、修正が再起動後も残るようスタートアップの種類を設定します。sc.exe config rasman start= delayed-auto です。今は動作していても起動時に無効なサービスは、翌朝また同じ障害を再現します。
起動した後に自然に停止するサービスに注意します。このパターンは依存関係かポリシーを示し、再起動は数分おきに効くだけなので、きれいな失敗より厄介です。断続的なネットワーク問題に見えるからです。試行時刻の前後で System ログのサービス名を確認し、依存関係も動いていることを確かめます。
現在のユーザーかローカルコンピューターか:二つの証明書ストア
クライアントが空の証明書一覧で開くなら、原因はプロファイルでもサービスでもありません。クライアントは現在のユーザーの個人ストアを読みます。certmgr.msc を開き、Certificates、Current User、Personal、Certificates を展開し、証明書が秘密キー付きであることを確認します。
certlm.msc で開くローカルコンピューターのストアは別のストアで、そこにインストールしてもユーザーストアを見るクライアントは満たされません。証明書認証では、ゲートウェイが持つのはルートの公開キーだけであり、各デバイスはそのルートから発行された自分の証明書を必要とします。他のマシンからコピーした証明書は通常、秘密キーなしで届くため、選択はできても認証できない項目になります。
空の選択画面はストアの問題であり、トンネルの問題ではありません。
証明書認証か Azure AD か:異なる失敗の形
Azure AD 認証では、ポイント対サイト構成にテナントの URL、対象として Azure VPN Client のアプリケーション ID、STS の発行者が必要で、管理者が Azure VPN アプリケーションに同意を与えます。その構成を保存し、パッケージをダウンロードし直し、古いコピーを使い回さず新しいファイルをインポートします。
クライアントのアドレスプールが仮想ネットワークやオンプレミスの範囲と重ならないこと、対象マシンのネットワークセキュリティグループがそのプールを許可することも確認します。この二つの誤りはクライアント側のあらゆる修復をすり抜けます。
ノート PC 側かゲートウェイ側か
パブリックアドレスの確認でトンネルを判断しないでください。ポイント対サイト接続はすべてのインターネット通信を Azure に送るわけではないので、トンネルが正しく動作していてもパブリックアドレスが変わらないのは想定どおりです。代わりに仮想ネットワーク内のプライベートアドレスを試し、マシンの有効なルートを読みます。
どの手順で接続が戻ったか、クライアントのバージョン、プロファイルのダウンロード日、資格情報を証明書と ID プロバイダーのどちらが供給したかを書き留めます。その記録は次の発生を二分の確認に変え、障害がノート PC にとどまらずゲートウェイ側へ移っているかを示します。
作業順序は、最新のプロファイルを再インポートし、RasMan を再起動し、バックグラウンド実行を許可し、パッケージを修復し、証明書ストアが無傷だと確認できた場合にのみリセットします。