La comprovació d’estat del VPN no bloqueja? Segueix primer l’informe
L’agent de l’extrem informa que tot està bé, però l’aplicació interna encara s’obre. Recorre el col·lector, el veredicte i el bloc, i després demostra el rebuig amb una petició.
Si un portàtil amb signatures antivirus que van deixar d’actualitzar-se fa setmanes encara pot obrir la vostra aplicació interna, poques vegades el document de política és el que està malament. Tres sistemes separats s’han de posar d’acord abans que es denegi l’accés: un mesura l’extrem, un altre converteix aquesta mesura en un veredicte de permetre o denegar, i un tercer descarta realment el trànsit. Quan un dispositiu no conforme hi entra de totes maneres, exactament un d’aquests enllaços falta o confia en proves que no hauria. Les comprovacions següents van en aquest ordre i cadascuna té un punt d’aturada.
El bloc és l’últim pas, no el primer
L’autenticació i l’estat del dispositiu responen preguntes diferents. Un inici de sessió correcte demostra que s’ha presentat una credencial; no diu res sobre el programari que s’executa a la màquina que l’ha presentada. Aquest buit és la raó per la qual un perfil de client copiat pot portar una sessió d’aspecte saludable a un amfitrió no saludable.
La feina de conformitat d’extrems ja té vocabulari per a aquesta cadena. El model de referència NEA de l’RFC 5209 divideix la tasca en un col·lector, un pas d’avaluació i un punt d’aplicació, i diu clarament que un client que menteix sobre el seu propi estat queda fora del model. Aquest advertiment importa més que el diagrama: un mòdul de plataforma fiable no converteix una mesura autodeclarada en un fet.
Manteniu el col·lector honest pel que fa a l’abast. Ha d’informar dels atributs que la vostra política nomena, al dispositiu que demana accés, i de poca cosa més. Un agent d’inventari que llista cada paquet instal·lat és una eina diferent d’un col·lector d’estat, i la diferència és alhora un problema de retenció i de precisió. Si l’informe no es pot lligar a una identitat de dispositiu, l’avaluador endevina quina màquina acaba d’aprovar.
Un tauler que mostra un estat vermell no és un control. Pregunteu a què pot arribar encara un usuari denegat: el wiki, el recurs compartit, el port de la base de dades? La remediació necessita una sola superfície estreta, i tota la resta va darrere del bloc.
Llegeix l’informe abans de llegir la regla
Comença per la font i no per la marca verda del client. A Windows, la mesura local ve del Defender o del producte que s’hagi registrat al Security Center, i tots dos es poden llegir sense consola del proveïdor:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateLa segona ordre retorna un enter anomenat productState. Els seus bits estan documentats de manera vaga i els proveïdors empaqueten de forma diferent les banderes d’activació i d’actualització, així que corroboreu-lo en lloc d’analitzar-lo. Les suites de tercers també deixen l’entrada del Security Center després de desinstal·lar-se, i aleshores informen sobre programari que ja no és al disc.
L’edat és el camp que la gent s’estalvia. Una marca de temps de signatura només significa alguna cosa respecte del rellotge de la màquina que fa l’avaluació, així que convertiu-la en un interval en lloc d’ullar-la:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursAra la política té un número per llegir. Si la vostra regla diu 72 hores, aquest és el número que fa servir, i un portàtil adormit una setmana falla sense que ningú interpreti una etiqueta. Anoteu el llindar al costat de l’ordre, perquè tots dos es desalineen quan es substitueix l’eina de l’extrem.
Converteix cada estat de dispositiu en un veredicte escrit
La majoria de disputes sobre l’estat són en realitat disputes sobre la fila desconeguda. Decideix-ho abans del primer incident, en una taula que nomena la prova, el veredicte i el propietari, perquè ningú improvisi a la consola de la passarel·la.
| 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 |
La fila de baix és on els productes difereixen. Algunes passarel·les refusen la connexió i expliquen per què; altres deixen aixecar el túnel i apliquen una política restringida; unes poques tornen a l’últim informe bo conegut. Només les dues primeres són defensables, i val la pena provar quina fa la vostra.
Manteniu la identitat i el permís en carrils propis. Un portàtil que passa totes les proves d’estat encara necessita l’autorització humana correcta per a l’aplicació, i un certificat de dispositiu demostra la possessió d’una clau, no l’estat del sistema de fitxers. Col·lapsar els tres en un sol booleà és com un compte d’assistència acaba amb accés permanent a producció.
Comprova el camí d’aplicació amb una petició, no amb un tauler
L’aplicació és una propietat d’una petició, així que mesureu-la amb una. Posa una màquina no conforme al túnel i fes la crida que faria un usuari real:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthUn 200 d’un dispositiu que hauria d’estar bloquejat vol dir que la decisió no va arribar mai al camí de dades. Dues causes habituals: la política està lligada a un grup al qual el compte de prova no es va unir mai, o l’aplicació és abastable per una ruta que el VPN no posseeix.
Comprova primer la suposició d’encaminament. Si el nom intern es resol a una adreça a què el client ja arriba per la LAN local, el túnel és irrellevant i no s’aplicarà cap política. Compareu aquesta adreça amb la ruta que empeny la passarel·la. A OpenVPN, la política per client viu en fitxers clauats pel nom comú, així que és fàcil d’inspeccionar:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17Un fitxer que conté disable desconnecta aquell client del tot, mentre que una línia push "route ..." estreny allò a què pot arribar. Tots dos són aplicació, i tots dos són visibles per a qui depura l’informe.
Prova els quatre casos en un sol compte de proves
La comprovació final és una matriu petita, no un camí feliç. Porta un compte de prova per quatre estats: actual, signatura caducada, protecció desactivada, agent no instal·lat. Per a cadascun, anota el veredicte al registre d’avaluació, l’estat HTTP que retorna l’aplicació i si es va carregar la pàgina de remediació.
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 detalls són fàcils de passar per alt. Primer la repetició: un informe capturat mentre la màquina era sana no s’ha d’acceptar per a una sessió posterior al mateix dispositiu, així que busqueu una marca de temps lligada a la connexió actual. Després la retirada: desinstal·lar l’agent hauria de produir la mateixa denegació que un informe caducat, no un pas net, i aquest és el cas que més sovint no es prova mai.
Quan la matriu coincideixi amb la taula, lliura tres elements a qui gestioni la passarel·la després: les ordres, el llindar i els quatre resultats esperats. Aquest lliurament és el resultat real, perquè un disseny d’estat que només viu en un document de política es desvia el primer cop que l’eina de l’extrem canvia el seu camp d’informació.