¿Falta a directiva de grupo na VPN? Comprobe o ámbito antes do túnel

Algo que se aplicaba na rede da oficina deixa de aplicarse a semana en que un usuario comeza a traballar por VPN, e o túnel recibe a culpa antes de que ninguén abra un informe. A directiva de grupo decide que configuracións chegan ao usuario e ao equipo de Windows, recolle o material do dominio e executa o procesamento no lado do cliente, e eses tres pasos fallan de tres maneiras distintas. O túnel só cambia que ruta ten o cliente. Percorrer as comprobacións en orde evita que un problema de permisos de ficheiro se persiga como un problema de encamiñamento.

Comece pola configuración, non polo túnel

Anote unha GPO esperada e unha configuración concreta dentro dela, e despois decida se esa configuración vive en Configuración de usuario ou en Configuración de equipo. Isto supón un cliente Windows autorizado e unido ao dominio nunha VPN aprobada, non un dispositivo non xestionado ou só na nube que se converte en membro do dominio. A resposta sobre o ámbito decide quen pode ler o resultado e se fai falta elevación, así que resolva iso antes de executar nada.

Pregunte ao administrador do dominio que vínculo, localización de obxecto, filtros de seguridade e filtros WMI deberían estar en xogo. Cambiar eses controis para que unha proba pase é outro proxecto con outro responsable.

Lea o informe coa conta á que pertence a configuración

Na sesión propia do usuario afectado, execute whoami /user e despois gpresult /scope user /r. A conta que autenticou a VPN non é automaticamente a conta de Windows cuxa directiva está a ler, e unha comprobación desde unha conta de administrador responde a outra pregunta. Garde a liña base cun nome de ficheiro novo, como %TEMP%\vpn-policy-user-before.html. A referencia de gpresult documenta os modificadores de ámbito e de saída, e paga a pena saber que xerar un informe non actualiza nada.

A directiva de equipo ten o seu propio ámbito e contexto de permisos, así que revísea por separado coa elevación que necesita. Xuntar ambos os ámbitos nun só informe é a forma en que unha configuración de usuario se declara ausente cando nunca estivo nese ámbito.

O descubrimento non é acceso: primeiro os rexistros SRV, despois SMB

Coa VPN aprobada conectada, confirme que o cliente resolve os controladores de dominio pola ruta DNS prevista; un sitio web público que carga non di nada sobre o descubrimento de controladores. Para o dominio ilustrativo corp.example, nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example responde á pregunta que realmente ten. Un rexistro de servizo devolto é só unha proba de descubrimento, porque o enderezo do controlador seleccionado aínda ten que ser alcanzable coa autenticación requirida e os servizos de directorio permitidos. O material de directiva chega despois desde SYSVOL, que é unha lectura SMB contra ese controlador concreto e non unha proba ICMP.

Unha proba máis feble confúndese facilmente cunha proba. Unha resposta ICMP dun controlador, xunto a unha lectura denegada dun modelo de directiva, produce un informe que parece baleiro por unha razón que aínda ninguén conectou.

Manteña coherentes os permisos do servizo AD, as rutas de retorno e a sincronización horaria do despregamento, en lugar de substituílos por unha apertura xeral da devasa ou un servidor DNS público. Os datos de directiva que difiren entre controladores son unha cuestión de réplica para o propietario do directorio.

Unha actualización, dous informes, unha comparación

Coa ruta probada, solicite a actualización correspondente con gpupdate /target:user e lea o resultado en lugar de supoñelo. A actualización predeterminada aplica a directiva modificada mentres que /force pide unha reaplicación; ningunha das dúas repara DNS, permisos de ficheiro nin filtrado. Algunhas extensións só se completan nun inicio de sesión posterior ou noutro evento en primeiro plano, así que unha soa execución non é un veredicto. Engadir modificadores de peche de sesión ou reinicio á sesión dun usuario remoto como diagnóstico rutineiro bota o que tivese aberto.

Xere un segundo informe cun nome de ficheiro distinto e compare o tempo de procesamento, a GPO esperada, o seu estado aplicado ou denegado e a propia configuración. Un informe dunha sesión anterior correcta non demostra nada sobre esta actualización. Unha directiva filtrada apunta á aplicabilidade máis que ao transporte, o que cambia quen posúe o paso seguinte.

Ate o fallo a unha soa actividade

No Visor de eventos, comece polo aviso ou o erro de directiva de grupo no rexistro do sistema e despois pase ao rexistro operativo GroupPolicy en Rexistros de aplicacións e servizos. Filtre ese rexistro operativo polo identificador de actividade da actualización que acaba de executar, porque unha actualización nova obtén un identificador novo e mesturalo cos eventos de onte produce unha conclusión segura e errónea. Anote a hora, o contexto de usuario ou equipo, o controlador seleccionado, a GPO, o código de erro e a dependencia fallida.

Esa nota é aquilo sobre o que pode actuar o propietario da rede ou do directorio. Estar conectado á VPN e ter executado gpupdate varias veces non son probas, e ningunha das dúas sobrevive a un traspaso.

Manteña os informes HTML privados, porque expoñen nomes internos, pertenza a grupos e configuración de seguridade. Unha vez confirmada a configuración, retire os permisos temporais que engadiu en lugar de deixalos no seu sitio.