Visual Studio langsomt kun på VPN? Tjek CRL og OCSP

Visual Studio starter normalt derhjemme, og så tilslutter den samme bærbare computer sig den virksomheds-tunnel, og hver start hænger på splash-skærmen i et halvt minut. Fjern politikken, og forsinkelsen forsvinder med den; fjern tunnelen, og det samme sker. Begge observationer er korrekte, og derfor får de to komponenter hele tiden skylden for hinanden. Det afgørende spørgsmål er, om et spærringsopslag på et certifikat venter på en rute, som kun tunnelen tilbyder, eller slet ikke finder nogen.

Mål hentningen, ikke starten

En WDAC-politik, udrullet som en signeret SiPolicy.p7b, afgør, hvilke images der må køre på maskinen. Kodeintegritet validerer et images signaturkæde før kørsel, og den validering kan omfatte et spørgsmål om spærring. Svaret afhænger af det CRL-distributionspunkt eller den OCSP-responder, som certifikatet angiver inde i sig selv.

Det er almindelige netværksanmodninger, så deres pris afhænger af, hvor responderen bor. Når den kun kan nås gennem tunnelen, eller dens navn kun opløses gennem en DNS-server bag tunnelen, venter valideringen på, at tunnelen er klar. Visual Studio indlæser ved opstart et stort antal signerede assemblies og udvidelser, og en lille forsinkelse pr. image bliver en synlig stopklods. Intet er forkert, og politikken opfører sig præcis som konfigureret, og derfor ser det ud, som om fjernelsen af politikken løser problemet.

Hvert signeret image kan udløse et netværkskald

Start med en signeret binær fil, der allerede ligger på disken, og bed platformen om at verificere den med samme hente-adfærd, som en start bruger. Kør kommandoen én gang på tunnelen og én gang uden for den, og sammenlign derefter hentelinjerne i stedet for den endelige dom.

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

Outputtet viser kæden, CRL- og OCSP-adresserne og om hver hentning lykkedes. En responder, der timer ud på tunnelen og svarer uden for den, er det bevis, du har brug for, og det vejer langt tungere end en fornemmelse af langsomhed. Hvis hentningen lykkes langsomt, så noter adressen, så næste trin kan teste den vært direkte.

Slå responderens værtsnavn op, og test tilgængeligheden uden for programmet, for et navn, der ikke kan opløses, bliver aldrig repareret af en klientindstilling. CodeIntegritys driftslog leverer den anden halvdel af beviset og knytter en valideringshændelse til tidsstemplet for den langsomme start.

Skær forsinkelsen ned uden at fjerne kontrollen

At deaktivere politikken eller skifte den til revisionstilstand fjerner forsinkelsen og fjerner den kontrol, organisationen har udrullet, så betragt det som den forkerte reparation. De snævrere muligheder er en ændring af routing, så responderen kan nås gennem tunnelen, en undtagelse i den opdelte tunnel for responderens værter, en DNS-korrektion, når navnet opløses til en utilgængelig adresse, eller en understøttet cache-proxy til spærringsdata. Hver har en forskellig ejer: PKI-teamet ejer responderens tilgængelighed, netværksteamet ejer tunnelopdelingen, og endpoint-teamet ejer politikken.

At udelukke hver spærringsvært fra tunnelen er ikke automatisk sikkert, da en intern responder kan være intern med vilje. Bekræft undtagelsen med det team, der driver PKI, før du skriver en regel, der stille sender certifikattjek til det offentlige internet. En ændring uden den bekræftelse er den slags, der rulles tilbage ved næste politikopdatering.

Verificer en kold start efter ændringen

Mål en kold start i begge tilstande, og gem tallene, for en varm start beviser næsten intet, når assemblies er cachede. Gentag starten fra en ny session, så udvidelsernes indlæsningsvej bliver brugt igen.

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

En repareret konfiguration kontakter stadig responderen eller bruger en cache-vej, som dit PKI-team har godkendt, og loggen viser, at valideringen fuldføres i stedet for at time ud. Bekræft, at et nyligt signeret program stadig starter, for en politik, der tillader alt, er ikke en vellykket reparation. Tjek også mappen med den aktive politik og håndhævelsestilstanden, så det vides, at den politik, du fejlretter, er den, der kører. Hold certifikatkæden, responderens adresse og starttidsstemplerne i samme billet, for en fornyelse flytter normalt responderen og efterlader undtagelses- eller DNS-reglen forældet.