VPN ਡਿਵਾਈਸ ਸਥਿਤੀ ਜਾਂਚ ਨਹੀਂ ਰੋਕ ਰਹੀ? ਪਹਿਲਾਂ ਰਿਪੋਰਟ ਵੇਖੋ
ਤੁਹਾਡਾ ਐਂਡਪੌਇੰਟ ਏਜੰਟ ਸਿਹਤਮੰਦ ਸਥਿਤੀ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਪਰ ਅੰਦਰੂਨੀ ਐਪ ਅਜੇ ਵੀ ਖੁੱਲ੍ਹਦੀ ਹੈ। ਸੰਗ੍ਰਾਹਕ, ਫ਼ੈਸਲਾ ਅਤੇ ਰੋਕ ਤੋਂ ਲੰਘੋ, ਫਿਰ ਇੱਕ ਬੇਨਤੀ ਨਾਲ ਇਨਕਾਰ ਸਾਬਤ ਕਰੋ।
ਜੇ ਹਫ਼ਤੇ ਪਹਿਲਾਂ ਐਂਟੀਵਾਇਰਸ ਦਸਤਖ਼ਤਾਂ ਦਾ ਅਪਡੇਟ ਹੋਣਾ ਬੰਦ ਹੋ ਚੁੱਕੇ ਲੈਪਟਾਪ ਅਜੇ ਵੀ ਤੁਹਾਡੀ ਅੰਦਰੂਨੀ ਐਪ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ, ਤਾਂ ਨੀਤੀ ਦਸਤਾਵੇਜ਼ ਹੀ ਗਲਤ ਚੀਜ਼ ਹੁੰਦਾ ਹੈ, ਇਹ ਘੱਟ ਹੀ ਹੁੰਦਾ ਹੈ। ਪਹੁੰਚ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਵੱਖਰੇ ਸਿਸਟਮਾਂ ਨੂੰ ਸਹਿਮਤ ਹੋਣਾ ਪੈਂਦਾ ਹੈ: ਕੋਈ ਚੀਜ਼ ਐਂਡਪੌਇੰਟ ਨੂੰ ਮਾਪਦੀ ਹੈ, ਕੋਈ ਚੀਜ਼ ਉਸ ਮਾਪ ਨੂੰ ਮਨਜ਼ੂਰੀ ਜਾਂ ਇਨਕਾਰ ਦਾ ਫ਼ੈਸਲਾ ਬਣਾਉਂਦੀ ਹੈ, ਅਤੇ ਕੋਈ ਚੀਜ਼ ਅਸਲ ਵਿੱਚ ਟ੍ਰੈਫ਼ਿਕ ਸੁੱਟ ਦਿੰਦੀ ਹੈ। ਜਦੋਂ ਗੈਰ-ਅਨੁਕੂਲ ਡਿਵਾਈਸ ਫਿਰ ਵੀ ਅੰਦਰ ਆ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਠੀਕ ਇੱਕ ਕੜੀ ਗ਼ੈਰਹਾਜ਼ਰ ਹੁੰਦੀ ਹੈ ਜਾਂ ਅਜਿਹੇ ਸਬੂਤ ’ਤੇ ਭਰੋਸਾ ਕਰਦੀ ਹੈ ਜੋ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਹੇਠਾਂ ਦੀਆਂ ਜਾਂਚਾਂ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਚੱਲਦੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਇੱਕ ਰੁਕਣ ਦਾ ਬਿੰਦੂ ਹੈ।
ਰੋਕ ਆਖ਼ਰੀ ਕਦਮ ਹੈ, ਪਹਿਲਾ ਨਹੀਂ
ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਡਿਵਾਈਸ ਦੀ ਸਥਿਤੀ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਸਫਲ ਲੌਗਇਨ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਕੋਈ ਪ੍ਰਮਾਣ ਪੱਤਰ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ; ਇਹ ਉਸ ਮਸ਼ੀਨ ’ਤੇ ਚੱਲ ਰਹੇ ਸੌਫਟਵੇਅਰ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਜਿਸਨੇ ਉਹ ਪੇਸ਼ ਕੀਤਾ। ਇਸੇ ਖੱਪ ਨੇ ਹੀ ਨਕਲ ਕੀਤੀ ਕਲਾਇੰਟ ਪ੍ਰੋਫ਼ਾਈਲ ਨੂੰ ਸਿਹਤਮੰਦ ਦਿਖਣ ਵਾਲਾ ਸੈਸ਼ਨ ਅਸਿਹਤਮੰਦ ਹੋਸਟ ’ਤੇ ਲੈ ਜਾਣ ਦੀ ਆਗਿਆ ਦਿੱਤੀ ਹੈ।
ਐਂਡਪੌਇੰਟ ਅਨੁਕੂਲਤਾ ਦੇ ਕੰਮ ਕੋਲ ਇਸ ਲੜੀ ਲਈ ਸ਼ਬਦਾਵਲੀ ਪਹਿਲਾਂ ਹੀ ਹੈ। RFC 5209 ਵਿੱਚਲਾ NEA ਸੰਦਰਭ ਮਾਡਲ ਕੰਮ ਨੂੰ ਸੰਗ੍ਰਾਹਕ, ਮੁਲਾਂਕਣ ਕਦਮ ਅਤੇ ਲਾਗੂਕਰਨ ਬਿੰਦੂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ, ਅਤੇ ਸਾਫ਼ ਕਹਿੰਦਾ ਹੈ ਕਿ ਆਪਣੀ ਸਥਿਤੀ ਬਾਰੇ ਝੂਠ ਬੋਲਣ ਵਾਲਾ ਕਲਾਇੰਟ ਮਾਡਲ ਤੋਂ ਬਾਹਰ ਹੈ। ਇਹ ਚੇਤਾਵਨੀ ਚਿੱਤਰ ਨਾਲੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਭਰੋਸੇਯੋਗ ਪਲੇਟਫ਼ਾਰਮ ਮੌਡਿਊਲ ਆਪਣੇ ਆਪ ਦੱਸੇ ਮਾਪ ਨੂੰ ਤੱਥ ਨਹੀਂ ਬਣਾ ਦਿੰਦਾ।
ਸੰਗ੍ਰਾਹਕ ਨੂੰ ਦਾਇਰੇ ਬਾਰੇ ਇਮਾਨਦਾਰ ਰੱਖੋ। ਇਹ ਤੁਹਾਡੀ ਨੀਤੀ ਵਿੱਚ ਨਾਮਿਤ ਗੁਣ ਪਹੁੰਚ ਮੰਗਣ ਵਾਲੀ ਡਿਵਾਈਸ ’ਤੇ ਦੱਸਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਬਹੁਤ ਘੱਟ ਹੋਰ ਕੁਝ। ਹਰ ਇੰਸਟਾਲ ਪੈਕੇਜ ਦੀ ਸੂਚੀ ਬਣਾਉਣ ਵਾਲਾ ਇਨਵੈਂਟਰੀ ਏਜੰਟ ਸਥਿਤੀ ਸੰਗ੍ਰਾਹਕ ਤੋਂ ਵੱਖਰਾ ਸੰਦ ਹੈ, ਅਤੇ ਇਹ ਫ਼ਰਕ ਇੱਕੋ ਸਮੇਂ ਸੰਭਾਲ ਅਤੇ ਸ਼ੁੱਧਤਾ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਜੇ ਰਿਪੋਰਟ ਨੂੰ ਇੱਕ ਡਿਵਾਈਸ ਪਛਾਣ ਨਾਲ ਬੰਨ੍ਹਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ, ਤਾਂ ਮੁਲਾਂਕਣਕਰਤਾ ਅੰਦਾਜ਼ਾ ਲਾ ਰਿਹਾ ਹੈ ਕਿ ਉਸਨੇ ਹੁਣੇ ਕਿਹੜੀ ਮਸ਼ੀਨ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ।
ਲਾਲ ਸਥਿਤੀ ਦਿਖਾਉਣ ਵਾਲਾ ਡੈਸ਼ਬੋਰਡ ਨਿਯੰਤਰਣ ਨਹੀਂ ਹੈ। ਪੁੱਛੋ ਕਿ ਇਨਕਾਰ ਕੀਤਾ ਵਰਤੋਂਕਾਰ ਅਜੇ ਕਿੱਥੇ ਪਹੁੰਚ ਸਕਦਾ ਹੈ: ਵਿਕੀ, ਫ਼ਾਈਲ ਸ਼ੇਅਰ, ਡੇਟਾਬੇਸ ਪੋਰਟ? ਸੁਧਾਰ ਲਈ ਇੱਕ ਤੰਗ ਸਤ੍ਹਾ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਬਾਕੀ ਸਭ ਰੋਕ ਦੇ ਪਿੱਛੇ ਹੈ।
ਨਿਯਮ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਰਿਪੋਰਟ ਪੜ੍ਹੋ
ਕਲਾਇੰਟ ਦੇ ਹਰੇ ਟਿੱਕ ਤੋਂ ਨਹੀਂ, ਸਰੋਤ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। Windows ਵਿੱਚ ਸਥਾਨਕ ਮਾਪ Defender ਤੋਂ ਜਾਂ ਉਸ ਉਤਪਾਦ ਤੋਂ ਆਉਂਦਾ ਹੈ ਜਿਸਨੇ ਆਪਣੇ ਆਪ ਨੂੰ Security Center ਵਿੱਚ ਰਜਿਸਟਰ ਕੀਤਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਵਿਕਰੇਤਾ ਕਨਸੋਲ ਤੋਂ ਬਿਨਾਂ ਪੜ੍ਹੇ ਜਾ ਸਕਦੇ ਹਨ:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productState
ਦੂਜਾ ਹੁਕਮ productState ਨਾਮਕ ਪੂਰਨ ਅੰਕ ਦਿੰਦਾ ਹੈ। ਇਸਦੇ ਬਿੱਟ ਢਿੱਲੇ ਤੌਰ ’ਤੇ ਦਰਜ ਹਨ ਅਤੇ ਵਿਕਰੇਤਾ ਸਮਰੱਥਾ ਤੇ ਤਾਜ਼ਗੀ ਦੇ ਝੰਡੇ ਵੱਖਰੇ ਤਰੀਕਿਆਂ ਨਾਲ ਪੈਕ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੀ ਥਾਂ ਪੁਸ਼ਟੀ ਕਰੋ। ਤੀਜੀ ਧਿਰ ਦੇ ਸੂਟ ਅਣਇੰਸਟਾਲ ਤੋਂ ਬਾਅਦ ਵੀ Security Center ਐਂਟਰੀ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਉਹ ਹੁਣ ਡਿਸਕ ’ਤੇ ਨਾ ਰਹੇ ਸੌਫਟਵੇਅਰ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ।
ਲੋਕ ਜਿਸ ਖੇਤਰ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਨ ਉਹ ਉਮਰ ਹੈ। ਦਸਤਖ਼ਤ ਦੀ ਸਮਾਂ-ਮੋਹਰ ਮੁਲਾਂਕਣ ਕਰਨ ਵਾਲੀ ਮਸ਼ੀਨ ਦੀ ਘੜੀ ਦੇ ਮੁਕਾਬਲੇ ਹੀ ਅਰਥ ਰੱਖਦੀ ਹੈ, ਇਸ ਲਈ ਅੱਖੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਇਸਨੂੰ ਅੰਤਰਾਲ ਵਿੱਚ ਬਦਲੋ:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHours
ਹੁਣ ਨੀਤੀ ਕੋਲ ਪੜ੍ਹਨ ਲਈ ਇੱਕ ਸੰਖਿਆ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਨਿਯਮ 72 ਘੰਟੇ ਕਹਿੰਦਾ ਹੈ, ਤਾਂ ਉਹੀ ਸੰਖਿਆ ਇਹ ਵਰਤਦੀ ਹੈ, ਅਤੇ ਹਫ਼ਤਾ ਸੁੱਤਾ ਲੈਪਟਾਪ ਕਿਸੇ ਦੇ ਲੇਬਲ ਦੀ ਵਿਆਖਿਆ ਕੀਤੇ ਬਿਨਾਂ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ। ਹੁਕਮ ਦੇ ਕੋਲ ਥ੍ਰੈਸ਼ਹੋਲਡ ਲਿਖੋ, ਕਿਉਂਕਿ ਐਂਡਪੌਇੰਟ ਸੰਦ ਬਦਲਣ ’ਤੇ ਦੋਵੇਂ ਦੂਰ ਹੋ ਜਾਂਦੇ ਹਨ।
ਹਰ ਡਿਵਾਈਸ ਸਥਿਤੀ ਨੂੰ ਲਿਖਤੀ ਫ਼ੈਸਲੇ ਵਿੱਚ ਬਦਲੋ
ਸਥਿਤੀ ਬਾਰੇ ਬਹੁਤੇ ਝਗੜੇ ਅਸਲ ਵਿੱਚ ਅਣਜਾਣ ਕਤਾਰ ਬਾਰੇ ਝਗੜੇ ਹੁੰਦੇ ਹਨ। ਪਹਿਲੀ ਘਟਨਾ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਇਹ ਤੈਅ ਕਰੋ, ਅਜਿਹੀ ਸਾਰਣੀ ਵਿੱਚ ਜੋ ਸਬੂਤ, ਫ਼ੈਸਲਾ ਅਤੇ ਮਾਲਕ ਦਾ ਨਾਮ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਜੋ ਕੋਈ ਵੀ ਗੇਟਵੇ ਕਨਸੋਲ ’ਤੇ ਤੁਰੰਤ ਕੁਝ ਨਾ ਘੜੇ।
| 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 |
ਉਤਪਾਦ ਹੇਠਲੀ ਕਤਾਰ ਵਿੱਚ ਹੀ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਕੁਝ ਗੇਟਵੇ ਕਨੈਕਸ਼ਨ ਤੋਂ ਇਨਕਾਰ ਕਰਦੇ ਹਨ ਅਤੇ ਕਾਰਨ ਦੱਸਦੇ ਹਨ; ਹੋਰ ਟਨਲ ਨੂੰ ਉੱਪਰ ਆਉਣ ਦੇ ਕੇ ਸੀਮਤ ਨੀਤੀ ਲਾਗੂ ਕਰਦੇ ਹਨ; ਕੁਝ ਗਿਣੇ-ਚੁਣੇ ਆਖ਼ਰੀ ਜਾਣੀ ਜਾਂਦੀ ਚੰਗੀ ਰਿਪੋਰਟ ’ਤੇ ਵਾਪਸ ਜਾਂਦੇ ਹਨ। ਸਿਰਫ਼ ਪਹਿਲੇ ਦੋ ਹੀ ਜਾਇਜ਼ ਹਨ, ਅਤੇ ਇਹ ਪਰਖਣਾ ਲਾਹੇਵੰਦ ਹੈ ਕਿ ਤੁਹਾਡਾ ਕਿਹੜਾ ਕਰਦਾ ਹੈ।
ਪਛਾਣ ਅਤੇ ਇਜਾਜ਼ਤ ਨੂੰ ਵੀ ਆਪਣੀਆਂ ਲੇਨਾਂ ਵਿੱਚ ਰੱਖੋ। ਹਰ ਸਥਿਤੀ ਪਰਖ ਪਾਸ ਕਰਨ ਵਾਲੇ ਲੈਪਟਾਪ ਨੂੰ ਐਪ ਲਈ ਢੁੱਕਵਾਂ ਮਨੁੱਖੀ ਅਧਿਕਾਰ ਅਜੇ ਵੀ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਡਿਵਾਈਸ ਸਰਟੀਫ਼ਿਕੇਟ ਕੁੰਜੀ ਦੇ ਕਬਜ਼ੇ ਨੂੰ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਫ਼ਾਈਲ ਸਿਸਟਮ ਦੀ ਸਥਿਤੀ ਨੂੰ ਨਹੀਂ। ਤਿੰਨੇ ਨੂੰ ਇੱਕ ਬੂਲੀਅਨ ਵਿੱਚ ਨਿਚੋੜਨਾ ਉਹੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਹੈਲਪਡੈਸਕ ਖਾਤੇ ਨੂੰ ਉਤਪਾਦਨ ਤੱਕ ਪੱਕੀ ਪਹੁੰਚ ਮਿਲ ਜਾਂਦੀ ਹੈ।
ਲਾਗੂਕਰਨ ਦਾ ਰਾਹ ਡੈਸ਼ਬੋਰਡ ਨਾਲ ਨਹੀਂ, ਬੇਨਤੀ ਨਾਲ ਪਰਖੋ
ਲਾਗੂਕਰਨ ਬੇਨਤੀ ਦਾ ਗੁਣ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਇੱਕ ਬੇਨਤੀ ਨਾਲ ਮਾਪੋ। ਗੈਰ-ਅਨੁਕੂਲ ਮਸ਼ੀਨ ਨੂੰ ਟਨਲ ’ਤੇ ਰੱਖੋ ਅਤੇ ਉਹ ਕਾਲ ਕਰੋ ਜੋ ਅਸਲ ਵਰਤੋਂਕਾਰ ਕਰਦਾ:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/health
ਜਿਸ ਡਿਵਾਈਸ ਨੂੰ ਰੋਕਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਉਸ ਤੋਂ 200 ਆਉਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਫ਼ੈਸਲਾ ਕਦੇ ਡੇਟਾ ਰਾਹ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ। ਦੋ ਆਮ ਕਾਰਨ: ਨੀਤੀ ਉਸ ਗਰੁੱਪ ਨਾਲ ਜੁੜੀ ਹੈ ਜਿਸ ਵਿੱਚ ਪਰਖ ਖਾਤਾ ਕਦੇ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋਇਆ, ਜਾਂ ਐਪ ਉਸ ਰੂਟ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੈ ਜਿਸਦਾ VPN ਮਾਲਕ ਨਹੀਂ।
ਪਹਿਲਾਂ ਰੂਟਿੰਗ ਦਾ ਅਨੁਮਾਨ ਪਰਖੋ। ਜੇ ਅੰਦਰੂਨੀ ਨਾਮ ਉਸ ਪਤੇ ’ਤੇ ਹੱਲ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ ਕਲਾਇੰਟ ਸਥਾਨਕ LAN ਰਾਹੀਂ ਪਹਿਲਾਂ ਹੀ ਪਹੁੰਚਦਾ ਹੈ, ਤਾਂ ਟਨਲ ਅਪ੍ਰਸੰਗਿਕ ਹੈ ਅਤੇ ਕੋਈ ਨੀਤੀ ਲਾਗੂ ਨਹੀਂ ਹੋਵੇਗੀ। ਉਸ ਪਤੇ ਦੀ ਤੁਲਨਾ ਗੇਟਵੇ ਵੱਲੋਂ ਧੱਕੇ ਜਾਂਦੇ ਰੂਟ ਨਾਲ ਕਰੋ। OpenVPN ’ਤੇ ਹਰ ਕਲਾਇੰਟ ਦੀ ਨੀਤੀ ਆਮ ਨਾਮ ਨਾਲ ਕੁੰਜੀਬੱਧ ਫ਼ਾਈਲਾਂ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਵੇਖਣਾ ਸੌਖਾ ਹੈ:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17
disable ਵਾਲੀ ਫ਼ਾਈਲ ਉਸ ਕਲਾਇੰਟ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੱਟ ਦਿੰਦੀ ਹੈ, ਜਦਕਿ push "route ..." ਲਾਈਨ ਉਹ ਤੰਗ ਕਰਦੀ ਹੈ ਜਿੱਥੇ ਉਹ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਦੋਵੇਂ ਲਾਗੂਕਰਨ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਰਿਪੋਰਟ ਡੀਬੱਗ ਕਰਨ ਵਾਲੇ ਨੂੰ ਦਿਸਦੇ ਹਨ।
ਇੱਕ ਹੀ ਪਰਖ ਖਾਤੇ ’ਤੇ ਚਾਰੇ ਕੇਸ ਪਰਖੋ
ਆਖ਼ਰੀ ਜਾਂਚ ਛੋਟੀ ਮੈਟ੍ਰਿਕਸ ਹੈ, ਸੁਖਦ ਰਾਹ ਨਹੀਂ। ਇੱਕ ਪਰਖ ਖਾਤੇ ਨੂੰ ਚਾਰ ਸਥਿਤੀਆਂ ਵਿੱਚੋਂ ਲੰਘਾਓ: ਮੌਜੂਦਾ, ਸਮਾਂ ਲੰਘਿਆ ਦਸਤਖ਼ਤ, ਸੁਰੱਖਿਆ ਬੰਦ, ਏਜੰਟ ਸਥਾਪਿਤ ਨਹੀਂ। ਹਰ ਇੱਕ ਲਈ, ਮੁਲਾਂਕਣ ਲੌਗ ਵਿੱਚ ਫ਼ੈਸਲਾ, ਐਪ ਵੱਲੋਂ ਦਿੱਤੀ HTTP ਸਥਿਤੀ, ਅਤੇ ਸੁਧਾਰ ਪੰਨਾ ਲੋਡ ਹੋਇਆ ਕਿ ਨਹੀਂ, ਦਰਜ ਕਰੋ।
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
}
ਦੋ ਵੇਰਵੇ ਖੁੰਝ ਜਾਣੇ ਸੌਖੇ ਹਨ। ਪਹਿਲਾਂ ਮੁੜ-ਪ੍ਰਸਾਰਣ: ਮਸ਼ੀਨ ਦੇ ਸਿਹਤਮੰਦ ਹੁੰਦੇ ਸਮੇਂ ਲਈ ਗਈ ਰਿਪੋਰਟ ਨੂੰ ਉਸੇ ਡਿਵਾਈਸ ’ਤੇ ਬਾਅਦ ਦੇ ਸੈਸ਼ਨ ਲਈ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਇਸ ਲਈ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨ ਨਾਲ ਬੱਝੀ ਸਮਾਂ-ਮੋਹਰ ਲੱਭੋ। ਫਿਰ ਹਟਾਉਣਾ: ਏਜੰਟ ਅਣਇੰਸਟਾਲ ਕਰਨ ’ਤੇ ਪੁਰਾਣੀ ਰਿਪੋਰਟ ਵਰਗਾ ਹੀ ਇਨਕਾਰ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਾਫ਼ ਪਾਸ ਨਹੀਂ, ਅਤੇ ਇਹੀ ਕੇਸ ਸਭ ਤੋਂ ਵੱਧ ਕਦੇ ਪਰਖਿਆ ਨਹੀਂ ਜਾਂਦਾ।
ਜਦੋਂ ਮੈਟ੍ਰਿਕਸ ਸਾਰਣੀ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਤਾਂ ਅੱਗੇ ਗੇਟਵੇ ਚਲਾਉਣ ਵਾਲੇ ਨੂੰ ਤਿੰਨ ਚੀਜ਼ਾਂ ਸੌਂਪੋ: ਹੁਕਮ, ਥ੍ਰੈਸ਼ਹੋਲਡ ਅਤੇ ਉਮੀਦ ਕੀਤੇ ਚਾਰ ਨਤੀਜੇ। ਇਹੀ ਸੌਂਪਣਾ ਅਸਲ ਡਿਲਿਵਰੇਬਲ ਹੈ, ਕਿਉਂਕਿ ਸਿਰਫ਼ ਨੀਤੀ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਜੀਊਂਦੀ ਸਥਿਤੀ-ਰਚਨਾ ਐਂਡਪੌਇੰਟ ਸੰਦ ਦੇ ਰਿਪੋਰਟਿੰਗ ਖੇਤਰ ਬਦਲਣ ’ਤੇ ਪਹਿਲੀ ਵਾਰ ਭਟਕ ਜਾਂਦੀ ਹੈ।