A comprobación de estado da VPN non bloquea? Segue primeiro o informe
O axente do endpoint informa dun estado san, pero a aplicación interna segue abríndose. Percorre o colector, o veredicto e o bloqueo, e despois demostra a denegación cunha soa petición.
Se un portátil cuxas sinaturas de antivirus deixaron de actualizarse hai semanas aínda pode abrir a túa aplicación interna, raramente o documento de política é o que está mal. Tres sistemas separados teñen que poñerse de acordo antes de que se denegue o acceso: algo mide o endpoint, algo converte esa medición nun veredicto de permitir ou denegar, e algo descarta realmente o tráfico. Cando un dispositivo non conforme entra de todos os xeitos, exactamente un deses elos falta ou confía en probas que non debería. As comprobacións seguintes van nesa orde, e cada unha ten un punto de parada.
O bloqueo é o último paso, non o primeiro
A autenticación e o estado do dispositivo responden preguntas distintas. Un inicio de sesión correcto demostra que se presentou unha credencial; non di nada sobre o software que se executa na máquina que a presentou. Ese oco é a razón pola que un perfil de cliente copiado pode levar unha sesión de aspecto san a un host non san.
O traballo de conformidade do endpoint xa ten vocabulario para esta cadea. O modelo de referencia NEA do RFC 5209 divide a tarefa nun colector, un paso de avaliación e un punto de aplicación, e di claramente que un cliente que mente sobre o seu propio estado queda fóra do modelo. Esa salvedade importa máis que o diagrama: un módulo de plataforma fiable non converte unha medición autoinformada nun feito.
Mantén honesto o colector en canto ao alcance. Debe informar dos atributos que nomea a túa política, no dispositivo que pide acceso, e de pouco máis. Un axente de inventario que lista cada paquete instalado é unha ferramenta distinta dun colector de estado, e a diferenza é á vez un problema de retención e de precisión. Se o informe non se pode atar a unha identidade de dispositivo, o avaliador adiviña que máquina acaba de autorizar.
Un panel que mostra un estado vermello non é un control. Pregunta a que pode chegar aínda un usuario denegado: o wiki, o recurso compartido, o porto da base de datos? A remediación necesita unha soa superficie estreita, e todo o demais vai detrás do bloqueo.
Le o informe antes de ler a regra
Comeza pola fonte en lugar da marca verde do cliente. En Windows a medición local vén de Defender ou do produto que se rexistrase en Security Center, e ambas se len sen consola do provedor:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateO segundo comando devolve un enteiro chamado productState. Os seus bits están documentados de forma laxa e os provedores empaquetan de xeito distinto as bandeiras de activación e actualización, así que corrobórao en vez de analizalo. Os paquetes de terceiros tamén deixan a entrada de Security Center tras a desinstalación, e esa informa sobre software que xa non está no disco.
A idade é o campo que a xente salta. Unha marca de tempo de sinatura só significa algo fronte ao reloxo da máquina que fai a avaliación, así que convértea nun intervalo en lugar de estimarlle a ollo:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursAgora a política ten un número que ler. Se a túa regra di 72 horas, ese é o número que usa, e un portátil que dorme unha semana falla sen que ninguén interprete unha etiqueta. Anota o limiar xunto ao comando, porque ambos se desalinean cando se substitúe a ferramenta do endpoint.
Converte cada estado de dispositivo nun veredicto escrito
A maioría das disputas sobre o estado son en realidade disputas sobre a fila descoñecida. Decídea antes do primeiro incidente, nunha táboa que nomea a proba, o veredicto e o propietario, para que ninguén improvise na consola da pasarela.
| Evidence the assessor has | Verdict | What it protects against |
|---|---|---|
| Timestamp inside the policy window, protective service running | Admit to normal applications | Nothing yet; the other checks still apply |
| Timestamp older than the window | Deny, admit remediation page only | Signature rollback and dormant laptops |
| Service disabled or reporting off | Deny, escalate to the endpoint owner | An agent reporting stale success |
| No report at all for this session | Treat as deny, never as healthy | Agents that fail open under load |
A fila inferior é onde os produtos difiren. Algunhas pasarelas rexeitan a conexión e explican por que; outras deixan subir o túnel e aplican unha política restrinxida; unhas poucas volven ao último informe bo coñecido. Só as dúas primeiras son defendibles, e paga a pena probar cal fai a túa.
Mantén a identidade e o permiso nos seus propios carrís. Un portátil que pasa todas as probas de estado segue necesitando a autorización humana correcta para a aplicación, e un certificado de dispositivo demostra a posesión dunha chave, non o estado do sistema de ficheiros. Colapsar os tres nun só booleano é como unha conta de asistencia acaba con acceso permanente a produción.
Comproba a ruta de aplicación cunha petición, non cun panel
A aplicación é unha propiedade dunha petición, así que mídaa cunha. Pon unha máquina non conforme no túnel e fai a chamada que faría un usuario real:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthUn 200 dun dispositivo que debería estar bloqueado significa que a decisión nunca chegou á ruta de datos. Dúas causas habituais: a política está ligada a un grupo ao que a conta de proba nunca se uniu, ou a aplicación é alcanzable por unha ruta que a VPN non posúe.
Comproba primeiro a suposición de encamiñamento. Se o nome interno se resolve nun enderezo ao que o cliente xa chega pola LAN local, o túnel é irrelevante e non se aplicará ningunha política. Compara ese enderezo coa ruta que empurra a pasarela. En OpenVPN a política por cliente vive en ficheiros con chave por nome común, así que é doado inspeccionala:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17Un ficheiro que contén disable desconecta ese cliente por completo, mentres que unha liña push "route ..." estreita o que pode alcanzar. Ambos son aplicación, e ambos son visibles para quen depura o informe.
Proba os catro casos nunha soa conta de proba
A comprobación final é unha matriz pequena, non un camiño feliz. Leva unha conta de proba por catro estados: actual, sinatura caducada, protección desactivada, axente non instalado. Para cada un, anota o veredicto no rexistro de avaliación, o estado HTTP que devolve a aplicación e se se cargou a páxina 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
}Dous detalles son fáciles de pasar por alto. Primeiro a repetición: un informe capturado mentres a máquina estaba san non debe aceptarse para unha sesión posterior no mesmo dispositivo, así que busca unha marca de tempo ligada á conexión actual. Logo a retirada: desinstalar o axente debería producir a mesma denegación que un informe caducado, non un paso limpo, e ese é o caso que máis a miúdo nunca se proba.
Cando a matriz coincida coa táboa, entrega tres elementos a quen xestione a pasarela despois: os comandos, o limiar e os catro resultados esperados. Esa entrega é o entregable real, porque un deseño de estado que só vive nun documento de política desvía a primeira vez que a ferramenta do endpoint cambia o seu campo de informe.