¿La comprobación de estado del VPN no bloquea? Sigue primero el informe

Si un portátil cuyas firmas de antivirus dejaron de actualizarse hace semanas todavía puede abrir tu aplicación interna, rara vez el documento de política es lo que está mal. Tres sistemas separados tienen que ponerse de acuerdo antes de que se deniegue el acceso: algo mide el endpoint, algo convierte esa medición en un veredicto de permitir o denegar, y algo descarta realmente el tráfico. Cuando un dispositivo no conforme entra de todos modos, exactamente uno de esos eslabones falta o confía en pruebas que no debería. Las comprobaciones siguientes van en ese orden, y cada una tiene un punto de parada.

El bloqueo es el último paso, no el primero

La autenticación y el estado del dispositivo responden preguntas distintas. Un inicio de sesión correcto demuestra que se presentó una credencial; no dice nada sobre el software que se ejecuta en la máquina que la presentó. Ese hueco es la razón por la que un perfil de cliente copiado puede llevar una sesión de aspecto sano a un host no sano.

El trabajo de conformidad del endpoint ya tiene vocabulario para esta cadena. El modelo de referencia NEA del RFC 5209 divide la tarea en un recopilador, un paso de evaluación y un punto de aplicación, y dice claramente que un cliente que miente sobre su propio estado queda fuera del modelo. Esa salvedad importa más que el diagrama: un módulo de plataforma fiable no convierte una medición autoinformada en un hecho.

Mantén honesto al recopilador en cuanto al alcance. Debe informar de los atributos que nombra tu política, en el dispositivo que pide acceso, y de poco más. Un agente de inventario que enumera cada paquete instalado es una herramienta distinta de un recopilador de estado, y la diferencia es a la vez un problema de retención y de precisión. Si el informe no se puede atar a una identidad de dispositivo, el evaluador adivina qué máquina acaba de autorizar.

Un panel que muestra un estado rojo no es un control. Pregunta a qué puede llegar todavía un usuario denegado: ¿el wiki, el recurso compartido, el puerto de la base de datos? La remediación necesita una sola superficie estrecha, y todo lo demás va detrás del bloqueo.

Lee el informe antes de leer la regla

Empieza por la fuente en lugar de por la marca verde del cliente. En Windows la medición local viene de Defender o del producto que se haya registrado en Security Center, y ambas se leen sin consola del proveedor:

Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productState

El segundo comando devuelve un entero llamado productState. Sus bits están documentados de forma laxa y los proveedores empaquetan de forma distinta las banderas de activación y actualización, así que corrobóralo en vez de analizarlo. Los paquetes de terceros también dejan la entrada de Security Center tras la desinstalación, y esa informa sobre software que ya no está en el disco.

La edad es el campo que la gente se salta. Una marca de tiempo de firma solo significa algo frente al reloj de la máquina que hace la evaluación, así que conviértela en un intervalo en lugar de estimarla a ojo:

$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHours

Ahora la política tiene un número que leer. Si tu regla dice 72 horas, ese es el número que usa, y un portátil que duerme una semana falla sin que nadie interprete una etiqueta. Anota el umbral junto al comando, porque ambos se desalinean cuando se sustituye la herramienta del endpoint.

Convierte cada estado de dispositivo en un veredicto escrito

La mayoría de las disputas sobre el estado son en realidad disputas sobre la fila desconocida. Decídela antes del primer incidente, en una tabla que nombre la prueba, el veredicto y el propietario, para que nadie improvise en la consola de la puerta de enlace.

La fila inferior es donde los productos difieren. Algunas puertas de enlace rechazan la conexión y explican por qué; otras dejan subir el túnel y aplican una política restringida; unas pocas vuelven al último informe bueno conocido. Solo las dos primeras son defendibles, y merece la pena probar cuál hace la tuya.

Mantén la identidad y el permiso en sus propios carriles. Un portátil que pasa todas las pruebas de estado sigue necesitando la autorización humana correcta para la aplicación, y un certificado de dispositivo demuestra la posesión de una clave, no el estado del sistema de archivos. Colapsar los tres en un solo booleano es como una cuenta de asistencia acaba con acceso permanente a producción.

Comprueba la ruta de aplicación con una petición, no con un panel

La aplicación es una propiedad de una petición, así que mídela con una. Pon una máquina no conforme en el túnel y haz la llamada que haría un usuario real:

curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/health

Un 200 de un dispositivo que debería estar bloqueado significa que la decisión nunca llegó a la ruta de datos. Dos causas habituales: la política está ligada a un grupo al que la cuenta de prueba nunca se unió, o la aplicación es alcanzable por una ruta que el VPN no posee.

Comprueba primero la suposición de enrutamiento. Si el nombre interno se resuelve a una dirección a la que el cliente ya llega por la LAN local, el túnel es irrelevante y no se aplicará ninguna política. Compara esa dirección con la ruta que empuja la puerta de enlace. En OpenVPN la política por cliente vive en archivos con clave por nombre común, así que es fácil de inspeccionar:

ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17

Un archivo que contiene disable desconecta a ese cliente por completo, mientras que una línea push "route ..." estrecha lo que puede alcanzar. Ambos son aplicación, y ambos son visibles para quien depura el informe.

Prueba los cuatro casos en una sola cuenta de pruebas

La comprobación final es una matriz pequeña, no un camino feliz. Lleva una cuenta de prueba por cuatro estados: actual, firma caducada, protección desactivada, agente no instalado. Para cada uno, anota el veredicto en el registro de evaluación, el estado HTTP que devuelve la aplicación y si se cargó la página de remediación.

foreach ($case in 'current', 'stale', 'disabled', 'absent') {
  Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
  curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}

Dos detalles son fáciles de pasar por alto. Primero la repetición: un informe capturado mientras la máquina estaba sana no debe aceptarse para una sesión posterior en el mismo dispositivo, así que busca una marca de tiempo ligada a la conexión actual. Luego la retirada: desinstalar el agente debería producir la misma denegación que un informe caducado, no un paso limpio, y ese es el caso que más a menudo nunca se prueba.

Cuando la matriz coincida con la tabla, entrega tres elementos a quien gestione la puerta de enlace después: los comandos, el umbral y los cuatro resultados esperados. Ese traspaso es el entregable real, porque un diseño de estado que solo vive en un documento de política se desvía la primera vez que la herramienta del endpoint cambia su campo de informe.