Visual Studio が VPN 接続時だけ遅い？CRL と OCSP を確認する

Visual Studio は自宅では普通に起動しますが、同じノート PC が社内トンネルに接続すると、どの起動もスプラッシュ画面で三十秒止まります。ポリシーを外せば遅延も一緒に消え、トンネルを外しても同じことが起こります。どちらの観察も正しいため、二つのコンポーネントが互いに責任を押し付け合い続けます。決め手となる問いは、証明書の失効確認の照会がトンネルだけが提供する経路を待っているのか、それとも経路をまったく見つけられないのか、という点です。

起動時間ではなく取得時間を測る

署名された WDAC ポリシーは、 SiPolicy.p7b として展開され、どのイメージを実行できるかを決めます。コード整合性は実行前にイメージの署名チェーンを検証し、その検証に失効確認の問いが含まれることがあります。答えは、証明書が内部で示す CRL 配布ポイントまたは OCSP レスポンダーによって決まります。

これらは通常のネットワーク要求なので、コストはレスポンダーの場所によって変わります。トンネル経由でしか到達できない場合、または その名前がトンネルの内側の DNS サーバーでしか解決されない場合、検証はトンネルが準備できるまで待ちます。Visual Studio は起動時に多数の署名済みアセンブリと拡張機能を読み込むため、イメージごとの小さな遅延が見える停止になります。壊れているものはなく、ポリシーは設定どおりに動作しているので、ポリシーを外すと直ったように見えます。

署名済みのイメージはどれもネットワーク呼び出しを起こしうる

ディスク上に既にある署名済みバイナリから始め、起動時と同じ取得動作でプラットフォームに検証させます。コマンドをトンネル内と外で一度ずつ実行し、最終的な判定ではなく取得の行を比較します。

certutil -verify -urlfetch C:\Tools\Contoso.Editor.dll
nslookup ocsp.contoso.example
Test-NetConnection ocsp.contoso.example -Port 80

出力にはチェーン、CRL と OCSP のアドレス、各取得が成功したかが並びます。トンネル上でタイムアウトし、外では応答するレスポンダーが、必要としている証拠であり、遅いという印象よりはるかに重みがあります。取得が遅くても成功する場合は、次の手順でそのホストを直接試せるようアドレスを控えます。

レスポンダーのホスト名を解決し、解決できない名前はクライアント設定では決して直らないため、アプリケーションの外で到達性を試します。CodeIntegrity の操作ログが証拠の残り半分を与え、検証イベントを遅い起動のタイムスタンプに結び付けます。

制御を外さずに遅延を縮める

ポリシーを無効化したり監査モードに移したりすると遅延は消え、組織が展開した制御も外れるため、それは誤った修復とみなしてください。より狭い選択肢は、レスポンダーにトンネル経由で到達できるようにするルーティング変更、レスポンダーのホストに対するスプリットトンネルの除外、名前が到達不能なアドレスに解決されるときの DNS 修正、失効データ向けのサポートされたキャッシュプロキシです。それぞれ所有者が異なり、PKI チームがレスポンダーの到達性を、ネットワークチームがトンネルの分割を、エンドポイントチームがポリシーを担当します。

すべての失効ホストをトンネルから除外することは、内部レスポンダーが意図的に内部にある場合があるため、自動的に安全とは限りません。証明書チェックを静かに公衆インターネットへ送るルールを書く前に、PKI を運用するチームと除外を確認してください。その確認なしの変更は、次のポリシー更新で取り消される類のものです。

変更後にコールドスタートを検証する

両方の状態でコールドスタートを測定し、アセンブリがキャッシュされた後ではウォームスタートがほとんど何も証明しないため、数値を残します。新しいセッションから起動を繰り返し、拡張機能の読み込み経路をもう一度通します。

Get-WinEvent -LogName Microsoft-Windows-CodeIntegrity/Operational -MaxEvents 40 |
  Where-Object { $_.TimeCreated -gt (Get-Date).AddMinutes(-10) }
Get-ChildItem C:\Windows\System32\CodeIntegrity\CiPolicies\Active
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

修復された構成は依然としてレスポンダーに接続するか、PKI チームが承認したキャッシュ経路を使い、ログは検証がタイムアウトせず完了することを示します。すべてを許可するポリシーは成功した修復ではないため、新しく署名されたアプリケーションが今も起動することを確認してください。アクティブなポリシーのフォルダーと適用状態も確認し、デバッグしているポリシーが実際に動作しているものだと分かるようにします。更新は通常レスポンダーを移動させて除外や DNS のルールを古いままにするため、証明書チェーン、レスポンダーのアドレス、起動のタイムスタンプを同じチケットに残してください。