1つのVPN、2つのWindowsアカウント：もう一方のセッションが壊れる理由
ルートとリゾルバーはマシン全体に適用されるため、一方のアカウントのトンネルが他方を経路変更します。次に、どのポリシーまたはログオンモジュールが「ユーザーの切り替え」項目を削除したかを突き止めます。
二人がサインインしていて、一方が社内トンネルに接続すると、もう一方のアカウントのブラウザーが一分前まで正常だったページを読み込まなくなります。同じマシンではサインイン画面から「ユーザーの切り替え」項目も消えているため、二人目は自分のセッションに戻れません。これを二番目のセッションから外側へ追うのが最も速い理解の道であり、最初のユーザーの接続に隠れたものはなく、共有されているオブジェクトがどれか分かれば二人目の問題に謎は残らないからです。
壊れたセッションから始める
一番目ではなく二番目のアカウントのデスクトップへ移動します。そこでターミナルを開き、もう一方のセッションが接続された状態でルーティングテーブルとリゾルバーの一覧を見ます。目にするものはすべてマシンに属し、もう一方のユーザーに属するものはなく、これが最初の手がかりです。
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 12 DestinationPrefix,NextHop,InterfaceAlias
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,ServerAddresses
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,IPv4Connectivity既定ルートがトンネルインターフェイスを指すようになっていれば、二人目のトラフィックもそれをたどります。リゾルバー一覧にプライベートサーバーが加わっていれば、その検索はトンネルが切れた後に到達できない場所へ向かいます。どちらもクライアントの不具合ではなく、単一の共有ネットワークスタックの結果です。
三番目のコマンドは二つ目の種類の苦情を説明します。アダプターがマシンをパブリックからプライベートのネットワークカテゴリに切り替えると、プロファイルに限定されたファイアウォール規則が全アカウントで一斉に変わり、朝は許可されていたアプリが、誰も規則に触れないまま午後にブロックされることがあります。
接続はユーザーごとだが、ネットワークはそうではない
Windowsは接続オブジェクトを、それを作成したユーザーのプロファイルに保持します。それが生成する仮想アダプター、インストールするルート、そして登録するDNSサーバーはマシン全体の範囲です。この分離がタイトルにある二つの症状の源です。
最初のユーザーをサインアウトすると二人目が直ることが多い理由も説明できます。接続を削除するとアダプターとルートも一緒に削除され、マシン全体の状態は誰かが接続する前の状態に戻ります。これは有用な診断であり、サインアウトで別のアカウントが直るなら、壊れたプロファイルではなく共有状態を見ているのです。
できないのは、二番目のセッションに別のルーティングテーブルを与えることです。テーブルは一つしかなく、どの二つのセッションもそれを共有します。これはオペレーティングシステムの性質であり、特定のクライアントの制限ではありません。逆を前提とする設計は失敗し続け、その失敗は無関係なアプリの不具合に見えるでしょう。
「ユーザーの切り替え」を削除したものを、この順で探す
高速ユーザー切り替えはまったく別の理由で消えており、修正はルーティングとは関係ありません。四つの候補を順にたどりますが、最初の二つは数秒で元に戻せ、後のものにはコストがかかります。
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name HideFastUserSwitching
gpresult /h $env:TEMP\gp.html
Get-Service | Where-Object { $_.DisplayName -match 'Logon|Access|Credential' } | Select-Object Status,Name,DisplayNameレジストリ値が最も単純な説明です。それが存在して1と読めるなら、項目はポリシーで非表示になっており、グループポリシーのパスは「コンピューターの構成」「管理用テンプレート」「システム」「ログオン」で、高速ユーザー切り替えのエントリポイントを非表示にするという名前の設定です。これを「未構成」に設定し、gpupdate /force で更新します。
二番目のコマンドは、そのポリシーがローカルに書かれているのではなくドメインから配信されているかを示します。レポートに勝者のGPOとともに現れるなら、ローカル値を編集しても次の更新で戻る一時的な修正であり、話はポリシーの所有者とすべきです。
三番目のコマンドはもう一つの仕組みを扱います。ログオンモジュールをインストールする資格情報またはネットワークアクセスのプロバイダーは、実行中に項目を抑制でき、一部のクライアントはログオン前に起動してサインイン画面に要求を保持するコンポーネントも登録します。そのサービスを無効にすると切り替えは戻りますが、モジュールが提供するために存在するログオン前や体制の機能も失われます。
| Cause | How to confirm | Cost of the fix |
|---|---|---|
| HideFastUserSwitching policy | Registry value present and set to 1 | None; remove the policy |
| Logon module service | Service running under a vendor name | Loses pre-logon and posture behaviour |
| GINA-era assumption | Only relevant on very old Windows | Nothing to fix; the mechanism is gone |
自分を締め出さずに変更する
作業中は管理セッションを一つ開いたままにし、その画面を通してしか到達できないマシンでは決してサインイン画面を変更しないでください。先に他のセッションをサインアウトし、変更を適用して更新し、再起動ではなくユーザーの切り替えでテストします。
どの体制機能を無効にしたか記録します。クライアントの更新でログオンモジュールが再インストールまたは再有効化され、症状は明白な原因なく戻り、たいていはサポート対応の最中で、誰も以前の変更を覚えていないときに起こります。
管理されたデバイスでは、設定は上から配信されると考えてください。ポリシーレポートを先に確認すれば、元に戻るローカル編集の一時間を節約できます。答えが「いいえ」のときに誰に聞くべきかも分かります。勝者のポリシーを名指ししたチケットは、誰かがすでに変更したレジストリキーを説明するチケットの二倍速く解決します。
両方のアカウントを確認し、モデルを選ぶ
二人のユーザーが経験する順序で結果をテストします。一番目を切断した状態で二番目のアカウントとしてサインインし、通常のアクセスを確認し、次に一番目のアカウントのトンネルを接続して、二番目のアカウントの想定経路が依然として意図したものであることを確認します。
qwinsta
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Select-Object InterfaceAlias,NextHop,RouteMetric
Test-NetConnection -ComputerName intranet.example.internal -Port 443両方のアカウントが本当に同時に異なるネットワーク経路を必要とするなら、正直な答えは二台のマシン、二台の仮想マシン、または経路を一つだけ要求するポリシーです。共有接続のスプリットトンネルは流れるものを狭められますが、各セッションに独自のテーブルを与えることはできません。三回の回避策の後に発見するより、早くそこへ行くほうが安く済みます。
それが、周りを継ぎ当てするのではなく明示的に下すべき判断です。ルーティングテーブルが一つ、リゾルバー一覧が一つ、ファイアウォールプロファイルが一つで、ほかのすべてはそこから導かれ、それを尊重する修正は来月も機能します。