Windows では、無関係に見える二つの症状、つまり保存済みの接続がデバイス不在を報告する症状と数秒のうちに起動して停止する SSTP サービスが、同じ原因を共有する。どちらもパスワードの問題ではなく、どちらも先にプロファイルを作り直しても直らない。サインインの試行より前に存在していなければならないローカルの部品こそ、修復の出発点である。

以下の順に外側へ進み、症状が変わる最初の段階で止める。デバイスが存在する前にプロファイルを作り直しても、同じメッセージの二つ目の項目ができるだけだ。

認証情報ではなく、まずサービスから

ネイティブの Windows 接続の背後には、Telephony、Remote Access Connection Manager、Remote Access Auto Connection Manager という三つのサービスがある。発信プロファイルには三つとも動いている必要があり、どれも以前のクリーンアップスクリプトや堅牢化されたイメージによって無効のまま残りうる。使用中のサービスは Disabled のままにせず Manual か Automatic に設定し、他の何かに触れる前に起動しておく。Routing and Remote Access は着信接続をホストする別のコンポーネントであり、有効化は発信の前提条件ではない。

Get-Service -Name TapiSrv,RasMan,RasAuto | Format-Table Name,Status,StartType
Get-WinEvent -LogName System -MaxEvents 30 | Where-Object { $_.ProviderName -match 'Ras|RemoteAccess' }

起動してすぐに Stopped へ戻るサービスは、単に無効化されていたものとは別の障害だ。該当するイベントの記録が、続行を拒否したコンポーネント名を示す。

次にプロファイル背後のミニポートを確認する

正常なインストールでは、使用できるプロトコル、つまり PPTP、L2TP、IKEv2、PPPoE の WAN Miniport デバイスが一覧に載る。これらの項目がないか無効なら、Windows には接続を結びつける先がなく、プロファイルはデバイス不在を報告し続ける。隠しデバイスを表示した Device Manager を開き、Network adapters を展開して、絞り込まれた一覧ではなく実際の構成を見る。接続マネージャーを起動するとこれらのデバイスが再列挙されることが多く、だからサービスの不具合がハードウェア不在を装えるのだ。

ミニポートを有効にするのはサポートされた修復だが、アダプターをまとめて削除するのはそうではない。この違いは遠隔のマシンで効いてくる、削除したアダプターが失われる戻り道そのものだからだ。

SSTP が数秒で起動と停止を繰り返すとき

SSTP の下には、イベントログと WMI リポジトリという二つの共通コンポーネントがある。そのリポジトリが壊れていると、サービスは動作を続けることを拒み、VPN プロファイル側には説明がない。管理者セッションで Safe Mode に起動し、システムドライブの WMI ログフォルダー内にある RtBackup ディレクトリを、ディレクトリ自体は残したまま空にする。名前の変更がブロックされる場合は、先に中身を消してから改名し、古いファイルは置き換え側へ移す。イベントログを保存してから空にするのは、空の RtBackup で起動したサービスがログの壊れたままでは次の起動でも再び失敗しやすいからだ。

Event Viewer がまったく開かないなら、問題は VPN の設定ではなくログにある。別の設定を変える前にログへ戻ること。

項目を一つ作り直し、単独で試す

ネイティブの接続はすべて電話帳ファイルにあり、ユーザーごとのコピーは Network/Connections というパスのローミングアプリケーションデータフォルダーにある。マシン全体の電話帳は別のファイルで、互いに関係のない項目を含みうる。ウィザードで新しい接続を一つ追加するか、事業者が提供するパッケージをインポートし、他の何よりも先にその項目だけを試す。電話帳を丸ごと入れ替えると、壊れた接続と一緒に動いている接続まで落ちる。

rasdial "Office VPN"
rasdial "Office VPN" /disconnect
Get-PnpDevice -Class Net | Where-Object FriendlyName -like '*WAN Miniport*'

接続が確立しても何も運ばないなら、この修復の範囲は超えている。Hyper-V ホストでは、仮想アダプターで NetBIOS over TCP/IP を有効にすることが、文書化された複数の SSTP 事例で欠けている部品であり、確認に費用はかからない。期限切れのパスワードは、サインインが成功した後にしかディレクトリが新しい値を知らないため、接続したまま修復する。認証エラーに応じてデバイス経路を作り直しても混乱が増えるだけなので、進む前にどの段階で失敗したかを記録すること。

サービス、次にミニポート、次に一つのプロファイル、次に認証、次に遠隔のリソース。この順序が手法のすべてであり、最初の変化で止まることが、それを短く保つ。

関連記事