Visual Studio tregt bare på VPN? Sjekk CRL og OCSP

Visual Studio starter normalt hjemme, så kobler den samme laptopen seg til bedriftstunnelen og hver oppstart står et halvt minutt på oppstartsskjermen. Fjern policyen og forsinkelsen forsvinner med den; fjern tunnelen og det samme skjer. Begge observasjonene er riktige, og derfor får de to komponentene stadig skylden for hverandre. Det avgjørende spørsmålet er om et tilbakekall-oppslag venter på en rute som bare tunnelen tilbyr, eller om det ikke finner noen i det hele tatt.

Mål hentingen, ikke oppstarten

En WDAC-policy, rullet ut som en signert SiPolicy.p7b, avgjør hvilke bilder som får kjøre på maskinen. Kodeintegritet validerer signaturkjeden til et bilde før kjøring, og den valideringen kan inneholde et spørsmål om tilbakekall. Svaret avhenger av CRL-distribusjonspunktet eller OCSP-responderen som sertifikatet navngir inne i seg.

Dette er vanlige nettverksforespørsler, så kostnaden avhenger av hvor responderen ligger. Når den bare er tilgjengelig gjennom tunnelen, eller navnet bare løses gjennom en DNS-server bak tunnelen, venter valideringen til tunnelen er klar. Visual Studio laster ved oppstart et stort antall signerte assemblyer og utvidelser, og en liten forsinkelse per bilde blir en synlig stopp. Ingenting er feil, og policyen oppfører seg nøyaktig som konfigurert, og derfor ser det ut som om fjerning av policyen løser problemet.

Hvert signert bilde kan utløse et nettverkskall

Start med en signert binærfil som allerede ligger på disken, og be plattformen verifisere den med samme henteatferd som en oppstart bruker. Kjør kommandoen én gang på tunnelen og én gang utenfor, og sammenlign deretter hentelinjene i stedet for den endelige dommen.

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

Utdataene lister opp kjeden, CRL- og OCSP-adressene og om hver henting lyktes. En responder som timer ut på tunnelen og svarer utenfor, er beviset du trenger, og det veier langt tyngre enn et inntrykk av treghet. Hvis hentingen lykkes sakte, noter adressen slik at neste trinn kan teste den verten direkte.

Slå opp vertsnavnet til responderen og test tilgjengeligheten utenfor applikasjonen, for et navn som ikke løses, blir aldri reparert av en klientinnstilling. Driftsloggen til CodeIntegrity gir den andre halvdelen av beviset og knytter en valideringshendelse til tidsstemplet for den trege oppstarten.

Kort ned forsinkelsen uten å fjerne kontrollen

Å deaktivere policyen eller bytte den til revisjonsmodus fjerner forsinkelsen og fjerner kontrollen organisasjonen rullet ut, så betrakt det som den feil reparasjonen. De smalere alternativene er en rutingsendring slik at responderen er tilgjengelig gjennom tunnelen, et unntak i den delte tunnelen for respondervertens navn, en DNS-korreksjon når navnet løses til en utilgjengelig adresse, eller en støttet hurtigbufferproxy for tilbakekallsdata. Hver har en annen eier: PKI-teamet eier tilgjengeligheten til responderen, nettverksteamet eier tunneldelingen, og endepunktsteamet eier policyen.

Å utelukke hver tilbakekallsvert fra tunnelen er ikke automatisk trygt, siden en intern responder kan være intern med vilje. Bekreft utelukkelsen med teamet som drifter PKI-en, før du skriver en regel som stille sender sertifikatsjekker til det offentlige internettet. En endring gjort uten den bekreftelsen er den typen som blir rullet tilbake ved neste policyoppdatering.

Verifiser en kaldstart etter endringen

Mål en kaldstart i begge tilstander og ta vare på tallene, for en varmstart beviser nesten ingenting når assemblyene er bufret. Gjenta oppstarten fra en ny økt slik at innlastingsbanen for utvidelsene blir prøvd igjen.

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 reparert konfigurasjon kontakter fortsatt responderen, eller bruker en hurtigbufferbane PKI-teamet ditt godkjente, og loggen viser at valideringen fullføres i stedet for å time ut. Bekreft at et nylig signert program fortsatt starter, for en policy som tillater alt er ikke en vellykket reparasjon. Sjekk også mappen for den aktive policyen og håndhevingstilstanden, slik at det er kjent at policyen du feilsøker er den som kjører. Hold sertifikatkjeden, responderens adresse og oppstartstidspunktene i samme sak, for en fornyelse flytter vanligvis responderen og lar unntaks- eller DNS-regelen bli utdatert.